12017-08-03T00:00:41  <jnewbery> #10882 is squashed and ready for reACK/merge
   22017-08-03T00:00:44  <gribble> https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
   32017-08-03T00:01:32  <sipa> jnewbery: thanks!
   42017-08-03T00:05:09  *** http_GK1wmSU has joined #bitcoin-core-dev
   52017-08-03T00:05:12  *** http_GK1wmSU has left #bitcoin-core-dev
   62017-08-03T00:10:13  *** AaronvanW has quit IRC
   72017-08-03T00:13:46  *** derbumi has quit IRC
   82017-08-03T00:15:05  *** derbumi has joined #bitcoin-core-dev
   92017-08-03T00:21:20  *** LampTreadStone07 has joined #bitcoin-core-dev
  102017-08-03T00:26:19  *** blznblzn2 has quit IRC
  112017-08-03T00:31:42  *** jtimon has quit IRC
  122017-08-03T00:50:44  *** LampTreadStone07 has quit IRC
  132017-08-03T00:53:21  *** Cheeseo has joined #bitcoin-core-dev
  142017-08-03T00:54:43  *** lifeofguenter has quit IRC
  152017-08-03T00:56:40  *** cheese_ has quit IRC
  162017-08-03T01:00:56  *** lifeofguenter has joined #bitcoin-core-dev
  172017-08-03T01:07:25  *** dabura667 has joined #bitcoin-core-dev
  182017-08-03T01:16:13  *** Orion3k has quit IRC
  192017-08-03T01:29:28  *** Orion3k has joined #bitcoin-core-dev
  202017-08-03T01:29:38  *** Ylbam has quit IRC
  212017-08-03T01:30:20  *** sam_c has quit IRC
  222017-08-03T01:32:30  *** sam_c has joined #bitcoin-core-dev
  232017-08-03T01:35:01  *** Orion3k has quit IRC
  242017-08-03T01:45:46  *** Orion3k has joined #bitcoin-core-dev
  252017-08-03T01:49:15  *** james0909 has joined #bitcoin-core-dev
  262017-08-03T01:49:28  <james0909> hi, i'm having an issue with core, could someone help?
  272017-08-03T01:51:33  <instagibbs> james0909, #bitcoin please, someone can help there
  282017-08-03T02:20:48  *** veleiro has joined #bitcoin-core-dev
  292017-08-03T02:24:16  *** sam_c has quit IRC
  302017-08-03T02:41:30  *** jr2014 has joined #bitcoin-core-dev
  312017-08-03T02:47:19  <praxeology> Would it be worth adding some ECC to chainstate and the block index?  Maybe running a memtest before the first synch?
  322017-08-03T02:47:58  <praxeology> Memtest could auto start on the first synch from genesis... but be skippable
  332017-08-03T02:48:33  <praxeology> Although... sure memtest is better to be done w/ something like Memtest86+
  342017-08-03T02:50:59  *** Deacydal has joined #bitcoin-core-dev
  352017-08-03T02:54:16  *** Deacyde has quit IRC
  362017-08-03T02:56:33  *** veleiro has quit IRC
  372017-08-03T03:20:13  *** jeep-ss has quit IRC
  382017-08-03T03:28:30  *** blznblzn2 has joined #bitcoin-core-dev
  392017-08-03T03:42:04  *** Giszmo1 has joined #bitcoin-core-dev
  402017-08-03T03:43:02  *** Giszmo has quit IRC
  412017-08-03T03:48:00  *** ekerstein has quit IRC
  422017-08-03T03:50:52  *** chjj has quit IRC
  432017-08-03T03:55:36  *** miknotauro has joined #bitcoin-core-dev
  442017-08-03T03:55:59  <gmaxwell> praxeology: error correction wouldn't really help unless it was very very high overhead.
  452017-08-03T04:03:15  <praxeology> I guess I wasn't really calling for error correction, more error detection.  But yea I guess it already does detect an error eventually
  462017-08-03T04:04:51  <gmaxwell> There is error detection.
  472017-08-03T04:06:04  <praxeology> Maybe if the client gets stuck on an old block, it should suggest to the user that maybe its database is corrupted... and give some suggestions on what to do about it
  482017-08-03T04:12:10  <sipa> it does
  492017-08-03T04:12:15  <sipa> and asks if you want to reindex
  502017-08-03T04:14:41  *** james0909 has quit IRC
  512017-08-03T04:18:24  <praxeology> ok.  james0909 in #bitcoin said his error log said...  "ERROR: invalid header received 2017-08-03 01:48:18 ProcessMessages(headers, 11422 bytes) FAILED peer=38"?  and his tip was stuck at 478645.
  522017-08-03T04:18:56  <praxeology> But he didn't say anything about it asking him to reindex... although he did ask if he should reindex.
  532017-08-03T04:19:48  <gmaxwell> praxeology: why do you think there is corruption...
  542017-08-03T04:20:26  <gmaxwell> praxeology: the invalid headers messages are bcash nodes getting banned. And he may not catch up if he's been offline until the next block if the peer he picked for the initial header sync was broken or malicious.
  552017-08-03T04:21:17  <praxeology> he said he tried connecting to other peers.
  562017-08-03T04:21:47  <gmaxwell> what does that even mean
  572017-08-03T04:21:48  <praxeology> I guess I didn't confirm that he actually connected to a known good peer
  582017-08-03T04:22:11  <gmaxwell> doesn't matter f he is 'connected' to a good peer, he won't continue syncing until there is a new block.
  592017-08-03T04:22:31  <praxeology> oh.  I didn't know that
  602017-08-03T04:22:42  *** miknotauro has quit IRC
  612017-08-03T04:22:45  <gmaxwell> (if he was behind and the peer he elected for initial headers was bogus)
  622017-08-03T04:22:54  <praxeology> So he needs to be connected to a good peer while a new block comes in
  632017-08-03T04:23:29  <gmaxwell> praxeology: sure, just doing nothing will do that with very high likelyhood since it'll be connected to at least 8 peers.
  642017-08-03T04:24:01  <praxeology> when bitcoin starts up, it only chooses one peer to ask for latest headers?
  652017-08-03T04:24:22  <sdaftuar> praxeology: yes
  662017-08-03T04:24:30  <praxeology> and if that fails... it doesn't ask another?
  672017-08-03T04:24:30  <gmaxwell> praxeology: right, and if doesn't give all of them it won't learn that it's behind until someone else advertises a block.
  682017-08-03T04:24:37  <sdaftuar> praxeology: in 0.15, there will be a timeout on that request
  692017-08-03T04:24:38  <gmaxwell> it can't tell when it 'fails'
  702017-08-03T04:24:55  <gmaxwell> except for a total timeout, which sdaftuar notes is detected in 0.15
  712017-08-03T04:25:13  <praxeology> hm, well if the time of his last block is really old... or if the peer he is asking has a different tip...
  722017-08-03T04:25:44  <gmaxwell> praxeology: different tip than what
  732017-08-03T04:26:24  <praxeology> if your own node has a different tip than the one you are requesting the latest headers from
  742017-08-03T04:26:46  <gmaxwell> praxeology: of course its different or fetching headers from it was pointless...
  752017-08-03T04:26:48  <praxeology> like, their tip is in a different chain or behind or something
  762017-08-03T04:27:08  <praxeology> bah ok you right
  772017-08-03T04:27:17  <sdaftuar> you don't request headers from a peer who is on a less-work chain than your tip
  782017-08-03T04:27:44  <gmaxwell> And any countermeasure has to not do things like terminate a long header sync from a valid peer just because it's a lot of data... otherwise a newly syncing node could get stuck if it's link was too low in bandwidth.
  792017-08-03T04:28:07  <sdaftuar> actually, i said that wrong.  you don't request blocks from such a peer
  802017-08-03T04:28:36  *** Deacydal has quit IRC
  812017-08-03T04:30:11  <gmaxwell> praxeology: there are a bunch of places we could improve responsiveness by punting less helpful peers, but such rules require just a lot of care because false positives are potententially severe attack vectors.
  822017-08-03T04:31:35  *** chjj has joined #bitcoin-core-dev
  832017-08-03T04:35:09  <praxeology> alright... well, its unfortunate I misdiagnosed the guy's issue.  Thanks for the help.  Hopefully he will come back and ask again on #bitcoin and one of sees him... for his sake... before he -reindex
  842017-08-03T04:36:56  <gmaxwell> it's also important to not let malicious peers cause users to get any kind of error to the greatest extent that we can avoid it.
  852017-08-03T04:37:24  <gmaxwell> because unfortunately any warning you show users will cause a small percentage of them to jump off bridges.
  862017-08-03T04:38:16  <gmaxwell> "I saw a warning that wouldn't go away so I deleted my wallet, and now I still have the warning and where are my bitcoins?"
  872017-08-03T04:42:36  *** ivan has quit IRC
  882017-08-03T04:44:08  *** JackH has quit IRC
  892017-08-03T04:46:59  <mryandao> LOL
  902017-08-03T04:48:23  <gmaxwell> not really funny though. :(
  912017-08-03T04:48:53  <gmaxwell> it's not like people are stupid, first they try all the things they think are reasonable, then they try other things...
  922017-08-03T04:49:17  <gmaxwell> and with enough users, someone is going to think they should try sawing off their hands or whatever.
  932017-08-03T04:49:39  <Emcy_> throwing your wallet in a lake isnt reasonable
  942017-08-03T04:49:43  <mryandao> i can't connect the dots between deleting wallet.dat and addressing the problem.
  952017-08-03T04:50:08  <gmaxwell> mryandao: because it's state that could be causing the error.
  962017-08-03T04:50:19  <gmaxwell> Emcy_: but they saved the addresses first!
  972017-08-03T04:50:32  <gmaxwell> you and I know that doesn't help, but it's not exactly obvious
  982017-08-03T04:50:42  <Emcy_> it was even called "wallet" as a kind of linguistic skeumorph to get people to understand what it is
  992017-08-03T04:50:45  <mryandao> hmm, this sounds like motivation to decouple key from wallet.dat?
 1002017-08-03T04:51:04  <mryandao> so at least even if wallet.dat was removed out of a panic attack, at least keys is still somewhere safe?
 1012017-08-03T04:52:06  <Emcy_> youre right about explaining pubkey crypto to normies though oh boy
 1022017-08-03T04:52:15  <gmaxwell> well we've talked before about writing wallet backup files periodically but there is a counter argument that doing so will make it more likely for users to get their wallets stolen. e.g. clear wallet off a disk before giving it to someone else...
 1032017-08-03T04:55:37  <Emcy_> i meant to ask why the default datadir on windows in is the domain roaming profile folder, actually, instead of the local profile
 1042017-08-03T04:55:41  *** e4xit has quit IRC
 1052017-08-03T04:55:45  <Emcy_> since the subject came up
 1062017-08-03T04:57:51  <praxeology> does bitcoin still use windows registry?
 1072017-08-03T04:58:21  <praxeology> windows configuration/file system usage needs a rework :p
 1082017-08-03T04:59:55  <praxeology> HKEY_CURRENT_USER\Software\Bitcoin\Bitcoin-Qt
 1092017-08-03T05:00:54  <praxeology> Not that I am actually making demands for your time, sorry.  Have a good night!
 1102017-08-03T05:03:44  *** wfef has joined #bitcoin-core-dev
 1112017-08-03T05:04:33  *** clarkmoody_ has quit IRC
 1122017-08-03T05:12:34  *** miknotauro has joined #bitcoin-core-dev
 1132017-08-03T05:17:29  <sipa> praxeology: why?
 1142017-08-03T05:50:57  *** chjj has quit IRC
 1152017-08-03T05:54:11  *** chjj has joined #bitcoin-core-dev
 1162017-08-03T05:59:45  <goatpig> isn't that just the URI registration?
 1172017-08-03T06:00:47  <praxeology> windows registry is not very compatible with multiple installations in use on the same OS
 1182017-08-03T06:02:32  <praxeology> magic hidden settings that one wouldn't know to move to a new system
 1192017-08-03T06:27:57  *** Drabiv has joined #bitcoin-core-dev
 1202017-08-03T06:29:42  *** Ylbam has joined #bitcoin-core-dev
 1212017-08-03T06:47:50  *** felco has quit IRC
 1222017-08-03T06:51:18  *** BashCo has quit IRC
 1232017-08-03T06:58:48  *** marcoagner has quit IRC
 1242017-08-03T07:06:59  *** JackH has joined #bitcoin-core-dev
 1252017-08-03T07:10:25  *** marcoagner has joined #bitcoin-core-dev
 1262017-08-03T07:11:10  *** BashCo has joined #bitcoin-core-dev
 1272017-08-03T07:12:57  *** BashCo_ has joined #bitcoin-core-dev
 1282017-08-03T07:16:32  *** BashCo has quit IRC
 1292017-08-03T07:20:22  *** Orie has quit IRC
 1302017-08-03T07:41:03  *** clarkmoody has joined #bitcoin-core-dev
 1312017-08-03T07:41:22  *** timothy has joined #bitcoin-core-dev
 1322017-08-03T07:46:36  *** timothy has quit IRC
 1332017-08-03T07:47:13  *** timothy has joined #bitcoin-core-dev
 1342017-08-03T07:47:40  *** Cheeseo has quit IRC
 1352017-08-03T07:47:54  *** timothy has quit IRC
 1362017-08-03T07:50:56  *** timothy has joined #bitcoin-core-dev
 1372017-08-03T07:52:31  *** jtimon has joined #bitcoin-core-dev
 1382017-08-03T08:01:55  *** AaronvanW has joined #bitcoin-core-dev
 1392017-08-03T08:02:21  *** yRDIUTgn has joined #bitcoin-core-dev
 1402017-08-03T08:03:58  <gmaxwell> I wonder if we should adopt a patch to instantly disconnect bcash nodes based on their service flags.  Sucks to burn a service bit forever to their recklessness though. :(
 1412017-08-03T08:03:58  *** Aaronvan_ has joined #bitcoin-core-dev
 1422017-08-03T08:04:16  <gmaxwell> and presumably the constant inadvertant dos attack of connecting to nodes on another network will move them onto another port eventually.
 1432017-08-03T08:06:05  *** AaronvanW has quit IRC
 1442017-08-03T08:07:41  *** Deacyde has joined #bitcoin-core-dev
 1452017-08-03T08:09:05  <praxeology> potentially in the future the burned service code could be recovered in the future after the problem goes away
 1462017-08-03T08:09:52  <praxeology> are they refusing to move to a different port?
 1472017-08-03T08:10:43  <gmaxwell> they refused people people asked them previously.
 1482017-08-03T08:10:59  <gmaxwell> it's not all that easy to recover a service bit where its use results in instantly being disconnected!
 1492017-08-03T08:11:13  <praxeology> Maybe in a month bcash won't have anyone mining it anymore
 1502017-08-03T08:11:52  <gmaxwell> perhaps we shouldn't worry much about burning one because we know we're due for some other pretty substantial p2p revisions, and other updates can add new capabilities flags.
 1512017-08-03T08:12:54  <gmaxwell> I think we only use service flags now for things we absolutely need to have in addr messages, and if we create a addr message replacement (to support NG hidden services and I2P, we'd probably give it a different capabilities signaling tool)
 1522017-08-03T08:14:05  <praxeology> service flags... "flags" implies a 32 bit or 64 bit number?
 1532017-08-03T08:14:50  <praxeology> Maybe switch to a set of service tags instead?
 1542017-08-03T08:15:08  <gmaxwell> well, they need to be small because they're rumored everwhere in addr messages.
 1552017-08-03T08:15:25  *** d_t has quit IRC
 1562017-08-03T08:15:30  <gmaxwell> making them fat sidechannels would likely have clowns using them for file trading. :)
 1572017-08-03T08:17:17  <praxeology> ok, well you could put a size constraint on the tag set... but whatever I'm just sleep dep and over engineering something I don't know enough about
 1582017-08-03T08:25:00  *** tucenaber has quit IRC
 1592017-08-03T08:25:40  *** tucenaber has joined #bitcoin-core-dev
 1602017-08-03T08:25:40  *** tucenaber has joined #bitcoin-core-dev
 1612017-08-03T08:55:33  *** goatpig has quit IRC
 1622017-08-03T09:02:25  *** ivan has joined #bitcoin-core-dev
 1632017-08-03T09:10:08  *** bincap has quit IRC
 1642017-08-03T09:10:16  *** rafalcpp has quit IRC
 1652017-08-03T09:11:19  *** miknotauro has quit IRC
 1662017-08-03T09:27:08  <Eliel> jonasschnelli: is bitcoind's code that does that too difficulty to understand?
 1672017-08-03T09:27:19  <Eliel> (never mind, was looking at the past)
 1682017-08-03T09:27:23  <jonasschnelli> Eliel: depends on you experience
 1692017-08-03T09:27:39  <Eliel> ah true
 1702017-08-03T09:34:59  *** jimpo has joined #bitcoin-core-dev
 1712017-08-03T09:34:59  *** LeMiner has joined #bitcoin-core-dev
 1722017-08-03T09:59:41  *** Austindoggie has joined #bitcoin-core-dev
 1732017-08-03T10:01:45  *** dabura667 has quit IRC
 1742017-08-03T10:03:07  *** karelb has joined #bitcoin-core-dev
 1752017-08-03T10:03:52  <gmaxwell> Hi all, karelb is working on the trezor wallet, and they've been trying to use these patches to bitcoin that implement the bitcore address indexing stuff, but they're finding it really slow to the point where performance is problematic.
 1762017-08-03T10:04:10  <karelb> we are using it for a while now :)
 1772017-08-03T10:04:29  <karelb> but right now we are reindexing bitcoin blockchain and it takes foreved
 1782017-08-03T10:04:34  <gmaxwell> Maybe someone would be interested in giving them a bit of a hand at looking at it? (I need to get to bed); I've already provided the standard disclaimers about the inherent non-scalability of address-indexes-of-all-history. :)
 1792017-08-03T10:04:46  *** AaronvanW has joined #bitcoin-core-dev
 1802017-08-03T10:05:10  <karelb> (It is actually bitcoin-abc, I hope I won't be banned :D, but this issue popped up in bitcoin core too)
 1812017-08-03T10:05:17  <gmaxwell> karelb: one question would be what kind of system is this running on? e.g. is it on some VPS with remote storage that may have poor IO speed?
 1822017-08-03T10:05:47  <gmaxwell> karelb: we'll forgive you for your sins. though obviously can't help with any abc specific issues.
 1832017-08-03T10:05:47  <karelb> it is our local server that has SSD, lots of RAM and processors
 1842017-08-03T10:05:59  <gmaxwell> darn.
 1852017-08-03T10:06:56  <karelb> actually one issue was sort-of ABC related, but it was because of a commit ported from master from bitcoin core, so it will be relevant anyway
 1862017-08-03T10:07:04  <karelb> https://github.com/Bitcoin-ABC/bitcoin-abc/issues/43 , https://github.com/satoshilabs/bitcoin-abc/commit/5337f8f210eaa34d1212103f700698dd4989f479
 1872017-08-03T10:07:26  <gmaxwell> so since I doubt that addrindex has a useful caching layer, you could look for the leveldb::Options object for the database it creates and try increasing the options.block_cache and options.write_buffer_size to really large levells.
 1882017-08-03T10:07:38  <karelb> it's because the bitcore patches do address index in ConnectBlock/DisconnectBlock, even on the start during the testing thing
 1892017-08-03T10:07:49  *** Aaronvan_ has quit IRC
 1902017-08-03T10:08:04  <karelb> (jpochyla is my colleague)
 1912017-08-03T10:08:41  <gmaxwell> karelb: probably code based on Bitcoin Core master (including ABC) will not be reliably compatible with that address indexing stuff until it is changed.
 1922017-08-03T10:08:50  <karelb> And the introduction of ApplyBlockUndo somehow caused that
 1932017-08-03T10:09:35  <karelb> yeah. We want to write our own indexing thing that you won't need to put inside the C++ code, since that is a little insane and we need to keep on rebasing that
 1942017-08-03T10:09:46  *** erts has joined #bitcoin-core-dev
 1952017-08-03T10:10:08  *** erts is now known as Guest16355
 1962017-08-03T10:10:13  <karelb> gmaxwell: just fyi, ABC is not based on master, but on 0.14.1, but they took that thing from master
 1972017-08-03T10:10:16  <gmaxwell> karelb: bitcoin core master changed the atomiticity requirements for the backend database, but a side effect of this is that it needs special replay logic to handle crash recovery.  ABC has partially ported some of these changes. I am not sure, but I wouldn't be surprised if the address indexing would get corrupted until updated to have the right synchronization behavior.
 1982017-08-03T10:10:32  <gmaxwell> I know it's based on 0.14.1, but they copied some of these database changes.
 1992017-08-03T10:10:36  <karelb> ok
 2002017-08-03T10:11:21  <gmaxwell> in any case, beyond the cache options I mentioned above, I am out of ideas for making it faster without substantial design changes.
 2012017-08-03T10:11:55  <gmaxwell> I think you should probably also make an extra effort to always cleanly start and stop that node, because I wouldn't be confident that it is durable across crashes without corruption.
 2022017-08-03T10:13:36  <Austindoggie> Did it take a long time to reindex because you went back a version of bitcoin core?
 2032017-08-03T10:14:33  <Austindoggie> Sorry if im not allowed to talk here...
 2042017-08-03T10:14:47  <karelb> gmaxwell: hah, that is not a good news. We also noticed the node randomly crashes once in a while and we are not sure why
 2052017-08-03T10:15:24  <gmaxwell> ::sigh::
 2062017-08-03T10:15:29  <karelb> yeah
 2072017-08-03T10:16:31  <karelb> block_cache and write_buffer_size can be set via conf, or only in code?
 2082017-08-03T10:16:39  <karelb> wait I will have a look
 2092017-08-03T10:16:44  <gmaxwell> karelb: run more nodes, reindex anytime one crashes?  At least until you can test if the address index is accurate across crashes?  I'm not completely confident that it won't be, but it would take some careful review and testing to be sure (especially in the context of ABC that has really scrambled things up a lot)
 2102017-08-03T10:17:02  <gmaxwell> karelb: I think only in the code, I don't think there is an external way to override.
 2112017-08-03T10:17:21  <gmaxwell> in any case, I have to go to bed. Hopefully someone else will wake up and have some other suggestions.
 2122017-08-03T10:17:32  <karelb> (I really hate how ABC reformatted everything for no good reason, but that is another issue from this)
 2132017-08-03T10:17:44  *** jannes has joined #bitcoin-core-dev
 2142017-08-03T10:18:05  *** Guest16355 has left #bitcoin-core-dev
 2152017-08-03T10:18:26  <gmaxwell> yes, it makes it really hard to see what exactly has changed because the reformats were heavily intermixed with real changes. :(
 2162017-08-03T10:19:58  <karelb> @austindoggie nope we started to download blockchain from 0. And it is always stuck on IO for insanely long times
 2172017-08-03T10:20:16  <karelb> and normal bitcoin without bitcore patches doesn't do it, on the same HW
 2182017-08-03T10:20:39  <gmaxwell> karelb: gross final suggestion before I really go:  if you really have a lot of ram, create a tmpfs mount big enough for the entire datadir, and sync in there, when it finishes copy it to disk.
 2192017-08-03T10:21:44  <gmaxwell> karelb: the challenge there is that we have insanely optimized bitcoin core's sync process.. we avoid writing to leveldb at all costs, basically, and a significant fraction of UTXO never hit the database at all during normal sync because they're spent before the dbcache fills)
 2202017-08-03T10:24:27  *** dobak has joined #bitcoin-core-dev
 2212017-08-03T10:25:00  <karelb> thanks a lot for your help
 2222017-08-03T10:25:18  <karelb> going to IRC was a wild shot but it seems it might help :)
 2232017-08-03T10:25:33  *** dobak has left #bitcoin-core-dev
 2242017-08-03T10:26:50  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/659c09613408...2e857bb619f5
 2252017-08-03T10:26:50  <bitcoin-git> bitcoin/master 49d903e Alex Morcos: Eliminate fee overpaying edge case when subtracting fee from recipients
 2262017-08-03T10:26:51  <bitcoin-git> bitcoin/master 2e857bb Wladimir J. van der Laan: Merge #10942: Eliminate fee overpaying edge case when subtracting fee from recipients...
 2272017-08-03T10:27:25  <bitcoin-git> [bitcoin] laanwj closed pull request #10942: Eliminate fee overpaying edge case when subtracting fee from recipients (master...subtractfee) https://github.com/bitcoin/bitcoin/pull/10942
 2282017-08-03T10:27:25  *** LordCow has joined #bitcoin-core-dev
 2292017-08-03T10:34:40  <karelb> Hm. options.block_cache and options.write_buffer_size are derived from dbcache
 2302017-08-03T10:35:16  <karelb> dbcache option
 2312017-08-03T10:35:35  <jonasschnelli> Updated to Debian 9 (stretch) and suddenly get gitian build errors: init.lxc: failed to mount /dev/shm : No such file or directory
 2322017-08-03T10:35:46  <jonasschnelli> Anyone else experiences this?
 2332017-08-03T10:39:18  *** Austindoggie has quit IRC
 2342017-08-03T10:39:32  *** Austindoggie has joined #bitcoin-core-dev
 2352017-08-03T10:39:49  *** Deacydal has joined #bitcoin-core-dev
 2362017-08-03T10:40:22  <karelb> maximum dbcache is 16384 MB hard-capped in code; is there a reason for that?
 2372017-08-03T10:40:38  <jonasschnelli> karelb: why would you need more?
 2382017-08-03T10:41:58  *** Deacyde has quit IRC
 2392017-08-03T10:42:23  *** sam_c has joined #bitcoin-core-dev
 2402017-08-03T10:47:00  <karelb> see the past discussion... we are running bitcore address index patches and they are very slow and stuck on disk operations. And it happens probably because it gets stuck on adding things to address index and commiting it to hard disk on every block
 2412017-08-03T10:47:11  <karelb> probably
 2422017-08-03T10:48:13  <karelb> it must be because of the address index somehow, because on the same PC, bitcoin core without bitcore (sigh) patches runs fine
 2432017-08-03T10:48:46  *** sam_c has quit IRC
 2442017-08-03T10:49:00  <karelb> I am actually talking about ABC, but the same issue crops up in bitcoin, plus it might be because ABC added some db logic from master
 2452017-08-03T10:49:45  *** sam_c has joined #bitcoin-core-dev
 2462017-08-03T10:50:54  *** paveljanik has joined #bitcoin-core-dev
 2472017-08-03T10:52:00  *** Austindoggie has quit IRC
 2482017-08-03T10:53:08  <karelb> hm, we stopped the bitcoind and it got into some crashed state which is inconsistent and nothing happens
 2492017-08-03T10:53:11  <karelb> :/
 2502017-08-03T10:53:22  <karelb> this is hell
 2512017-08-03T10:54:16  <gmaxwell> karelb: the leveldb caching isn't very useful for the leveldb databases in core because we've already cached the heck out of those things at a higher level...  but for the options set for your custom address index it may be very helpful.
 2522017-08-03T10:55:52  *** jr2014 has quit IRC
 2532017-08-03T11:03:44  *** sam_c has quit IRC
 2542017-08-03T11:05:08  <karelb> well it started chugging again, but is still gets stuck. With dbcache set at 16384. Memory has 1GB full and 63GB free
 2552017-08-03T11:06:15  <gmaxwell> karelb: what does stuck mean exactly
 2562017-08-03T11:07:37  *** felco has joined #bitcoin-core-dev
 2572017-08-03T11:08:44  <karelb> Log says nothing, and iotop shows 100% and doing a lot of reading/writing in the leveldb
 2582017-08-03T11:09:10  <karelb> and after about 20 minutes, log messages start to appear again
 2592017-08-03T11:09:59  <gmaxwell> dear lord. :(
 2602017-08-03T11:13:45  <karelb> and the binary doesn't reply even to kill signals
 2612017-08-03T11:19:03  *** paveljanik has quit IRC
 2622017-08-03T11:19:31  *** paveljanik has joined #bitcoin-core-dev
 2632017-08-03T11:19:39  *** paveljanik has joined #bitcoin-core-dev
 2642017-08-03T11:24:43  *** brg444 has quit IRC
 2652017-08-03T11:26:20  *** jr2014 has joined #bitcoin-core-dev
 2662017-08-03T11:27:11  *** brg444 has joined #bitcoin-core-dev
 2672017-08-03T11:29:56  <karelb> data/blocks/index is compacting like crazy when it is stuck
 2682017-08-03T11:30:33  <karelb> https://pastebin.com/SvsyQyiL
 2692017-08-03T11:33:56  *** SopaXorzTaker has quit IRC
 2702017-08-03T11:34:05  <karelb> The bitcoind is stuck and at the same time when this is hapenning
 2712017-08-03T11:34:23  <karelb> and it keeps writing compacting
 2722017-08-03T11:34:50  *** SopaXorzTaker has joined #bitcoin-core-dev
 2732017-08-03T11:34:55  *** laurentmt has joined #bitcoin-core-dev
 2742017-08-03T11:40:08  *** laurentmt has quit IRC
 2752017-08-03T11:55:21  *** snq has joined #bitcoin-core-dev
 2762017-08-03T12:02:21  *** drizztbsd has joined #bitcoin-core-dev
 2772017-08-03T12:03:04  *** timothy has quit IRC
 2782017-08-03T12:11:19  *** blznblzn2 has quit IRC
 2792017-08-03T12:23:29  *** jimpo has quit IRC
 2802017-08-03T12:31:00  *** dobak has joined #bitcoin-core-dev
 2812017-08-03T13:03:45  *** Cheeseo has joined #bitcoin-core-dev
 2822017-08-03T13:04:24  *** jeep-ss has joined #bitcoin-core-dev
 2832017-08-03T13:07:13  *** rafalcpp has joined #bitcoin-core-dev
 2842017-08-03T13:07:48  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2e857bb619f5...e222618a32a1
 2852017-08-03T13:07:48  <bitcoin-git> bitcoin/master 3498a8d Cory Fields: depends: fix fontconfig with newer glibc...
 2862017-08-03T13:07:49  <bitcoin-git> bitcoin/master e222618 Wladimir J. van der Laan: Merge #10851: depends: fix fontconfig with newer glibc...
 2872017-08-03T13:08:13  <bitcoin-git> [bitcoin] laanwj closed pull request #10851: depends: fix fontconfig with newer glibc (master...fontconfig-bump) https://github.com/bitcoin/bitcoin/pull/10851
 2882017-08-03T13:14:56  *** dobak has quit IRC
 2892017-08-03T13:16:54  *** dobak has joined #bitcoin-core-dev
 2902017-08-03T13:17:48  *** cheese_ has joined #bitcoin-core-dev
 2912017-08-03T13:18:42  *** dobak has left #bitcoin-core-dev
 2922017-08-03T13:20:23  *** spudowiar has joined #bitcoin-core-dev
 2932017-08-03T13:20:42  *** Cheeseo has quit IRC
 2942017-08-03T13:21:50  *** Guyver2 has joined #bitcoin-core-dev
 2952017-08-03T13:24:35  *** dobak has joined #bitcoin-core-dev
 2962017-08-03T13:27:12  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 2972017-08-03T13:56:16  *** dobak has quit IRC
 2982017-08-03T14:30:04  *** jtimon has quit IRC
 2992017-08-03T14:30:53  *** PaulCapestany has quit IRC
 3002017-08-03T14:34:33  *** PaulCapestany has joined #bitcoin-core-dev
 3012017-08-03T14:36:01  *** timothy has joined #bitcoin-core-dev
 3022017-08-03T14:37:04  *** drizztbsd has quit IRC
 3032017-08-03T14:45:21  *** yRDIUTgn has quit IRC
 3042017-08-03T14:45:34  *** yRDIUTgn has joined #bitcoin-core-dev
 3052017-08-03T14:46:02  <bitcoin-git> [bitcoin] NicolasDorier opened pull request #10980: [WIP] Decouple CKeyStore from CWatchOnlyStore (master...decouplewatchonly) https://github.com/bitcoin/bitcoin/pull/10980
 3062017-08-03T14:49:43  *** clarkmoody has quit IRC
 3072017-08-03T14:50:04  *** clarkmoody has joined #bitcoin-core-dev
 3082017-08-03T14:54:40  *** BashCo_ has quit IRC
 3092017-08-03T14:55:18  *** BashCo has joined #bitcoin-core-dev
 3102017-08-03T14:56:26  *** Murch has joined #bitcoin-core-dev
 3112017-08-03T14:58:11  *** Mirobit has joined #bitcoin-core-dev
 3122017-08-03T14:59:27  *** BashCo has quit IRC
 3132017-08-03T15:00:32  <Mirobit> Doesn't anyone know BCash nodes aren't sending BCash transactions to Core peers? My node has only recieved 2 BCash tx and banned both peers. But the other ~5-10 peers don't seem to send any txs. Weird?
 3142017-08-03T15:16:25  *** jr2014 has quit IRC
 3152017-08-03T15:20:52  *** BashCo has joined #bitcoin-core-dev
 3162017-08-03T15:30:20  *** snkey has joined #bitcoin-core-dev
 3172017-08-03T15:33:31  *** snq has quit IRC
 3182017-08-03T15:41:54  *** jimpo has joined #bitcoin-core-dev
 3192017-08-03T15:42:00  *** Dizzle has joined #bitcoin-core-dev
 3202017-08-03T15:52:04  *** Drabiv has quit IRC
 3212017-08-03T15:52:12  *** Deacydal has quit IRC
 3222017-08-03T15:52:37  *** Drabiv has joined #bitcoin-core-dev
 3232017-08-03T15:59:04  <BlueMatt> achow101: re: #10952: Do you have any idea *how* these folks' wallets got corrupted like that?
 3242017-08-03T15:59:05  <gribble> https://github.com/bitcoin/bitcoin/issues/10952 | [wallet] Remove vchDefaultKey and have better first run detection by achow101 · Pull Request #10952 · bitcoin/bitcoin · GitHub
 3252017-08-03T15:59:15  <BlueMatt> I'm highly skeptical that "just write a new default key" is the right solution here
 3262017-08-03T15:59:40  <BlueMatt> their wallet got confused somehow, auto-fixing without telling them something may be wrong is probably not a good idea
 3272017-08-03T16:05:09  *** abpa has joined #bitcoin-core-dev
 3282017-08-03T16:12:53  *** sam_c has joined #bitcoin-core-dev
 3292017-08-03T16:16:49  *** snq has joined #bitcoin-core-dev
 3302017-08-03T16:19:05  *** snkey has quit IRC
 3312017-08-03T16:19:50  *** JackH has quit IRC
 3322017-08-03T16:24:04  *** laurentmt has joined #bitcoin-core-dev
 3332017-08-03T16:27:22  *** gribble has quit IRC
 3342017-08-03T16:31:57  *** laurentmt has quit IRC
 3352017-08-03T16:38:41  *** gribble has joined #bitcoin-core-dev
 3362017-08-03T16:40:15  *** sam_c has quit IRC
 3372017-08-03T16:42:17  *** sam_c has joined #bitcoin-core-dev
 3382017-08-03T16:44:30  *** fizzwont has quit IRC
 3392017-08-03T16:45:09  *** fizzwont has joined #bitcoin-core-dev
 3402017-08-03T16:45:32  *** fizzwont is now known as Guest95816
 3412017-08-03T16:46:57  *** Yogaqueef has joined #bitcoin-core-dev
 3422017-08-03T16:48:53  *** timothy has quit IRC
 3432017-08-03T16:55:27  <achow101> BlueMatt: absolutely no idea how they got corrupted
 3442017-08-03T16:55:40  <achow101> I was not able to get a copy of their wallet files either so I couldn't examine them
 3452017-08-03T16:56:23  <achow101> BlueMatt: the solution isn't to "just write a new default key". The solution is to change the first run checker from "there's a valid default key" to "there are keys in the wallet"
 3462017-08-03T16:57:09  <achow101> so with 10952, those wallets would not be considered to be new first run wallets as they have keys but not a valid default key
 3472017-08-03T17:00:48  *** jtimon has joined #bitcoin-core-dev
 3482017-08-03T17:06:48  <wumpus> default key should completely go (for post-0.15 though)
 3492017-08-03T17:08:41  <BlueMatt> achow101: well my point is more broadly that their wallets clearly got corrupted
 3502017-08-03T17:08:44  <wumpus> the check for a new allet should be replaced by a proper "is this an empty database" check
 3512017-08-03T17:08:55  <BlueMatt> achow101: so silently continuing isnt really the right solution
 3522017-08-03T17:09:07  <wumpus> a wallet without any keys yet could in principle be valid
 3532017-08-03T17:09:26  <wumpus> though a bit strange as we initially generate a mempool
 3542017-08-03T17:09:34  <karelb> ok we got abc node working, but it was some crazy solution of switching between various binaries and invalidating nodes; it did not crash (yet). But it seems that bitcore patches inside connectblock/disconnectblock are really not the way for the future; it will probably break again (both in abc and later in bitcoin core once you release the db changes)
 3552017-08-03T17:09:34  <wumpus> (and we don't allow mempoolsize=0)
 3562017-08-03T17:10:16  <achow101> BlueMatt: that would require a specific check for the case that a default key is invalid
 3572017-08-03T17:10:38  *** Chris_Stewart_5 has quit IRC
 3582017-08-03T17:10:57  <achow101> wumpus: a database is initially created when the wallet file is created. I'm not sure how to check it is empty except that when the database is then read in, there are no keys
 3592017-08-03T17:11:17  <achow101> that's that 10952 does; it checks if there are any keys in the database
 3602017-08-03T17:11:35  <wumpus> yes, that sounds sane
 3612017-08-03T17:12:15  <wumpus> for a new format I'd suggest adding a "database-type" "wallet" k/v pair to distinguish it from other bdb databases, and check for that, but for backwards compatibility that works better
 3622017-08-03T17:12:37  <wumpus> (and no one would be so stupid to put a random other berkeleydb database as wallet.dat? right? :-)
 3632017-08-03T17:15:16  <Lightsword> anyone working on switching bdb out for something else like sqlite?
 3642017-08-03T17:15:30  <achow101> Lightsword: there's a pr somewhere for that I think
 3652017-08-03T17:15:37  <sipa> meh, overkill
 3662017-08-03T17:15:54  <sipa> all we need is a key-value store that's effectively read into memory entirely anyway
 3672017-08-03T17:16:22  <sipa> i had a patch years ago to switch it to an append-only flat file
 3682017-08-03T17:16:27  <Lightsword> the main advantage to sqlite though is that it has good data integrity protection
 3692017-08-03T17:16:43  <achow101> we could upgrade to bdb whatever latest and change how records are stored there
 3702017-08-03T17:16:54  <wumpus> Lightsword: it's quite easy to swap the database for any k/v store, I have a local branch that uses leveldb
 3712017-08-03T17:17:12  <BlueMatt> achow101: if you have a wallet with keys, and a default key that is invalid or missing, your wallet was clearly either corrupted or generated by something other than bitcoin core
 3722017-08-03T17:17:22  <wumpus> achow101: bdb latest (6.x) has serious license issues
 3732017-08-03T17:17:22  <BlueMatt> achow101: continuing silently in that case is not what we want
 3742017-08-03T17:18:35  <Lightsword> sipa, would there not be some potential future use cases where having sql support be helpful?
 3752017-08-03T17:18:37  <achow101> BlueMatt: if there is corruption in the keys themselves or other data, that will be caught elsewhere
 3762017-08-03T17:18:48  <BlueMatt> achow101: we can also change the "first run" check to ignore vchDefaultKey, which we clearly should, but you're pointing to wallets in the wild that have been corrupted and suggesting we should silently continue
 3772017-08-03T17:18:50  <achow101> BlueMatt: I don't think we should care that much about corruption in the default key as it has no use
 3782017-08-03T17:19:01  <sipa> Lightsword: i don't wee how
 3792017-08-03T17:19:04  <sipa> *see
 3802017-08-03T17:19:13  <BlueMatt> achow101: yes we should!
 3812017-08-03T17:19:18  <achow101> BlueMatt: only one of those wallets would silently continue, and the guy had no problems with older versions of core
 3822017-08-03T17:19:19  <BlueMatt> the user should stop using that computer for a wallet!
 3832017-08-03T17:19:27  <wumpus> sql could be useful for metadata kind of things, but meh, I don't think there's really an advantage to it for us we don't index anything
 3842017-08-03T17:19:31  <achow101> BlueMatt: the other wallet ran into other corruption problems
 3852017-08-03T17:19:38  <BlueMatt> that user should be told to throw out their hard drive and get a better one
 3862017-08-03T17:19:39  <BlueMatt> or a new computer
 3872017-08-03T17:19:41  <wumpus> although the current 'keep everything in memory' is kind of dumb
 3882017-08-03T17:19:43  <BlueMatt> not continue
 3892017-08-03T17:20:30  <Lightsword> yeah, I was thinking maybe metadata/multiple accounts or something along those lines could possibly make use of sql
 3902017-08-03T17:20:33  <wumpus> if the wallet would keep things in the database instead and query them when needed, indexes could be useful
 3912017-08-03T17:20:48  <wumpus> accounts are deprecated, if anything we're simplifying the wallet
 3922017-08-03T17:21:44  <achow101> BlueMatt: sure they should be warned, but a corrupted default key should not be a reason to halt the software entirely as default key is useless
 3932017-08-03T17:21:53  <Lightsword> wumpus, what about multiwallet?
 3942017-08-03T17:22:03  <sipa> Lightsword: that uses multiple wallet files
 3952017-08-03T17:22:10  <achow101> with older versions of core, IIRC the default key would have either been overwritten or ignored and allowed the user to continue
 3962017-08-03T17:22:14  <BlueMatt> achow101: if someone's wallet is corrupted, we should exit with an error....if they wish to then restart with -salvagewallet or equivalent, that is also ok
 3972017-08-03T17:22:22  <BlueMatt> achow101: and that is a bug!
 3982017-08-03T17:22:53  <BlueMatt> if we read something and see that someone's hardware is silently corrupting their wallet, we should exit the same way we do with any other wallet corruption errors
 3992017-08-03T17:23:00  <BlueMatt> silently fixing wallets is not ok
 4002017-08-03T17:23:30  <sipa> wumpus: well if we expect to ever need indexes on the future because we won't keep everything in memory, i'd say that sqlite is a good choice
 4012017-08-03T17:23:32  <wumpus> with older versions of core the lack of the default key record would make it assume it's a new wallet, which could do all kinds of bad things? I don't think that's abetter
 4022017-08-03T17:23:51  <BlueMatt> there are clearly bugs here that achow101 identified (that i think need fixing for 15)
 4032017-08-03T17:24:00  <sipa> wumpus: not sure if it's worthwhile though
 4042017-08-03T17:24:03  <BlueMatt> I'm just not sure that silently correcting /anything/ is every good in wallets
 4052017-08-03T17:24:05  <wumpus> for 0.15 it's too lte imo
 4062017-08-03T17:24:14  <wumpus> we should do rc1 asap
 4072017-08-03T17:24:15  <BlueMatt> wumpus: we've seen it in the wild, and it can be a simple fix
 4082017-08-03T17:24:16  <BlueMatt> :(
 4092017-08-03T17:24:25  <wumpus> not add new stuff
 4102017-08-03T17:24:27  <sipa> have we even identified the bug?
 4112017-08-03T17:24:38  <wumpus> but that's just my opinion (and being harried at all sides to do 0.15 asap)
 4122017-08-03T17:24:41  <BlueMatt> sipa: as far as anyone knows its hardware/bdb silently corrupting things
 4132017-08-03T17:24:42  <sipa> as opposed to "we have ween a wallet with no default key, somehow"
 4142017-08-03T17:24:43  <achow101> sipa: I can replicate the problem, not necessarily the cause
 4152017-08-03T17:25:20  <wumpus> but sure if it's a clearly defined problem, with a clearly defined fix, and it can be reviewed in the next days, we can include it
 4162017-08-03T17:25:20  <sipa> achow101: elaborate
 4172017-08-03T17:25:45  <achow101> sipa: encrypt a wallet, use db_dump to dump it, remove the default key, load with db_load, start core, runtime exception
 4182017-08-03T17:26:03  <sipa> well, ok
 4192017-08-03T17:26:04  <wumpus> that's what I expect if you just remove a record
 4202017-08-03T17:26:10  <wumpus> don't do that.
 4212017-08-03T17:26:21  <sipa> but if you permit random file changes, you can make anything happen
 4222017-08-03T17:26:26  <BlueMatt> wumpus: yes, sorry, my understanding is its that kind of "simple fix" that would be easy to get in in a day or two
 4232017-08-03T17:26:28  <achow101> if you do it unencrypted, it works fine
 4242017-08-03T17:26:30  <wumpus> if you delete a random record from the utxo database you'll also be in for a world of pain
 4252017-08-03T17:26:41  *** jimpo has quit IRC
 4262017-08-03T17:26:59  <BlueMatt> the issue is that this encourages people to downgrade wallets
 4272017-08-03T17:27:02  <wumpus> we're not resistant to that kind of corruption, and one special case is not going to change that
 4282017-08-03T17:27:14  <achow101> I suppose then a check for a valid default key can be added and that would just be a corruption warning?
 4292017-08-03T17:27:15  <BlueMatt> just making it a nice error message and making sure -salvagewallet works correctly is the Correct (tm) fix, imo
 4302017-08-03T17:27:17  <wumpus> could just as well have been a key record that disappears
 4312017-08-03T17:27:26  <BlueMatt> achow101: yes
 4322017-08-03T17:27:32  <achow101> fine
 4332017-08-03T17:27:34  <wumpus> salvagewallet should work as long as there is any private key left
 4342017-08-03T17:27:45  <achow101> btw the current corruption warnings are kinda bad
 4352017-08-03T17:27:55  <wumpus> that's a known issue...
 4362017-08-03T17:28:18  <wumpus> there's even a chance of running into asserts on db corruption
 4372017-08-03T17:29:30  <wumpus> would be nice if it could detect corruption at run time and offer the user a chance to repair
 4382017-08-03T17:29:56  <wumpus> though if a wallet gets corrupted that's a good indication you should stop using that computer for bitcoin, now
 4392017-08-03T17:30:21  <wumpus> so I agree with BlueMatt in that regard
 4402017-08-03T17:31:32  <achow101> the main problem I have with that is it encourages people who don't know what they are doing (i.e. don't ask, can't use -salvagewallet, etc.) to downgrade
 4412017-08-03T17:31:44  <sipa> ?
 4422017-08-03T17:31:55  <wumpus> why would they think downgrading would work?
 4432017-08-03T17:32:01  <achow101> wumpus: because it does.
 4442017-08-03T17:32:04  <wumpus> say, your wallet is suddenly corrupted one day
 4452017-08-03T17:32:16  <wumpus> why would you consider downgrading?
 4462017-08-03T17:32:26  <wumpus> only if it happens on upgrade I suppose
 4472017-08-03T17:32:28  <achow101> with this specific corruption problem, downgrading to non-hd wallet software (0.12.0- or -usehd=0) will ignore this problem
 4482017-08-03T17:32:31  <sipa> if the corruption ransomly happens right after uograding, i can see why someone would think that
 4492017-08-03T17:32:42  <sipa> *randomly
 4502017-08-03T17:32:45  <sipa> not ransomly
 4512017-08-03T17:32:57  <wumpus> yes, if it happens right after upgrading, but then it's probably a version issue and not a random corruption in any case, would be extremely unlikely otherwise
 4522017-08-03T17:33:13  <sipa> achow101: update wallet version number?
 4532017-08-03T17:33:18  <BlueMatt> anyway, this is why i think we should give an error message
 4542017-08-03T17:33:19  <achow101> sipa: bleh
 4552017-08-03T17:33:29  <sipa> oh, we can't because the optional stuff uses it
 4562017-08-03T17:33:40  <sipa> we really need wallet features grr
 4572017-08-03T17:33:40  <BlueMatt> the crash is better than continuing silently, but if it makes people downgrade, we should instead tell them whats up
 4582017-08-03T17:34:18  <achow101> IIRC salvagewallet didn't fix their problems either, so that will need to be updated
 4592017-08-03T17:34:34  <BlueMatt> sipa: arent you the one who added wallet versioning?
 4602017-08-03T17:34:44  <BlueMatt> achow101: yes, lets do that :)
 4612017-08-03T17:35:04  <wumpus> wallet versioning is used for *optional* features?
 4622017-08-03T17:35:13  <BlueMatt> oh, no
 4632017-08-03T17:35:17  <achow101> I think it would be fine to write some random default key right? it isn't used for anything
 4642017-08-03T17:35:30  <achow101> wumpus: yes, hd and hd chain split or optional, but they have version numbers
 4652017-08-03T17:35:38  <BlueMatt> achow101: its used for pay-to-IP :p
 4662017-08-03T17:36:02  <BlueMatt> (I think)
 4672017-08-03T17:36:07  <sipa> BlueMatt: yes, and now we can't use it
 4682017-08-03T17:36:18  <sipa> because the version number is used for optional features
 4692017-08-03T17:36:59  <sipa> like HD and split HD
 4702017-08-03T17:37:25  <sipa> those should have been a separate record, rather the version number
 4712017-08-03T17:37:31  <wumpus> would have been better to use a new key to indicate those (as well as bump the version number, but not in itself)
 4722017-08-03T17:37:46  <wumpus> well teh version should be bumped too to make it incompatible, but yeah
 4732017-08-03T17:38:10  <sipa> right
 4742017-08-03T17:39:05  *** tyngdekraften has joined #bitcoin-core-dev
 4752017-08-03T17:39:35  <BlueMatt> Make Bitcoin Great Again: Bring back Pay-2-IP
 4762017-08-03T17:40:31  <sipa> BlueMatt: i tried :(
 4772017-08-03T17:40:53  <wumpus> with .onion addresses or some other way to authenticate an IP at the transport layer (such as ipsec) it even could work securely!
 4782017-08-03T17:41:07  <BlueMatt> wumpus: I'm currently working on tcpcrypt for linux patchset :p
 4792017-08-03T17:41:28  <wumpus> BlueMatt: I have no idea what that is
 4802017-08-03T17:41:38  <BlueMatt> wumpus: tcp-crypt :p
 4812017-08-03T17:42:19  <sipa> en..crypt...TCP?
 4822017-08-03T17:42:24  <Lightsword> http://www.tcpcrypt.org/
 4832017-08-03T17:42:26  <BlueMatt> yes, that
 4842017-08-03T17:43:35  <sipa> ah, nice
 4852017-08-03T17:44:17  *** tyngdekraften has quit IRC
 4862017-08-03T17:45:18  <wumpus> "and your network connections will continue to work even if the remote end does not support Tcpcrypt, in which case connections will gracefully fall back to standard clear-text TCP" - that screams downgrade attack :)
 4872017-08-03T17:46:11  <achow101> oh damn, now default key can't be removed :(
 4882017-08-03T17:46:12  <sipa> wumpus: read on
 4892017-08-03T17:46:21  <sipa> achow101: ?
 4902017-08-03T17:46:41  <sipa> wumpus: it only protects against passive attacks
 4912017-08-03T17:46:44  <achow101> sipa: to check if default key is valid, it needs to be in CWallet
 4922017-08-03T17:46:52  <sipa> achow101: ?
 4932017-08-03T17:46:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 4942017-08-03T17:46:56  <BlueMatt> wumpus: yes, if the application layer does nto support it it only protects against passive mitm attacks, if the application layer supports it you can disconnect if tcpcrypt failed (but dont do that, cause middleware sucks)
 4952017-08-03T17:47:17  <achow101> I need some way to get default key out of database into a checker, which also checks if default key exists
 4962017-08-03T17:47:28  <sipa> achow101: you can just check when loading the wallet
 4972017-08-03T17:47:31  <achow101> the only vehicle for that right now is cwallet I think
 4982017-08-03T17:48:05  <sipa> i'm sure there is or can be a LoadDefaultKey function on CWallet, called from walletdb
 4992017-08-03T17:48:18  <sipa> switch that to do a check, but not store
 5002017-08-03T17:48:57  <achow101> I guess I could also just add more parameters too
 5012017-08-03T17:49:49  *** Mirobit has quit IRC
 5022017-08-03T18:10:53  *** miknotauro has joined #bitcoin-core-dev
 5032017-08-03T18:14:29  <earlz> I'm trying to get gitian working with 0.14.0. Has anyone seen an error like this? lxcbr0: ERROR while getting interface flags: No such device
 5042017-08-03T18:14:32  <earlz> SIOCSIFADDR: No such device
 5052017-08-03T18:14:57  <earlz> just following the gitian-building.md document exactly and getting that error
 5062017-08-03T18:18:18  <earlz> ifconfig
 5072017-08-03T18:18:22  <earlz> er, woops
 5082017-08-03T18:19:48  <earlz> do I need a kernel flag or something? It's failing at the sudo ifconfig lxcbr0 up 10.0.2.2 bit
 5092017-08-03T18:20:43  <sipa> do you have the lxc kernel module loaded?
 5102017-08-03T18:21:20  <earlz> I pretty much just followed the gitian build instructions and I don't see anywhere in them that the kernel module was explicitly installed unless the lxc package does that
 5112017-08-03T18:24:59  <wumpus> looks like you don't have a lxcbr0 interface for bridging between the lxc and host
 5122017-08-03T18:25:09  <wumpus> not sure how and where that gets created though
 5132017-08-03T18:25:37  <earlz> yea, I'm not understanding where that gets created in the guide. Last time I setup gitian it was for Bitcoin 0.9 so not sure what all has changed since then
 5142017-08-03T18:25:39  *** Mattie161 has joined #bitcoin-core-dev
 5152017-08-03T18:27:54  <earlz> maybe related: https://github.com/lxc/lxc/issues/1218
 5162017-08-03T18:28:16  <earlz> LXC seems to be broken in some subtle way every time I try to do a new setup of gitian
 5172017-08-03T18:28:36  <sipa> wumpus, BlueMatt: i think we really need to fix the versioning issues
 5182017-08-03T18:28:47  <BlueMatt> wallet versioning?
 5192017-08-03T18:28:55  <sipa> that would make it so much easier (you could say, past wallet version X, no default key is needed anymore)
 5202017-08-03T18:29:02  <sipa> i want to move hd to a separate record
 5212017-08-03T18:29:12  <sipa> rather than store it in the version number
 5222017-08-03T18:29:29  * BlueMatt is actually confused why
 5232017-08-03T18:29:41  <sipa> because we can't upgrade the wallet format, ever, now
 5242017-08-03T18:29:51  <sipa> in a backward incompatible way
 5252017-08-03T18:29:55  <BlueMatt> version number = backwards-incompatible change (ie hd), new-key is backwards-compatible extra features
 5262017-08-03T18:29:57  <sipa> without turning the wallet into an hd wallet
 5272017-08-03T18:30:06  <sipa> yes, that's what it's supposed to be
 5282017-08-03T18:30:11  <sipa> but HD is a version number
 5292017-08-03T18:30:11  <BlueMatt> so?
 5302017-08-03T18:30:23  <sipa> we can't increment the version number to indicate something incompatible now
 5312017-08-03T18:30:25  <BlueMatt> what do you want to add that needs to upgrade without being hd?
 5322017-08-03T18:30:34  <sipa> anything
 5332017-08-03T18:30:38  <BlueMatt> we should implement hd upgrade
 5342017-08-03T18:30:45  <BlueMatt> thats something we very much need to do anyway
 5352017-08-03T18:30:52  <sipa> what does that mean?
 5362017-08-03T18:31:13  <BlueMatt> taking a non-hd wallet and adding an hd key
 5372017-08-03T18:31:34  <sipa> yes, ok, that too
 5382017-08-03T18:31:43  <sipa> but do you want to force everyone to have an hd wallet?
 5392017-08-03T18:31:50  <BlueMatt> (probably also need an hd-key-rotate option, but thats separate and I think not related to hd)
 5402017-08-03T18:31:52  <BlueMatt> ^
 5412017-08-03T18:32:07  <BlueMatt> I'm happy to force everyone into an hd wallet if we have an hd-master-key-rotate option
 5422017-08-03T18:32:16  <sipa> yeah, ok...
 5432017-08-03T18:32:24  <sipa> but those are all bigger features
 5442017-08-03T18:32:31  <BlueMatt> well i think all of those are relatively limited code changes
 5452017-08-03T18:32:44  <BlueMatt> and at least hd-master-key-rotate can happen with no format change, I think
 5462017-08-03T18:32:52  <sipa> i am talking about 0.15
 5472017-08-03T18:32:55  <BlueMatt> even if "big" features
 5482017-08-03T18:33:11  <BlueMatt> do we need to add anything else? why rush the no vchdefaultkey thing?
 5492017-08-03T18:33:15  <sipa> otherwise we'll complicate things further for ourselves
 5502017-08-03T18:33:24  <sipa> to add a compatibility layer for split hd
 5512017-08-03T18:33:37  <BlueMatt> ok, I'm missing something...need context
 5522017-08-03T18:33:39  <sipa> no, ignore the vchdefaultkey thing
 5532017-08-03T18:34:07  <sipa> hd and hdsplit, i think, are optional features - things that people can choose not to use
 5542017-08-03T18:34:32  <BlueMatt> now, yes, but i have no problem with them not being optional in the future
 5552017-08-03T18:34:36  <sipa> as they break existing wallet's expectation
 5562017-08-03T18:35:43  <sipa> hmm, ok
 5572017-08-03T18:36:00  <BlueMatt> not being optional in our traditional -walletupgrade sense, that is
 5582017-08-03T18:36:40  <BlueMatt> i mean I'm happy for someone to disagree, I just dont see much downside to it (as long as we have an hd-master-key-rotate option and good documentation on it)
 5592017-08-03T18:36:52  <sipa> i think i agree
 5602017-08-03T18:37:03  <sipa> except i'm not sure we'll have that feature implemented by the time we need it
 5612017-08-03T18:37:18  <BlueMatt> well hd-master-key-rotate is ~trivial with today's format
 5622017-08-03T18:37:24  <sipa> okay
 5632017-08-03T18:37:29  <BlueMatt> hd-upgrade may be slightly less so, I havent thought about it
 5642017-08-03T18:37:35  <BlueMatt> but I expect it to be
 5652017-08-03T18:37:49  <sipa> in that case, i guess it makes sense that those things are in fact in the version number
 5662017-08-03T18:39:17  <sipa> i just wasn't seeing hd as a 'next version', and more as an optional but recommended feature
 5672017-08-03T18:40:55  <BlueMatt> i mean its possible i did /because/ of our versioning scheme, but it is simpler to see it as such and there seem to be relatively limited downsides for it, given some code that doesnt exist yet :p
 5682017-08-03T18:53:31  <wumpus> I'd say using hdsplit isn't really optional, given that you're using hd
 5692017-08-03T18:54:06  <wumpus> hdsplit is a pure improvement on hd
 5702017-08-03T18:57:13  <sipa> agree
 5712017-08-03T18:57:35  <sipa> but do we support upgrading from hd to hdsplit?
 5722017-08-03T18:57:37  <sipa> (right now)
 5732017-08-03T18:58:30  <gmaxwell> ugh. how could we except via invalidating backups which people wouldn't expect...
 5742017-08-03T18:58:49  <wumpus> no, we don't support that right now
 5752017-08-03T18:59:02  <wumpus> hdsplit was sort-of rushed to make 0.15, so that at least new wallets would use it
 5762017-08-03T18:59:28  <sipa> so, until we find a way to (forcefully) upgrade non-hd and hd to hdsplit, we should consider hdsplit an optional feature
 5772017-08-03T18:59:42  <wumpus> but it's strictly superior to hd without hdsplit, so there should be no way to choose that for new wallets
 5782017-08-03T18:59:54  <gmaxwell> I don't think forcefully upgrading is at all possible, because it will invalidate backups.
 5792017-08-03T19:00:11  <wumpus> it wouldn't need to be 'forceful' upgrading, just a *way*
 5802017-08-03T19:00:34  <wumpus> and in any case we don't ever automatically upgrade wallets
 5812017-08-03T19:00:41  <wumpus> (because of backwards compatibility)
 5822017-08-03T19:00:46  <gmaxwell> switch to using segwit, and that will upgrade you. :)
 5832017-08-03T19:00:54  <wumpus> #startmeeting
 5842017-08-03T19:00:54  <lightningbot> Meeting started Thu Aug  3 19:00:54 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 5852017-08-03T19:00:54  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
 5862017-08-03T19:01:06  <achow101> hi
 5872017-08-03T19:01:18  <jonasschnelli> hi
 5882017-08-03T19:01:20  <sipa> hi
 5892017-08-03T19:01:24  <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
 5902017-08-03T19:01:36  <kanzure> hi.
 5912017-08-03T19:01:48  <jtimon> hi
 5922017-08-03T19:01:49  <cfields> hi
 5932017-08-03T19:01:50  <wumpus> 0.15.0rc1 is planned for the 6th (next sunday), so let's go over the open issues again
 5942017-08-03T19:02:50  <wumpus> there's not much anymore
 5952017-08-03T19:02:57  <wumpus> https://github.com/bitcoin/bitcoin/milestones/0.15.0
 5962017-08-03T19:03:16  <paveljanik> Hi
 5972017-08-03T19:03:17  <wumpus> (and the scripted-diffs are option, and should be done at the last minute to not conflict with anything else)
 5982017-08-03T19:03:46  <wumpus>  Keypool topup #10882  is the most complicated PR open still, but should be almost ready
 5992017-08-03T19:03:50  <gribble> https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
 6002017-08-03T19:04:01  <BlueMatt> https://github.com/bitcoin/bitcoin/issues/10977
 6012017-08-03T19:04:02  <BlueMatt> could go
 6022017-08-03T19:04:09  <BlueMatt> (makes test_bitcoin valgrind-better)
 6032017-08-03T19:04:11  <BlueMatt> and is trivial
 6042017-08-03T19:04:32  <jnewbery> yeah, I've been working on 10882 today. Should be able to push my commits in the next hour or two
 6052017-08-03T19:04:34  <wumpus> I'm not really fishing for new things to add to 0.15
 6062017-08-03T19:04:55  <gmaxwell> jnewbery made a suggestion to fix my outstanding concern in review.
 6072017-08-03T19:05:00  <wumpus> but if there are things that could be merged without affecting anything else that's ok
 6082017-08-03T19:05:07  <jtimon> after #10758, #10919 seems simple to review, it's only +14-13
 6092017-08-03T19:05:09  <gribble> https://github.com/bitcoin/bitcoin/issues/10758 | Fix some chainstate-init-order bugs. by TheBlueMatt · Pull Request #10758 · bitcoin/bitcoin · GitHub
 6102017-08-03T19:05:10  <gribble> https://github.com/bitcoin/bitcoin/issues/10919 | Fix more init bugs. by TheBlueMatt · Pull Request #10919 · bitcoin/bitcoin · GitHub
 6112017-08-03T19:05:35  <sipa> it's also already marked 0.15
 6122017-08-03T19:05:35  <cfields> i think there's a one-liner that could be used to fix the issue in 10977, if it's deemed too much of a change
 6132017-08-03T19:05:41  <gmaxwell> BlueMatt: I'd like to see 10977 fixed! but darn I wish that patch was smaller and easier to review.
 6142017-08-03T19:05:49  <wumpus> yes, just needs some ACKs
 6152017-08-03T19:05:55  <BlueMatt> could be smaller, but is easy to review imo
 6162017-08-03T19:05:57  <sdaftuar> there's one commit in #10919 that i'm hoping others can review/ack
 6172017-08-03T19:05:59  <gribble> https://github.com/bitcoin/bitcoin/issues/10919 | Fix more init bugs. by TheBlueMatt · Pull Request #10919 · bitcoin/bitcoin · GitHub
 6182017-08-03T19:07:14  <wumpus> which one?
 6192017-08-03T19:07:21  <BlueMatt> the first, i believe
 6202017-08-03T19:07:39  <sdaftuar> yep
 6212017-08-03T19:08:13  <wumpus> the threadgroup one? seems obviously sane to me, though it does mean things need to be interrupted too
 6222017-08-03T19:08:31  *** goatpig has joined #bitcoin-core-dev
 6232017-08-03T19:08:45  <BlueMatt> well i think the point is that there is a comment there that notes we dont do it "because dragons"
 6242017-08-03T19:09:00  <BlueMatt> i believe strongly that it is safe, and qt does it, but "dragons"
 6252017-08-03T19:09:04  <wumpus> it is very bad practice not to wait for threads before exiting
 6262017-08-03T19:09:37  <wumpus> yes, qt does it already, it's somewhat less scared of dragons it seems :)
 6272017-08-03T19:09:51  <BlueMatt> isnt qt's logo a dragon or something?
 6282017-08-03T19:10:08  <cfields> heh, think you're thinking of kde
 6292017-08-03T19:10:14  <BlueMatt> oh, yea
 6302017-08-03T19:10:22  <wumpus> (e.g. due to qt's handling of shutdown we also needed #10832)
 6312017-08-03T19:10:24  <gribble> https://github.com/bitcoin/bitcoin/issues/10832 | init: Factor out AppInitLockDataDirectory and fix startup core dump issue by laanwj · Pull Request #10832 · bitcoin/bitcoin · GitHub
 6322017-08-03T19:10:35  <wumpus> anyhow that commit looks good to me, I don't think there's any dragons left
 6332017-08-03T19:11:24  <sdaftuar> sounds-good-to-me-ack
 6342017-08-03T19:12:01  <wumpus> ok, wow, that seems to be all that is left between here and 0.15.0rc1
 6352017-08-03T19:12:13  <BlueMatt> !
 6362017-08-03T19:12:19  <cfields> :)
 6372017-08-03T19:13:10  <morcos> wumpus: i had an assert crash this morning, i imagine it'll be a simple bug.. hopefully i'll have a PR this afternoon, just haven't had time to look at it yet
 6382017-08-03T19:13:11  <wumpus> (there's another PR #10971 by cfields for fixing depends builds, but I don't think that needs disussion, it's a one-liner in the build system)
 6392017-08-03T19:13:12  <gribble> https://github.com/bitcoin/bitcoin/issues/10971 | build: fix missing warnings and sse42 in depends builds by theuni · Pull Request #10971 · bitcoin/bitcoin · GitHub
 6402017-08-03T19:13:45  <wumpus> morcos: ouch, can you open an issue to track it?
 6412017-08-03T19:13:48  <cfields> yea, nothing major
 6422017-08-03T19:14:06  <morcos> yes will open one or the other shortly
 6432017-08-03T19:14:29  <wumpus> ok, thanks
 6442017-08-03T19:15:06  <wumpus> do we need any updates to bips.md for 0.15?
 6452017-08-03T19:15:18  <sipa> hmm, good question
 6462017-08-03T19:15:19  <wumpus> (that's the item in the release process that still has a ? here)
 6472017-08-03T19:15:46  <BlueMatt> is there a bip that recommends hd split?
 6482017-08-03T19:15:49  *** chjj has quit IRC
 6492017-08-03T19:15:53  <sipa> BlueMatt: bip32? :p
 6502017-08-03T19:16:15  <wumpus> there's also "Update `src/chainparams.cpp` chainTxData with statistics about the transaction count and rate." left
 6512017-08-03T19:16:29  <sipa> want me to do that?
 6522017-08-03T19:16:31  <wumpus> and the BLOCK_CHAIN_SIZE, but that's straightforward
 6532017-08-03T19:16:49  <wumpus> yes, if you know what's exactly to be done there that'd help :)
 6542017-08-03T19:17:01  <sipa> sure
 6552017-08-03T19:18:38  <wumpus> thanks
 6562017-08-03T19:18:55  <sipa> short topic: bip173 unit tests issue
 6572017-08-03T19:19:09  <wumpus> #topic bip173 unit tests issue
 6582017-08-03T19:19:13  <jnewbery> There are a few more things for release notes
 6592017-08-03T19:19:40  *** clarkmoody_ has joined #bitcoin-core-dev
 6602017-08-03T19:19:43  <sipa> so, bip173 specifies how to translate address strings to witness version/program, and defers to bip141 for encoding that to scriptPubKeys
 6612017-08-03T19:19:59  <sipa> however, the unit tests actually test the whole step from address to scriptPubKey
 6622017-08-03T19:20:07  <sipa> turns out, incorrectly
 6632017-08-03T19:20:26  <sipa> the tests and reference implementation (of the tests) was wrong, and every reimplementation copied it
 6642017-08-03T19:21:05  <gmaxwell> The the error was that it confused hex and dec values.
 6652017-08-03T19:21:07  <sipa> i've made a PR to update the BIP, and all reference implementations i could find, but this is kind of scary
 6662017-08-03T19:21:17  <cfields> corner-cases wrong? or in all cases?
 6672017-08-03T19:21:24  <wumpus> jnewbery: agreed, but release notes need to be finished before -final, not -rc1, so it's not a blocker
 6682017-08-03T19:21:36  <sipa> cfields: it assumed OP_n was encoded as 0x80 + n, rather than 80 + n
 6692017-08-03T19:21:57  <BlueMatt> sipa: so they generate garbage scripts?
 6702017-08-03T19:22:01  <jnewbery> got it. Thanks wumpus
 6712017-08-03T19:22:06  <sipa> BlueMatt: the tests, yes
 6722017-08-03T19:22:26  <sipa> the code itself doesn't contain a conversion to scriptPubKey at all, only a conversion to witness version/program
 6732017-08-03T19:22:27  <gmaxwell> cfields: It was wrong for witness program versions other than 0
 6742017-08-03T19:22:34  <cfields> yikes
 6752017-08-03T19:22:39  <wumpus> oops
 6762017-08-03T19:22:44  <gmaxwell> so this could happily have been deployed and started causing problems when v1 was used.
 6772017-08-03T19:22:47  <sipa> but the tests contain a version/program -> scriptPubKey converter in order to be able the test
 6782017-08-03T19:23:01  *** marcoagner has quit IRC
 6792017-08-03T19:23:05  <BlueMatt> well if it generated garbage scripts, not much that can be done but fix it
 6802017-08-03T19:23:13  <BlueMatt> are you asking if we should like change the prefix now?
 6812017-08-03T19:23:23  <sipa> no
 6822017-08-03T19:23:28  <sipa> just raising awareness
 6832017-08-03T19:23:32  <BlueMatt> ok, cool
 6842017-08-03T19:23:38  <sdaftuar> perhaps an email to the -dev list would also be good?
 6852017-08-03T19:23:38  <gmaxwell> Also, it highlighes an implementation footgun, I suggested some warning text in the BIP itself.   One protection here is that the particular error in sipas' code would result in non-standard outputs.
 6862017-08-03T19:23:42  <sipa> sdaftuar: yes
 6872017-08-03T19:24:06  <gmaxwell> BlueMatt: I did make a suggestion that we consider changing it to break the checksum, but there doesn't appear to be reason to.
 6882017-08-03T19:24:16  *** clarkmoody has quit IRC
 6892017-08-03T19:24:18  <BlueMatt> ok
 6902017-08-03T19:24:22  *** jonasschnelli has quit IRC
 6912017-08-03T19:24:24  <morcos> just to be clear what we are talking about, we're not talking about anything merged into Core, but code referenced from the BIP
 6922017-08-03T19:24:25  <BlueMatt> awareness raised!
 6932017-08-03T19:24:27  <gmaxwell> Especially since if someone had slavishly reimplemented the error in the reference, they'd produce non-standard outputs.
 6942017-08-03T19:24:31  <sipa> morcos: indeed.
 6952017-08-03T19:24:52  <morcos> still, a bit scary
 6962017-08-03T19:25:06  <sipa> (though i'd like to PR it to core soon - apparently last week it was suggested to do that in 0.15.1?)
 6972017-08-03T19:25:21  <gmaxwell> Don't start a debate about the name of the version. :P
 6982017-08-03T19:25:25  <sipa> haha
 6992017-08-03T19:25:42  <sipa> (though i'd like to PR it to core soon - apparently last week it was suggested to do that in some soon next version)
 7002017-08-03T19:25:48  *** jonasschnelli has joined #bitcoin-core-dev
 7012017-08-03T19:25:51  <gmaxwell> It also suggests that BIP173 support's test plan should include testing it with other witness version numbers. :)
 7022017-08-03T19:25:51  <sdaftuar> prs welcome :)
 7032017-08-03T19:26:11  <gmaxwell> sipa: well fix the testing shortfalls I found in the C++ version please. :)
 7042017-08-03T19:26:17  <wumpus> PRs to improve the tests are always welcome anyhow
 7052017-08-03T19:26:17  <sipa> gmaxwell: of course
 7062017-08-03T19:26:23  <sipa> anyway, end topic
 7072017-08-03T19:26:28  <wumpus> ok, other topics?
 7082017-08-03T19:26:32  *** jonasschnelli has quit IRC
 7092017-08-03T19:26:32  *** jonasschnelli has joined #bitcoin-core-dev
 7102017-08-03T19:28:04  <gmaxwell> uh
 7112017-08-03T19:28:05  <gmaxwell> yes.
 7122017-08-03T19:28:14  <gmaxwell> So service bits and altcoins.
 7132017-08-03T19:28:21  <wumpus> #topic service bits and altcoins
 7142017-08-03T19:28:29  <BlueMatt> wait are altcoins using serice bits now?
 7152017-08-03T19:28:41  <BlueMatt> oh, right 2x did
 7162017-08-03T19:28:43  <gmaxwell> Bcash is using our port, p2pmagic, etc. They distinguish themselve with a blinking service bit.
 7172017-08-03T19:28:44  <BlueMatt> what is wrong with people
 7182017-08-03T19:28:54  <gmaxwell> (also 2x will do this too it seems)
 7192017-08-03T19:29:03  <BlueMatt> gmaxwell: can someone open a pr to change this? or do they refuse to work properly?
 7202017-08-03T19:29:04  <cfields> gmaxwell: i was under the impression that they were planning to change the magic soon
 7212017-08-03T19:29:09  <gmaxwell> We mostly ban them when they send us transactions or headers.
 7222017-08-03T19:29:19  <gmaxwell> cfields: not when I looked three days ago, maybe now.
 7232017-08-03T19:29:36  <karelb> OK, maybe I will ask here. What format are the bitcoin .dat files in data/blocks/*.dat? is that leveldb? what is it exactly?
 7242017-08-03T19:29:47  <jonasschnelli> karelb: meeting, not now
 7252017-08-03T19:29:47  <gmaxwell> If so then the issue becomes moot, otherwise I was going to suggest we ban these bits on connect. The downside is we lose the bits basically forever.
 7262017-08-03T19:29:48  <sipa> they are p2p network format
 7272017-08-03T19:29:51  <karelb> ok sorry
 7282017-08-03T19:29:52  <sipa> oops, yes, layer
 7292017-08-03T19:30:02  <karelb> sorry going out
 7302017-08-03T19:30:14  * karelb apologizes
 7312017-08-03T19:30:17  <BlueMatt> gmaxwell: yes, first should be someone bludgening them to work properly
 7322017-08-03T19:30:23  <BlueMatt> gmaxwell: before we start burning service bits
 7332017-08-03T19:30:44  <gmaxwell> BlueMatt: people have been since before they started. Obviously I'll go monitor but I'm not super confident.
 7342017-08-03T19:30:52  <sdaftuar> gmaxwell: why not just ban for eg the next 3 months or something?
 7352017-08-03T19:30:55  <achow101> BlueMatt: gmaxwell IIRC they will be changing their magic and port
 7362017-08-03T19:30:56  <sdaftuar> if we need to do anything at all
 7372017-08-03T19:31:03  <achow101> dunno about 2x
 7382017-08-03T19:31:04  <gmaxwell> One reason burning service bits may not be so bad is because we are due to replace the addr message for i2p and NG-HS support.
 7392017-08-03T19:31:04  <BlueMatt> achow101: what about 2x?
 7402017-08-03T19:31:22  <gmaxwell> So we could at that point just define a new service flagging mechenism.
 7412017-08-03T19:31:26  <BlueMatt> gmaxwell: yea, does anyone have a spec for that?
 7422017-08-03T19:31:33  <gmaxwell> Not yet.
 7432017-08-03T19:31:36  <BlueMatt> k
 7442017-08-03T19:31:51  <gmaxwell> Well if they're finally going to change it, it becomes moot.. but the same issue arises with 2x.
 7452017-08-03T19:32:16  <wumpus> how would a service bit help here?
 7462017-08-03T19:32:19  <BlueMatt> well someone needs to bludgen the 2x folks to change it, otherwise we start banning for a few months
 7472017-08-03T19:32:20  <wumpus> just ban everyone without NODE_SEGWIT? :p
 7482017-08-03T19:32:37  <gmaxwell> wumpus: we still want to support non-upgraded nodes.
 7492017-08-03T19:32:48  <wumpus> but they won't have any new version bit either
 7502017-08-03T19:32:58  <wumpus> that was my point, not to suggest that seriously :)
 7512017-08-03T19:33:11  <gmaxwell> wumpus: oh no, you misunderstand: ABC and 2x both set randomly generated service bits.
 7522017-08-03T19:33:23  <cfields> gmaxwell: eh?
 7532017-08-03T19:33:26  <BlueMatt> I think sdaftuar's suggestion is reasonable, assuming they refuse to do something sane
 7542017-08-03T19:33:27  <gmaxwell> (which they've helpfully ignored the gigantic comment in the code that tells you to at least inform the list.)
 7552017-08-03T19:33:44  <cfields> oh
 7562017-08-03T19:33:45  <gmaxwell> sdaftuar: I hadn't considered a time limited ban. Good point.
 7572017-08-03T19:33:46  <wumpus> oh you mean banning everything that sets their version bit?
 7582017-08-03T19:33:53  <wumpus> yes, that'd be doable
 7592017-08-03T19:33:56  <BlueMatt> wumpus: yes, with a time limit
 7602017-08-03T19:33:59  <gmaxwell> wumpus: well disconnecting, not banning.
 7612017-08-03T19:34:06  <BlueMatt> nah, ban for 3 months
 7622017-08-03T19:34:08  <gmaxwell> Okay thanks, Time limit makes sense. duh.
 7632017-08-03T19:34:16  <wumpus> temporarily, yes
 7642017-08-03T19:34:24  <morcos> wumpus: opened issue #10981, easy fix, but i'll let someone else do the PR as i'm not in the office for next week.  please tag with 0.15.
 7652017-08-03T19:34:25  <gribble> https://github.com/bitcoin/bitcoin/issues/10981 | resendwallettransactions asserts if walletbroadcast=0 · Issue #10981 · bitcoin/bitcoin · GitHub
 7662017-08-03T19:34:32  <gmaxwell> BlueMatt: banning creates problems when you run multiple things on one machine.
 7672017-08-03T19:34:40  <BlueMatt> gmaxwell: meh
 7682017-08-03T19:34:40  <wumpus> morcos: thanks, will tag later (not logged in now)
 7692017-08-03T19:35:03  <BlueMatt> gmaxwell: they refused to do something that wasnt astoundingly broken, if it means their users get fucked, its not really my problem
 7702017-08-03T19:35:13  <wumpus> (or if someone else can do it)
 7712017-08-03T19:35:21  <morcos> BlueMatt: so chaincode ip will be banned.  nice.
 7722017-08-03T19:35:37  <BlueMatt> morcos: -connect=altcoin.dns.seed
 7732017-08-03T19:35:38  <BlueMatt> :)
 7742017-08-03T19:36:07  <wumpus> agree that banning goes too far, just not allow connections
 7752017-08-03T19:36:13  <sipa> maye just disconnect?
 7762017-08-03T19:36:15  <wumpus> there's no point in banning everything after that
 7772017-08-03T19:36:16  <gmaxwell> what? no. matt, doing that will ban Bitcoin Core users when someone on the same IP ran crapware.
 7782017-08-03T19:36:19  <jtimon> perhaps better for after the meeting, but I'm still not sure why #8498 wasn't suitable for 0.15 ...
 7792017-08-03T19:36:21  <gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Near-Bugfix: Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub
 7802017-08-03T19:36:55  <gmaxwell> To be clear this is important because these useless altcoin nodes waste connection slots, and are potentially at risk of gobbling up our initial headers fetch.
 7812017-08-03T19:36:57  <BlueMatt> gmaxwell: ugh
 7822017-08-03T19:37:04  <BlueMatt> fine, disconnect
 7832017-08-03T19:37:15  <BlueMatt> at some point someone is gonna create some altcoin crapware that reconnects agressively, though
 7842017-08-03T19:37:16  <wumpus> disconnect up until a certain date
 7852017-08-03T19:37:20  <BlueMatt> some spv forks probably will
 7862017-08-03T19:37:23  <wumpus> what would be that point?
 7872017-08-03T19:37:33  <BlueMatt> because crapware
 7882017-08-03T19:37:34  <wumpus> it would disconnect immediately after the version message
 7892017-08-03T19:37:37  <gmaxwell> Also, looks like ABC has some kind of deadlocking bug, because I see a few of them just going unresponsive to anything but pings, which delays them getting banned for being on the wrong network.
 7902017-08-03T19:37:38  <morcos> +1 disconnect up to certain date, but i think it should be 12 mos and not 3
 7912017-08-03T19:37:41  <BlueMatt> do not make assumptions about crapware working in a sane way
 7922017-08-03T19:37:42  <wumpus> banning would ban 1 message sooner
 7932017-08-03T19:37:47  <morcos> no reason we'll need that next service bit right away
 7942017-08-03T19:37:59  <sdaftuar> morcos: sure, that sounds fine
 7952017-08-03T19:38:04  <wumpus> s/ban/disconnect
 7962017-08-03T19:38:05  <BlueMatt> morcos: seems reasonable
 7972017-08-03T19:38:19  <gmaxwell> ack on disconnect based on service bits for 12months or similar.
 7982017-08-03T19:38:38  <wumpus> unless we start adding banned nodes to the local firewall, there's no serious difference between disconnecting on connect or after the version message
 7992017-08-03T19:38:51  <gmaxwell> though in general, one of these clowns is going to squat service buts we're in the process of trying to use. :( I have no suggestion on dealing with that.
 8002017-08-03T19:39:12  *** CubicEarth has joined #bitcoin-core-dev
 8012017-08-03T19:39:12  <morcos> but i think it'd be worth a quick email/github message to jgarzik to check that they aren't imminently changing their plan
 8022017-08-03T19:39:14  <BlueMatt> lets deal with that when we get there
 8032017-08-03T19:39:16  <gmaxwell> s/buts/bits/
 8042017-08-03T19:39:23  <wumpus> well if they change the magic and port we can stop worrying about the service bits they claim
 8052017-08-03T19:39:31  <BlueMatt> morcos: yes, as I stated previously we should tell these guys to change network magic *first*
 8062017-08-03T19:39:33  <wumpus> also we could at that point check for NODE_SEGWIT + our service bit
 8072017-08-03T19:39:34  <morcos> yes but what if they change to a different service bit
 8082017-08-03T19:39:41  <gmaxwell> morcos: there is some PR where people have been arguing for ages, about this, so I'm doubtful but sure.
 8092017-08-03T19:39:54  <morcos> might as well ask first and tell him what we're planning on doing
 8102017-08-03T19:39:57  <wumpus> change to a different version bit? what would that accomplish?
 8112017-08-03T19:40:07  <morcos> whooo knows?!!
 8122017-08-03T19:40:11  <gmaxwell> At the end we're doing them a favor, there are a lot more bitcoin nodes than random altcoin nodes, so these incorrect connections tend to cause them a lot more problems than us.
 8132017-08-03T19:40:22  <BlueMatt> yup
 8142017-08-03T19:40:27  <BlueMatt> ok, probalem solved
 8152017-08-03T19:40:34  <BlueMatt> who wants to go tell them that we're gonna disconnect them?
 8162017-08-03T19:40:39  <wumpus> if avoiding detection is the point, they could better stop setting their version bti at that point is better than randomly cycling it according to moon phases
 8172017-08-03T19:41:00  <gmaxwell> BlueMatt: perhaps we should just open the disconnect PR and ping them to comment on it?
 8182017-08-03T19:41:06  <wumpus> bleh
 8192017-08-03T19:41:15  <BlueMatt> gmaxwell: wfm, but seems like someone should open an issue
 8202017-08-03T19:41:18  <BlueMatt> I vote morcos does it
 8212017-08-03T19:41:39  <gmaxwell> throw him to the wolves... enh? what did he do so wrong?
 8222017-08-03T19:41:42  <BlueMatt> actually, it was sdaftuar's idea, he can do it
 8232017-08-03T19:41:49  <gmaxwell> throw him to the wolves... enh? what did he do so wrong?
 8242017-08-03T19:42:04  <wumpus> seems we'd rather not invite certain discussions to our github but eh
 8252017-08-03T19:42:25  <BlueMatt> gmaxwell: fine, I'll deal with it
 8262017-08-03T19:42:35  <gmaxwell> BlueMatt: good, I know what you did so wrong. :P
 8272017-08-03T19:43:04  <jtimon> but if the bits are selected randomly, how does burning them help?
 8282017-08-03T19:43:34  <sipa> jtimon: s/randomly/arbitrarily/
 8292017-08-03T19:43:38  <wumpus> they aren't selected randomly, they're not doing service bit hopping or something like that
 8302017-08-03T19:43:42  <sipa> they're not different every time
 8312017-08-03T19:43:50  <sipa> they just arbitrarily picked one
 8322017-08-03T19:43:50  <jtimon> sipa: I see, thanks
 8332017-08-03T19:43:54  <gmaxwell> jtimon: I don't follow your question. The altcoin efforts have selected randomly but hardcoded the result or their fair dice roll. :)
 8342017-08-03T19:44:13  <morcos> +1 sdaftuar doing it...  i'm trying to pack
 8352017-08-03T19:44:13  <jtimon> gmaxwell: yeah, got it
 8362017-08-03T19:44:16  <gmaxwell> and just failed to follow the giant comment in the code to make a public announcement about it even.
 8372017-08-03T19:44:22  <wumpus> e.g. they have monkeys throw darts to select one when they need it, not every connection
 8382017-08-03T19:44:51  <morcos> oh nm, or bluematt
 8392017-08-03T19:45:22  <BlueMatt> I think morcos is clearly just trying to throw anyone else under the bus, sounds like he should do it, then :p
 8402017-08-03T19:45:25  <BlueMatt> anyway, next topic?
 8412017-08-03T19:45:49  <gmaxwell> ;;action bluematt goes under the bus
 8422017-08-03T19:45:50  * gribble bluematt goes under the bus
 8432017-08-03T19:46:02  <gmaxwell> see, the robot overlords agree
 8442017-08-03T19:46:04  <BlueMatt> ;;action goes under the bus
 8452017-08-03T19:46:04  * gribble goes under the bus
 8462017-08-03T19:46:17  <achow101> we can't/shouldn't ban 2x peers until they fork
 8472017-08-03T19:46:23  <BlueMatt> achow101: yes we should
 8482017-08-03T19:46:37  *** jonasschnelli has quit IRC
 8492017-08-03T19:46:40  <wumpus> I think this was mainly about BCC which already forked
 8502017-08-03T19:46:51  <achow101> BlueMatt: why? we won't be giving them invalid stuff until they fork, and vice versa
 8512017-08-03T19:47:13  <gmaxwell> hash that out outside of the meeting plz.
 8522017-08-03T19:47:24  <wumpus> achow101: on the other hand, adding logic to the code to check whether they've forked would complicate things more than just disconnecting on a service bit
 8532017-08-03T19:47:29  <wumpus> yeah
 8542017-08-03T19:47:40  <BlueMatt> next topic?
 8552017-08-03T19:47:46  <gmaxwell> But in general if someone is going to make broken software, we can only go so far to accomidate it.
 8562017-08-03T19:47:49  <wumpus> we've run out of topics
 8572017-08-03T19:48:00  <achow101> wumpus: we know when they activate. at block X start banning them
 8582017-08-03T19:48:18  <gmaxwell> I doubt we do.
 8592017-08-03T19:48:31  <jtimon> perhaps better for after the meeting, but I'm still not sure why #8498 wasn't suitable for 0.15 ...
 8602017-08-03T19:48:33  <BlueMatt> achow101: I'm not jumping through hoops to make sure altcoins stay in consensus until *right before* they fork...
 8612017-08-03T19:48:33  <gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Near-Bugfix: Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub
 8622017-08-03T19:48:33  <wumpus> #endmeeting
 8632017-08-03T19:48:33  <lightningbot> Meeting ended Thu Aug  3 19:48:33 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
 8642017-08-03T19:48:33  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-03-19.00.html
 8652017-08-03T19:48:33  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-03-19.00.txt
 8662017-08-03T19:48:33  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-03-19.00.log.html
 8672017-08-03T19:48:36  <gmaxwell> since they still don't have a correct published specification and keep changing things.
 8682017-08-03T19:48:53  <achow101> gmaxwell: they have stayed on using 12960 blocks after segwit activation
 8692017-08-03T19:50:29  <gmaxwell> achow101: and what happens if they pull it up to 0 blocks, with a weeks notice? They're clearly being adversarial and trying to harm things, otherwise they'd change port/magic.
 8702017-08-03T19:50:37  <BlueMatt> achow101: and what if they change it next week? No point, if they want to make sure they stay in consensus, they can run bridge nodes, its not hard
 8712017-08-03T19:51:41  <achow101> we risk partitioning the network since there are miners that use btc1
 8722017-08-03T19:52:05  *** jonasschnelli has joined #bitcoin-core-dev
 8732017-08-03T19:52:07  <BlueMatt> achow101: that can be remedied otherwise
 8742017-08-03T19:52:09  <BlueMatt> (and will be)
 8752017-08-03T19:52:22  <BlueMatt> and, mostly, hopefully, they just change network magic
 8762017-08-03T19:52:27  <BlueMatt> and then they can do whatever they want
 8772017-08-03T19:53:07  *** SopaXorzTaker has quit IRC
 8782017-08-03T19:54:05  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10982: Disconnect network service bits 6 and 8 until Aug 1, 2018 (master...2017-08-bad-service-bits) https://github.com/bitcoin/bitcoin/pull/10982
 8792017-08-03T19:57:13  *** chjj has joined #bitcoin-core-dev
 8802017-08-03T19:59:55  <jnewbery> gmaxwell BlueMatt new commits in #10882 ready for review
 8812017-08-03T19:59:57  <gribble> https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
 8822017-08-03T20:02:58  <BlueMatt> thanks
 8832017-08-03T20:08:55  *** Cobra-Bitcoin has joined #bitcoin-core-dev
 8842017-08-03T20:09:24  <Cobra-Bitcoin> Any core dev around?
 8852017-08-03T20:09:25  *** Dizzle has quit IRC
 8862017-08-03T20:09:34  <sipa> many
 8872017-08-03T20:12:29  <Cobra-Bitcoin> Anyone know what btcdrak means when he says "future releases will be linked" here https://github.com/bitcoin-core/bitcoincore.org/issues/33?
 8882017-08-03T20:12:49  <Cobra-Bitcoin> So the release notes will point users to bitcoincore.org binaries?
 8892017-08-03T20:15:10  <sipa> BlueMatt: ^
 8902017-08-03T20:17:52  <BlueMatt> Cobra-Bitcoin: that is the intention, yes, I mailed you about this a while back :). I think the goal is to start pointing people to bitcoincore.org, but also sicne y'all wanted to keep mirroring on bitcoin.org (and cause no point telling people to go somewhere else if they're already used to bitcoin.org), they'd be in both places
 8912017-08-03T20:18:16  <BlueMatt> ie cause security isnt helped by making people make hops
 8922017-08-03T20:18:51  <BlueMatt> Cobra-Bitcoin: see-also #10651
 8932017-08-03T20:18:53  <gribble> https://github.com/bitcoin/bitcoin/issues/10651 | Verify binaries from bitcoincore.org and bitcoin.org by TheBlueMatt · Pull Request #10651 · bitcoin/bitcoin · GitHub
 8942017-08-03T20:23:02  <Cobra-Bitcoin> But is bitcoin.org not doing enough to already distribute the binaries effectively?
 8952017-08-03T20:23:49  <Cobra-Bitcoin> We have no choice but to mirror, since we have a lot of pages structured around the binaries and Core
 8962017-08-03T20:25:21  <achow101> wumpus: BlueMatt so what do we do about salvagewallet and this default key thing?
 8972017-08-03T20:25:51  <achow101> write a new one?
 8982017-08-03T20:27:11  *** snq has quit IRC
 8992017-08-03T20:27:17  *** snq has joined #bitcoin-core-dev
 9002017-08-03T20:27:37  <BlueMatt> Cobra-Bitcoin: see pm
 9012017-08-03T20:27:59  <BlueMatt> achow101: I havent looked at salvage, I mean certainly making it return an error instead of throwing like it does is not too hard
 9022017-08-03T20:28:10  <wumpus> Cobra-Bitcoin: hosting on both bitcoin.org and bitconcore.org is perfectly acceptable, preferable even IMO
 9032017-08-03T20:28:25  <achow101> BlueMatt: I have it return a db corrupt error now (local change, not yet pushed)
 9042017-08-03T20:28:33  <wumpus> Cobra-Bitcoin: more (trusted) places to get the binaries from gives some redundancy
 9052017-08-03T20:28:41  <BlueMatt> plus what wumpus said
 9062017-08-03T20:29:23  <achow101> but my concern is that people will downgrade because downgrading works. there's no way to prevent downgrade is to use a new wallet version, but that's a mess that I don't want to deal with right now
 9072017-08-03T20:30:02  <BlueMatt> achow101: well a reasonable error message should help, then
 9082017-08-03T20:30:31  <BlueMatt> I dont care about preventing users from doing X or Y, but giving them an error message informing them that their hardware appears to have silently corrupted their wallet is appropriate
 9092017-08-03T20:30:50  <BlueMatt> ideally salvagewallet would handle this case (does it not, my understanding was it should?)
 9102017-08-03T20:31:16  <achow101> currently it says "Error loading wallet.dat: Wallet corrupted" with a more specific "invalid default key" message in the debug.log
 9112017-08-03T20:31:27  <BlueMatt> thats fine?
 9122017-08-03T20:31:40  <achow101> salvagewallet doesn't handle uncorrupting keys, it only pulls data that it can find being valid and passes it through
 9132017-08-03T20:31:52  <achow101> so any corrupted keys will get passed through to a salvaged wallet
 9142017-08-03T20:32:02  <achow101> (not like you could uncorrupt a key anyways)
 9152017-08-03T20:32:06  <wumpus> is there even such a thing as 'uncorrupting keys'?
 9162017-08-03T20:32:19  *** Cobra-Bitcoin has quit IRC
 9172017-08-03T20:32:22  <wumpus> it's not like we encode in some redundant way that allows recovery
 9182017-08-03T20:32:29  <wumpus> we could do that, but we don't
 9192017-08-03T20:32:34  <achow101> wumpus: well you could easily uncorrupt a default key by just writing a generic valid key like the generator
 9202017-08-03T20:32:54  <wumpus> you could erase/ignore corrupted keys, though that's somewhat scary...
 9212017-08-03T20:33:05  <BlueMatt> wumpus: isnt salvagewallet always scary?
 9222017-08-03T20:33:09  <wumpus> (but not much different from what bdb salvage already does)
 9232017-08-03T20:33:18  <wumpus> yes, sure, but this isn't black and white
 9242017-08-03T20:33:31  <BlueMatt> true
 9252017-08-03T20:33:34  <wumpus> there are certainly ways to make it even scarier :)
 9262017-08-03T20:33:35  <sipa> so there is an added point here: any key that got corrupted ever probably resulted in the wallet just failing, and the user starting over or finding other solution
 9272017-08-03T20:33:54  <sipa> but if it was the default key that was corrupted, it likely just meant that the wallet replenished the keypool at every startup, ever
 9282017-08-03T20:34:02  <sipa> and everything kept working
 9292017-08-03T20:34:05  <wumpus> yes
 9302017-08-03T20:34:26  <sipa> so there may be a survivalship bias, resulting in currently a higher than expected number of people with a corrupted default key
 9312017-08-03T20:34:46  <wumpus> there probably should be a way to salvage and ignore corrupt keys...
 9322017-08-03T20:34:53  <sipa> yes.
 9332017-08-03T20:35:03  <wumpus> (another salvage level!)
 9342017-08-03T20:35:17  <sipa> unfortunately, not possible for encrypted keys
 9352017-08-03T20:35:24  <sipa> at least not without passphrase
 9362017-08-03T20:35:35  <wumpus> yeah...
 9372017-08-03T20:35:48  <wumpus> repair for an encrypted wallet should ideally ask for the passphrase
 9382017-08-03T20:36:00  <wumpus> it's the only way to recover most effectively
 9392017-08-03T20:38:52  <achow101> it also seems like the two reported cases of this involve wallets that have corrupted keys, which salvagewallet doesn't help with
 9402017-08-03T20:39:14  <achow101> it's just that the user doesn't notice those keys were corrupted until they try to spend
 9412017-08-03T20:39:18  *** davec has quit IRC
 9422017-08-03T20:39:26  <achow101> then the wallet fails to decrypt
 9432017-08-03T20:40:05  *** davec has joined #bitcoin-core-dev
 9442017-08-03T20:42:55  <wumpus> yes that's not good
 9452017-08-03T20:44:56  <achow101> so i guess we could just leave this as a warning about wallet corruption and not do any salvaging which would exacerbate the problem?
 9462017-08-03T20:45:41  *** Guest95816 is now known as fizzwont
 9472017-08-03T20:45:48  *** fizzwont has joined #bitcoin-core-dev
 9482017-08-03T20:47:42  *** dgenr8 has quit IRC
 9492017-08-03T20:57:00  *** Dizzle has joined #bitcoin-core-dev
 9502017-08-03T21:00:24  <wumpus> agreed, any 'salvaging' should be at user initiative
 9512017-08-03T21:17:22  *** jeep-ss has quit IRC
 9522017-08-03T21:26:02  *** Giszmo1 has quit IRC
 9532017-08-03T21:26:30  *** Giszmo has joined #bitcoin-core-dev
 9542017-08-03T21:32:49  *** elias19r has joined #bitcoin-core-dev
 9552017-08-03T21:33:11  *** elias19r has left #bitcoin-core-dev
 9562017-08-03T21:38:49  *** chjj has quit IRC
 9572017-08-03T21:42:32  *** Guyver2 has quit IRC
 9582017-08-03T21:50:19  *** chjj has joined #bitcoin-core-dev
 9592017-08-03T22:00:57  *** spudowiar has quit IRC
 9602017-08-03T22:10:12  *** Chris_Stewart_5 has quit IRC
 9612017-08-03T22:14:52  <earlz> Is there any easy way to make gitian skip building dependencies? I'm having some trouble with a modification I made breaking the gitian build for bitcoind itself, but the 2 hours spent compiling dependencies is killing me
 9622017-08-03T22:16:20  *** ekerstein has joined #bitcoin-core-dev
 9632017-08-03T22:19:55  *** fizzwont has quit IRC
 9642017-08-03T22:20:42  *** fizzwont has joined #bitcoin-core-dev
 9652017-08-03T22:21:05  *** fizzwont is now known as Guest17799
 9662017-08-03T22:21:32  <cfields> earlz: the dependencies are cached, they'll only be built once
 9672017-08-03T22:21:36  *** Guest17799 is now known as fizzwont
 9682017-08-03T22:21:45  *** fizzwont has joined #bitcoin-core-dev
 9692017-08-03T22:25:06  *** LampTreadStone07 has joined #bitcoin-core-dev
 9702017-08-03T22:26:33  *** Drabiv has quit IRC
 9712017-08-03T22:27:37  <earlz> cfields: that does not seem to be the case if gbuild fails
 9722017-08-03T22:29:50  <earlz> is there some command line argument or something I'm missing to prevent it from saving the cache, cause right now I basiclaly do gbuild, it compiles all deps, then encounters failure, I'll apply a fix and commit/push it, then update the gbuild command for the new commit hash and I observe it compiles all deps again
 9732017-08-03T22:30:00  <cfields> earlz: do a vanilla build, make sure it finishes, get the deps cached
 9742017-08-03T22:30:03  <cfields> then rebuild with your changes
 9752017-08-03T22:30:18  <earlz> oh I see, so it only caches if the build succeeds?
 9762017-08-03T22:30:40  <cfields> yes
 9772017-08-03T22:31:37  *** Mattie161 has quit IRC
 9782017-08-03T22:35:05  *** Dizzle has quit IRC
 9792017-08-03T22:48:43  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10984: Allow 2 simultaneous (compact-)block downloads (master...2017-08-paralell-block-downloads) https://github.com/bitcoin/bitcoin/pull/10984
 9802017-08-03T23:05:30  <BlueMatt> cfields: when you do the next round of cleanups on #10756, can you not move InitializeNode/FinalizeNode? I'm starting work on building on top and have patches that conflict :/
 9812017-08-03T23:05:32  <gribble> https://github.com/bitcoin/bitcoin/issues/10756 | net processing: swap out signals for an interface class by theuni · Pull Request #10756 · bitcoin/bitcoin · GitHub
 9822017-08-03T23:06:37  <cfields> BlueMatt: heh, i thought we agreed that was the next step?
 9832017-08-03T23:06:52  <BlueMatt> cfields: nono, i mean dont move the code down in the file
 9842017-08-03T23:06:54  <BlueMatt> not dont move
 9852017-08-03T23:07:28  *** chjj has quit IRC
 9862017-08-03T23:08:45  <cfields> BlueMatt: oh, I see what you mean
 9872017-08-03T23:08:54  <cfields> BlueMatt: they have to move out of the anon namespace though :(
 9882017-08-03T23:09:18  *** d_t has joined #bitcoin-core-dev
 9892017-08-03T23:09:30  *** ekerstein has quit IRC
 9902017-08-03T23:09:46  <BlueMatt> ohh, didnt realize they were in a namespace
 9912017-08-03T23:09:48  <BlueMatt> damn, ok, fine
 9922017-08-03T23:09:54  <BlueMatt> I'll just have to do some dirty rebase
 9932017-08-03T23:10:08  <cfields> yea, that's the only reason i moved them
 9942017-08-03T23:10:39  <cfields> could do something ugly like closing/reopening the namespace, but i'd rather not :)
 9952017-08-03T23:19:27  *** chjj has joined #bitcoin-core-dev
 9962017-08-03T23:23:09  *** laurentmt has joined #bitcoin-core-dev
 9972017-08-03T23:23:55  *** laurentmt has quit IRC
 9982017-08-03T23:26:15  <bitcoin-git> [bitcoin] sipa opened pull request #10985: Add undocumented -forcecompactdb to force LevelDB compactions (master...20170803_forcecompactdb) https://github.com/bitcoin/bitcoin/pull/10985
 9992017-08-03T23:39:03  *** Yogaqueef has quit IRC
10002017-08-03T23:40:54  <bitcoin-git> [bitcoin] sipa opened pull request #10986: Update chain transaction statistics (master...20170803_txstats) https://github.com/bitcoin/bitcoin/pull/10986
10012017-08-03T23:47:29  <gmaxwell> #10985: \0/
10022017-08-03T23:47:31  <gribble> https://github.com/bitcoin/bitcoin/issues/10985 | Add undocumented -forcecompactdb to force LevelDB compactions by sipa · Pull Request #10985 · bitcoin/bitcoin · GitHub
10032017-08-03T23:47:50  <sipa> gmaxwell: ^ untested
10042017-08-03T23:56:19  *** marcoagner has joined #bitcoin-core-dev
10052017-08-03T23:59:34  *** praxeology has quit IRC
10062017-08-03T23:59:36  *** abpa has quit IRC