1 2017-07-20 00:06:16 0|bitcoin-git|[13bitcoin] 15promag opened pull request #10885: Prevent duplicate wallets (06master...062017-07-prevent-duplicate-wallets) 02https://github.com/bitcoin/bitcoin/pull/10885
2 2017-07-20 00:09:18 0|promag|sipa: there you go
3 2017-07-20 00:29:13 0|Chris_Stewart_5|The CScript constructor in the python testing framework will add push ops for constants right? Or do I need to add them manually
4 2017-07-20 00:51:30 0|Chris_Stewart_5|nvm, dynamic typing got me..
5 2017-07-20 01:33:27 0|bitcoin-git|[13bitcoin] 15MeshCollider opened pull request #10886: Remove unused #define in sync.h (06master...06remove-unused-define) 02https://github.com/bitcoin/bitcoin/pull/10886
6 2017-07-20 01:33:47 0|bitcoin-git|[13bitcoin] 15MeshCollider closed pull request #10886: Remove unused #define in sync.h (06master...06remove-unused-define) 02https://github.com/bitcoin/bitcoin/pull/10886
7 2017-07-20 07:03:44 0|wumpus|a user on transifex is misbehaving (vandalizing the German translations), anyone have experience with how to handle this? I don't see any ban controls etc in their interface
8 2017-07-20 07:09:30 0|jonasschnelli|hmm...can we revert his changes?
9 2017-07-20 07:09:33 0|wumpus|e.g. nearly all of these are nonsense https://www.transifex.com/bitcoin/bitcoin/translate/#de/$/104570304?user=pehotinec, sometimes he copies slightly similar messages to make it look ok, sometimes he just copies the English message, in any cast this seems deliberate
10 2017-07-20 07:11:14 0|jonasschnelli|I'll write transiflex support to ban that user
11 2017-07-20 07:11:27 0|wumpus|thank you
12 2017-07-20 07:11:41 0|jonasschnelli|But is there a way to revert all his changes?
13 2017-07-20 07:12:54 0|wumpus|not in one go - there's a revert button on messages, but usually it seems to be disabled; I think that means these messages have no previous translation, it's only noticed now
14 2017-07-20 07:13:27 0|jonasschnelli|Okay. I'll check the german part (and eventually write in the correct transaltion)
15 2017-07-20 07:13:29 0|wumpus|they should be reveted back to untranslated
16 2017-07-20 07:13:36 0|wumpus|yes, or that
17 2017-07-20 07:14:24 0|Victorsueca|I don't know a way to block a user from a project that doesn't go through making people request to join the translation team
18 2017-07-20 07:15:02 0|jonasschnelli|wumpus: do we also need to take care of <0.15 translations (do these get pulled again?)?
19 2017-07-20 07:15:36 0|wumpus|only 0.14, the others are closed. Those get pulled again when there is a minor release.
20 2017-07-20 07:18:45 0|jonasschnelli|wumpus: although users pehotinec did also correct translations...
21 2017-07-20 07:19:33 0|wumpus|there are a few that seem to be correct, some look very convincing but seem copies of related messages, and others are complete nonsense
22 2017-07-20 07:20:28 0|wumpus|it's quite sneaky which is why it took months to discover, unlike if he just wrote 'poop' everywhere. seone has sent him a message asking about his motivation but I have the feeling he's not going to respond normally to that
23 2017-07-20 07:21:09 0|jonasschnelli|Yes. I guess he filled in english translations into the missing german ones
24 2017-07-20 07:23:23 0|wumpus|he also has some english to english messages in de_DE https://www.transifex.com/bitcoin/bitcoin/translate/#de_DE/$/65093519?user=pehotinec
25 2017-07-20 08:36:08 0|bitcoin-git|13bitcoin/06master 142264236 15Alex Morcos: Rename -usewallet to -rpcwallet
26 2017-07-20 08:36:08 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/df0793f324e3...bf3b742e2852
27 2017-07-20 08:36:09 0|bitcoin-git|13bitcoin/06master 14bf3b742 15Wladimir J. van der Laan: Merge #10883: Rename -usewallet to -rpcwallet...
28 2017-07-20 08:36:42 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10883: Rename -usewallet to -rpcwallet (06master...06rpcwallet) 02https://github.com/bitcoin/bitcoin/pull/10883
29 2017-07-20 09:45:04 0|bitcoin-git|[13bitcoin] 15benma opened pull request #10888: range-based loops and const qualifications in net.cpp (06master...06netcpp_cosmetics2) 02https://github.com/bitcoin/bitcoin/pull/10888
30 2017-07-20 14:11:38 0|bitcoin-git|[13bitcoin] 15jnewbery closed pull request #10868: Remove -usewallet (06master...06remove_use_wallet) 02https://github.com/bitcoin/bitcoin/pull/10868
31 2017-07-20 14:43:02 0|bitcoin-git|13bitcoin/06master 146b4f231 15Andrew Chow: Move transaction combining from signrawtransaction to new RPC...
32 2017-07-20 14:43:02 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/bf3b742e2852...adf170daf90f
33 2017-07-20 14:43:03 0|bitcoin-git|13bitcoin/06master 14adf170d 15Wladimir J. van der Laan: Merge #10571: [RPC]Move transaction combining from signrawtransaction to new RPC...
34 2017-07-20 14:43:23 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10571: [RPC]Move transaction combining from signrawtransaction to new RPC (06master...06combineraw-rpc) 02https://github.com/bitcoin/bitcoin/pull/10571
35 2017-07-20 14:57:37 0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/adf170daf90f...fd2814ef1182
36 2017-07-20 14:57:38 0|bitcoin-git|13bitcoin/06master 1435aff43 15practicalswift: Remove unused variable int64_t nEnd...
37 2017-07-20 14:57:38 0|bitcoin-git|13bitcoin/06master 145a6671c 15practicalswift: Fix typo: "conditon" ââ â "condition"...
38 2017-07-20 14:57:39 0|bitcoin-git|13bitcoin/06master 14fd2814e 15Wladimir J. van der Laan: Merge #10862: Remove unused variable int64_t nEnd. Fix typo: "conditon" ââ â "condition"....
39 2017-07-20 14:58:12 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10862: Remove unused variable int64_t nEnd. Fix typo: "conditon" ââ â "condition". (06master...06nEnd) 02https://github.com/bitcoin/bitcoin/pull/10862
40 2017-07-20 15:02:52 0|bitcoin-git|13bitcoin/06master 14999ef20 15Gregory Sanders: importmulti options are optional
41 2017-07-20 15:02:52 0|bitcoin-git|13bitcoin/06master 14a70d025 15Gregory Sanders: fixup some rpc param counting for rpc help
42 2017-07-20 15:02:52 0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/fd2814ef1182...041dad94b047
43 2017-07-20 15:02:53 0|bitcoin-git|13bitcoin/06master 144dc1915 15Gregory Sanders: check for null values in rpc args and handle appropriately
44 2017-07-20 15:03:13 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10783: [RPC] Various rpc argument fixes (06master...06rpcargfixes) 02https://github.com/bitcoin/bitcoin/pull/10783
45 2017-07-20 15:31:11 0|jnewbery|sipa gmaxwell: you were asking for #10882 . It should be review-ready now.
46 2017-07-20 15:31:13 0|gribble|https://github.com/bitcoin/bitcoin/issues/10882 | [WIP] Keypool topup by jnewbery ÷ Pull Request #10882 ÷ bitcoin/bitcoin ÷ GitHub
47 2017-07-20 15:32:46 0|sipa|jnewbery: thanks!
48 2017-07-20 15:35:37 0|bitcoin-git|13bitcoin/06master 14d9d1bd3 15romanornr: nCheckDepth chain height fix
49 2017-07-20 15:35:37 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/041dad94b047...7c2400cb8ab7
50 2017-07-20 15:35:38 0|bitcoin-git|13bitcoin/06master 147c2400c 15Wladimir J. van der Laan: Merge #10775: nCheckDepth chain height fix...
51 2017-07-20 15:36:02 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10775: nCheckDepth chain height fix (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/10775
52 2017-07-20 15:39:26 0|instagibbs|jnewbery, could you squash?
53 2017-07-20 15:40:09 0|jnewbery|sure - I'll do that now
54 2017-07-20 15:40:23 0|instagibbs|\o/
55 2017-07-20 18:00:41 0|sipa|meeting?
56 2017-07-20 18:00:53 0|instagibbs|in an hour?
57 2017-07-20 18:00:53 0|sipa|oops, in an hour
58 2017-07-20 18:01:01 0|instagibbs|:) thanks for reminder though, completely forgot
59 2017-07-20 18:02:06 0|sipa|yes, i didn't actually think it was meeting time, just wanted to give a veiled reminder </yeahright>
60 2017-07-20 18:02:20 0|instagibbs|so humble
61 2017-07-20 18:08:04 0|gmaxwell|do we have a editable web doc for release notes again?
62 2017-07-20 18:08:51 0|sipa|unsure
63 2017-07-20 18:12:19 0|jonasschnelli|wumpus: https://github.com/bitcoin/bitcoin/pull/10870#discussion_r128546723, .. what do you think about not doing the URL encode
64 2017-07-20 18:12:42 0|jonasschnelli|The allowed wallet characters would not require an urlencode...
65 2017-07-20 18:12:44 0|wumpus|jonasschnelli: well you do an URL decode at the other side, so I think that'd potentially result in problems
66 2017-07-20 18:13:09 0|jonasschnelli|wumpus: look at SAFE_CHARS_FILENAME
67 2017-07-20 18:13:12 0|wumpus|better to keep it symmetrical just in case, even if not strictly needed for what we see now
68 2017-07-20 18:13:38 0|jonasschnelli|I though because its a temp fix and the URI encode/decode (atm) do nothing-.
69 2017-07-20 18:13:49 0|sipa|it may do something later
70 2017-07-20 18:13:54 0|sipa|i don't think it hurts to have it
71 2017-07-20 18:13:55 0|wumpus|I have some terrible experiences with escaping if not very carefully taking care of on both sides
72 2017-07-20 18:14:06 0|jonasschnelli|Yes. Okay. Then lets keep it.
73 2017-07-20 18:14:24 0|jonasschnelli|https://github.com/bitcoin/bitcoin/pull/10870#discussion_r128546723 must be removed (replaced) once 0.15 is fixed.
74 2017-07-20 18:17:32 0|jonasschnelli|whats the long term solution for wallet arguments like -usehd in conjunction with multiwallet?
75 2017-07-20 18:17:47 0|jonasschnelli|A createwallet RPC?
76 2017-07-20 18:18:45 0|sipa|i think so
77 2017-07-20 18:18:46 0|wumpus|yes - dynamically loading/unloading and creating wallets should be possible at some point
78 2017-07-20 18:19:53 0|jonasschnelli|but if you would create a wallet, would it be automatically loaded next start? (== have wallet>s<.dat file somewhere that keeps track of wallets to load)?
79 2017-07-20 18:20:08 0|wumpus|I don't thikn so
80 2017-07-20 18:20:24 0|jonasschnelli|Assume you use Qt and create a wallet.
81 2017-07-20 18:20:35 0|jonasschnelli|You don't want to add a -wallet= to your config file
82 2017-07-20 18:20:39 0|jonasschnelli|But Qt may be different
83 2017-07-20 18:20:44 0|jonasschnelli|(QSettings)
84 2017-07-20 18:20:48 0|wumpus|well, just add a menu option "load wallet"
85 2017-07-20 18:20:53 0|sipa|i guess qt can have modifiable settings that include the wallets to load
86 2017-07-20 18:21:05 0|wumpus|but yes, qt has a dynamic settings mechanism
87 2017-07-20 18:21:10 0|wumpus|it could use that
88 2017-07-20 18:21:56 0|jonasschnelli|Not auto-loading RPC created wallets can be cumbersome if one uses pruning.
89 2017-07-20 18:22:29 0|wumpus|yes, maybe, I think it's something to worry about later
90 2017-07-20 18:23:24 0|wumpus|there's no reason bitcoind couldn't have a dynamic settings mechanism, with some configuration that automatically gets re-loaded on next run, for example the bitcoin-rw.conf idea
91 2017-07-20 18:29:08 0|bitcoin-git|[13bitcoin] 15laanwj pushed 6 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7c2400cb8ab7...16240f43a550
92 2017-07-20 18:29:09 0|bitcoin-git|13bitcoin/06master 142991c91 15Pieter Wuille: Add SHA256 dispatcher
93 2017-07-20 18:29:09 0|bitcoin-git|13bitcoin/06master 144d50f38 15Pieter Wuille: Support multi-block SHA256 transforms...
94 2017-07-20 18:29:10 0|bitcoin-git|13bitcoin/06master 14c1ccb15 15Pieter Wuille: Add SSE4 based SHA256
95 2017-07-20 18:29:39 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10821: Add SSE4 optimized SHA256 (06master...0620170713_shasse) 02https://github.com/bitcoin/bitcoin/pull/10821
96 2017-07-20 18:35:09 0|sipa|\o/
97 2017-07-20 18:36:11 0|instagibbs|jnewbery, gmaxwell re:unlock of wallet, one issue I see is that we have no way(?) of unlocking the wallet as bitcoind startup argument, so if the user hits the minimum they will be stuck aside from heroically fast fingers
98 2017-07-20 18:36:13 0|gmaxwell|(so bystanders aren't confused, thats defaulted to off, enabled with a configure flag, in master)
99 2017-07-20 18:36:40 0|gmaxwell|instagibbs: yea, it's ugly.
100 2017-07-20 18:36:50 0|sipa|instagibbs: it's annoying... we effectively have no means of recovery
101 2017-07-20 18:37:00 0|instagibbs|at a minimum, should the wallet.dat get copied and backed up temporarily?
102 2017-07-20 18:37:03 0|instagibbs|upon any rescan
103 2017-07-20 18:37:12 0|sipa|but i do think that it's better than the alternative (which is making the state even harder to recover from, with also no means of recovery)
104 2017-07-20 18:37:20 0|instagibbs|at least allow the user to take the older wallet.dat to some other software
105 2017-07-20 18:37:40 0|instagibbs|sipa, im sorry what's the worse idea of the two?
106 2017-07-20 18:37:54 0|instagibbs|not scanning forward and missing funds?
107 2017-07-20 18:37:58 0|gmaxwell|sipa: if it just won't start syncing with the wallet emptied and locked.. then you could unlock at your leasure.
108 2017-07-20 18:38:28 0|sipa|instagibbs: well if you don't stop, it means your wallet will go further out of sync with the chain, which may force you to do a full reindex later (if you're pruning)
109 2017-07-20 18:38:38 0|sipa|gmaxwell: yes, if we had support for stopping sync without shutdown, absolutely
110 2017-07-20 18:38:48 0|instagibbs|oh, stop syncing wallet but not chain, didn't know what you were talking about
111 2017-07-20 18:38:54 0|instagibbs|agreed
112 2017-07-20 18:38:59 0|gmaxwell|sipa: I mean it could shut down still but on restart just not start again.
113 2017-07-20 18:39:09 0|gmaxwell|It's easier to not start than it is to stop it, I think.
114 2017-07-20 18:39:16 0|sipa|gmaxwell: i see, that may be the case yes
115 2017-07-20 18:39:25 0|sipa|instagibbs: no, i mean that's what we're currently doing
116 2017-07-20 18:39:42 0|sipa|instagibbs: the keypool would go out of sync, and you'd keep syncing, making the wallet go out of sync (while not even being aware of it)
117 2017-07-20 18:39:52 0|sipa|so i think stopping when running out is a strict improvement
118 2017-07-20 18:40:08 0|sipa|but it's far from a complete solution
119 2017-07-20 18:40:12 0|instagibbs|wait it's already doing that?
120 2017-07-20 18:40:21 0|instagibbs|:(
121 2017-07-20 18:40:26 0|BlueMatt|sipa: do you know offhand what the performance difference between the sse4 sha256 and the avx1 sha256 impls are?
122 2017-07-20 18:40:26 0|instagibbs|ok then
123 2017-07-20 18:40:35 0|sipa|BlueMatt: small
124 2017-07-20 18:40:40 0|sipa|instagibbs: that's the problem we're trying to solve, no?
125 2017-07-20 18:40:47 0|instagibbs|sipa, I thought it was adding a "min" level
126 2017-07-20 18:40:53 0|gmaxwell|BlueMatt: AVX1 is a performance disaster on AMD and hardly faster on intel.
127 2017-07-20 18:40:57 0|instagibbs|which is separate from the "total"
128 2017-07-20 18:41:12 0|BlueMatt|gmaxwell: hmm, ok, i was just trying to figure if i should remove the avx1 patch i have in fibre or leave it
129 2017-07-20 18:41:12 0|sipa|instagibbs: i'm confused
130 2017-07-20 18:41:15 0|instagibbs|< 500 of 1000, topup vs 1000 of 1000 topup
131 2017-07-20 18:41:29 0|wumpus|BlueMatt: https://github.com/laanwj/bitcoin/tree/2016_05_sha256_accel readme.md has some benchmarks
132 2017-07-20 18:41:33 0|instagibbs|sipa, I'm probably just horribly confused about how the wallet currently operates
133 2017-07-20 18:41:47 0|wumpus|but yes, on most cpus there's hardly or no difference
134 2017-07-20 18:42:02 0|wumpus|and when there is a big difference it's SLOW
135 2017-07-20 18:42:24 0|BlueMatt|wumpus: ok, so, unless i get some rorx CPUs, just use sse4 and wait till there's shani
136 2017-07-20 18:42:33 0|sipa|shani is awesome
137 2017-07-20 18:42:38 0|instagibbs|sipa, right now the PR makes it shut down when you are below a new argument, default of 500
138 2017-07-20 18:42:39 0|sipa|it's 5.5x faster than sse4 here
139 2017-07-20 18:42:44 0|BlueMatt|lol, nice
140 2017-07-20 18:42:45 0|sipa|sorry, 4.5x
141 2017-07-20 18:42:47 0|wumpus|the rorx implementations are a little bit faster
142 2017-07-20 18:42:56 0|BlueMatt|so, fibre servers will use that in....5 years?
143 2017-07-20 18:43:01 0|wumpus|but yes, -ni is definitely what to go for
144 2017-07-20 18:43:16 0|BlueMatt|yea, I'm just limited by what random cheap hosting providers have available
145 2017-07-20 18:43:16 0|gmaxwell|BlueMatt: broadwell-ep
146 2017-07-20 18:43:18 0|gmaxwell|+------------ | ---------- | --------
147 2017-07-20 18:43:18 0|gmaxwell|+Impl | avg | speed%
148 2017-07-20 18:43:19 0|gmaxwell|+avx |0.00397483 | 151
149 2017-07-20 18:43:19 0|gmaxwell|+basic |0.00599851 | 100
150 2017-07-20 18:43:19 0|gmaxwell|+sse4 |0.00396052 | 151
151 2017-07-20 18:43:21 0|gmaxwell|+rorx |0.00334802 | 179
152 2017-07-20 18:43:22 0|sipa|BlueMatt: shani makes my reindex to 450k time go from 4900s to 4200s
153 2017-07-20 18:43:23 0|gmaxwell|+rorx_x8ms | 0.00328667 | 183
154 2017-07-20 18:44:04 0|gmaxwell|sipa: do you have a table like that for your system with shani on it?
155 2017-07-20 18:44:11 0|sipa|i had, somewhere
156 2017-07-20 18:44:20 0|sipa|it's probably in your PM history with me
157 2017-07-20 18:45:05 0|sipa|SHA256_32b_avx,4,0.464040040969849,0.464066028594971,0.464053034782410,1670543604,1670636664,1670590134
158 2017-07-20 18:45:15 0|sipa|SHA256_32b_basic,4,0.298919439315796,0.298947453498840,0.298933446407318,1076109714,1076210442,1076160078
159 2017-07-20 18:45:26 0|sipa|SHA256_32b_rorx,6,0.215215563774109,0.216080069541931,0.215623021125793,774776664,777886704,776242368
160 2017-07-20 18:46:10 0|sipa|SHA256_32b_rorx8,4,0.460553050041199,0.460564017295837,0.460558533668518,1657989792,1658029986,1658009889
161 2017-07-20 18:46:48 0|sipa|SHA256_32b_shani,16,0.064792513847351,0.065104484558105,0.064978063106537,233253936,234375822,233920892
162 2017-07-20 18:46:56 0|sipa|SHA256_32b_sse4,6,0.230213999748230,0.230278015136719,0.230246663093567,828768096,829000080,828886758
163 2017-07-20 18:47:10 0|gmaxwell|Thanks.
164 2017-07-20 18:48:14 0|gmaxwell|BlueMatt: I assume we'll add rorx and sha-ni right after branching...
165 2017-07-20 18:48:39 0|BlueMatt|gmaxwell: yea, would be cool to not carry patches for that on fibre
166 2017-07-20 18:48:40 0|sipa|that's already with a patch to make the rorx cases use larger CSHA256 buffers, because they process multiple blocks at once faster
167 2017-07-20 18:49:02 0|sipa|that patch doesn't affect the performance of others (in fact, it seems to slightly improve it...)
168 2017-07-20 18:49:53 0|gmaxwell|BlueMatt: ISTM you'd be better off with what we have in master than what you have now. (IIRC you're using just the AVX not the rorx one)
169 2017-07-20 18:50:45 0|BlueMatt|gmaxwell: that is correct, yes
170 2017-07-20 18:51:41 0|sipa|i'm afraid we'll need to startup benchmark to determine what sha256 implementation to use :(
171 2017-07-20 18:51:54 0|gmaxwell|I don't see why.
172 2017-07-20 18:52:13 0|sipa|because rorx8 is presumably faster than sse4 on intel, but slower on amd
173 2017-07-20 18:52:41 0|gmaxwell|sipa: well we need to try with the multiblock changes, it wasn't a big change before, but good point.
174 2017-07-20 18:52:56 0|gmaxwell|sipa: though we could simply check for intel and only use it on intel.
175 2017-07-20 18:53:34 0|wumpus|doing a sha256 benchmark at every start seems excessive to me
176 2017-07-20 18:54:46 0|gmaxwell|I doubt we'll have reason to do so. even if rorx8 is faster only on intel, and enough faster to include, fine.. we'll just check the vendor string.
177 2017-07-20 18:55:00 0|sipa|fair
178 2017-07-20 19:00:25 0|achow101|meeting?
179 2017-07-20 19:00:42 0|gmaxwell|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
180 2017-07-20 19:00:46 0|jonasschnelli|hi
181 2017-07-20 19:00:48 0|instagibbs|hi
182 2017-07-20 19:00:49 0|wumpus|#startmeeting
183 2017-07-20 19:00:50 0|lightningbot|Meeting started Thu Jul 20 19:00:49 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
184 2017-07-20 19:00:50 0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
185 2017-07-20 19:00:53 0|cfields|hi
186 2017-07-20 19:01:20 0|achow101|hi
187 2017-07-20 19:01:27 0|wumpus|#topic high priority for review
188 2017-07-20 19:02:10 0|sipa|#10882 needs 0.15 tag?
189 2017-07-20 19:02:12 0|gribble|https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery ÷ Pull Request #10882 ÷ bitcoin/bitcoin ÷ GitHub
190 2017-07-20 19:02:16 0|wumpus|https://github.com/bitcoin/bitcoin/projects/8 has pretty much been cleaned out (only #10652 left), anything new?
191 2017-07-20 19:02:17 0|sipa|otherwise, the things with current 0.15 tag?
192 2017-07-20 19:02:18 0|gribble|https://github.com/bitcoin/bitcoin/issues/10652 | Small step towards demangling cs_main from CNodeState by TheBlueMatt ÷ Pull Request #10652 ÷ bitcoin/bitcoin ÷ GitHub
193 2017-07-20 19:02:29 0|gmaxwell|ACK for 10882 0.15 tag
194 2017-07-20 19:02:37 0|wumpus|https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.15.0
195 2017-07-20 19:02:47 0|BlueMatt|10652 can lose its 15 tag
196 2017-07-20 19:03:11 0|BlueMatt|#10758 really wants review sooner rather than later
197 2017-07-20 19:03:12 0|gribble|https://github.com/bitcoin/bitcoin/issues/10758 | Fix some chainstate-init-order bugs. by TheBlueMatt ÷ Pull Request #10758 ÷ bitcoin/bitcoin ÷ GitHub
198 2017-07-20 19:03:35 0|cfields|i'd say #10821 needs high prio review if it's going in for 0.15, though it's got a bunch of ACKs already
199 2017-07-20 19:03:37 0|gribble|https://github.com/bitcoin/bitcoin/issues/10821 | Add SSE4 optimized SHA256 by sipa ÷ Pull Request #10821 ÷ bitcoin/bitcoin ÷ GitHub
200 2017-07-20 19:03:50 0|instagibbs|cfields, it got merged..
201 2017-07-20 19:03:51 0|jonasschnelli|cfields: it's merged
202 2017-07-20 19:03:52 0|wumpus|10821 is merged
203 2017-07-20 19:04:01 0|cfields|hah
204 2017-07-20 19:04:08 0|wumpus|there's virtually no regression risk as it's disabled by default
205 2017-07-20 19:04:12 0|kanzure|hi.
206 2017-07-20 19:05:47 0|wumpus|ok, added #10758 to project 8, and #10882 to 0.15
207 2017-07-20 19:05:48 0|gribble|https://github.com/bitcoin/bitcoin/issues/10758 | Fix some chainstate-init-order bugs. by TheBlueMatt ÷ Pull Request #10758 ÷ bitcoin/bitcoin ÷ GitHub
208 2017-07-20 19:05:50 0|gribble|https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery ÷ Pull Request #10882 ÷ bitcoin/bitcoin ÷ GitHub
209 2017-07-20 19:06:45 0|wumpus|#10652 was already untagged for 0.15 2 days ago
210 2017-07-20 19:06:47 0|gribble|https://github.com/bitcoin/bitcoin/issues/10652 | Small step towards demangling cs_main from CNodeState by TheBlueMatt ÷ Pull Request #10652 ÷ bitcoin/bitcoin ÷ GitHub
211 2017-07-20 19:06:57 0|BlueMatt|good :)
212 2017-07-20 19:07:41 0|wumpus|other topics?
213 2017-07-20 19:08:09 0|BlueMatt|Make 0.15 Great Again!
214 2017-07-20 19:08:20 0|achow101|forks! forks! forks!
215 2017-07-20 19:08:22 0|instagibbs|10882 halting condition
216 2017-07-20 19:08:35 0|gmaxwell|10882 halting problem.
217 2017-07-20 19:08:39 0|instagibbs|so, there's gotta be something better than "load your wallet in an older bitcoin instance"
218 2017-07-20 19:08:39 0|sipa|i'd like to bring up #10526
219 2017-07-20 19:08:41 0|gribble|https://github.com/bitcoin/bitcoin/issues/10526 | Force on-the-fly compaction during pertxout upgrade by sipa ÷ Pull Request #10526 ÷ bitcoin/bitcoin ÷ GitHub
220 2017-07-20 19:08:45 0|btcdrak|hi
221 2017-07-20 19:08:46 0|instagibbs|oh sorry il lwait for topic
222 2017-07-20 19:09:03 0|wumpus|about 2.5 weeks to go before projected 0.15 split-off
223 2017-07-20 19:09:21 0|wumpus|#topic Force on-the-fly compaction during pertxout upgrade
224 2017-07-20 19:09:25 0|gmaxwell|master is too reliable.
225 2017-07-20 19:09:40 0|sipa|so, the 0.15 per-txout database needs conversion on first startup
226 2017-07-20 19:09:54 0|sipa|this has the risk of leveldb leaving the old tables around
227 2017-07-20 19:10:24 0|sipa|leaving you with a 4.something GB chainstate rather than 2.something
228 2017-07-20 19:10:26 0|wumpus|did anyone see any difference with that merged?
229 2017-07-20 19:10:37 0|sipa|i did - i don't know if anyone else tried
230 2017-07-20 19:10:48 0|sipa|but it's pretty worrying if it doesn't work deterministically
231 2017-07-20 19:11:04 0|wumpus|did it make a difference for you? any idea what happened in my case?
232 2017-07-20 19:11:31 0|sipa|wumpus: no...
233 2017-07-20 19:11:53 0|sipa|it did make a difference for me, yes, as far as i remember
234 2017-07-20 19:12:00 0|sipa|i'll investigate again and rebase
235 2017-07-20 19:12:13 0|sipa|probably not much else to say
236 2017-07-20 19:12:32 0|wumpus|can anyone else try, please? I think it makes a lot of sense to have it in 0.15, *if* it works :)
237 2017-07-20 19:12:38 0|sipa|agree.
238 2017-07-20 19:12:39 0|sipa|will rebase
239 2017-07-20 19:12:49 0|wumpus|will tag it
240 2017-07-20 19:13:20 0|wumpus|#action test #10526
241 2017-07-20 19:13:21 0|gribble|https://github.com/bitcoin/bitcoin/issues/10526 | Force on-the-fly compaction during pertxout upgrade by sipa ÷ Pull Request #10526 ÷ bitcoin/bitcoin ÷ GitHub
242 2017-07-20 19:13:31 0|gmaxwell|wumpus: I thought there might have been something weird about your test; hardlinked database directories or something
243 2017-07-20 19:13:46 0|wumpus|gmaxwell: not hard-linked directories, just individual files
244 2017-07-20 19:15:21 0|wumpus|e.g. I use https://gist.github.com/laanwj/3c4614a23e072cbb3d39090da1834a68 to make copies - but not sure how it could cause the problem
245 2017-07-20 19:15:33 0|sipa|i don't see that either
246 2017-07-20 19:15:55 0|wumpus|but sure I could copy the ldb files instead and retry
247 2017-07-20 19:16:06 0|gmaxwell|Unrelated, does anyone have a point of contact with '1Hash' (or whomever was the author of block 476670)
248 2017-07-20 19:16:14 0|gmaxwell|?
249 2017-07-20 19:16:42 0|wumpus|no, no idea
250 2017-07-20 19:17:00 0|btcdrak|gmaxwell: I do
251 2017-07-20 19:18:17 0|gmaxwell|btcdrak: thanks.
252 2017-07-20 19:18:30 0|wumpus|#topic 10882 halting condition
253 2017-07-20 19:19:30 0|jnewbery|instagibbs ?
254 2017-07-20 19:19:36 0|instagibbs|I think users need some sane way of recovering from their wallet hitting topup
255 2017-07-20 19:20:09 0|instagibbs|and their node shutting down, since the user cannot recover using the current software
256 2017-07-20 19:20:52 0|instagibbs|sorry, don't have great solutions, just bringing it up because I'd like it merged
257 2017-07-20 19:21:25 0|instagibbs|(for encrypted wallets, obviously)
258 2017-07-20 19:21:51 0|gmaxwell|My suggestion is the although stoping the sync was hard, preventing it from starting may be easy.
259 2017-07-20 19:22:16 0|gmaxwell|so if you start with a locked tip-behind wallet, that doesn't have enough keys, it could just not start the sync until unlocked.
260 2017-07-20 19:22:22 0|gmaxwell|but I haven't investigated.
261 2017-07-20 19:22:38 0|wumpus|sounds good to me
262 2017-07-20 19:22:50 0|gmaxwell|instagibbs: Sipa's point was that an unrecoverable always shuts down state is STILL better than what we do now.
263 2017-07-20 19:23:02 0|gmaxwell|because you at least won't end up with a silently screwed up wallet.
264 2017-07-20 19:23:21 0|jnewbery|There are a couple of solutions that I hope we could get into v0.15.1 : dynamic loading of wallets with the option to unlock on load (#10740) and a standalone wallet tool with option to topup (#8745)
265 2017-07-20 19:23:23 0|gribble|https://github.com/bitcoin/bitcoin/issues/10740 | [WIP] [wallet] dynamic loading/unloading of wallets by jnewbery ÷ Pull Request #10740 ÷ bitcoin/bitcoin ÷ GitHub
266 2017-07-20 19:23:24 0|gribble|https://github.com/bitcoin/bitcoin/issues/8745 | [PoC] Add wallet inspection and modification tool "bitcoin-wallet-tool" by jonasschnelli ÷ Pull Request #8745 ÷ bitcoin/bitcoin ÷ GitHub
267 2017-07-20 19:23:41 0|instagibbs|gmaxwell, mmm sure, conveying actionable info is still a requirement, though this may be off topic for meeting
268 2017-07-20 19:23:55 0|wumpus|dynamic loading is a feature, that won't make it into 0.15.1
269 2017-07-20 19:25:37 0|wumpus|(but will to 0.16, ofc)
270 2017-07-20 19:25:53 0|instagibbs|jnewbery, oh optional unlock on load, nice, will look
271 2017-07-20 19:26:33 0|jnewbery|it's not in 10740 yet, but hopefully not too difficult to add
272 2017-07-20 19:26:37 0|instagibbs|ok, well if it's not super pressing to anyone else, whatever. I don't run crypted anyways :)
273 2017-07-20 19:27:11 0|wumpus|suddeny crashing on startup w/ the wallet effectively being unusable is unacceptable at least
274 2017-07-20 19:27:42 0|gmaxwell|I think it's preferable to current behavior where the wallet is effectively silently corrupted.
275 2017-07-20 19:28:04 0|BlueMatt|well its fixable with rescan
276 2017-07-20 19:28:10 0|sipa|BlueMatt: no
277 2017-07-20 19:28:15 0|sipa|it'll fail to load
278 2017-07-20 19:28:25 0|instagibbs|sipa, ?
279 2017-07-20 19:28:28 0|BlueMatt|i was responding to greg's "silently corrupted" comment
280 2017-07-20 19:28:35 0|sipa|oh, ok
281 2017-07-20 19:28:40 0|wumpus|forcing a rescan would be somewhat better
282 2017-07-20 19:28:41 0|wumpus|but just crashing will lead people to do things like salvagewallet and worse
283 2017-07-20 19:28:59 0|instagibbs|nvm
284 2017-07-20 19:29:01 0|gmaxwell|BlueMatt: fixable somehow doesn't mean not silently corrupted though. since it's silent you won't know to rescan.
285 2017-07-20 19:29:04 0|gmaxwell|wumpus good point.
286 2017-07-20 19:29:11 0|gmaxwell|in any case, lets see what we can do with the PR.
287 2017-07-20 19:29:13 0|BlueMatt|fair
288 2017-07-20 19:29:31 0|gmaxwell|(there were people running salvage wallet in response to the 50/100 warning... :( :( )
289 2017-07-20 19:29:43 0|BlueMatt|holy what the fuck
290 2017-07-20 19:29:59 0|gmaxwell|Humans.
291 2017-07-20 19:30:09 0|wumpus|yes, at least if it crashes it should tell something actionable to do, not just leave the user to dry
292 2017-07-20 19:30:27 0|jnewbery|Yes, the current error message is "Error: Keypool is too small. Shutting down"
293 2017-07-20 19:30:33 0|jnewbery|which isn't helpful enough
294 2017-07-20 19:30:35 0|instagibbs|startingly vague
295 2017-07-20 19:30:39 0|wumpus|not helpful at all
296 2017-07-20 19:30:45 0|instagibbs|salvagewallet may seem reasonable in response
297 2017-07-20 19:30:55 0|wumpus|they'll try providing a larger -keypool
298 2017-07-20 19:30:57 0|wumpus|which doesn't help
299 2017-07-20 19:31:00 0|gmaxwell|Any time we create a warning or an error condition that a user can't suppress a few people will do increasingly insane things to try to get it to go away.
300 2017-07-20 19:31:00 0|instagibbs|"my keys disappeared!"
301 2017-07-20 19:31:06 0|jnewbery|suggested action for user could be: set "-keypoolmin to 0 and then rescan"?
302 2017-07-20 19:31:07 0|wumpus|yes, 'core nuked my wallet!'
303 2017-07-20 19:31:25 0|sipa|jnewbery: and unlock beforehand
304 2017-07-20 19:31:29 0|gmaxwell|jnewbery: no, that'll just corrupt their wallet. (they'll end up scanning past the end)
305 2017-07-20 19:31:37 0|gmaxwell|they need to unlock before.
306 2017-07-20 19:31:50 0|wumpus|ideally this would just be automated
307 2017-07-20 19:31:57 0|wumpus|if there is a course of recovery
308 2017-07-20 19:32:02 0|jnewbery|ok: "set -keypoolmin to 0, unlock wallet, rescan"
309 2017-07-20 19:32:02 0|jtimon|my keypool is too small? isn't this just a warning because I resuse addresses and they want me to create more new ones?
310 2017-07-20 19:32:04 0|gmaxwell|I guess you can keypoolmin, restart, unlock, and restart with rescan.
311 2017-07-20 19:32:11 0|jtimon|sorry, bad joke
312 2017-07-20 19:32:49 0|gmaxwell|or we find out if we can just suppress the scanstart until unlock, then it just needs to nag you to unlock.
313 2017-07-20 19:33:01 0|wumpus|would be nice
314 2017-07-20 19:33:21 0|instagibbs|if error messages are more helpful, and there is a manual method of recovery, I'm fine with it for now
315 2017-07-20 19:33:29 0|wumpus|sure
316 2017-07-20 19:33:54 0|wumpus|if this is a rare condition, and explaining what to do is easier than automating it, that would be acceptable for 0.15
317 2017-07-20 19:34:02 0|jnewbery|ok, I'll improve the error message. PR could still do with lots of review
318 2017-07-20 19:34:18 0|instagibbs|Great!
319 2017-07-20 19:34:29 0|sipa|note that all of this can only ever occur when restoring a wallet backup in the first place
320 2017-07-20 19:34:45 0|wumpus|#action review #10882
321 2017-07-20 19:34:46 0|gribble|https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery ÷ Pull Request #10882 ÷ bitcoin/bitcoin ÷ GitHub
322 2017-07-20 19:35:25 0|wumpus|the more important not to scare people with unrecoverable errors
323 2017-07-20 19:36:15 0|gmaxwell|if people can't tell what to do in order to get rid of the error, they'll do something dangerous eventually, after trying a few safe but unsuccessful things.
324 2017-07-20 19:36:33 0|gmaxwell|I wonder how many people have died due to blinking 12 on VCRs.
325 2017-07-20 19:36:50 0|wumpus|they'll escalate to worse and worse things
326 2017-07-20 19:36:54 0|wumpus|heh
327 2017-07-20 19:38:14 0|sipa|well improving the error message at least would be a start
328 2017-07-20 19:38:55 0|wumpus|yes, that would be good
329 2017-07-20 19:39:05 0|sipa|but i agree more is needed
330 2017-07-20 19:39:26 0|jnewbery|It's a shame all the wallet initialization stuff is so coupled to node initialization. Hopefully we can make some good progress with that in 0.16. That'd make issues like this a lot easier to deal with.
331 2017-07-20 19:39:35 0|sipa|jnewbery: yeah
332 2017-07-20 19:39:57 0|wumpus|it is a shame indeed
333 2017-07-20 19:40:22 0|wumpus|although it's better than it used to be
334 2017-07-20 19:40:57 0|wumpus|but both multiwallet and this are good reasons to make further progress with it in 0.16
335 2017-07-20 19:41:35 0|wumpus|any other topics?
336 2017-07-20 19:43:40 0|wumpus|... I guess not, we can end the meeting early
337 2017-07-20 19:44:02 0|lightningbot|Meeting ended Thu Jul 20 19:44:01 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
338 2017-07-20 19:44:02 0|wumpus|#endmeeting
339 2017-07-20 19:44:03 0|lightningbot|Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-20-19.00.log.html
340 2017-07-20 19:44:03 0|lightningbot|Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-20-19.00.html
341 2017-07-20 19:44:03 0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-20-19.00.txt
342 2017-07-20 19:44:17 0|instagibbs|"activate segwit" maybe not so much of a joke this time :)
343 2017-07-20 19:44:32 0|sipa|may be the fork be with you
344 2017-07-20 19:44:35 0|sipa|always
345 2017-07-20 19:45:07 0|wumpus|it was never a joke :)
346 2017-07-20 19:45:55 0|cfields|instagibbs: whew, good thing we don't have to talk about a UASF to activate BIP91 :p
347 2017-07-20 19:46:13 0|instagibbs|we still have time!
348 2017-07-20 19:46:16 0|kanzure|should there be a reorgs warning about bip91 and possible partial activation
349 2017-07-20 19:46:46 0|kanzure|?
350 2017-07-20 19:46:51 0|instagibbs|bitcoincore.org could have something like bitcoin.org's warning
351 2017-07-20 19:46:53 0|instagibbs|btcdrak, ?
352 2017-07-20 19:47:01 0|Chris_Stewart_5|kanzure: that is what I was wondering too
353 2017-07-20 19:47:03 0|kanzure|the bitcoin.org warning was about aug1?
354 2017-07-20 19:47:06 0|instagibbs|oh right
355 2017-07-20 19:47:10 0|kanzure|well i don't know.
356 2017-07-20 19:47:17 0|gmaxwell|premature.
357 2017-07-20 19:47:30 0|gmaxwell|we should look again a day after 91 lockin.
358 2017-07-20 19:47:42 0|kanzure|is there signalling during the lock in period?
359 2017-07-20 19:47:49 0|gmaxwell|it may be at that point ~100% hashrate is setting bit 1 and there will be little reason to warn more.
360 2017-07-20 19:47:52 0|sipa|bip9 specifies that there should
361 2017-07-20 19:48:02 0|kanzure|well okay then.
362 2017-07-20 19:48:18 0|jtimon|sipa: but it is not required, is it?
363 2017-07-20 19:48:32 0|gmaxwell|if its still 50% hashrate setting bit1 at that point, there will need to be a warning.
364 2017-07-20 19:48:51 0|sipa|jtimon: it is not consensus enforced
365 2017-07-20 19:49:01 0|btcdrak|instagibbs: sorry battery died
366 2017-07-20 19:50:25 0|jtimon|I don't see why specify that then, it doesn't make any difference, does it? not even the warnings need it, do they?
367 2017-07-20 19:51:31 0|sipa|jtimon: it's helpful to be able to observe how the adoption goes
368 2017-07-20 19:51:57 0|jtimon|oh, I see
369 2017-07-20 19:56:58 0|instagibbs|how do I trigger a rescan inside -cli?(outside of importing a key/addr...)
370 2017-07-20 19:57:04 0|instagibbs|sorry for #bitcoin level q, testing
371 2017-07-20 19:58:29 0|jonasschnelli|instagibbs: impossibke
372 2017-07-20 19:58:41 0|sipa|isn't there a rescanchain RPC?
373 2017-07-20 19:58:50 0|sipa|or was that in an unmerged PR?
374 2017-07-20 19:58:51 0|instagibbs|so... I have to import a junk key to recover? oh boi
375 2017-07-20 19:58:52 0|jonasschnelli|https://github.com/bitcoin/bitcoin/pull/7061
376 2017-07-20 19:58:55 0|jonasschnelli|But unmerged
377 2017-07-20 19:59:02 0|sipa|oh
378 2017-07-20 19:59:12 0|jonasschnelli|I think RPC makes much more sense then -argument
379 2017-07-20 19:59:26 0|jonasschnelli|Will rebase soon
380 2017-07-20 20:02:01 0|instagibbs|ah! walletpassphrase calls topup, and rescan works. Ok.
381 2017-07-20 20:27:39 0|Guest19525|shouldnt there be a better warning for "ââ¬Åunknown block versions being mineââ¬Â
382 2017-07-20 20:27:47 0|Guest19525|?
383 2017-07-20 21:08:27 0|jnewbery|wumpus: Any chance of #10604 being tagged 0.15?
384 2017-07-20 21:08:29 0|gribble|https://github.com/bitcoin/bitcoin/issues/10604 | [wallet] [tests] Add listwallets RPC, include wallet name in `getwalletinfo` and add multiwallet test by jnewbery ÷ Pull Request #10604 ÷ bitcoin/bitcoin ÷ GitHub
385 2017-07-20 21:12:27 0|wumpus|jnewbery: tagged
386 2017-07-20 21:14:58 0|wumpus|(don't know if it's going to be controversial because it adds RPC stuff after the feature freeze, but it seems pretty simple straightforward)
387 2017-07-20 21:16:20 0|wumpus|...and doesn't add translation messages
388 2017-07-20 21:16:56 0|jnewbery|thanks. It had plenty of ACKs while we were settling on the multiwallet API. Trivial rebase
389 2017-07-20 21:17:12 0|sipa|can i haz review on https://github.com/bitcoin-core/leveldb/pull/5 and https://github.com/bitcoin-core/leveldb/pull/10 ?
390 2017-07-20 21:17:53 0|jnewbery|speaking of translations, #10882 has some translations strings. Is that going to be an issue?
391 2017-07-20 21:17:55 0|gribble|https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery ÷ Pull Request #10882 ÷ bitcoin/bitcoin ÷ GitHub
392 2017-07-20 21:20:29 0|wumpus|jnewbery: it's increasingly unlikely that they're going to be translated before the 0.15 release
393 2017-07-20 21:24:39 0|jnewbery|ok, but that doesn't block the PR from going in?
394 2017-07-20 21:26:56 0|wumpus|blah according to the release schedule it should, it's too late to change messages, but anyhow having the functionality untranslated is better than not having it at all in this case I guess?
395 2017-07-20 21:29:10 0|wumpus|that's the consideration that needs to be made, the message freeze is there to give the translators time, and thus increase the quality of the translations, but that might not matter for last-minute fixes
396 2017-07-20 21:29:57 0|wumpus|would be stupid to leave the walllet in a broken state just because we can't add a translation emssage
397 2017-07-20 21:30:24 0|jnewbery|ok good. 10882 is now mostly waiting on review. So far I have comments from instagibbs and ryanofsky
398 2017-07-20 21:39:25 0|bitcoin-git|13bitcoin/06master 146adc3a3 15Wladimir J. van der Laan: qt: Periodic translations update...
399 2017-07-20 21:39:25 0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 06master: 02https://github.com/bitcoin/bitcoin/commit/6adc3a37324caa07015368bfe8529e1964366eef