--- Day changed Thu Nov 16 2017
00:00 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds]     
00:06 -!- dat_ [cbdb59ee@gateway/web/freenode/ip.203.219.89.238] has joined #bitcoin-core-dev     
00:23 -!- checksauce [~checksauc@103.254.153.113] has joined #bitcoin-core-dev     
00:25 -!- LumberCartel [~randolf@96.53.47.42] has quit [Ping timeout: 240 seconds]     
00:25 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:26 < eck> random question: if leveldb already has its own WAL, then why does bitcoin need an in-memory cache/buffer for utxo updates
00:27 < wumpus> eck: because we can do it more efficient because we know the properties of the data and access patterns
00:27 < wumpus> eck: leveldb's caching is virtually useless for our use case, so we minimize their caches
00:28 < wumpus> why does a database implement its own caching if the OS already has a page cache'
00:28 -!- qoqsj [893bfccf@gateway/web/freenode/ip.137.59.252.207] has joined #bitcoin-core-dev     
00:28 < wumpus> would be similar :)
00:28 < 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
00:28 -!- LumberCartel [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
00:29 < eck> in this example you have bitcoin cache + leveldb cache + kernel page cache
00:29 -!- checksauce [~checksauc@103.254.153.113] has quit [Ping timeout: 248 seconds]     
00:29 < eck> that's a lot of caching layers
00:29 < wumpus> why would that be problematic? it's pretty much how modern platforms work, your CPU also has caches as different levels
00:30 < sipa> eck: there are a number of reasons why our caching provides functionality on top of LevelDB's
00:30 < sipa> one is that LevelDB inherently deals with serialized records, while our caching layer stores information using our native in-memory formats
00:30 < sipa> serialization and deserialization have a nontrivial cost
00:30 < wumpus> in any case, if you find a way to improve performance, go for it
00:31 < 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
00:32 < eck> maybe I can or cannot, just trying to make sure I understand the current state of affaris:
00:32 < eck> as i understand it, by default a full node today will flush to disk as infrequently as once every 24h
00:32 < 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
00:33 < sipa> this optimization saves us 90% of all I/O or more, depending on cache sizes
00:33 < sipa> because many UTXO entries get spent quickly after being created
00:33 < bitcoin-git> [bitcoin] laanwj pushed 9 new commits to master: https://github.com/bitcoin/bitcoin/compare/54aedc013744...3c098a8aa078
00:33 < bitcoin-git> bitcoin/master 1a44534 MeshCollider: scripted-diff: Replace #include "" with #include <> (ryanofsky)...
00:33 < bitcoin-git> bitcoin/master 5b56ec9 Wladimir J. van der Laan: qt: refactor: Use absolute include paths in .ui files
00:33 < bitcoin-git> bitcoin/master 0c71521 Wladimir J. van der Laan: build: Remove -I for everything but project root...
00:33 < eck> could you point me (rougly) to the part of the code i woudl oook at?
00:33 < wumpus> yes, leveldb does not do this for batches
00:34 < sipa> eck: coins.cpp
00:34 < wumpus> so if you queue both adds, updates, and deletes, they will actually get executed
00:34 < bitcoin-git> [bitcoin] laanwj closed pull request #11651: refactor: Make all #includes relative to project root (laanwj, MeshCollider, ryanofsky) (master...201711_absolute_includes) https://github.com/bitcoin/bitcoin/pull/11651
00:34 < sipa> yes, LevelDB's "batch" structure is literally an std::string
00:34 < wumpus> also leveldb's batch storage format is really inefficient with regard to memroy allocation, large consecutive memory areas
00:34 < wumpus> right
00:34 < sipa> with serialized write/erase operations in it
00:35 < 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.
00:35 < 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.
00:35 < 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
00:35 < sipa> right, the idea is to move the flushing to a background process that continuously flushes the oldest dirty cache entries
00:36 < sipa> but never gets too close to 'now', as to not interfere with our freshness optimization
00:36 < sipa> eck: cool
00:36 -!- jouke [~jouke@a80-100-203-151.adsl.xs4all.nl] has quit [Ping timeout: 240 seconds]     
00:39 -!- jouke [~jouke@a80-100-203-151.adsl.xs4all.nl] has joined #bitcoin-core-dev     
00:39 < eck> thanks everyone for your help, I will report back if I have further conclusions or questions
00:41 < sipa> yw!     
00:50 -!- ekrok_ [~ekrok@10.249.16.62.customer.cdi.no] has quit [Read error: Connection reset by peer]     
00:50 -!- ekrok_ [~ekrok@10.249.16.62.customer.cdi.no] has joined #bitcoin-core-dev     
00:51 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev     
00:52 -!- whphhg [~whphhg@unaffiliated/whphhg] has quit [Remote host closed the connection]     
00:52 -!- whphhg_ [~whphhg@unaffiliated/whphhg] has joined #bitcoin-core-dev     
00:52 -!- whphhg_ is now known as whphhg     
00:53 < eck> related, if I wanted to follow up with someone speifically about the storage layer, who is an expert?
00:54 < gmaxwell> just ask here.
00:54 < gmaxwell> other people would learn from your questions.
00:55 < 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
00:56 < wumpus> that's what sipa just explained
00:57 < eck> from my superfcial understanding, i would just write directly to leveldb and let it take care of the rest
00:57 < wumpus> that was the first thing that was tried, and perf was abysmal
00:57 < gmaxwell> eck: you can do that, it takes about a week to sync the chain that way on typical hardware.
00:57 < wumpus> that might work better with other databases, but not leveldb
00:58 < gmaxwell> everything else we've tried was basically an order of magnitude slower than leveldb.
00:58 < 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
00:58 < eck> interesting, I would like to / am willin g to repeat the experiment to verify it locally
00:59 < gmaxwell> eck: you can just set the dbcache to a minimal value and see the result for 95% of the effect.
00:59 < eck> ok, thanks
00:59 < wumpus> I have some old utxo database experiments here: https://github.com/laanwj/bitcoin  
01:00 < gmaxwell> eck: syncing the chain with every operation going to the database requires about 1 billion database updates.
01:00 < wumpus> maybe that's useful at least for seeing what files to touch...
01:00 -!- qoqsj [893bfccf@gateway/web/freenode/ip.137.59.252.207] has quit [Ping timeout: 260 seconds]     
01:01 < eck> generally though,i would account for the wallet db taking basically 0 time, right?
01:01 < 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
01:02 < gmaxwell> eck: I can't figure out why you think the wallet database would be involved at all.
01:02 < wumpus> wallet has nothing to do with this, when you benchmark this, I suggest you disable it compile-time
01:02 < gmaxwell> The wallet database uses reasources when you have wallets with loads of transactions and keys, otherwise it does nothing.
01:02 < eck> i don't care about the wallet database, it's slow but it's smalll
01:03 < wumpus> it's also only read at startup, and written when the wallet actually changes, which is infrequent for most people
01:03 < eck> my interest recently is syncing a g1-small GCE instance
01:03 < 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).
01:03 < eck> it has 1.5GB of memory, and essentially 0 disk I/O
01:03 -!- inimaxedwards [3306f193@gateway/web/freenode/ip.51.6.241.147] has joined #bitcoin-core-dev     
01:04 -!- inimaxedwards [3306f193@gateway/web/freenode/ip.51.6.241.147] has quit [Client Quit]     
01:04 < wumpus> it has terrible I/O, disabling caching is certainly not what you should look at
01:04 < eck> my instance on core right now is synicin at < 5% a *day*, which seems like there is some fundamental horkage in some layer
01:04 < wumpus> sync on a faster machine then copy over the state
01:04 < eck> yeah maybe
01:05 < gmaxwell> I think you might just be underestimating how much work is involved in syncing and how slow those instances are. :)
01:05 < wumpus> w/ the cloud thing, you could just hire one of the large instances for a day or so
01:05 < gmaxwell> with 1.5GB memory you may be able to increase the cache further without crashing, it will speed it up.
01:06 < eck> from what I can tell, on GCE they give you I/O capacity base on the disk size
01:07 < 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
01:07 < eck> so if you want 200 GB, you're basically on teh bottom wrung, even if you have a ton of cpu/memory
01:07 < 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 )
01:07 < 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
01:09 < eck> thanks all, I will definitely be in here asking about this gain
01:09 < gmaxwell> indeed, the only IO with a huge db cache is just writing blocks out to disk and the final flush.
01:09 < eck> I will ask more once I've done more research
01:10 < 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
01:11 -!- Antoinette31Kuhl [~Antoinett@ns334669.ip-5-196-64.eu] has quit [Remote host closed the connection]     
01:17 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-wgcshzttlkcvspys] has joined #bitcoin-core-dev     
01:19 -!- Edward48Beier [~Edward48B@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
01:20 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
01:21 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
01:29 -!- jadox [5d73fdbd@gateway/web/freenode/ip.93.115.253.189] has joined #bitcoin-core-dev     
01:30 -!- Edward48Beier [~Edward48B@ns334669.ip-5-196-64.eu] has quit [Remote host closed the connection]     
01:40 -!- jsfour [~jsfour@cpe-45-50-168-164.socal.res.rr.com] has joined #bitcoin-core-dev     
01:43 -!- Yasmeen76Emard [~Yasmeen76@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
01:45 -!- jsfour [~jsfour@cpe-45-50-168-164.socal.res.rr.com] has quit [Ping timeout: 246 seconds]     
01:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:50 -!- qposdf [893bfccf@gateway/web/freenode/ip.137.59.252.207] has joined #bitcoin-core-dev     
02:01 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-dhwbzyaiztrjsgvr] has quit [Quit: Connection closed for inactivity]     
02:02 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev     
02:04 -!- roconnor_ [~roconnor@host-45-78-201-152.dyn.295.ca] has quit [Ping timeout: 248 seconds]     
02:05 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
02:14 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
02:14 -!- jadox [5d73fdbd@gateway/web/freenode/ip.93.115.253.189] has quit [Ping timeout: 260 seconds]     
02:28 < 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?
02:28 < sipa> aha!
02:29 < sipa> Hash160(x) = RIPEMD160(SHA256(x))
02:29 -!- Yasmeen76Emard [~Yasmeen76@ns334669.ip-5-196-64.eu] has quit [Remote host closed the connection]     
02:29 < sipa> so given y=SHA256(x) you can compute Hash160(x) as RIPEMD160(y)
02:29 < meshcollider> Oh! Perfect :)
02:36 -!- Edgardo10Toy [~Edgardo10@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
02:49 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3c098a8aa078...66d46c7901b7
02:49 < bitcoin-git> bitcoin/master ec85248 John Newbery: [travis-ci] Only run linters on Pull Requests...
02:49 < bitcoin-git> bitcoin/master 66d46c7 Wladimir J. van der Laan: Merge #11699: [travis-ci] Only run linters on Pull Requests...
02:49 < bitcoin-git> [bitcoin] laanwj closed pull request #11699: [travis-ci] Only run linters on Pull Requests (master...lint_only_prs) https://github.com/bitcoin/bitcoin/pull/11699
02:50 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/66d46c7901b7...084f52f38dc2
02:50 < bitcoin-git> bitcoin/master 069215e practicalswift: Initialize recently introduced non-static class member lastCycles to zero in constructor...
02:50 < bitcoin-git> bitcoin/master 084f52f Wladimir J. van der Laan: Merge #11654: tests: Initialize recently introduced non-static class member lastCycles to zero in constructor...
02:50 < bitcoin-git> [bitcoin] laanwj closed pull request #11654: tests: Initialize recently introduced non-static class member lastCycles to zero in constructor (master...uninitialized-members) https://github.com/bitcoin/bitcoin/pull/11654
02:57 -!- asu [dfdfda46@gateway/web/freenode/ip.223.223.218.70] has joined #bitcoin-core-dev     
02:58 < asu> hi, all
02:58 < asu> i has a question.
02:59 < asu> i want to build a bitcoin p2p trade web
03:00 < asu> buy i found if my customer send 0.01bitcoin to another, the fee is 0.00027 bitcoin
03:01 < asu> but in localbitcoins.com, the fee is zero
03:02 < asu> how can i do it? thanks
03:02 < asu> who can help me
03:03 < kinlo> asu: that question is for #bitcoin, not for here
03:03 < asu> ok, thanks
03:04 < asu> where is the bitcoin irc?
03:04 < kinlo> just join #bitcoin
03:04 < asu> join #bitcoin
03:05 < kinlo> it's /join #bitcoin
03:05 < asu> thanks
03:11 < 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.
03:11 < 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 
03:12 < meshcollider> basically put the same input twice, once with the P2SH redeemScript and once with the witness redeemScript
03:13 < meshcollider> which is good to know but certainly not the cleanest way to do it
03:14 < kgc> yeah
03:14 < kgc> I made a suggestion how to potentially clean it up a bit, but that's already for you to decide change or not :)
03:16 < meshcollider> kgc: I'm working on something right now here: github.com/MeshCollider/bitcoin/tree/201711_signrawtransaction_wsh
03:16 < meshcollider> haven't tested yet
03:18 < kgc> good to know
03:19 < 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
03:19 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
03:20 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
03:21 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds]     
03:24 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/084f52f38dc2...99bc0b428b03
03:24 < bitcoin-git> bitcoin/master 28f8b66 Eelis: Diagnose unsuitable outputs in lockunspent()....
03:24 < bitcoin-git> bitcoin/master 99bc0b4 Wladimir J. van der Laan: Merge #11087: Diagnose unsuitable outputs in lockunspent()....
03:24 < bitcoin-git> [bitcoin] laanwj closed pull request #11087: Diagnose unsuitable outputs in lockunspent(). (master...lockunspent) https://github.com/bitcoin/bitcoin/pull/11087
03:41 -!- jsfour [~jsfour@cpe-45-50-168-164.socal.res.rr.com] has joined #bitcoin-core-dev     
03:43 < wumpus> re: https://github.com/bitcoin/bitcoin/pull/11281#discussion_r151390218   
03:43 < wumpus> is there anything that makes scanning blocks out of order go wrong?
03:43 < wumpus> (maybe when there are chains of transactions depending on each other?)
03:44 < wumpus> in that case we'd want to disable scanning of the wallet of incoming blocks when it is rescanning
03:45 < wumpus> and we would need logic to backtrack in case of reorgs 
03:45 -!- jsfour [~jsfour@cpe-45-50-168-164.socal.res.rr.com] has quit [Ping timeout: 240 seconds]     
03:48 -!- asu [dfdfda46@gateway/web/freenode/ip.223.223.218.70] has quit [Ping timeout: 260 seconds]     
03:56 -!- qposdf [893bfccf@gateway/web/freenode/ip.137.59.252.207] has quit [Ping timeout: 260 seconds]     
04:02 -!- jsfour [~jsfour@cpe-45-50-168-164.socal.res.rr.com] has joined #bitcoin-core-dev     
04:05 -!- shesek [~shesek@5.102.229.206] has joined #bitcoin-core-dev     
04:05 -!- shesek [~shesek@5.102.229.206] has quit [Changing host]     
04:05 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev     
04:07 -!- jsfour [~jsfour@cpe-45-50-168-164.socal.res.rr.com] has quit [Ping timeout: 246 seconds]     
04:18 -!- jsfour [~jsfour@cpe-45-50-168-164.socal.res.rr.com] has joined #bitcoin-core-dev     
04:20 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 268 seconds]     
04:21 -!- mxg [~mxg@cpe-74-73-140-155.nyc.res.rr.com] has joined #bitcoin-core-dev     
04:22 -!- jsfour [~jsfour@cpe-45-50-168-164.socal.res.rr.com] has quit [Ping timeout: 248 seconds]     
04:40 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
04:45 -!- lex11 [~Mutter@2607:fb90:525b:bd27:c8e7:c3c4:2970:edd2] has joined #bitcoin-core-dev     
04:47 -!- lex11 [~Mutter@2607:fb90:525b:bd27:c8e7:c3c4:2970:edd2] has quit [Client Quit]     
04:51 -!- mxg [~mxg@cpe-74-73-140-155.nyc.res.rr.com] has quit [Quit: brb]     
04:51 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
04:52 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
04:57 < bitcoin-git> [bitcoin] sipsorcery opened pull request #11704: Windows build doc update (master...windoc) https://github.com/bitcoin/bitcoin/pull/11704
05:02 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]     
05:18 -!- Gnof [~Gnof@CPE00fc8d7da303-CM00fc8d7da300.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev     
05:39 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has joined #bitcoin-core-dev     
05:44 -!- Gnof [~Gnof@CPE00fc8d7da303-CM00fc8d7da300.cpe.net.cable.rogers.com] has quit [Quit: ---]     
05:46 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
05:49 -!- roconnor_ [~roconnor@host-192.252-163-122.dyn.295.ca] has joined #bitcoin-core-dev     
06:00 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
06:14 -!- bitstr3am [~Mutter@50-47-107-125.evrt.wa.frontiernet.net] has joined #bitcoin-core-dev     
06:15 -!- dat_ [cbdb59ee@gateway/web/freenode/ip.203.219.89.238] has quit [Ping timeout: 260 seconds]     
06:16 -!- blockchain [~linux@178.237.154.22] has joined #bitcoin-core-dev     
06:17 -!- bitstr3am [~Mutter@50-47-107-125.evrt.wa.frontiernet.net] has quit [Client Quit]     
06:19 -!- jsfour [~jsfour@cpe-45-50-168-164.socal.res.rr.com] has joined #bitcoin-core-dev     
06:21 -!- indistylo [~indistylo@119.82.105.106] has quit [Ping timeout: 248 seconds]     
06:22 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-hjojabgfvtcxamsj] has quit [Quit: Connection closed for inactivity]     
06:23 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev     
06:23 -!- jsfour [~jsfour@cpe-45-50-168-164.socal.res.rr.com] has quit [Ping timeout: 246 seconds]     
06:24 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 248 seconds]     
06:27 -!- lukedashjr is now known as luke-jr     
06:45 -!- jsfour [~jsfour@cpe-45-50-168-164.socal.res.rr.com] has joined #bitcoin-core-dev     
06:46 < bitcoin-git> [bitcoin] laanwj closed pull request #10772: Implementation of BIP8 (master...bip8-height) https://github.com/bitcoin/bitcoin/pull/10772
06:47 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host]     
06:47 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #bitcoin-core-dev     
06:49 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
06:49 -!- coin_trader [~coin_trad@2604:2000:14c4:8161:1061:8c43:a461:9373] has quit [Ping timeout: 252 seconds]     
06:50 -!- jsfour [~jsfour@cpe-45-50-168-164.socal.res.rr.com] has quit [Ping timeout: 248 seconds]     
06:50 -!- coin_trader [~coin_trad@2604:2000:14c4:8161:f9ed:cf0f:3f28:72a4] has joined #bitcoin-core-dev     
06:51 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
06:59 -!- lex11 [~Mutter@2607:fb90:9040:ccae:5df3:a4ec:34d7:d46c] has joined #bitcoin-core-dev     
07:02 -!- lex11 [~Mutter@2607:fb90:9040:ccae:5df3:a4ec:34d7:d46c] has quit [Client Quit]     
07:16 < bitcoin-git> [bitcoin] zhaokexun opened pull request #11705: 0.15 (master...0.15) https://github.com/bitcoin/bitcoin/pull/11705
07:17 < bitcoin-git> [bitcoin] laanwj closed pull request #11705: 0.15 (master...0.15) https://github.com/bitcoin/bitcoin/pull/11705
07:19 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds]     
07:27 -!- lex11 [~Mutter@2607:fb90:9040:ccae:5df3:a4ec:34d7:d46c] has joined #bitcoin-core-dev     
07:33 -!- lex11 [~Mutter@2607:fb90:9040:ccae:5df3:a4ec:34d7:d46c] has quit [Remote host closed the connection]     
07:33 -!- lex11 [~Mutter@2607:fb90:9040:ccae:5df3:a4ec:34d7:d46c] has joined #bitcoin-core-dev     
07:34 -!- jcorgan [~jcorgan@64-142-68-61.dsl.static.sonic.net] has quit [Changing host]     
07:34 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev     
07:36 -!- lex11 [~Mutter@2607:fb90:9040:ccae:5df3:a4ec:34d7:d46c] has quit [Client Quit]     
07:40 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
07:57 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 240 seconds]     
08:01 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
08:21 -!- indistylo [~indistylo@122.167.222.235] has joined #bitcoin-core-dev     
08:26 < BlueMatt> wumpus: do you want a followup pr to #11686 ?
08:26 < 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
08:28 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
08:28 < wumpus> BlueMatt: I think it'd make sense, but I don't really want to turn it into a controversial topic
08:29 < BlueMatt> oh I dont think anyone cares *that* much, I was just curious if you want more pr volume
08:29 < BlueMatt> its also a github md file, not like we need to have big review cycles on it.......
08:29 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
08:34 -!- Khunbish [~Khunbish@213.108-247-81.adsl-dyn.isp.belgacom.be] has joined #bitcoin-core-dev     
08:35 -!- m8tion01 [~m8tion@81-65-53-254.rev.numericable.fr] has quit [Read error: Connection reset by peer]     
08:37 -!- LumberCartel [~randolf@96.53.47.42] has quit [Ping timeout: 260 seconds]     
08:37 < wumpus> right, a change to a github md isn't so bad with regards to PR volume
08:37 < BlueMatt> k, I'll tweak it again
08:37 < wumpus> thanks :)
08:44 -!- cbag [4d397228@gateway/web/freenode/ip.77.57.114.40] has joined #bitcoin-core-dev     
08:46 -!- jsfour [~jsfour@cpe-45-50-168-164.socal.res.rr.com] has joined #bitcoin-core-dev     
08:50 -!- jsfour [~jsfour@cpe-45-50-168-164.socal.res.rr.com] has quit [Ping timeout: 240 seconds]     
08:50 -!- sunday-afternoon [~jack@66-188-250-34.dhcp.eucl.wi.charter.com] has joined #bitcoin-core-dev     
08:51 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #11706: Make default issue text all comments to make issues more readable (master...2017-11-shorter-default-issue-redux) https://github.com/bitcoin/bitcoin/pull/11706
08:51 < BlueMatt> wumpus: ^
08:55 -!- chartractegg [~chartract@gateway/vpn/privateinternetaccess/chartractegg] has joined #bitcoin-core-dev     
08:56 -!- chartractegg [~chartract@gateway/vpn/privateinternetaccess/chartractegg] has quit [Client Quit]     
09:04 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
09:04 -!- indistylo [~indistylo@122.167.222.235] has quit [Remote host closed the connection]     
09:06 -!- LumberCartel [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
09:24 -!- jsfour [~jsfour@cpe-45-50-168-164.socal.res.rr.com] has joined #bitcoin-core-dev     
09:25 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
09:29 -!- jsfour [~jsfour@cpe-45-50-168-164.socal.res.rr.com] has quit [Ping timeout: 260 seconds]     
09:29 -!- kk_ [5e075e24@gateway/web/freenode/ip.94.7.94.36] has joined #bitcoin-core-dev     
09:33 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
09:43 -!- LumberCartel [~randolf@96.53.47.42] has quit [Ping timeout: 240 seconds]     
09:44 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev     
09:47 -!- jsfour [~jsfour@cpe-76-90-140-31.socal.res.rr.com] has joined #bitcoin-core-dev     
09:55 -!- cbag [4d397228@gateway/web/freenode/ip.77.57.114.40] has quit [Ping timeout: 260 seconds]     
10:01 -!- LumberCartel [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
10:04 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
10:34 -!- kk_ [5e075e24@gateway/web/freenode/ip.94.7.94.36] has quit [Quit: Page closed]     
10:36 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
10:36 -!- sh4ft [a2df8f04@gateway/web/freenode/ip.162.223.143.4] has joined #bitcoin-core-dev     
10:39 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wthlscpkleyhtmoe] has joined #bitcoin-core-dev     
10:42 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Quit: Leaving]     
10:42 -!- sipa [~pw@2001:19f0:ac01:2fb:5400:ff:fe5b:c3ff] has quit [Changing host]     
10:42 -!- sipa [~pw@unaffiliated/sipa1024] has joined #bitcoin-core-dev     
10:43 -!- tux3do [~tux3do@ip72-201-18-238.ph.ph.cox.net] has joined #bitcoin-core-dev     
10:43 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Quit: laurentmt]     
10:54 -!- JackH [~laptop@alvira.static.korbank.pl] has joined #bitcoin-core-dev     
10:55 < bitcoin-git> [bitcoin] jnewbery opened pull request #11707: [tests] Fix sendheaders (master...fix_sendheaders) https://github.com/bitcoin/bitcoin/pull/11707
10:55 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-seezadxfjsnlyzyn] has joined #bitcoin-core-dev     
11:00 < achow101> meeting?
11:00 < luke-jr> hajimemashite?
11:01 < wumpus> #startmeeting
11:01 < lightningbot> Meeting started Thu Nov 16 19:01:04 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:01 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:01 < 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
11:01 < sipa> present
11:01 < achow101> hi     
11:01 < jtimon> hi     
11:01 < meshcollider> hello
11:01 < gmaxwell> hi     
11:01 < sdaftuar> ack     
11:01 < jonasschnelli> hi     
11:01 < gmaxwell> will be back in 10 minutes, maybe the meeting won't be over by then. :P
11:02 < wumpus> #topic high priority for review
11:02 < BlueMatt> new high-priority for me: #11639
11:02 < 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
11:02 < kanzure> hi.     
11:02 < wumpus> only four things left https://github.com/bitcoin/bitcoin/projects/8
11:03 < 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)
11:03 < 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
11:03 -!- promag [57c450b0@gateway/web/freenode/ip.87.196.80.176] has joined #bitcoin-core-dev     
11:03 < wumpus> added 11639
11:03 < promag> Hi     
11:04 < luke-jr> should #11383 be on there? I can rebase after the meeting
11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub
11:04 -!- Cogito_Ergo_Sum [~Myself@athedsl-4564842.home.otenet.gr] has joined #bitcoin-core-dev     
11:04 -!- Cogito_Ergo_Sum [~Myself@athedsl-4564842.home.otenet.gr] has quit [Changing host]     
11:04 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #bitcoin-core-dev     
11:05 < wumpus> luke-jr: added
11:05 < bitcoin-git> [bitcoin] luke-jr closed pull request #10391: OP_CHECKBLOCKATHEIGHT anti-replay (BIP 115; logic only) (master...cbah) https://github.com/bitcoin/bitcoin/pull/10391
11:06 < promag> Rpc console still only for 1st wallet right?
11:06 < luke-jr> promag: that PR has an independent combobox for the debug window
11:06 < luke-jr> (including a "no wallet" option)
11:07 < promag> Should rebase on dynamic wallet loading? Or vice-versa?
11:07 < wumpus> #topic rpc console for multi wallet
11:07 < jonasschnelli> The dropdown seems okay isch.
11:07 < luke-jr> promag: IMO GUI should go before dynamic loading
11:07 < jonasschnelli> Ideally we would have a higher-level visual selector
11:07 < promag> Kk     
11:07 < luke-jr> jonasschnelli: ?
11:07 < jonasschnelli> luke-jr: agree
11:08 < jonasschnelli> luke-jr: it confusing to have a wallet level switch in the console
11:08 < jtimon> what's wrong with the combobox ?
11:08 < jonasschnelli> But I don't see another simple way
11:08 < promag> One thing that bothers me with the combo is that the gui state is lost
11:08 < luke-jr> maybe improvements there can be made after merge, if someone thinks of a better way
11:08 < luke-jr> promag: ?
11:08 < 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
11:09 < wumpus> the combobox is ok
11:09 < jonasschnelli> I think its an acceptable first step
11:09 < promag> Like list scroll position, selection, focus, etc
11:09 < sipa> pieter was here
11:09 < wumpus> the debug window is supposed to be separate from the main GUI, having it influence what wallet is selected is even more confusing
11:09 < jtimon> I think it's perfectly fine for the debug console to be flexible like this. seems just handy to put it there
11:09 < wumpus> yes     
11:09 < promag> Another option is one tab per wallet
11:10 < wumpus> no, please not
11:10 < 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
11:10 < 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
11:10 < wumpus> meh     
11:10 < achow101> then users can change the wallet if they want to
11:11 < jonasschnelli> I think the dropbox is still the best solution on the table,... (even if not ideal)
11:11 < jtimon> that sounds reasonable to me
11:11 < 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
11:11 < wumpus> okay, any other topic?
11:11 < luke-jr> sounds like we at least agree it's a post-merge topic XD
11:11 < jonasschnelli> ack     
11:11 < jtimon> oh, if it's a mess in the code, I'm not sure it's worth it. I'll shut up
11:11 < promag> wumpus: btw why not tabs? 
11:12 < wumpus> promag: multiple tabs with the same console just pointing at a different wallet sounds terrible to me
11:12 < jtimon> spaces are better
11:12 < jonasschnelli> promag: most calls are pure node calls...
11:12  * jtimon hidfdes
11:12 < wumpus> promag: the tabs are supposed to be for essentially different things
11:12 < promag> At least you keep track of the correct log
11:12 < wumpus> e.g. more charts, more pages of debug info, etc
11:12 < jnewbery> promag: multiwallet comes first, dynamic loading later
11:13 < jnewbery> *multiwallet GUI comes first
11:13 < promag> Anyway, ack on the order
11:13 < luke-jr> promag: perhaps a log entry after you execute a command on a different wallet than previously (post-merge stuff)
11:13 < promag> Ok ok
11:13 < wumpus> why not a command to switch between wallets, btw?
11:14 < wumpus> the combobox is great to show what the current wallet is, but shouldn't the wallet be switchable with typing?
11:14 < luke-jr> /wallet <name> ?
11:14 < wumpus> for ex.
11:14 < jonasschnelli> yes... ideally it would be stateless.
11:14 < jonasschnelli> to ensure one is not executing on the wrong wallet
11:14 < achow101> so it would be a gui only command?
11:14 < jonasschnelli> wallet:xyz getnewaddress
11:14 < wumpus> achow101: yes
11:14 < jonasschnelli> if wallet:<filename> is missing, we get the standard rpcish reject
11:14 < wumpus> jonasschnelli: type the wallet name for every command? yes, maybe
11:14 < promag> It could be part of the "prompt"
11:15 < MarcoFalke> Needs autocomplete!
11:15 < jonasschnelli> I think the wallet-selected-state can be dangerous
11:15 < wumpus> jonasschnelli: that's absolutely safest
11:15 < wumpus> jonasschnelli: agree
11:15 < jonasschnelli> and it's RPC like
11:15 < wumpus> yes     
11:15 < jonasschnelli> one can still use arrow-up edit
11:15 < jtimon> a gui only command doesn't feel right
11:16 < luke-jr> nesting is already GUI-only
11:16 < 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
11:16 < jonasschnelli> yes. It's fine
11:16 < luke-jr> is this still post-merge, or have we un-concept-ack'd the MW GUI PR?
11:17 < promag> Even when there is 1 wallet only?
11:17 < MarcoFalke> promag: No
11:17 < wumpus> promag: that's the exception
11:17 < jonasschnelli> luke-jr: both would be okay for me (post merge or now)
11:17 < wumpus> if it is unambigious then why not
11:17 < wumpus> wallet needs to be provided if multiple wallets are loaded
11:17 < promag> Ack     
11:17 < luke-jr> wumpus: because it'd be really annoying to use?
11:17 < wumpus> if no wallet is loaded, there's no problem, if one wallet is loaded, then it's clear which one is meant
11:18 < wumpus> if mutliple are loaded then wallet commands are ambigious
11:18 < promag> It's the same with cli
11:18 < wumpus> yes, it's the same with bitcoin-cli
11:18 < jonasschnelli> It's maybe annoying... but it's the wallet. Safety first
11:18 < luke-jr> cli is just a testing tool though; it doesn't need to be convenient
11:18 < gmaxwell> why wouldn't the debug window just have a combo box
11:18 < luke-jr> gmaxwell: that's the current code
11:18 < jonasschnelli> gmaxwell: I think you will quickly choose the wrong wallet
11:19 < wumpus> gmaxwell: it's somewhat dangerous; easy to type a command with the wrong one selected
11:19 < jtimon> gmaxwell: some people are worried about a state, not sure what the problem is either
11:19 < 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 )
11:19 < luke-jr> could do both, I guess
11:19 < luke-jr> gmaxwell: I highly doubt that!
11:19 < achow101> luke-jr: I think there could be some weird interactions with doing both
11:19 < 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
11:19 < luke-jr> both = combobox with in-command override only when no-wallet selected
11:20 < wumpus> e.g. ============ current wallet: blabla.dat ===============
11:20 < gmaxwell> wumpus: thats a point, the prompt to could also show the wallet.
11:20 < wumpus> gmaxwell: yes, indeed
11:20 < gmaxwell> and there could be a line written in when it chages, like that.
11:20 < jtimon> how is it going to be with the cli again?
11:20 < luke-jr> jtimon: no changes needed there
11:20 < 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
11:21 < gmaxwell> jtimon: cli makes you specify it as a dashed argument to bitcoin-cli, which is a bit obnoxious but works.
11:21 < wumpus> decision is to be made about the console
11:21 < wumpus> but seems a combobox will do for now
11:21 < wumpus> so leave it like that for now luke-jr
11:21 < luke-jr> k     
11:21 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
11:21 < promag> Next?
11:21 < jtimon> I see, thanks. just like you have to provide testnet or regtest every time but you don't need that in the GUI
11:21 < wumpus> jtimon: yep
11:21 < wumpus> GUI can keep state for you that the cli cannot
11:22 < wumpus> because it 'captures' the user, unlike a command that's launched every time
11:22 < wumpus> yes, other topics?
11:22 < achow101> topic suggestion: encrypted wallets by default
11:22 < promag> Flat options in rpc?
11:23 < wumpus> #topic encrypted wallets by default
11:23 < jtimon> I wanted to ask jl2012 about #11398
11:23 < gribble> https://github.com/bitcoin/bitcoin/issues/11398 | Hardcode CSV and SEGWIT deployment by jl2012 · Pull Request #11398 · bitcoin/bitcoin · GitHub
11:23 < wumpus> ... why??
11:23 < 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
11:23 < jonasschnelli> achow101: with an option to unencrypt later?
11:23 < achow101> jonasschnelli: I guess?
11:24 < sipa> wumpus: why what?
11:24 < wumpus> why encrypt the wallet by default?
11:24 < jonasschnelli> achow101: I think that would be great.
11:24 < 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. 
11:24 < wumpus> it forces people to choose a passphrase which they'll probably forget
11:24 < 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
11:24 < wumpus> I think most people lose money because of losing wallets or losing passphrases not theft
11:24 < wumpus> what thread model does encrypting wallets protect against anyhow?
11:24 < jonasschnelli> that true on the other hand
11:25 < jonasschnelli> Those who have access to support ticket systems of consumer wallets do know that
11:25 < luke-jr> wumpus: bad PR
11:25 < 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.
11:25 < morcos> couldn't we encrypt the wallet by default but not create the wallet by default
11:25 < morcos> so you solve the problem of them just clicking through the encryption aspect
11:25 < achow101> morcos: that was the idea I was thinking about
11:25 < 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.
11:26 < achow101> you don't make the wallet until it is actually used, and only then do you prompt the user to make a wallet
11:26 < 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
11:26 < gmaxwell> +1 on the late initilization. 
11:26 < wumpus> I don't think it protects against any other attacks
11:26 < morcos> wumpus: you dont think its useful for backups?
11:26 < 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
11:26 < luke-jr> morcos: for backups you really want to encrypt the whole thing anyway
11:27 < gmaxwell> morcos: ^
11:27 < achow101> I have a branch for late initialiation: https://github.com/achow101/bitcoin/tree/start-no-wallet
11:27 < morcos> i suppose, maybe backups wasn't the right word
11:27 < achow101> it doesn't work right now
11:27 < morcos> maybe i meant having the wallet to check on things but not worrying too much about it
11:27 < 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
11:27 < achow101> also encryption reduces the file size by like half because unencrypted keys are massive for some reason
11:28 < wumpus> another thing that will cause confusion is that for other wallets, the passphrase is the seed
11:28 < luke-jr> wumpus: even when it was introduced, it was acknowledged as mostly just a PR stunt
11:28 < wumpus> so people will think that only keeping the passphrase is enough to keep access to their funds
11:28 < jtimon> gmaxwell: I was actually scared to suggest a default key for "resolving this mess of having to preserve unencrypted keys"
11:28 < wumpus> there are already peple making that mistake now but it's rarer 
11:28 < wumpus> (because you only have to choose it explicitly)
11:28 < luke-jr> achow101: huh? how?
11:28 -!- pugsh [~adam@pug.sh] has joined #bitcoin-core-dev     
11:28 < 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. 
11:28 < 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
11:29 < wumpus> so no, I think focing people to choose a passphrase when first creating their wallet is a bad idea
11:29 < achow101> luke-jr: encrypted keys are way smaller than unencrypted ones
11:29 < morcos> +1 gmaxwells +/-1's
11:29 < luke-jr> how is that even possible?
11:29 < promag> Sorry have to be afk
11:29 < gmaxwell> luke-jr: because the unencryted keys use some brain damaged openssl encoding
11:29 < gmaxwell> that encludes all the curve parameters.
11:29 < wumpus> that's just an implementation detail htough; unencrypted keys could be stored smaller, too
11:29 < achow101> luke-jr: the format. unencrypted keys are DER format or something. they have the curve params in them
11:29 < wumpus> we could encrypt the wallet by default, with an empty passphrase
11:30 < luke-jr> ew     
11:30 < gmaxwell> right, thats a reason to change the format, not a reason to encrypt.
11:30 < sipa> achow101: they have field params, curve params, generator, public key and private key in them :)
11:30 < sipa> and all of that in inefficient DER
11:30 < sipa> 279 bytes total, iirc
11:30 < wumpus> yes it's terrible
11:31 < 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
11:31 < BlueMatt> I mean its error correction in case we forget our curve parameters...or something
11:31 < luke-jr> XD     
11:32 < sipa> BlueMatt: we actually hardly look at it
11:32 < 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.
11:32 < luke-jr> at that size, just store 8 copies of it
11:32 < wumpus> gmaxwell: the recovery code would be the HD seed?
11:32 < 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. 
11:32 < achow101> gmaxwell: recovery code as in something like bip39?
11:32 < gmaxwell> wumpus: yea, an encoding of the HD seed.
11:33 < wumpus> gmaxwell: that sounds great to me
11:33 < morcos> gmaxwell: encryption using recovery code?
11:33 < luke-jr> gmaxwell: sure, but in that case you're screwed with checksums too
11:33 < gmaxwell> achow101: not bip39 as it's a brainwallet scheme that can't encode arbritary data, but yes.
11:33 < 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
11:33 < wumpus> achow101: more like other wallets lke electrum's seed phrase
11:33 < achow101> wumpus: yes, I would prefer using Electrum's scheme
11:33 < wumpus> achow101: (there's a BIP for it but I don't know the number)
11:33 < gmaxwell> morcos: I think we need to get to having an import tainted flag on wallets, and warnings about that.
11:33 < achow101> that's what we plan to do for Armory
11:34 < luke-jr> morcos: importing private keys is already considered dangerous and "never do this"
11:34 < wumpus> gmaxwell: I also greatly like the idea of not creating a wallet by default, so starting in no-wallet mode
11:34 < jtimon> so what's wrong with the "yes"/default/empty passphrase/key?
11:34 < jonasschnelli> the recovery phrase would be unencrypted?
11:34 < 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.
11:34 < achow101> jonasschnelli: it would have to be to be able to recover from forgotten passwords
11:35 < achow101> gmaxwell: it can't? (I haven't really looked at it)
11:35 < jtimon> jonasschnelli: yes, would be public knowledge (and for the user it would be like if none was set) unless you actively set one
11:35 < jonasschnelli> achow101: I just worry about people storing those recovery phrases on phones and "plaintext "papers
11:35 < 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.
11:36 < 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. 
11:36 < wumpus> it gets quite complex to manage if the recovery key is encrypted too
11:36  * BlueMatt notes that if we do some kind of default-encryption-with-weak-password we should have a clear tag on keys to help out the "shitsihitshit, please scan entire raw disk for anything that looks like a key" use-case
11:36 < jonasschnelli> gmaxwell: Indeed. Though people who can take care of a passphase should not be punished
11:36 < wumpus> there's the recovery key passphrase, the wallet passphrase,...
11:36 < gmaxwell> achow101: unless I'm confused (always likely) it's just a minor fixup of BIP39.
11:37 < luke-jr> BlueMatt: +1
11:37 < wumpus> BlueMatt: that's where the redundant key format is useful :)
11:37 < wumpus> BlueMatt: it greatly helps efficiently scanning for private keys on a disk :p
11:37 < BlueMatt> heh, I know
11:37 < 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. 
11:37 < wumpus> I don't think you can do a similar thing for the encrypted keys right now
11:38 < wumpus> not that they're any use without the master key
11:38 < 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"
11:38 < BlueMatt> but now we're going down a rewrite-wallet-format rabbit hole
11:38 < 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.
11:38 < jonasschnelli> Yes. That would be great
11:39 < gmaxwell> jonasschnelli: I have a lovely suggestion for hardware wallet friendly KDFs for these things too. 
11:39 < achow101> BlueMatt: I propose that we just deprecate the wallet :p
11:39 < 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.
11:39 < luke-jr> achow101: I get the feeling often
11:39 < jtimon> ack on starting in no-wallet mode
11:39 < jonasschnelli> gmaxwell: +1 (happy to hear)
11:39 < achow101> morcos: meeting notes writer
11:39 < achow101> morcos: he'll write the meeting notes sometime after exams this week
11:39 < 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
11:40 < luke-jr> wumpus: write a new one :p
11:40 < wumpus> luke-jr: you can do that without deprecating anything
11:40 < 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
11:40 < gmaxwell> the block drifting UI should play https://www.youtube.com/watch?v=8Z-fyNdnOKE in a loop.
11:41 < achow101> I'm scared to click that link
11:41 < gmaxwell> it's just music.
11:41 < gmaxwell> but we've trained you well.
11:41 -!- promag [57c450b0@gateway/web/freenode/ip.87.196.80.176] has quit [Ping timeout: 260 seconds]     
11:41 < sipa> morcos: i've just posted a bit of a writeup/rant on wallet design and segwit support: https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2
11:41 < wumpus> morcos: yes, we shouldn't forget segwit wallet
11:41 < morcos> woohoo!
11:42 < wumpus> morcos: that's the thing people are actually waiting for now :)
11:42 < sdaftuar> sipa: thanks!
11:42 < 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.
11:42 < wumpus> sipa: nice!
11:42 < luke-jr> clicking that link won't have permissions for my audio :p
11:42 < BlueMatt> when segwit wallet
11:42 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
11:42 < achow101> sipa: cool!
11:42 < achow101> BlueMatt: soon(tm)
11:43 < luke-jr> (mini rant: using #include <…> for our own files is stupid)
11:44 < 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
11:44 -!- go1111111 [~elliot@199.231.240.191] has quit [Quit: Leaving]     
11:45 < 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...
11:45 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
11:45 < luke-jr> I just hope /usr/include/primitive/block.h gets ignored
11:46 < wumpus> that doesn't get ignored either with ""
11:46 < luke-jr> :|     
11:47 < gmaxwell> obviously we need to rename every header file to filename_bitcoin_core_is_awesome.h
11:47 < wumpus> at least not the way we were using it, which is essentially as <>, I think if you use "" relatively you can avoid it
11:48 < wumpus> yep!
11:48 < luke-jr> gmaxwell: I'm thinking more of malware infecting builds this way
11:48 < wumpus> well if your build root is infected you're fucked anyway
11:48 < 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.
11:48 < luke-jr> true
11:48 < wumpus> protecting against that is even more questionable than encrypting your wallet, against any possible realistic threat model
11:49 < 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.
11:49 < wumpus> jnewbery: indeed, it's almost as if he waited for it to be merged
11:49  * BlueMatt nominates #11363 for cfields' high-priority-for-review, cause he apparently isnt here...
11:49 < gribble> https://github.com/bitcoin/bitcoin/issues/11363 | net: Split socket create/connect by theuni · Pull Request #11363 · bitcoin/bitcoin · GitHub
11:50 < luke-jr> wumpus: just didn't notice it until rebasing on top of the merged code
11:51 < luke-jr> anyhow, #11383 rebase is done
11:51 < gribble> https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub
11:51 < jonasschnelli> ^^     
11:52 < jonasschnelli> thanks.. will test
11:52 < Dizzle> I like multiwallet. Thanks for working on it, luke-jr. I miss the classic multibit bulk walletting.
11:52 < 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
11:53 < sipa> yay c++20... which we'll switch to in 20125?
11:53 < sipa> *2025
11:53 < wumpus> yes, in 20125
11:53 < luke-jr> :x     
11:53 < Chris_Stewart_5> ack     
11:53 < meshcollider>  lol
11:53 < jonasschnelli> heh     
11:53 < 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?
11:53 < wumpus> BlueMatt: will add that one
11:54 < wumpus> #topic DDoS network stats
11:54 < meshcollider> gmaxwell:  https://coin.dance/nodes says 139 but maybe not what you're after?
11:55 < 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)
11:55 < jonasschnelli> I can filter my seed crawler for uagent string?
11:55 < 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.
11:55 < gmaxwell> meshcollider: okay, probably not much to worry about.
11:56 < meshcollider> gmaxwell yeah lol there was a Reddit post which went into some detail showing 90% were hosted by AWS
11:56 < 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.
11:57 < jonasschnelli> 861 peers with "Bitcoin ABC" and 100% uptime during last two hours.
11:57 < luke-jr> jonasschnelli: that's just BCH
11:57 < achow101> gmaxwell: my btc1 node is connected to 34 other btc1 nodes, so at least 35
11:57 < meshcollider> ABC is not btc1
11:57 < BlueMatt> i mean its what we did 0.15.1 for, no?
11:58 < 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.
11:58 < jonasschnelli> meshcollider: what uagent does btc1 uses?
11:58 < luke-jr> jonasschnelli: /Satoshi:1.*/
11:58 < jonasschnelli> ah     
11:58 < achow101> jonasschnelli: most have a uacomment with "2x"
11:58 < jonasschnelli> 107     
11:58 < gmaxwell> with only 140ish it's pretty unlikely many nodes will get isolated behind them.
11:59 < achow101> what block were they forking at?
11:59 < achow101> (I need to add it to my site)
11:59 < gmaxwell> 494784
11:59 < jtimon> weren't they using a naming just the same as bitcoin core but increasing a version? (ie 0.14.3)
12:00 < gmaxwell> hopefully someone will mine a couple blocks on that fork to help get those nodes disconnected.
12:00 < gmaxwell> jtimon: they made the major version 1.
12:00 < achow101> gmaxwell: a mining pool announced that they would go with the 2x fork regardless
12:00 < jtimon> oh, right
12:00 < jnewbery> won't they disconnect themselves once a valid block is found?
12:00 < wumpus> ding dong
12:00 < gmaxwell> achow101: that was 'bitpico' who is crazy.
12:00 < gmaxwell> it's meaningless.
12:00 < achow101> oh     
12:01 < wumpus> #endmeeting
12:01 < lightningbot> Meeting ended Thu Nov 16 20:01:11 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:01 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-16-19.01.html
12:01 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-16-19.01.txt
12:01 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-16-19.01.log.html
12:01 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...]     
12:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds]     
12:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev     
12:27 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
12:30 -!- roadcrap [~roadcrypt@unaffiliated/roadcrap] has quit [Remote host closed the connection]     
12:54 -!- LumberCartel [~randolf@96.53.47.42] has quit [Ping timeout: 258 seconds]     
13:01 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
13:01 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
13:04 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 268 seconds]     
13:05 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
13:06 -!- wunpunch [~Alli@176.27.129.249] has joined #bitcoin-core-dev     
13:06 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
13:07 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
13:11 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
13:11 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
13:12 -!- sh4ft [a2df8f04@gateway/web/freenode/ip.162.223.143.4] has quit [Quit: Page closed]     
13:21 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
13:22 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
13:31 -!- torkel_ [~torkel@cm-84.215.56.187.getinternet.no] has joined #bitcoin-core-dev     
13:38 -!- torkel_ [~torkel@cm-84.215.56.187.getinternet.no] has quit [Quit: Konversation terminated!]     
13:39 -!- PaulCapestany [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has quit [Ping timeout: 248 seconds]     
13:39 -!- torkel_ [~torkel@cm-84.215.56.187.getinternet.no] has joined #bitcoin-core-dev     
13:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
13:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
13:44 < jonasschnelli> gmaxwell: I'm happy to hear your bip39 successor HWW KDF idea...
13:44 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: conversation terminated!]     
13:45 -!- torkel_ is now known as torkelrogstad     
13:45 < jonasschnelli> PBKDF2 with 2048 rounds seems not ideal (BIP39)
13:46 < 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
13:46 < sipa> and then being able to verify the computer did the hardening correctly
13:46 < jonasschnelli> +1     
13:47 < sipa> adam back proposed a scheme for this a while ago, but it's purely CPU dependent
13:47 < sipa> whether it can be combined with memory hard hardening is an open question i think
13:47 < jonasschnelli> purely CPU is still much better then 2048-PBKDF
13:47 < sipa> haha, yes
13:49 < 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.
13:49 < jonasschnelli> I'm not sure if a plain text seed dump (or BIP39) is something you want in a bank tresor
13:54 -!- PaulCapestany [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has joined #bitcoin-core-dev     
13:55 -!- jsfour [~jsfour@cpe-76-90-140-31.socal.res.rr.com] has quit [Ping timeout: 260 seconds]     
14:10 -!- LumberCartel [~randolf@24.244.32.136] has joined #bitcoin-core-dev     
14:11 < goatpig> mdisc?
14:12 < jonasschnelli> mdisc?
14:12 < goatpig> it's basically a cdrom made out of rock
14:12 < goatpig> really really durable
14:12 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
14:14 -!- ok7685 [182d7da7@gateway/web/freenode/ip.24.45.125.167] has joined #bitcoin-core-dev     
14:16 -!- LumberCartel [~randolf@24.244.32.136] has quit [Ping timeout: 248 seconds]     
14:18 -!- sunday-afternoon [~jack@66-188-250-34.dhcp.eucl.wi.charter.com] has quit [Quit: sunday-afternoon]     
14:21 < 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
14:21 -!- harrymm [~harrymm@85.203.47.135] has quit [Read error: Connection reset by peer]     
14:22 < goatpig> it's hard to demonstrate in practice
14:24 -!- jsfour [~jsfour@cpe-76-90-140-31.socal.res.rr.com] has joined #bitcoin-core-dev     
14:25 -!- harrymm [~harrymm@85.203.47.71] has joined #bitcoin-core-dev     
14:29 < jcorgan> it's a bit like closed-source software, the media is trade secret, but independent testing was pretty good
14:29 < jcorgan> http://www.esystor.com/images/China_Lake_Full_Report.pdf
14:30 < goatpig> at any rate it's far superior to plain cd/dvds or nvram
14:31 < jcorgan> certainly. they're great for "encrypted live boot cold-storage resurrection system" discs scattered in a few places
14:34 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds]     
14:38 -!- JackH [~laptop@alvira.static.korbank.pl] has quit [Read error: Connection reset by peer]     
14:38 -!- JackH [~laptop@alvira.static.korbank.pl] has joined #bitcoin-core-dev     
14:45 -!- wxss [~chatzilla@82.221.112.213] has quit [Ping timeout: 240 seconds]     
14:47 < cfields> whoops, totally forgot about today's meeting :\
14:56 -!- wxss [~chatzilla@103.60.9.26] has joined #bitcoin-core-dev     
14:58 -!- PaulCapestany [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has quit [Read error: Connection reset by peer]     
14:58 -!- PaulCape_ [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has joined #bitcoin-core-dev     
14:58 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev     
14:58 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host]     
14:58 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
15:02 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-seezadxfjsnlyzyn] has quit [Quit: Connection closed for inactivity]     
15:10 -!- torkelrogstad [~torkel@cm-84.215.56.187.getinternet.no] has quit [Quit: Konversation terminated!]     
15:10 -!- torkelrogstad [~torkel@cm-84.215.56.187.getinternet.no] has joined #bitcoin-core-dev     
15:11 -!- tux3do [~tux3do@ip72-201-18-238.ph.ph.cox.net] has quit [Quit: Leaving]     
15:20 -!- torkelrogstad [~torkel@cm-84.215.56.187.getinternet.no] has quit [Read error: Connection reset by peer]     
15:20 -!- torkelrogstad [~torkel@cm-84.215.56.187.getinternet.no] has joined #bitcoin-core-dev     
15:24 -!- LumberCartel [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
15:32 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
15:33 -!- torkelrogstad [~torkel@cm-84.215.56.187.getinternet.no] has quit [Ping timeout: 240 seconds]     
15:41 -!- torkelrogstad [~torkel@cm-84.215.56.187.getinternet.no] has joined #bitcoin-core-dev     
15:41 -!- LumberCartel [~randolf@96.53.47.42] has quit [Ping timeout: 250 seconds]     
15:42 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has quit []     
15:50 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has quit [Quit: Page closed]     
15:51 -!- torkelrogstad [~torkel@cm-84.215.56.187.getinternet.no] has quit [Read error: Connection reset by peer]     
15:51 -!- torkelrogstad [~torkel@cm-84.215.56.187.getinternet.no] has joined #bitcoin-core-dev     
15:51 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-ugggimhclvfyfjcz] has joined #bitcoin-core-dev     
15:56 -!- jsfour [~jsfour@cpe-76-90-140-31.socal.res.rr.com] has quit [Ping timeout: 255 seconds]     
16:03 < gmaxwell> jcorgan: after reading NIST tests of varrious CDR media I dunno about trusting any of it-- they found two order of magnitude variations in durability of even 'archival grade' media.  Seemed like the only way to be confident at all is to have an independant lab test it.
16:04 -!- jsfour [~jsfour@cpe-76-90-140-31.socal.res.rr.com] has joined #bitcoin-core-dev     
16:04 -!- torkelrogstad [~torkel@cm-84.215.56.187.getinternet.no] has quit [Ping timeout: 240 seconds]     
16:05 < gmaxwell> jonasschnelli: probably a short private key with error correction scribed on metal (with a diamond scribe or cryptosteel) is probably the best durability that can be achieved.  Most other alternatives are not especially fire/water durable.
16:09 < jcorgan> yeah, it's more a convenience than anything to really trust. the US navy testing report i posted above used fairly good methodology and th mdisc fared well. again, though, it's a convenience and only one part of an overall system.
16:09 < jcorgan> "If it isn't backed up in three different ways and stored in three different places, it is already lost."
16:10 < gmaxwell> yea, thanks for the pointer.
16:11 -!- ok7685 [182d7da7@gateway/web/freenode/ip.24.45.125.167] has quit [Ping timeout: 260 seconds]     
16:11 < gmaxwell> FWIW, I've found in research that CD readers actually have far less reading robustness that in theoretically possible.  So for data recovery you could potentially read a lot of unreadable disks with a specialized drive.  (there is a project on github to read audio CDs with a USRP bolted to the photodetector output of a laserdisk player).
16:11 < bitcoin-git> [bitcoin] CryptAxe closed pull request #11098: [Qt] Add spend all button to the SendCoinsDialog (master...spendall) https://github.com/bitcoin/bitcoin/pull/11098
16:12 < gmaxwell> far less == e.g. they use the inner RS code only as a checksum, and the outer only as an erasure code,  and don't do any soft-input or iteration.
16:16 < jcorgan> i don't think the system was designed around archival, only incidental damage (scratches, etc.) 
16:16 -!- LumberCartel [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
16:17 < jcorgan> so none of the commodity write-once optical systems deal with things like fires or chemical damage, etc.
16:18 -!- torkelrogstad [~torkel@cm-84.215.56.187.getinternet.no] has joined #bitcoin-core-dev     
16:19 < jcorgan> SDR/DSP is magic :-)
16:21 < jcorgan> physical damage aside, i'm still not sure if any proper bip32 hd-wallet seed/hierarchy designs have emerged
16:23 < gmaxwell> jonasschnelli: there are two things I'd like to talk to you about with future hardware wallet stuff.
16:24 < gmaxwell> jonasschnelli: One of them is that we now have a scheme where the host software can protect against a hardware wallet signing maliciously in a way that leaks keys.
16:24 < gmaxwell> jonasschnelli: perhaps you'd have some interest in implementing that. It requires an extra round trip between the host and HW wallet during signing.
16:25 < gmaxwell> jonasschnelli: the other thing is this KDF scheme.  Basically, I want to address the problem that you want to enter a password protected seed on a hardware wallet and not expose the password or seed to an untrusted host...  but the hardware wallet does not have enough CPU power to do a meaningful KDF (the 2000 rounds in BIP39 is basically pointless)
16:26 < gmaxwell> jonasschnelli: so I would suggest we use a scheme proposed some years ago by Adam Back that would let the host computer do the KDF grinding in zero knoweldge-- it learns nothing about the password entered on the hardware wallet.
16:30 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...]     
16:30 -!- torkelrogstad [~torkel@cm-84.215.56.187.getinternet.no] has quit [Ping timeout: 240 seconds]     
16:32 < sipa> link: https://bitcointalk.org/index.php?topic=311000.0
16:33 < achow101> what does everyone think about putting various docs about things in progress and plans (e.g. sipa's wallet thing) on the wiki here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki
16:33 < achow101> that's where we did release notes things
16:39 < sipa> achow101: without large scale effort to commit to keeping something like that up to date, i'm afraid it will very easily go outdated
16:40 < achow101> sipa: I was thinking more of a repository to keep these writeups that morcos keeps asking for
16:40 < sipa> ah, yes
16:40 < achow101> to have them all in one place instead of having to search for all of them
16:41 < sipa> any reason they couldn't be in the repo?
16:41 < sipa> https://github.com/bitcoin-core/docs for example
16:41 < achow101> they could be in the repo I guess
16:42 < achow101> just somewhere that they can be easily found in one place is good enough
16:47 < meshcollider> +1     
17:00 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
17:06 -!- blockchain [~linux@178.237.154.22] has quit [Quit: Verlassend]     
17:13 -!- vicenteH [~user@35.233.15.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds]     
17:16 -!- Khunbish [~Khunbish@213.108-247-81.adsl-dyn.isp.belgacom.be] has quit [Quit: Khunbish]     
17:35 -!- wunpunch [~Alli@176.27.129.249] has quit [Read error: Connection reset by peer]     
17:42 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
17:45 -!- Muis [sid26074@gateway/web/irccloud.com/x-cvxlefzowwqvgxbs] has joined #bitcoin-core-dev     
17:48 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
17:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]     
18:00 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 255 seconds]     
18:05 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wthlscpkleyhtmoe] has quit [Quit: Connection closed for inactivity]     
18:17 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev     
18:18 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
18:18 < bitcoin-git> [bitcoin] MeshCollider opened pull request #11708: Add P2SH-P2WSH support to signrawtransaction and listunspent RPC (master...201711_signrawtransaction_wsh) https://github.com/bitcoin/bitcoin/pull/11708
18:20 < meshcollider> validateaddress is basically an address info call isn't it
18:21 < meshcollider> so should witnessScript and redeemScript be added to its output?
18:27 < sipa> i believe my segwit wallet pr does that
18:28 < sipa> or something similar at least
18:29 < meshcollider> oh cool, thanks :)
18:40 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 248 seconds]     
18:42 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
18:48 -!- Guest83 [~textual@2602:306:378a:6fb0:61b1:8cc2:b749:93fe] has joined #bitcoin-core-dev     
18:58 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
19:03 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.7.1]     
19:08 -!- Guest83 [~textual@2602:306:378a:6fb0:61b1:8cc2:b749:93fe] has quit [Quit: Textual IRC Client: www.textualapp.com]     
19:08 -!- Guest83 [~textual@2602:306:378a:6fb0:61b1:8cc2:b749:93fe] has joined #bitcoin-core-dev     
19:09 -!- Guest83 [~textual@2602:306:378a:6fb0:61b1:8cc2:b749:93fe] has quit [Client Quit]     
19:09 -!- Guest83 [~textual@2602:306:378a:6fb0:61b1:8cc2:b749:93fe] has joined #bitcoin-core-dev     
19:14 -!- Guest83 [~textual@2602:306:378a:6fb0:61b1:8cc2:b749:93fe] has quit [Client Quit]     
19:15 -!- Guest83 [~textual@2602:306:378a:6fb0:61b1:8cc2:b749:93fe] has joined #bitcoin-core-dev     
19:20 -!- Guest83 [~textual@2602:306:378a:6fb0:61b1:8cc2:b749:93fe] has quit [Client Quit]     
19:20 -!- satwo [~textual@2602:306:378a:6fb0:61b1:8cc2:b749:93fe] has joined #bitcoin-core-dev     
19:46 -!- jsfour [~jsfour@cpe-76-90-140-31.socal.res.rr.com] has quit [Ping timeout: 268 seconds]     
19:54 -!- cxr [~cxr@1.214.207.2] has quit [Ping timeout: 240 seconds]     
20:08 -!- checksauce [~checksauc@96.30.102.162] has joined #bitcoin-core-dev     
20:09 -!- checksauce [~checksauc@96.30.102.162] has quit [Read error: Connection reset by peer]     
20:39 -!- jsfour [~jsfour@cpe-45-50-168-164.socal.res.rr.com] has joined #bitcoin-core-dev     
20:41 -!- jsfour [~jsfour@cpe-45-50-168-164.socal.res.rr.com] has quit [Client Quit]     
21:07 -!- Guest92143 [~wqetyy@212.133.241.10] has joined #bitcoin-core-dev     
21:20 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
21:28 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.7.1]     
21:28 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
21:30 -!- sunday-afternoon [~jack@66-188-250-34.dhcp.eucl.wi.charter.com] has joined #bitcoin-core-dev     
21:41 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Quit: Leaving]     
22:26 -!- satwo [~textual@2602:306:378a:6fb0:61b1:8cc2:b749:93fe] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
22:27 < achow101> meshcollider: yes, and that's why I have a PR to move most of the functionality to a new call getaddressinfo
22:27 < meshcollider> achow101: Ah sweet, will check it out in a second
22:30 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-cyxwqhdksnjzqhgv] has joined #bitcoin-core-dev     
22:37 < jonasschnelli> [14:24:20]  <gmaxwell>	jonasschnelli: One of them is that we now have a scheme where the host software can protect against a hardware wallet signing maliciously in a way that leaks keys.
22:37 < jonasschnelli> That is not adam3us's proposal? Right?
22:38 < sipa> jonasschnelli: https://www.reddit.com/r/Bitcoin/comments/7a7i69/electrum_30_release/dpaetyn/?context=3
22:39 < jonasschnelli> sipa... thanks! reading...
22:50 -!- Cory [~Cory@unaffiliated/cory] has quit [Read error: Connection reset by peer]     
22:53 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
22:54 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
22:54 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 248 seconds]     
22:57 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
22:59 < jonasschnelli> sipa: so your scheme is to protect against possible malicious HWW (and or it's firmware)?
23:17 < kallewoof> What was the configure option to enable deadlock detection stuff again?
23:20 < kallewoof> Got it, I think... (CPPFLAGS=-DDEBUG_LOCKORDER)
23:44 < sipa> kallewoof: indeed
23:44 < sipa> jonasschnelli: indeed
23:46 -!- cxr [~cxr@1.214.207.2] has joined #bitcoin-core-dev     
23:46 < jonasschnelli> For now,.. all HWW manufacturer consider the hosts/desktop as compromised.. but it's an interesting perspective (from the user) to get kind of a two factor security between HWW/Desktop
23:47 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
23:49 < jonasschnelli> sipa: is that scheme: (k1+H(k2,R1))*G = k1*G+H(k2,R1)*G = R1+H(k2,R1)*G compatible with BIP32?
23:50 < gmaxwell> it doesn't change anything about the public keys used, it changes the nonces in the signatures.
23:51 < jonasschnelli> gmaxwell: instead of secp256k1_nonce_function_rfc6979 it would use the construction k1+H(k2,R1)?
23:52 < jonasschnelli> interesting... the desktop could verify the signature before broadcasting.. I see
23:52 < gmaxwell> a concern is that hw wallets may actually reduce user security, if I were an /evil/ genius, I'd start making counterfeit trezors and selling them on ebay for slightly under the normal retail price... with evil firmware on them.  Backdooring regular computers would be a waste of my resources, but backdooring a hw wallet-- I could be confident that a high percentage of my backdoored devices were g
23:52 < gmaxwell> oing to get cryptocoins on them.
23:53 < gmaxwell> jonasschnelli: yes, the hw wallet sends the original R to the desktop and it can verify.  If the HW wallet did something malicious it couldn't get its malicious effect further than the desktop.
23:54 < gmaxwell> So a backdoored HW wallet would only compromise the user (1) through orignial key generation, if it does that (user can avoid by rolling dice or something for the key),  or (2) with the cooperation of the desktop; which an evil party selling backdoored hardware wallets hopefully wouldn't have.
23:54 < jonasschnelli> How Digital Bitbox wanted to prevent from that attack was by proving the device authenticity by signing arbitraty data via the HWW device and have the signature verified. But that security model is based on obscurity of the auth-private key inside the device
23:54 < gmaxwell> at least in that kind of setup a HW wallet couldn't make you less secure than your desktop alone.
23:55 < gmaxwell> jonasschnelli: right, which could be compromised, and it doesn't help against bad firmware being made at the maker.
23:55 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Ping timeout: 248 seconds]     
23:55 < gmaxwell> or something like making the compromised devices out of legitimate ones... where it just passes through the tamper detect to the original hardware but intercepts the rest.
23:55 < jonasschnelli> gmaxwell: bad firmware can't be installed because the bootloader only accepts signed firmware
23:56 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds]     
23:56 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
23:56 < jonasschnelli> In the case of proving authenticity with a pinned private key in the device,.. this can be made relatively secure when using a EPROM chip with physical extraction measurements
23:56 < jonasschnelli> It's as hard to extract as the seed on the device
23:57 < jonasschnelli> But I'd say both schemes should be implemented == more security
23:58 < sipa> well this protects against the case where the device creator is complicit