1 2017-11-16 00:31:36	0|bitcoin-git|[13bitcoin] 15willyko opened pull request #11700: Add gitian PGP key: willyko (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11700
  2 2017-11-16 02:15:38	0|meshcollider|sipa: re #11693 do you know if there is any way to currently signrawtransaction for P2SH-P2WSH ? Or should I open a PR to add a witness program key to that call
  3 2017-11-16 02:15:39	0|gribble|https://github.com/bitcoin/bitcoin/issues/11693 | Signing raw transaction that has p2sh-p2wsh input · Issue #11693 · bitcoin/bitcoin · GitHub
  4 2017-11-16 02:15:53	0|meshcollider|Or is there something else planned
  5 2017-11-16 02:18:38	0|sipa|meshcollider: hmm, that is surprising
  6 2017-11-16 02:19:08	0|sipa|meshcollider: maybe we should just automatically add the p2sh version of each script passed to signrawtransaction
  7 2017-11-16 02:19:18	0|sipa|that should work without api break
  8 2017-11-16 02:19:53	0|meshcollider|Mmm so you would just pass the internal WSH script in the scriptSig?
  9 2017-11-16 02:37:39	0|meshcollider|JSON*
 10 2017-11-16 02:38:16	0|sipa|right
 11 2017-11-16 02:38:38	0|sipa|hmm, but it would need to guess the witness version
 12 2017-11-16 02:38:50	0|meshcollider|sipa: it's already a JASON object so adding an extra key wouldn't break it anyway would it
 13 2017-11-16 02:38:56	0|meshcollider|Oops did that resend
 14 2017-11-16 02:42:15	0|sipa|okay
 15 2017-11-16 02:42:18	0|sipa|good
 16 2017-11-16 02:42:24	0|gmaxwell|from a usability perspective, having to have some extra key isn't super friendly, if it can be reasonably avoided.
 17 2017-11-16 02:42:49	0|gmaxwell|(these interfaces do exist for thigns other than driving test harnesses, you know)
 18 2017-11-16 02:46:16	0|meshcollider|I don't know how it could be avoided without instead passing in the witness version, like sipa mentioned
 19 2017-11-16 02:49:50	0|sipa|or alternatively, doing it automatically for all known witness types and versions
 20 2017-11-16 02:50:32	0|meshcollider|Why does the signrawtransaction help text already say "redeemScript": "hex",   (string, required for P2SH or P2WSH) redeem script
 21 2017-11-16 02:50:48	0|meshcollider|Oh don't worry, that's P2WSH not P2SH-P2WSH
 22 2017-11-16 02:52:40	0|gmaxwell|whatever we do, it should be the case the you can form a valid signraw line using nothing other than a simple reformatting of listunspent's output.
 23 2017-11-16 02:56:21	0|meshcollider|What is the redeemScript output from listunspent for P2SH-P2WSH
 24 2017-11-16 02:57:13	0|meshcollider|I assume it doesn't currently output the witness script at all, which will need to be modified too
 25 2017-11-16 02:57:20	0|sipa|gmaxwell: that's not really possible, and already not true for P2SH
 26 2017-11-16 02:58:47	0|sipa|at least not for watch-only outputs
 27 2017-11-16 02:59:13	0|gmaxwell|sipa: if you've imported the script it should be possible (I have no watch only p2sh so I don't know if it does)
 28 2017-11-16 02:59:30	0|sipa|gmaxwell: it won't work
 29 2017-11-16 02:59:39	0|gmaxwell|We should fix that then.
 30 2017-11-16 03:00:07	0|sipa|i mean it won't work when passing in explicit private keys
 31 2017-11-16 03:00:28	0|sipa|because then it uses the keystore consteucted from the rpc arguments rather than your wallet's keystore
 32 2017-11-16 03:00:59	0|sipa|part of this confusion is solved by finally splitting up signrawtransaction into a wallet version and a utility version (achow has a pr i think)
 33 2017-11-16 03:01:06	0|gmaxwell|the flaw here is that our private key encodings don't represent (or imply) the redeemscript.
 34 2017-11-16 03:01:31	0|sipa|in the wallet version, things already work fine and nothing is needed for p2sh-p2wsk
 35 2017-11-16 03:01:54	0|sipa|in the non-wallet version you inherently need to pass in the solving information somehow
 36 2017-11-16 03:02:04	0|sipa|indeed one way is to encode it in the private key
 37 2017-11-16 03:02:30	0|gmaxwell|or just declare that it's already encoded in the private key, and expand each private key all known ways; but that doesn't work e.g. for multisig.
 38 2017-11-16 03:02:49	0|sipa|but that's not generally possible for all output types (and specifically won't work for.any multisig kinda thing, which is exactly where p2wsh is used), so other ways must exist as well
 39 2017-11-16 03:02:58	0|sipa|right
 40 2017-11-16 03:03:33	0|gmaxwell|e.g. current private keys = {p2pk,p2pkh,p2sh-one-key,p2wpkhv0,p2wpkhv0-p2sh}
 41 2017-11-16 03:04:27	0|gmaxwell|we have the redeemscript for each input we're going to sign as an argument, so it could meet in the middle with the private keys. ugh.
 42 2017-11-16 03:05:49	0|sipa|yeah
 43 2017-11-16 03:06:23	0|sipa|whatwver encoding is used for the solving information, listunspent should probably be made to report it
 44 2017-11-16 03:06:28	0|sipa|if known
 45 2017-11-16 03:08:45	0|Chris_Stewart_5|gmaxwell: So basically this would look like attaching an extra byte of data to the current format to indicate the script it corresponds to>
 46 2017-11-16 03:08:48	0|Chris_Stewart_5|?
 47 2017-11-16 03:09:43	0|Chris_Stewart_5|and some sort of standardized scheme for standard script types I guess
 48 2017-11-16 03:25:22	0|meshcollider|So if I just made listunspent just report witness script for P2SH-P2WSH outputs and then signrawtransaction accept it that would be simple right
 49 2017-11-16 03:26:34	0|meshcollider|That's the cleanest way i can see to ensure P2SH-P2WSH multisig works for example, which is what brought on this discussion
 50 2017-11-16 03:26:40	0|sipa|while you're at it, also add redeemscript for P2SH?
 51 2017-11-16 03:38:58	0|meshcollider|To listunspent?
 52 2017-11-16 03:39:25	0|sipa|yes, it's also needed in signrawtransaction when giving private keys manually
 53 2017-11-16 03:39:54	0|meshcollider|sipa: I thought listunspent already had it
 54 2017-11-16 03:42:06	0|sipa|oh, indeed!
 55 2017-11-16 08:26:15	0|eck|random question: if leveldb already has its own WAL, then why does bitcoin need an in-memory cache/buffer for utxo updates
 56 2017-11-16 08:27:05	0|wumpus|eck: because we can do it more efficient because we know the properties of the data and access patterns
 57 2017-11-16 08:27:22	0|wumpus|eck: leveldb's caching is virtually useless for our use case, so we minimize their caches
 58 2017-11-16 08:28:20	0|wumpus|why does a database implement its own caching if the OS already has a page cache'
 59 2017-11-16 08:28:28	0|wumpus|would be similar :)
 60 2017-11-16 08:28:50	0|eck|i don't care/know that much about how leveldb implements read caches, but for writes, it seems really problematic you have multiple caching layrs
 61 2017-11-16 08:29:20	0|eck|in this example you have bitcoin cache + leveldb cache + kernel page cache
 62 2017-11-16 08:29:27	0|eck|that's a lot of caching layers
 63 2017-11-16 08:29:58	0|wumpus|why would that be problematic? it's pretty much how modern platforms work, your CPU also has caches as different levels
 64 2017-11-16 08:30:13	0|sipa|eck: there are a number of reasons why our caching provides functionality on top of LevelDB's
 65 2017-11-16 08:30:38	0|sipa|one is that LevelDB inherently deals with serialized records, while our caching layer stores information using our native in-memory formats
 66 2017-11-16 08:30:46	0|sipa|serialization and deserialization have a nontrivial cost
 67 2017-11-16 08:30:54	0|wumpus|in any case, if you find a way to improve performance, go for it
 68 2017-11-16 08:31:46	0|sipa|furthermore, we're able to exploit a very significant property of our data set: entries are written once, and deleted once - and almost never overwritten in between
 69 2017-11-16 08:32:03	0|eck|maybe I can or cannot, just trying to make sure I understand the current state of affaris:
 70 2017-11-16 08:32:27	0|eck|as i understand it, by default a full node today will flush to disk as infrequently as once every 24h
 71 2017-11-16 08:32:35	0|sipa|we keep track in our cache whether an entry exists in the caching layer below, and if not (= it's a freshly created entry) which gets deleted (utxo gets spent), we simply delete it from memory, without it ever needing to touch disk
 72 2017-11-16 08:33:12	0|sipa|this optimization saves us 90% of all I/O or more, depending on cache sizes
 73 2017-11-16 08:33:28	0|sipa|because many UTXO entries get spent quickly after being created
 74 2017-11-16 08:33:42	0|bitcoin-git|[13bitcoin] 15laanwj pushed 9 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/54aedc013744...3c098a8aa078
 75 2017-11-16 08:33:43	0|bitcoin-git|13bitcoin/06master 141a44534 15MeshCollider: scripted-diff: Replace #include "" with #include <> (ryanofsky)...
 76 2017-11-16 08:33:43	0|bitcoin-git|13bitcoin/06master 145b56ec9 15Wladimir J. van der Laan: qt: refactor: Use absolute include paths in .ui files
 77 2017-11-16 08:33:44	0|bitcoin-git|13bitcoin/06master 140c71521 15Wladimir J. van der Laan: build: Remove -I for everything but project root...
 78 2017-11-16 08:33:44	0|eck|could you point me (rougly) to the part of the code i woudl oook at?
 79 2017-11-16 08:33:47	0|wumpus|yes, leveldb does not do this for batches
 80 2017-11-16 08:34:07	0|sipa|eck: coins.cpp
 81 2017-11-16 08:34:12	0|wumpus|so if you queue both adds, updates, and deletes, they will actually get executed
 82 2017-11-16 08:34:17	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11651: refactor: Make all #includes relative to project root (laanwj, MeshCollider, ryanofsky) (06master...06201711_absolute_includes) 02https://github.com/bitcoin/bitcoin/pull/11651
 83 2017-11-16 08:34:42	0|sipa|yes, LevelDB's "batch" structure is literally an std::string
 84 2017-11-16 08:34:48	0|wumpus|also leveldb's batch storage format is really inefficient with regard to memroy allocation, large consecutive memory areas
 85 2017-11-16 08:34:49	0|wumpus|right
 86 2017-11-16 08:34:51	0|sipa|with serialized write/erase operations in it
 87 2017-11-16 08:35:23	0|gmaxwell|eck: the infrequency is basically unrelated to the structure, it could continiously flush, now that we have non-atomic flushing... that just hasn't been implemented yet.
 88 2017-11-16 08:35:48	0|eck|thanks! in the past I wrote my own (simpler obviously) C++ implementation of an ss-table-like structure, and I'm trying to confirm that the whole caching i/o layer in bitcoind works as I expect it would
 89 2017-11-16 08:35:48	0|gmaxwell|and in general we want to delay flushing as much as possible in order to suppress writes from ever happening in the first place.
 90 2017-11-16 08:35:51	0|sipa|right, the idea is to move the flushing to a background process that continuously flushes the oldest dirty cache entries
 91 2017-11-16 08:36:24	0|sipa|but never gets too close to 'now', as to not interfere with our freshness optimization
 92 2017-11-16 08:36:39	0|sipa|eck: cool
 93 2017-11-16 08:39:56	0|eck|thanks everyone for your help, I will report back if I have further conclusions or questions
 94 2017-11-16 08:41:29	0|sipa|yw!
 95 2017-11-16 08:53:47	0|eck|related, if I wanted to follow up with someone speifically about the storage layer, who is an expert?
 96 2017-11-16 08:54:11	0|gmaxwell|just ask here.
 97 2017-11-16 08:54:17	0|gmaxwell|other people would learn from your questions.
 98 2017-11-16 08:55:58	0|eck|alright, at a high level i want to know why bitcoin has a caching layer at all: there is already some caching in the kernel page cache, leveldb has some caching og it its own, and then bitcoin itself will cache data for up to 24h
 99 2017-11-16 08:56:57	0|wumpus|that's what sipa just explained
100 2017-11-16 08:57:00	0|eck|from my superfcial understanding, i would just write directly to leveldb and let it take care of the rest
101 2017-11-16 08:57:21	0|wumpus|that was the first thing that was tried, and perf was abysmal
102 2017-11-16 08:57:37	0|gmaxwell|eck: you can do that, it takes about a week to sync the chain that way on typical hardware.
103 2017-11-16 08:57:59	0|wumpus|that might work better with other databases, but not leveldb
104 2017-11-16 08:58:15	0|gmaxwell|everything else we've tried was basically an order of magnitude slower than leveldb.
105 2017-11-16 08:58:29	0|wumpus|the best (only) way to get feeling for it is to experiment, it's really hard to beat the performance of the current solution
106 2017-11-16 08:58:33	0|eck|interesting, I would like to / am willin g to repeat the experiment to verify it locally
107 2017-11-16 08:59:09	0|gmaxwell|eck: you can just set the dbcache to a minimal value and see the result for 95% of the effect.
108 2017-11-16 08:59:43	0|eck|ok, thanks
109 2017-11-16 08:59:59	0|wumpus|I have some old utxo database experiments here: https://github.com/laanwj/bitcoin
110 2017-11-16 09:00:03	0|gmaxwell|eck: syncing the chain with every operation going to the database requires about 1 billion database updates.
111 2017-11-16 09:00:11	0|wumpus|maybe that's useful at least for seeing what files to touch...
112 2017-11-16 09:01:10	0|eck|generally though,i would account for the wallet db taking basically 0 time, right?
113 2017-11-16 09:01:22	0|wumpus|LMDB seemed promising but I never got spectacular results, maybe I was just using it wrong, and maybe the approach of not caching at the bitcoin level would work better with it
114 2017-11-16 09:02:03	0|gmaxwell|eck: I can't figure out why you think the wallet database would be involved at all.
115 2017-11-16 09:02:13	0|wumpus|wallet has nothing to do with this, when you benchmark this, I suggest you disable it compile-time
116 2017-11-16 09:02:22	0|gmaxwell|The wallet database uses reasources when you have wallets with loads of transactions and keys, otherwise it does nothing.
117 2017-11-16 09:02:43	0|eck|i don't care about the wallet database, it's slow but it's smalll
118 2017-11-16 09:03:14	0|wumpus|it's also only read at startup, and written when the wallet actually changes, which is infrequent for most people
119 2017-11-16 09:03:15	0|eck|my interest recently is syncing a g1-small GCE instance
120 2017-11-16 09:03:35	0|gmaxwell|in any case, to sync in three hours (which we do, on a fast desktop at least with dbcache cranked) without a dbcache would require sustaining 100k operations per second, which is not realistic except on specialized hardware (e.g. nvme raid or whatever).
121 2017-11-16 09:03:42	0|eck|it has 1.5GB of memory, and essentially 0 disk I/O
122 2017-11-16 09:04:32	0|wumpus|it has terrible I/O, disabling caching is certainly not what you should look at
123 2017-11-16 09:04:41	0|eck|my instance on core right now is synicin at < 5% a *day*, which seems like there is some fundamental horkage in some layer
124 2017-11-16 09:04:42	0|wumpus|sync on a faster machine then copy over the state
125 2017-11-16 09:04:51	0|eck|yeah maybe
126 2017-11-16 09:05:38	0|gmaxwell|I think you might just be underestimating how much work is involved in syncing and how slow those instances are. :)
127 2017-11-16 09:05:39	0|wumpus|w/ the cloud thing, you could just hire one of the large instances for a day or so
128 2017-11-16 09:06:00	0|gmaxwell|with 1.5GB memory you may be able to increase the cache further without crashing, it will speed it up.
129 2017-11-16 09:06:44	0|eck|from what I can tell, on GCE they give you I/O capacity base on the disk size
130 2017-11-16 09:07:03	0|wumpus|this is comparable to running a node on e.g. rpi, they can keep up, but doing initial sync on them takes extreme amounts of patience
131 2017-11-16 09:07:10	0|eck|so if you want 200 GB, you're basically on teh bottom wrung, even if you have a ton of cpu/memory
132 2017-11-16 09:07:34	0|gmaxwell|But there is just an utterly stupendous amount of work required, ... the software is highly optimized (and sure, there are also still many things that could be done to make it faster). .. but e.g. compared to ethereum the amount of blockchain bitcoin core processes per second is something like two orders of magnitude greater. ( https://anduck.net/bitcoincore_vs_geth_full_node_stats.png )
133 2017-11-16 09:07:49	0|wumpus|if it's a vm maybe you can temporary increase the amount if memory, then sync with dbcache of 4000, then i/o will not be touched until it's done
134 2017-11-16 09:09:07	0|eck|thanks all, I will definitely be in here asking about this gain
135 2017-11-16 09:09:13	0|gmaxwell|indeed, the only IO with a huge db cache is just writing blocks out to disk and the final flush.
136 2017-11-16 09:09:44	0|eck|I will ask more once I've done more research
137 2017-11-16 09:10:17	0|wumpus|oh yes it will need to write out the blocks, but that's linear and granular, not seek-heavy database i/o I meant
138 2017-11-16 10:28:16	0|meshcollider|To add witnessScript to listunspent output, how do we retrieve a CScript from the wallet using WitnessV0ScriptHash if the CScripts are indexed by CScriptID which is Hash160 not SHA?
139 2017-11-16 10:28:47	0|sipa|aha!
140 2017-11-16 10:29:05	0|sipa|Hash160(x) = RIPEMD160(SHA256(x))
141 2017-11-16 10:29:27	0|sipa|so given y=SHA256(x) you can compute Hash160(x) as RIPEMD160(y)
142 2017-11-16 10:29:32	0|meshcollider|Oh! Perfect :)
143 2017-11-16 10:49:14	0|bitcoin-git|13bitcoin/06master 14ec85248 15John Newbery: [travis-ci] Only run linters on Pull Requests...
144 2017-11-16 10:49:14	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3c098a8aa078...66d46c7901b7
145 2017-11-16 10:49:15	0|bitcoin-git|13bitcoin/06master 1466d46c7 15Wladimir J. van der Laan: Merge #11699: [travis-ci] Only run linters on Pull Requests...
146 2017-11-16 10:49:47	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11699: [travis-ci] Only run linters on Pull Requests (06master...06lint_only_prs) 02https://github.com/bitcoin/bitcoin/pull/11699
147 2017-11-16 10:50:06	0|bitcoin-git|13bitcoin/06master 14069215e 15practicalswift: Initialize recently introduced non-static class member lastCycles to zero in constructor...
148 2017-11-16 10:50:06	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/66d46c7901b7...084f52f38dc2
149 2017-11-16 10:50:07	0|bitcoin-git|13bitcoin/06master 14084f52f 15Wladimir J. van der Laan: Merge #11654: tests: Initialize recently introduced non-static class member lastCycles to zero in constructor...
150 2017-11-16 10:50:37	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11654: tests: Initialize recently introduced non-static class member lastCycles to zero in constructor (06master...06uninitialized-members) 02https://github.com/bitcoin/bitcoin/pull/11654
151 2017-11-16 10:58:26	0|asu|hi, all
152 2017-11-16 10:58:44	0|asu|i has a question.
153 2017-11-16 10:59:50	0|asu|i want to build a bitcoin p2p trade web
154 2017-11-16 11:00:49	0|asu|buy i found if my customer send 0.01bitcoin to another, the fee is 0.00027 bitcoin
155 2017-11-16 11:02:00	0|asu|but in localbitcoins.com, the fee is zero
156 2017-11-16 11:02:28	0|asu|how can i do it? thanks
157 2017-11-16 11:02:46	0|asu|who can help me
158 2017-11-16 11:03:08	0|kinlo|asu: that question is for #bitcoin, not for here
159 2017-11-16 11:03:44	0|asu|ok, thanks
160 2017-11-16 11:04:18	0|asu|where is the bitcoin irc?
161 2017-11-16 11:04:30	0|kinlo|just join #bitcoin
162 2017-11-16 11:04:39	0|asu|join #bitcoin
163 2017-11-16 11:05:06	0|kinlo|it's /join #bitcoin
164 2017-11-16 11:05:36	0|asu|thanks
165 2017-11-16 11:11:02	0|kgc|Hi, I updated issue https://github.com/bitcoin/bitcoin/issues/11693 with some more information, while I can proceed with my implementation it's slightly tricky/confusing to use.
166 2017-11-16 11:11:50	0|meshcollider|sipa: It appears there is a way to use signrawtransaction with P2SH-P2WSH as-is, check out https://bitcoin.stackexchange.com/a/62746/51948
167 2017-11-16 11:12:49	0|meshcollider|basically put the same input twice, once with the P2SH redeemScript and once with the witness redeemScript
168 2017-11-16 11:13:21	0|meshcollider|which is good to know but certainly not the cleanest way to do it
169 2017-11-16 11:14:10	0|kgc|yeah
170 2017-11-16 11:14:40	0|kgc|I made a suggestion how to potentially clean it up a bit, but that's already for you to decide change or not :)
171 2017-11-16 11:16:03	0|meshcollider|kgc: I'm working on something right now here: github.com/MeshCollider/bitcoin/tree/201711_signrawtransaction_wsh
172 2017-11-16 11:16:20	0|meshcollider|haven't tested yet
173 2017-11-16 11:18:22	0|kgc|good to know
174 2017-11-16 11:19:38	0|kgc|if it makes it to official release most probably will switch it using to avoid confusion in the future when looking at my own code
175 2017-11-16 11:24:29	0|bitcoin-git|13bitcoin/06master 1428f8b66 15Eelis: Diagnose unsuitable outputs in lockunspent()....
176 2017-11-16 11:24:29	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/084f52f38dc2...99bc0b428b03
177 2017-11-16 11:24:30	0|bitcoin-git|13bitcoin/06master 1499bc0b4 15Wladimir J. van der Laan: Merge #11087: Diagnose unsuitable outputs in lockunspent()....
178 2017-11-16 11:24:54	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11087: Diagnose unsuitable outputs in lockunspent(). (06master...06lockunspent) 02https://github.com/bitcoin/bitcoin/pull/11087
179 2017-11-16 11:43:07	0|wumpus|re: https://github.com/bitcoin/bitcoin/pull/11281#discussion_r151390218
180 2017-11-16 11:43:26	0|wumpus|is there anything that makes scanning blocks out of order go wrong?
181 2017-11-16 11:43:50	0|wumpus|(maybe when there are chains of transactions depending on each other?)
182 2017-11-16 11:44:57	0|wumpus|in that case we'd want to disable scanning of the wallet of incoming blocks when it is rescanning
183 2017-11-16 11:45:56	0|wumpus|and we would need logic to backtrack in case of reorgs
184 2017-11-16 12:57:36	0|bitcoin-git|[13bitcoin] 15sipsorcery opened pull request #11704: Windows build doc update (06master...06windoc) 02https://github.com/bitcoin/bitcoin/pull/11704
185 2017-11-16 14:46:23	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10772: Implementation of BIP8 (06master...06bip8-height) 02https://github.com/bitcoin/bitcoin/pull/10772
186 2017-11-16 15:16:08	0|bitcoin-git|[13bitcoin] 15zhaokexun opened pull request #11705: 0.15 (06master...060.15) 02https://github.com/bitcoin/bitcoin/pull/11705
187 2017-11-16 15:17:28	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11705: 0.15 (06master...060.15) 02https://github.com/bitcoin/bitcoin/pull/11705
188 2017-11-16 16:26:37	0|BlueMatt|wumpus: do you want a followup pr to #11686 ?
189 2017-11-16 16:26:39	0|gribble|https://github.com/bitcoin/bitcoin/issues/11686 | Make ISSUE_TEMPLATE a bit shorter, mention hardware tests by TheBlueMatt · Pull Request #11686 · bitcoin/bitcoin · GitHub
190 2017-11-16 16:28:31	0|wumpus|BlueMatt: I think it'd make sense, but I don't really want to turn it into a controversial topic
191 2017-11-16 16:29:02	0|BlueMatt|oh I dont think anyone cares *that* much, I was just curious if you want more pr volume
192 2017-11-16 16:29:13	0|BlueMatt|its also a github md file, not like we need to have big review cycles on it.......
193 2017-11-16 16:37:25	0|wumpus|right, a change to a github md isn't so bad with regards to PR volume
194 2017-11-16 16:37:48	0|BlueMatt|k, I'll tweak it again
195 2017-11-16 16:37:57	0|wumpus|thanks :)
196 2017-11-16 16:51:45	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #11706: Make default issue text all comments to make issues more readable (06master...062017-11-shorter-default-issue-redux) 02https://github.com/bitcoin/bitcoin/pull/11706
197 2017-11-16 16:51:47	0|BlueMatt|wumpus: ^
198 2017-11-16 18:55:27	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #11707: [tests] Fix sendheaders (06master...06fix_sendheaders) 02https://github.com/bitcoin/bitcoin/pull/11707
199 2017-11-16 19:00:19	0|achow101|meeting?
200 2017-11-16 19:00:46	0|luke-jr|hajimemashite?
201 2017-11-16 19:01:05	0|lightningbot|Meeting started Thu Nov 16 19:01:04 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
202 2017-11-16 19:01:05	0|wumpus|#startmeeting
203 2017-11-16 19:01:06	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
204 2017-11-16 19:01:23	0|wumpus|#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 jl2012 achow101 meshcollider jnewbery maaku fanquake promag
205 2017-11-16 19:01:31	0|sipa|present
206 2017-11-16 19:01:35	0|achow101|hi
207 2017-11-16 19:01:35	0|jtimon|hi
208 2017-11-16 19:01:37	0|meshcollider|hello
209 2017-11-16 19:01:42	0|gmaxwell|hi
210 2017-11-16 19:01:47	0|sdaftuar|ack
211 2017-11-16 19:01:49	0|jonasschnelli|hi
212 2017-11-16 19:01:57	0|gmaxwell|will be back in 10 minutes, maybe the meeting won't be over by then. :P
213 2017-11-16 19:02:12	0|wumpus|#topic high priority for review
214 2017-11-16 19:02:17	0|BlueMatt|new high-priority for me: #11639
215 2017-11-16 19:02:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/11639 | Rewrite the interface between validation and net_processing wrt DoS by TheBlueMatt · Pull Request #11639 · bitcoin/bitcoin · GitHub
216 2017-11-16 19:02:33	0|kanzure|hi.
217 2017-11-16 19:02:56	0|wumpus|only four things left https://github.com/bitcoin/bitcoin/projects/8
218 2017-11-16 19:03:24	0|BlueMatt|also probably worth a post-merge review: #10286 (note that this will likely make lots of open wallet-rpc change conflict silently - you need to add the new BlockUntilSyncedToCurrentChain call in some wallet rpc functions as boiler plate, see dev docs for more)
219 2017-11-16 19:03:28	0|gribble|https://github.com/bitcoin/bitcoin/issues/10286 | Call wallet notify callbacks in scheduler thread (without cs_main) by TheBlueMatt · Pull Request #10286 · bitcoin/bitcoin · GitHub
220 2017-11-16 19:03:38	0|wumpus|added 11639
221 2017-11-16 19:03:43	0|promag|Hi
222 2017-11-16 19:04:16	0|luke-jr|should #11383 be on there? I can rebase after the meeting
223 2017-11-16 19:04:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub
224 2017-11-16 19:05:13	0|wumpus|luke-jr: added
225 2017-11-16 19:05:17	0|bitcoin-git|[13bitcoin] 15luke-jr closed pull request #10391: OP_CHECKBLOCKATHEIGHT anti-replay (BIP 115; logic only) (06master...06cbah) 02https://github.com/bitcoin/bitcoin/pull/10391
226 2017-11-16 19:06:08	0|promag|Rpc console still only for 1st wallet right?
227 2017-11-16 19:06:34	0|luke-jr|promag: that PR has an independent combobox for the debug window
228 2017-11-16 19:06:47	0|luke-jr|(including a "no wallet" option)
229 2017-11-16 19:07:02	0|promag|Should rebase on dynamic wallet loading? Or vice-versa?
230 2017-11-16 19:07:02	0|wumpus|#topic rpc console for multi wallet
231 2017-11-16 19:07:17	0|jonasschnelli|The dropdown seems okay isch.
232 2017-11-16 19:07:24	0|luke-jr|promag: IMO GUI should go before dynamic loading
233 2017-11-16 19:07:29	0|jonasschnelli|Ideally we would have a higher-level visual selector
234 2017-11-16 19:07:32	0|promag|Kk
235 2017-11-16 19:07:39	0|luke-jr|jonasschnelli: ?
236 2017-11-16 19:07:42	0|jonasschnelli|luke-jr: agree
237 2017-11-16 19:08:10	0|jonasschnelli|luke-jr: it confusing to have a wallet level switch in the console
238 2017-11-16 19:08:26	0|jtimon|what's wrong with the combobox ?
239 2017-11-16 19:08:31	0|jonasschnelli|But I don't see another simple way
240 2017-11-16 19:08:43	0|promag|One thing that bothers me with the combo is that the gui state is lost
241 2017-11-16 19:08:46	0|luke-jr|maybe improvements there can be made after merge, if someone thinks of a better way
242 2017-11-16 19:08:53	0|luke-jr|promag: ?
243 2017-11-16 19:08:57	0|achow101|I think it might be confusing to users to have the debug window possibly be for a different wallet than the main wallet gui
244 2017-11-16 19:09:14	0|wumpus|the combobox is ok
245 2017-11-16 19:09:17	0|jonasschnelli|I think its an acceptable first step
246 2017-11-16 19:09:23	0|promag|Like list scroll position, selection, focus, etc
247 2017-11-16 19:09:25	0|sipa|pieter was here
248 2017-11-16 19:09:39	0|wumpus|the debug window is supposed to be separate from the main GUI, having it influence what wallet is selected is even more confusing
249 2017-11-16 19:09:41	0|jtimon|I think it's perfectly fine for the debug console to be flexible like this. seems just handy to put it there
250 2017-11-16 19:09:51	0|wumpus|yes
251 2017-11-16 19:09:57	0|promag|Another option is one tab per wallet
252 2017-11-16 19:10:03	0|wumpus|no, please not
253 2017-11-16 19:10:15	0|luke-jr|maybe (post-merge) an idea might be to have a red alert icon next to the combobox if it doesn't match the main window
254 2017-11-16 19:10:44	0|achow101|I was thinking that when you first opened the debug window it could default to the wallet that was in use in the main window
255 2017-11-16 19:10:45	0|wumpus|meh
256 2017-11-16 19:10:55	0|achow101|then users can change the wallet if they want to
257 2017-11-16 19:11:14	0|jonasschnelli|I think the dropbox is still the best solution on the table,... (even if not ideal)
258 2017-11-16 19:11:15	0|jtimon|that sounds reasonable to me
259 2017-11-16 19:11:19	0|wumpus|I really think having the debug window and main window interact in that way is a mess both in code and in interaction, but anyhow
260 2017-11-16 19:11:41	0|wumpus|okay, any other topic?
261 2017-11-16 19:11:42	0|luke-jr|sounds like we at least agree it's a post-merge topic XD
262 2017-11-16 19:11:46	0|jonasschnelli|ack
263 2017-11-16 19:11:49	0|jtimon|oh, if it's a mess in the code, I'm not sure it's worth it. I'll shut up
264 2017-11-16 19:11:55	0|promag|wumpus: btw why not tabs?
265 2017-11-16 19:12:08	0|wumpus|promag: multiple tabs with the same console just pointing at a different wallet sounds terrible to me
266 2017-11-16 19:12:09	0|jtimon|spaces are better
267 2017-11-16 19:12:12	0|jonasschnelli|promag: most calls are pure node calls...
268 2017-11-16 19:12:23	0|wumpus|promag: the tabs are supposed to be for essentially different things
269 2017-11-16 19:12:34	0|promag|At least you keep track of the correct log
270 2017-11-16 19:12:38	0|wumpus|e.g. more charts, more pages of debug info, etc
271 2017-11-16 19:12:43	0|jnewbery|promag: multiwallet comes first, dynamic loading later
272 2017-11-16 19:13:05	0|jnewbery|*multiwallet GUI comes first
273 2017-11-16 19:13:18	0|promag|Anyway, ack on the order
274 2017-11-16 19:13:25	0|luke-jr|promag: perhaps a log entry after you execute a command on a different wallet than previously (post-merge stuff)
275 2017-11-16 19:13:43	0|promag|Ok ok
276 2017-11-16 19:13:49	0|wumpus|why not a command to switch between wallets, btw?
277 2017-11-16 19:14:11	0|wumpus|the combobox is great to show what the current wallet is, but shouldn't the wallet be switchable with typing?
278 2017-11-16 19:14:13	0|luke-jr|/wallet <name> ?
279 2017-11-16 19:14:17	0|wumpus|for ex.
280 2017-11-16 19:14:24	0|jonasschnelli|yes... ideally it would be stateless.
281 2017-11-16 19:14:31	0|jonasschnelli|to ensure one is not executing on the wrong wallet
282 2017-11-16 19:14:32	0|achow101|so it would be a gui only command?
283 2017-11-16 19:14:38	0|jonasschnelli|wallet:xyz getnewaddress
284 2017-11-16 19:14:39	0|wumpus|achow101: yes
285 2017-11-16 19:14:55	0|jonasschnelli|if wallet:<filename> is missing, we get the standard rpcish reject
286 2017-11-16 19:14:56	0|wumpus|jonasschnelli: type the wallet name for every command? yes, maybe
287 2017-11-16 19:14:58	0|promag|It could be part of the "prompt"
288 2017-11-16 19:15:09	0|MarcoFalke|Needs autocomplete!
289 2017-11-16 19:15:18	0|jonasschnelli|I think the wallet-selected-state can be dangerous
290 2017-11-16 19:15:19	0|wumpus|jonasschnelli: that's absolutely safest
291 2017-11-16 19:15:24	0|wumpus|jonasschnelli: agree
292 2017-11-16 19:15:27	0|jonasschnelli|and it's RPC like
293 2017-11-16 19:15:36	0|wumpus|yes
294 2017-11-16 19:15:40	0|jonasschnelli|one can still use arrow-up edit
295 2017-11-16 19:15:44	0|jtimon|a gui only command doesn't feel right
296 2017-11-16 19:16:08	0|luke-jr|nesting is already GUI-only
297 2017-11-16 19:16:22	0|wumpus|jtimon: no, agree, jonasschnelli's proposal to make it stateless and have to provide it for every command is better, that's the same as needs tobe done for bitcoin-cli
298 2017-11-16 19:16:24	0|jonasschnelli|yes. It's fine
299 2017-11-16 19:17:00	0|luke-jr|is this still post-merge, or have we un-concept-ack'd the MW GUI PR?
300 2017-11-16 19:17:02	0|promag|Even when there is 1 wallet only?
301 2017-11-16 19:17:14	0|MarcoFalke|promag: No
302 2017-11-16 19:17:18	0|wumpus|promag: that's the exception
303 2017-11-16 19:17:23	0|jonasschnelli|luke-jr: both would be okay for me (post merge or now)
304 2017-11-16 19:17:26	0|wumpus|if it is unambigious then why not
305 2017-11-16 19:17:38	0|wumpus|wallet needs to be provided if multiple wallets are loaded
306 2017-11-16 19:17:48	0|promag|Ack
307 2017-11-16 19:17:54	0|luke-jr|wumpus: because it'd be really annoying to use?
308 2017-11-16 19:17:55	0|wumpus|if no wallet is loaded, there's no problem, if one wallet is loaded, then it's clear which one is meant
309 2017-11-16 19:18:15	0|wumpus|if mutliple are loaded then wallet commands are ambigious
310 2017-11-16 19:18:20	0|promag|It's the same with cli
311 2017-11-16 19:18:27	0|wumpus|yes, it's the same with bitcoin-cli
312 2017-11-16 19:18:29	0|jonasschnelli|It's maybe annoying... but it's the wallet. Safety first
313 2017-11-16 19:18:37	0|gmaxwell|why wouldn't the debug window just have a combo box
314 2017-11-16 19:18:37	0|luke-jr|cli is just a testing tool though; it doesn't need to be convenient
315 2017-11-16 19:18:50	0|luke-jr|gmaxwell: that's the current code
316 2017-11-16 19:18:58	0|jonasschnelli|gmaxwell: I think you will quickly choose the wrong wallet
317 2017-11-16 19:19:12	0|wumpus|gmaxwell: it's somewhat dangerous; easy to type a command with the wrong one selected
318 2017-11-16 19:19:18	0|jtimon|gmaxwell: some people are worried about a state, not sure what the problem is either
319 2017-11-16 19:19:24	0|gmaxwell|luke-jr: that is not true. cli is probably about as frequently used for using the software as the gui (this probably says some unfortunate things about the gui, but.. :P )
320 2017-11-16 19:19:35	0|luke-jr|could do both, I guess
321 2017-11-16 19:19:38	0|luke-jr|gmaxwell: I highly doubt that!
322 2017-11-16 19:19:48	0|achow101|luke-jr: I think there could be some weird interactions with doing both
323 2017-11-16 19:19:56	0|wumpus|gmaxwell: there is no clear visual link between what you type and the combobox, though it could be somehow improved by logging in big colorful letters when a different wallet is selected
324 2017-11-16 19:19:59	0|luke-jr|both = combobox with in-command override only when no-wallet selected
325 2017-11-16 19:20:04	0|wumpus|e.g. ============ current wallet: blabla.dat ===============
326 2017-11-16 19:20:11	0|gmaxwell|wumpus: thats a point, the prompt to could also show the wallet.
327 2017-11-16 19:20:22	0|wumpus|gmaxwell: yes, indeed
328 2017-11-16 19:20:23	0|gmaxwell|and there could be a line written in when it chages, like that.
329 2017-11-16 19:20:32	0|jtimon|how is it going to be with the cli again?
330 2017-11-16 19:20:42	0|luke-jr|jtimon: no changes needed there
331 2017-11-16 19:20:58	0|wumpus|jtimon: for the cli you have to provide the wallet name on every call to select the endpoint ,if it's ambigious, nothing will change there
332 2017-11-16 19:21:12	0|gmaxwell|jtimon: cli makes you specify it as a dashed argument to bitcoin-cli, which is a bit obnoxious but works.
333 2017-11-16 19:21:13	0|wumpus|decision is to be made about the console
334 2017-11-16 19:21:17	0|wumpus|but seems a combobox will do for now
335 2017-11-16 19:21:22	0|wumpus|so leave it like that for now luke-jr
336 2017-11-16 19:21:25	0|luke-jr|k
337 2017-11-16 19:21:42	0|jtimon|I see, thanks. just like you have to provide testnet or regtest every time but you don't need that in the GUI
338 2017-11-16 19:21:42	0|promag|Next?
339 2017-11-16 19:21:50	0|wumpus|jtimon: yep
340 2017-11-16 19:21:59	0|wumpus|GUI can keep state for you that the cli cannot
341 2017-11-16 19:22:12	0|wumpus|because it 'captures' the user, unlike a command that's launched every time
342 2017-11-16 19:22:26	0|wumpus|yes, other topics?
343 2017-11-16 19:22:51	0|achow101|topic suggestion: encrypted wallets by default
344 2017-11-16 19:22:52	0|promag|Flat options in rpc?
345 2017-11-16 19:23:12	0|wumpus|#topic encrypted wallets by default
346 2017-11-16 19:23:19	0|jtimon|I wanted to ask jl2012 about #11398
347 2017-11-16 19:23:21	0|gribble|https://github.com/bitcoin/bitcoin/issues/11398 | Hardcode CSV and SEGWIT deployment by jl2012 · Pull Request #11398 · bitcoin/bitcoin · GitHub
348 2017-11-16 19:23:28	0|wumpus|... why??
349 2017-11-16 19:23:39	0|morcos|can someone open an issue about deciding wallet access from the console, i think shipping with it as i understand it to be now seems terrible, but i agree no reason to hold up progress on merging
350 2017-11-16 19:23:44	0|jonasschnelli|achow101: with an option to unencrypt later?
351 2017-11-16 19:24:00	0|achow101|jonasschnelli: I guess?
352 2017-11-16 19:24:04	0|sipa|wumpus: why what?
353 2017-11-16 19:24:10	0|wumpus|why encrypt the wallet by default?
354 2017-11-16 19:24:15	0|jonasschnelli|achow101: I think that would be great.
355 2017-11-16 19:24:25	0|gmaxwell|If you have users encrypt wallets when they open one without any value in it they will reliably lose the key.  The positive confirmation that the user is backed up like electrum has reduces that sort of risk.
356 2017-11-16 19:24:32	0|wumpus|it forces people to choose a passphrase which they'll probably forget
357 2017-11-16 19:24:34	0|achow101|a lot of wallet software do this now and I don't think people necessarily realize that their wallets are unencrypted until they go to the encrypt wallet option or rpc
358 2017-11-16 19:24:42	0|wumpus|I think most people lose money because of losing wallets or losing passphrases not theft
359 2017-11-16 19:24:52	0|wumpus|what thread model does encrypting wallets protect against anyhow?
360 2017-11-16 19:24:53	0|jonasschnelli|that true on the other hand
361 2017-11-16 19:25:11	0|jonasschnelli|Those who have access to support ticket systems of consumer wallets do know that
362 2017-11-16 19:25:22	0|luke-jr|wumpus: bad PR
363 2017-11-16 19:25:30	0|gmaxwell|Wallet encryption is mostly a tool for people to lose their money but feel better about it because its their own fault.    The great advantage of wallet encryption by default, as I'd see it, is resolving this mess of having to preserve unencrypted keys.
364 2017-11-16 19:25:35	0|morcos|couldn't we encrypt the wallet by default but not create the wallet by default
365 2017-11-16 19:25:46	0|morcos|so you solve the problem of them just clicking through the encryption aspect
366 2017-11-16 19:25:51	0|achow101|morcos: that was the idea I was thinking about
367 2017-11-16 19:25:59	0|gmaxwell|But for that advantage I would recommend a late initilization that doesn't create a wallet until you ask for an address... or go to encrypt it.
368 2017-11-16 19:26:07	0|achow101|you don't make the wallet until it is actually used, and only then do you prompt the user to make a wallet
369 2017-11-16 19:26:12	0|wumpus|I mean, the only use for encrypting wallets I see is: other people use your computer, and you're afraid of them copying the wallet but not installing a keylogger
370 2017-11-16 19:26:21	0|gmaxwell|+1 on the late initilization.
371 2017-11-16 19:26:25	0|wumpus|I don't think it protects against any other attacks
372 2017-11-16 19:26:47	0|morcos|wumpus: you dont think its useful for backups?
373 2017-11-16 19:26:49	0|gmaxwell|wumpus: well I really like encryption so that I know that I'm not accidentally going to send funds, but for that it's sufficient to make the key "yes" :P
374 2017-11-16 19:27:00	0|luke-jr|morcos: for backups you really want to encrypt the whole thing anyway
375 2017-11-16 19:27:08	0|achow101|I have a branch for late initialiation: https://github.com/achow101/bitcoin/tree/start-no-wallet
376 2017-11-16 19:27:08	0|gmaxwell|morcos: ^
377 2017-11-16 19:27:10	0|morcos|i suppose, maybe backups wasn't the right word
378 2017-11-16 19:27:11	0|achow101|it doesn't work right now
379 2017-11-16 19:27:31	0|morcos|maybe i meant having the wallet to check on things but not worrying too much about it
380 2017-11-16 19:27:35	0|wumpus|or maybe the case where e.g. malware in the browser sandbox can grab a fixed file from your computer, but there's no persistent access
381 2017-11-16 19:27:40	0|achow101|also encryption reduces the file size by like half because unencrypted keys are massive for some reason
382 2017-11-16 19:28:10	0|wumpus|another thing that will cause confusion is that for other wallets, the passphrase is the seed
383 2017-11-16 19:28:17	0|luke-jr|wumpus: even when it was introduced, it was acknowledged as mostly just a PR stunt
384 2017-11-16 19:28:21	0|jtimon|gmaxwell: I was actually scared to suggest a default key for "resolving this mess of having to preserve unencrypted keys"
385 2017-11-16 19:28:21	0|wumpus|so people will think that only keeping the passphrase is enough to keep access to their funds
386 2017-11-16 19:28:33	0|wumpus|there are already peple making that mistake now but it's rarer
387 2017-11-16 19:28:38	0|wumpus|(because you only have to choose it explicitly)
388 2017-11-16 19:28:41	0|luke-jr|achow101: huh? how?
389 2017-11-16 19:28:46	0|gmaxwell|+1 for late init,  +1 for positive confirmation recovery backup (like electrum);  -1 for more pressure to encrypt unless the last step is done, +1 for it if the last step is done.
390 2017-11-16 19:28:51	0|morcos|also, this might sound stupid, but if you have a Core-encrypted wallet, you at least know the balance, so you know whether it's worth trying to figure out how to unencrypt it
391 2017-11-16 19:29:02	0|wumpus|so no, I think focing people to choose a passphrase when first creating their wallet is a bad idea
392 2017-11-16 19:29:08	0|achow101|luke-jr: encrypted keys are way smaller than unencrypted ones
393 2017-11-16 19:29:15	0|morcos|+1 gmaxwells +/-1's
394 2017-11-16 19:29:21	0|luke-jr|how is that even possible?
395 2017-11-16 19:29:34	0|promag|Sorry have to be afk
396 2017-11-16 19:29:39	0|gmaxwell|luke-jr: because the unencryted keys use some brain damaged openssl encoding
397 2017-11-16 19:29:45	0|gmaxwell|that encludes all the curve parameters.
398 2017-11-16 19:29:45	0|wumpus|that's just an implementation detail htough; unencrypted keys could be stored smaller, too
399 2017-11-16 19:29:52	0|achow101|luke-jr: the format. unencrypted keys are DER format or something. they have the curve params in them
400 2017-11-16 19:29:56	0|wumpus|we could encrypt the wallet by default, with an empty passphrase
401 2017-11-16 19:30:03	0|luke-jr|ew
402 2017-11-16 19:30:06	0|gmaxwell|right, thats a reason to change the format, not a reason to encrypt.
403 2017-11-16 19:30:10	0|sipa|achow101: they have field params, curve params, generator, public key and private key in them :)
404 2017-11-16 19:30:18	0|sipa|and all of that in inefficient DER
405 2017-11-16 19:30:25	0|sipa|279 bytes total, iirc
406 2017-11-16 19:30:46	0|wumpus|yes it's terrible
407 2017-11-16 19:31:27	0|wumpus|and doesn't help with anything, if you're going to store the keys in redundant format at least pad it with something that provides error correction
408 2017-11-16 19:31:55	0|BlueMatt|I mean its error correction in case we forget our curve parameters...or something
409 2017-11-16 19:31:55	0|luke-jr|XD
410 2017-11-16 19:32:04	0|sipa|BlueMatt: we actually hardly look at it
411 2017-11-16 19:32:06	0|gmaxwell|wumpus: What are your thoughts on, long term:  delayed creation, at create time in the GUI force the user to write down a recovery code (like electrum does; force via reentry and copy/paste jamming).. and have a checkbox to encrypt there too?   recovery code would greatly offset all risks of loss, including lost the passphrase.
412 2017-11-16 19:32:18	0|luke-jr|at that size, just store 8 copies of it
413 2017-11-16 19:32:49	0|wumpus|gmaxwell: the recovery code would be the HD seed?
414 2017-11-16 19:32:54	0|gmaxwell|luke-jr: storing N copies of a key right next to each other hardly helps since disks tend to die a physical sector at a time.
415 2017-11-16 19:32:58	0|achow101|gmaxwell: recovery code as in something like bip39?
416 2017-11-16 19:32:59	0|gmaxwell|wumpus: yea, an encoding of the HD seed.
417 2017-11-16 19:33:04	0|wumpus|gmaxwell: that sounds great to me
418 2017-11-16 19:33:07	0|morcos|gmaxwell: encryption using recovery code?
419 2017-11-16 19:33:18	0|luke-jr|gmaxwell: sure, but in that case you're screwed with checksums too
420 2017-11-16 19:33:21	0|gmaxwell|achow101: not bip39 as it's a brainwallet scheme that can't encode arbritary data, but yes.
421 2017-11-16 19:33:31	0|morcos|i also like that idea, but i worry about the importing of private keys...  we'd have to put in a whole lot of warnings about that
422 2017-11-16 19:33:37	0|wumpus|achow101: more like other wallets lke electrum's seed phrase
423 2017-11-16 19:33:51	0|achow101|wumpus: yes, I would prefer using Electrum's scheme
424 2017-11-16 19:33:54	0|wumpus|achow101: (there's a BIP for it but I don't know the number)
425 2017-11-16 19:33:55	0|achow101|that's what we plan to do for Armory
426 2017-11-16 19:33:55	0|gmaxwell|morcos: I think we need to get to having an import tainted flag on wallets, and warnings about that.
427 2017-11-16 19:34:09	0|luke-jr|morcos: importing private keys is already considered dangerous and "never do this"
428 2017-11-16 19:34:22	0|wumpus|gmaxwell: I also greatly like the idea of not creating a wallet by default, so starting in no-wallet mode
429 2017-11-16 19:34:23	0|jtimon|so what's wrong with the "yes"/default/empty passphrase/key?
430 2017-11-16 19:34:33	0|jonasschnelli|the recovery phrase would be unencrypted?
431 2017-11-16 19:34:41	0|gmaxwell|achow101: ugg electrum itself. can't encode arbritary data, so it can't work with existing wallets. at least it's better than bip39.
432 2017-11-16 19:34:56	0|achow101|jonasschnelli: it would have to be to be able to recover from forgotten passwords
433 2017-11-16 19:35:26	0|achow101|gmaxwell: it can't? (I haven't really looked at it)
434 2017-11-16 19:35:28	0|jtimon|jonasschnelli: yes, would be public knowledge (and for the user it would be like if none was set) unless you actively set one
435 2017-11-16 19:35:34	0|jonasschnelli|achow101: I just worry about people storing those recovery phrases on phones and "plaintext "papers
436 2017-11-16 19:35:35	0|gmaxwell|jonasschnelli: I have mixed feelings about that.  I think a best practice is to have your recovery keys encrypted with a WEAK key,  like that insecure password your whole family knows; and there is no risk of it being forgotten... but which a burgler would likely be thwarted, but thats too complex to communicate.
437 2017-11-16 19:36:14	0|gmaxwell|jonasschnelli: but we should realize that risk of users losing a strong password is likely orders of magnitude more likely than a local in person attack.
438 2017-11-16 19:36:28	0|wumpus|it gets quite complex to manage if the recovery key is encrypted too
439 2017-11-16 19:36:38	0|jonasschnelli|gmaxwell: Indeed. Though people who can take care of a passphase should not be punished
440 2017-11-16 19:36:41	0|wumpus|there's the recovery key passphrase, the wallet passphrase,...
441 2017-11-16 19:36:47	0|gmaxwell|achow101: unless I'm confused (always likely) it's just a minor fixup of BIP39.
442 2017-11-16 19:37:16	0|luke-jr|BlueMatt: +1
443 2017-11-16 19:37:17	0|wumpus|BlueMatt: that's where the redundant key format is useful :)
444 2017-11-16 19:37:33	0|wumpus|BlueMatt: it greatly helps efficiently scanning for private keys on a disk :p
445 2017-11-16 19:37:39	0|BlueMatt|heh, I know
446 2017-11-16 19:37:50	0|gmaxwell|BlueMatt: yea, sure, anything key format should have e.g. somethin like the network magic then the private key then a 64 bit crc... and then its cheap to scan the media looking for it.
447 2017-11-16 19:37:55	0|wumpus|I don't think you can do a similar thing for the encrypted keys right now
448 2017-11-16 19:38:01	0|wumpus|not that they're any use without the master key
449 2017-11-16 19:38:28	0|BlueMatt|i mean ideally we'd have a clear tag on both so that such software can prompt the user with "found a wallet, please enter passphrase"
450 2017-11-16 19:38:36	0|BlueMatt|but now we're going down a rewrite-wallet-format rabbit hole
451 2017-11-16 19:38:39	0|gmaxwell|jonasschnelli: I don't know how to manage the multiple keys case. One possiblity would be to make the recovery key unencrypted by default, and have an advanced dialog that lets you set encryption for it. And support reading in encrypted ones.
452 2017-11-16 19:38:55	0|jonasschnelli|Yes. That would be great
453 2017-11-16 19:39:05	0|gmaxwell|jonasschnelli: I have a lovely suggestion for hardware wallet friendly KDFs for these things too.
454 2017-11-16 19:39:07	0|achow101|BlueMatt: I propose that we just deprecate the wallet :p
455 2017-11-16 19:39:10	0|morcos|May I make a meta suggestion.. I think we often lose progress on ideas like this by not having someone document what we discussed.  could we ask for volunteer every time we have a good discussion like this to draft up a plan.
456 2017-11-16 19:39:17	0|jtimon|ack on starting in no-wallet mode
457 2017-11-16 19:39:17	0|luke-jr|achow101: I get the feeling often
458 2017-11-16 19:39:23	0|jonasschnelli|gmaxwell: +1 (happy to hear)
459 2017-11-16 19:39:34	0|achow101|morcos: meeting notes writer
460 2017-11-16 19:39:50	0|achow101|morcos: he'll write the meeting notes sometime after exams this week
461 2017-11-16 19:39:53	0|wumpus|achow101: and then what, change it into an art project where you can look at blocks drifting by, without being able to do anything? :p
462 2017-11-16 19:40:23	0|luke-jr|wumpus: write a new one :p
463 2017-11-16 19:40:37	0|morcos|yeah but i mena more a focused thing... like after SF devcore -> plan for Segwit wallet  ;   this meeting -> plan for wallet encryption recovery code
464 2017-11-16 19:40:37	0|wumpus|luke-jr: you can do that without deprecating anything
465 2017-11-16 19:40:52	0|gmaxwell|the block drifting UI should play https://www.youtube.com/watch?v=8Z-fyNdnOKE in a loop.
466 2017-11-16 19:41:01	0|achow101|I'm scared to click that link
467 2017-11-16 19:41:07	0|gmaxwell|it's just music.
468 2017-11-16 19:41:18	0|gmaxwell|but we've trained you well.
469 2017-11-16 19:41:53	0|sipa|morcos: i've just posted a bit of a writeup/rant on wallet design and segwit support: https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2
470 2017-11-16 19:41:55	0|wumpus|morcos: yes, we shouldn't forget segwit wallet
471 2017-11-16 19:42:00	0|morcos|woohoo!
472 2017-11-16 19:42:03	0|wumpus|morcos: that's the thing people are actually waiting for now :)
473 2017-11-16 19:42:06	0|sdaftuar|sipa: thanks!
474 2017-11-16 19:42:09	0|gmaxwell|FWIW, sipa has been working on a stronger base=32 BCH code for things like private keys and stealth addresses; which could be an option for recovery codes.
475 2017-11-16 19:42:13	0|wumpus|sipa: nice!
476 2017-11-16 19:42:14	0|luke-jr|clicking that link won't have permissions for my audio :p
477 2017-11-16 19:42:23	0|BlueMatt|when segwit wallet
478 2017-11-16 19:42:32	0|achow101|sipa: cool!
479 2017-11-16 19:42:52	0|achow101|BlueMatt: soon(tm)
480 2017-11-16 19:43:21	0|luke-jr|(mini rant: using #include <…> for our own files is stupid)
481 2017-11-16 19:44:24	0|wumpus|luke-jr: sigh, the other alternative would have been to fix all relative includes, but that was discussed in detail in the PR and the one before it
482 2017-11-16 19:45:24	0|wumpus|luke-jr: so using #include "../primitive/block.h" in e.g. the wallet. This roots everything at the project root, which is just as unambigious and shorter...
483 2017-11-16 19:45:55	0|luke-jr|I just hope /usr/include/primitive/block.h gets ignored
484 2017-11-16 19:46:09	0|wumpus|that doesn't get ignored either with ""
485 2017-11-16 19:46:22	0|luke-jr|:|
486 2017-11-16 19:47:08	0|gmaxwell|obviously we need to rename every header file to filename_bitcoin_core_is_awesome.h
487 2017-11-16 19:47:09	0|wumpus|at least not the way we were using it, which is essentially as <>, I think if you use "" relatively you can avoid it
488 2017-11-16 19:48:04	0|luke-jr|gmaxwell: I'm thinking more of malware infecting builds this way
489 2017-11-16 19:48:04	0|wumpus|yep!
490 2017-11-16 19:48:21	0|wumpus|well if your build root is infected you're fucked anyway
491 2017-11-16 19:48:30	0|jnewbery|luke-jr: in any case, the PRs were open for a few months (much longer than I would have liked in fact). There was opportunity to comment on those PRs. I think the ship has sailed now.
492 2017-11-16 19:48:41	0|luke-jr|true
493 2017-11-16 19:48:58	0|wumpus|protecting against that is even more questionable than encrypting your wallet, against any possible realistic threat model
494 2017-11-16 19:49:46	0|gmaxwell|luke-jr: well if your host is compromised it's pretty unlikely that it would be limited to only tripping you up with shadowed include files.
495 2017-11-16 19:49:48	0|wumpus|jnewbery: indeed, it's almost as if he waited for it to be merged
496 2017-11-16 19:50:00	0|gribble|https://github.com/bitcoin/bitcoin/issues/11363 | net: Split socket create/connect by theuni · Pull Request #11363 · bitcoin/bitcoin · GitHub
497 2017-11-16 19:50:11	0|luke-jr|wumpus: just didn't notice it until rebasing on top of the merged code
498 2017-11-16 19:51:06	0|luke-jr|anyhow, #11383 rebase is done
499 2017-11-16 19:51:08	0|gribble|https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub
500 2017-11-16 19:51:18	0|jonasschnelli|^^
501 2017-11-16 19:52:34	0|jonasschnelli|thanks.. will test
502 2017-11-16 19:52:35	0|Dizzle|I like multiwallet. Thanks for working on it, luke-jr. I miss the classic multibit bulk walletting.
503 2017-11-16 19:52:42	0|wumpus|luke-jr: anyhow C/C++ including is fragile that way; possible modules https://clang.llvm.org/docs/Modules.html will improve that in the future
504 2017-11-16 19:53:14	0|sipa|yay c++20... which we'll switch to in 20125?
505 2017-11-16 19:53:21	0|sipa|*2025
506 2017-11-16 19:53:26	0|wumpus|yes, in 20125
507 2017-11-16 19:53:32	0|luke-jr|:x
508 2017-11-16 19:53:34	0|Chris_Stewart_5|ack
509 2017-11-16 19:53:37	0|meshcollider|lol
510 2017-11-16 19:53:40	0|jonasschnelli|heh
511 2017-11-16 19:53:54	0|gmaxwell|change in topic, anyone have recent stats for the number of remaining btc1 nodes-- which are likely about to become a distributed DOS attack on the bitcoin network?
512 2017-11-16 19:53:57	0|wumpus|BlueMatt: will add that one
513 2017-11-16 19:54:41	0|wumpus|#topic DDoS network stats
514 2017-11-16 19:55:00	0|meshcollider|gmaxwell:  https://coin.dance/nodes says 139 but maybe not what you're after?
515 2017-11-16 19:55:13	0|luke-jr|(I'm going to drop as soon as the meeting is officially over. I'll be back a few minutes later in case there's stuff to talk about)
516 2017-11-16 19:55:20	0|jonasschnelli|I can filter my seed crawler for uagent string?
517 2017-11-16 19:55:24	0|gmaxwell|meshcollider: ha. I didn't expect them to shut off that fast, I guess they were really almost all just a couple people sybling.
518 2017-11-16 19:55:54	0|gmaxwell|meshcollider: okay, probably not much to worry about.
519 2017-11-16 19:56:25	0|meshcollider|gmaxwell yeah lol there was a Reddit post which went into some detail showing 90% were hosted by AWS
520 2017-11-16 19:56:36	0|wumpus|PSA before the meeting is over: I want to collect corrupted leveldb files, if you have a leveldb corruption please patch https://github.com/bitcoin/bitcoin/pull/11674 and send me the indicated corrupted file.
521 2017-11-16 19:57:12	0|jonasschnelli|861 peers with "Bitcoin ABC" and 100% uptime during last two hours.
522 2017-11-16 19:57:25	0|luke-jr|jonasschnelli: that's just BCH
523 2017-11-16 19:57:26	0|achow101|gmaxwell: my btc1 node is connected to 34 other btc1 nodes, so at least 35
524 2017-11-16 19:57:27	0|meshcollider|ABC is not btc1
525 2017-11-16 19:57:37	0|BlueMatt|i mean its what we did 0.15.1 for, no?
526 2017-11-16 19:58:11	0|gmaxwell|BlueMatt: yes, sure I wanted to know how many there weer because if there were thousands I'd make a post on reddit to urge people to upgrade to 0.15+ seems it might not be needed.
527 2017-11-16 19:58:12	0|jonasschnelli|meshcollider: what uagent does btc1 uses?
528 2017-11-16 19:58:26	0|luke-jr|jonasschnelli: /Satoshi:1.*/
529 2017-11-16 19:58:31	0|jonasschnelli|ah
530 2017-11-16 19:58:43	0|achow101|jonasschnelli: most have a uacomment with "2x"
531 2017-11-16 19:58:47	0|jonasschnelli|107
532 2017-11-16 19:58:56	0|gmaxwell|with only 140ish it's pretty unlikely many nodes will get isolated behind them.
533 2017-11-16 19:59:26	0|achow101|what block were they forking at?
534 2017-11-16 19:59:31	0|achow101|(I need to add it to my site)
535 2017-11-16 19:59:35	0|gmaxwell|494784
536 2017-11-16 19:59:56	0|jtimon|weren't they using a naming just the same as bitcoin core but increasing a version? (ie 0.14.3)
537 2017-11-16 20:00:04	0|gmaxwell|hopefully someone will mine a couple blocks on that fork to help get those nodes disconnected.
538 2017-11-16 20:00:22	0|gmaxwell|jtimon: they made the major version 1.
539 2017-11-16 20:00:27	0|achow101|gmaxwell: a mining pool announced that they would go with the 2x fork regardless
540 2017-11-16 20:00:28	0|jtimon|oh, right
541 2017-11-16 20:00:29	0|jnewbery|won't they disconnect themselves once a valid block is found?
542 2017-11-16 20:00:35	0|wumpus|ding dong
543 2017-11-16 20:00:41	0|gmaxwell|achow101: that was 'bitpico' who is crazy.
544 2017-11-16 20:00:54	0|gmaxwell|it's meaningless.
545 2017-11-16 20:01:00	0|achow101|oh
546 2017-11-16 20:01:12	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-16-19.01.log.html
547 2017-11-16 20:01:12	0|lightningbot|Meeting ended Thu Nov 16 20:01:11 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
548 2017-11-16 20:01:12	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-16-19.01.html
549 2017-11-16 20:01:12	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-16-19.01.txt
550 2017-11-16 20:01:12	0|wumpus|#endmeeting
551 2017-11-16 21:44:48	0|jonasschnelli|gmaxwell: I'm happy to hear your bip39 successor HWW KDF idea...
552 2017-11-16 21:45:17	0|jonasschnelli|PBKDF2 with 2048 rounds seems not ideal (BIP39)
553 2017-11-16 21:46:17	0|sipa|jonasschnelli: the idea is a mechanism that allows you to enter the passphrase on a HW device, have the HW device outsource the hardening to a desktop computer (with more power) without revealing the passphrase
554 2017-11-16 21:46:27	0|sipa|and then being able to verify the computer did the hardening correctly
555 2017-11-16 21:46:52	0|jonasschnelli|+1
556 2017-11-16 21:47:03	0|sipa|adam back proposed a scheme for this a while ago, but it's purely CPU dependent
557 2017-11-16 21:47:18	0|sipa|whether it can be combined with memory hard hardening is an open question i think
558 2017-11-16 21:47:34	0|jonasschnelli|purely CPU is still much better then 2048-PBKDF
559 2017-11-16 21:47:41	0|sipa|haha, yes
560 2017-11-16 21:49:18	0|jonasschnelli|Somethine we (HWW company) do discuss regularly is how we can make the backup situation better.. a lot of things are involved. Bip39, sdcard, shamir's secret, notary services, etc.
561 2017-11-16 21:49:39	0|jonasschnelli|I'm not sure if a plain text seed dump (or BIP39) is something you want in a bank tresor
562 2017-11-16 22:11:49	0|goatpig|mdisc?
563 2017-11-16 22:12:20	0|jonasschnelli|mdisc?
564 2017-11-16 22:12:33	0|goatpig|it's basically a cdrom made out of rock
565 2017-11-16 22:12:36	0|goatpig|really really durable
566 2017-11-16 22:21:08	0|jcorgan|i'm not sure if the durability is really demonstrated, but i do have quite a few encrypted live boot images burned to them
567 2017-11-16 22:22:18	0|goatpig|it's hard to demonstrate in practice
568 2017-11-16 22:29:15	0|jcorgan|it's a bit like closed-source software, the media is trade secret, but independent testing was pretty good
569 2017-11-16 22:29:25	0|jcorgan|http://www.esystor.com/images/China_Lake_Full_Report.pdf
570 2017-11-16 22:30:13	0|goatpig|at any rate it's far superior to plain cd/dvds or nvram
571 2017-11-16 22:31:40	0|jcorgan|certainly. they're great for "encrypted live boot cold-storage resurrection system" discs scattered in a few places
572 2017-11-16 22:47:55	0|cfields|whoops, totally forgot about today's meeting :\