--- Day changed Thu Sep 08 2016
00:04 -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-core-dev
00:11 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:34 < wumpus> let's try to make cfields network refactor (https://github.com/bitcoin/bitcoin/pull/8085/files) happen , it's been open so long now, line-wise there's a lot of changes so he keeps having to rebase it
00:35 < wumpus> /home/user/projects/bitcoin/bitcoin/src/test/addrman_tests.cpp:336:471: warning: stack frame size of 328360 bytes in function 'addrman_tests::addrman_delete::test_method' [-Wframe-larger-than=]    whoa :) luckily only in the tests
00:37 < sipa> what is a reasonable max frame size?
00:38 < wumpus> largest in the normal core code is a stack frame size of 67256 bytes in function 'ThreadSocketHandler', which is peculiar but not that bad
00:39 < wumpus> 64k or so for non-recursive code? most is far below that, even <10kB
00:40 < wumpus> whopping 'warning: stack frame size of 984520 bytes in function 'net_tests::caddrdb_read::test_method'
00:41 < sipa> 8654 introduces a 9 kB struct in CTransactionSignatureChecker
00:41 < wumpus> peanuts
00:42 < sipa> 984kB sounds like mild overkill, indeex
00:42 < sipa> indeed
00:42 < sipa> also, agree on making the net refactor happen
00:50 < jonasschnelli> Yes. Net factor should happen... I have the PR running since a couple of days...
00:51 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 250 seconds]
01:12 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
01:36 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds]
01:36 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer]
01:44 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
01:59 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev
02:03 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
02:05 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev
02:13 < GitHub87> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ec139a5621a9...ddc308068d69
02:13 < GitHub87> bitcoin/master f71d4a3 Jeremy Rubin: Minimal fix to slow prevector tests as stopgap measure
02:13 < GitHub87> bitcoin/master ddc3080 MarcoFalke: Merge #8671: Minimal fix to slow prevector tests as stopgap measure...
02:13 < GitHub67> [bitcoin] MarcoFalke closed pull request #8671: Minimal fix to slow prevector tests as stopgap measure (master...simple_faster_tests) https://github.com/bitcoin/bitcoin/pull/8671
02:25 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Read error: Connection reset by peer]
02:26 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev
02:41 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds]
02:43 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev
03:06 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev
03:11 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds]
03:20 -!- JackH [~Jack@79-73-191-94.dynamic.dsl.as9105.com] has quit [Ping timeout: 240 seconds]
03:21 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev
03:30 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds]
03:39 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
03:45 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev
03:53 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
03:56 -!- owowo [ovovo@gateway/vpn/mullvad/x-wlffenriruuzmoqi] has joined #bitcoin-core-dev
04:12 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
04:15 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 244 seconds]
04:20 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds]
04:25 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev
04:38 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds]
04:40 -!- translatoree3 [a1ca48a0@gateway/web/cgi-irc/kiwiirc.com/ip.161.202.72.160] has joined #bitcoin-core-dev
04:41 < translatoree3> Hello, need help with contributing a translation
04:41 < translatoree3> I've seen transfix, so translations there get credit on the github bitcoin repo?
04:42 < translatoree3> I'd like to get credit as I have a github account
04:42 < translatoree3> is there a way to send a pull request if the Transifex process doesn't give contributor credit on github repo?
04:44 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev
04:58 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
05:01 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds]
05:01 -!- laurentmt [~Thunderbi@80.215.210.95] has joined #bitcoin-core-dev
05:02 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 264 seconds]
05:04 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
05:05 < GitHub24> [bitcoin] bitcoinsSG opened pull request #8683: fix incorrect file name bitcoin.qrc  (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8683
05:07 -!- translatoree3 [a1ca48a0@gateway/web/cgi-irc/kiwiirc.com/ip.161.202.72.160] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
05:08 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 264 seconds]
05:12 -!- laurentmt [~Thunderbi@80.215.210.95] has quit [Quit: laurentmt]
05:17 -!- jtimon [~quassel@38.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
05:19 -!- dermoth_ [~thomas@dsl-66-36-143-95.mtl.aei.ca] has joined #bitcoin-core-dev
05:20 -!- dermoth [~thomas@dsl-66-36-158-91.mtl.aei.ca] has quit [Disconnected by services]
05:20 -!- dermoth_ is now known as dermoth
05:21 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev
05:34 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:36 -!- MrBTCNor [c2135fa2@gateway/web/freenode/ip.194.19.95.162] has joined #bitcoin-core-dev
05:41 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds]
05:47 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev
05:57 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
05:59 -!- vega4 [~pc_rafals@user-31-175-254-216.play-internet.pl] has quit [Ping timeout: 250 seconds]
06:11 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
06:14 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!]
06:14 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
06:16 -!- cryptapus_ is now known as cryptapus
06:19 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has joined #bitcoin-core-dev
06:19 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
06:19 -!- vega4 [~pc_rafals@c0-100.icpnet.pl] has joined #bitcoin-core-dev
06:22 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 252 seconds]
06:22 -!- Guyver2_ is now known as Guyver2
06:23 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Ping timeout: 260 seconds]
06:24 -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Ping timeout: 250 seconds]
06:25 < sipa> cfields: nice work with the network refactor, and sorry for not having the courage earlier to read through 34 commits (it wasn't all that bad)
06:31  * sipa is slightly annoyed with the introduction of many 'for('s and 'if('s, but seems we're not consistent about that already anyway
06:35 < cfields> sipa: thanks. np about review. I haven't been pushy about it because it's pretty rough to get through. The next round should be much easier since after this PR it's mostly self-contained
06:35 < cfields> and yes, sorry about the fors and ifs. I know that one bugs you. That's a habit that I can't seem to get out of
06:36 < sipa> i realize it's just preference, and i'm sure the existing spaces bother you too :p
06:36 < cfields> mm, I should get vim to fix that for me
06:37 < cfields> not at all, they're only reminders that i forgot to space my changes around it (while re-reading post-commit, of course)
06:41 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
06:59 -!- Sanakov [~sanakov@bitfuse.org] has joined #bitcoin-core-dev
07:05 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
07:08 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 252 seconds]
07:08 -!- Guyver2_ is now known as Guyver2
07:08 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
07:15 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
07:17 -!- assder [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has joined #bitcoin-core-dev
07:23 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev
07:28 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
07:35 -!- face_ [~face@mail.hmel.org] has joined #bitcoin-core-dev
07:39 -!- face_ is now known as face
07:48 < jeremyrubin> cfields: be sure to look on the latest; I fixed it i beleive
07:54 -!- MrBTCNor [c2135fa2@gateway/web/freenode/ip.194.19.95.162] has quit [Quit: Page closed]
07:56 < cfields> jeremyrubin: see github comments
07:58 -!- Sanakov [~sanakov@bitfuse.org] has quit [Quit: Textual IRC Client: www.textualapp.com]
08:02 < morcos> cfields: i was just trying to review #8660, so this is also a regression caused by https://github.com/bitcoin/bitcoin/pull/7946?
08:03 < jeremyrubin> cfields: yeah you weren't looking at the one i sent you yest
08:03 < cfields> morcos: aha, probably so
08:04 < morcos> cfields: i wonder if we need to think a bit more carefully about that pull.  is there anything other than the RPC tests that might be depending on wallets being synced onces cs_main is released
08:04 < morcos> for instance you could imagine someone using bitcoin core has come to depend on that behavior
08:04 < morcos> not saying it shouldn't eventually be changed, but seems like something that requires a bit more thought
08:05 < cfields> morcos: think more about 7946, you mean?
08:05 < morcos> yeah
08:06 < jeremyrubin> cfields: oops I'm wrong you were sorry -- i need to fix my github notifs they suck
08:06 < sipa> morcos: 8660? sure you have the right number?
08:06 < morcos> what the RPC tests are uncovering is that the wallet can now be out of sync with the blockchain.
08:06 < cfields> morcos: now that you mention it, i wonder if blocknotify is affected
08:06 < jeremyrubin> sipa: morcos is referring to the already merged one
08:06 < morcos> yeoops 8680
08:06 < jeremyrubin> oops nvm
08:07 < cfields> ok nm, blocknotify uses the same signal, so the wallet would already be synced there
08:07 < sipa> cfields: for 8680, isn't it possible to use ping/waitforpong instead?
08:08 < morcos> sipa: the issues isn't fixing it for the RPC tests
08:08 < morcos> the issue is whether there are things other than the rpc tests that were relying on wallet always being synced with blockchain once cs_main was released
08:09 < cfields> sipa: isn't that just punting the problem to "now we assume we're all synced" at a different point?
08:09 < morcos> also ping/waitforpong would happen to work i think with the current architecture, but not necessarily in the future right..  
08:10 < sipa> morcos: i don't think we can get rid of the synchronizing behaviour of ping/pong without breaking half the network software
08:11 < morcos> sipa: there is a difference between it always synchronizing network behavior and synchronizing other thigns right?  it just happens that the processing of messages happens in the same thread as the wallet syncing code now
08:11 -!- vega4 [~pc_rafals@c0-100.icpnet.pl] has quit [Ping timeout: 265 seconds]
08:11 < morcos> so you couldn't get to the pong until you'd synced the wallets, but that doesn't seem like something that would necessarily always be true
08:11 -!- rubensayshi [~ruben@82.201.93.169] has quit [Remote host closed the connection]
08:11 < sipa> morcos: i see
08:11 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
08:11 < sipa> yes, i think we should prepare for a case where wallet syncing happens entirely in the background
08:12 < sipa> and can lag behind more than one block
08:12 -!- vega4 [~pc_rafals@c0-100.icpnet.pl] has joined #bitcoin-core-dev
08:12 < sipa> and network synchronizing messages don't change that
08:12 < cfields> i suppose that's why sdaftuar was thinking more in terms of wait_for_wallet()
08:12 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
08:13 < morcos> sipa: agreed.  and i think #7946 has forced that issue to be we have to think about that for 0.13.   b/c as far as RPC is concerned the wallet syncing can be happening several blocks behind now.
08:13 < morcos> sorry, for master, not 0.13.  i'm still behind.  :)
08:15 < BlueMatt> so what probably should happen, to avoid changing the api, is that any time you call into wallet it blocks until it has a consistent state with current blockchain
08:15 < cfields> in the event that we start moving towards more async behavior, i think it's only natural to start introducing blocking rpcs
08:16 < BlueMatt> otherwise you get an inconsistent rpc api - getblockheight will tell you something and then wallet will be behind that
08:16 < BlueMatt> which is a hugely surprising api change
08:16 < cfields> heh
08:16 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 265 seconds]
08:16 < morcos> cfields: i thought you just typed super fast
08:16 < BlueMatt> moving wallet sync out of main thread is an important goal - and unlocking cs_main for it is a first step
08:16 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
08:17 < BlueMatt> but an api change like that is probaly just not ok
08:17 < sipa> that does make sense
08:17 < sipa> just have the wallet rcps wait for sync
08:18 < morcos> but what exactly should they wait for
08:18 < BlueMatt> being up-to-date with the chain state at the call entry
08:18 < morcos> as you're catching up the blockheight could still be increasing i think
08:18 < BlueMatt> or, maybe, lock cs_main...
08:19 < cfields> morcos: you'd need to pass in the synced-to-x height to the wallet rpc :(
08:20 < morcos> i guess what i just described is an existing problem, so maybe thats ok, b/c cs_main is released anyway
08:21 < BlueMatt> i mean, ok, what makes the rpc consistent? if the rpc request blocks, then its not crazy to make the state returned consistent with where the chainstate was when you entered the rpc, because otherwise the client is multithreaded and thats gonna be broken no matter what we do
08:21 < cfields> morcos: but, if you've specifically waited for a certain height/hash, and it's blocked/returned until that's hit, then you're at least synced to that height for the next call
08:21 < cfields> (ignoring invalidate/reconsider, which ruin all of that)
08:21 < morcos> cfields: yes. agreed. i think we should fix it that much.
08:22 < cfields> morcos: well, the new rpcs in #8680 do all that we've described here. We could just wrap the old ones around those...
08:23 < morcos> cfields: yes that sounds right...  i think we need to call getblockheight from the wallet calls and then use your new calls to wait for that
08:23 < sipa> well the wallet can remember independently up to what block hash it is synced
08:24 < sipa> which afaik it does not do now
08:24 < morcos> sipa: i think you want to avoid querying the wallet mid-block
08:25 < BlueMatt> sipa: oh? I thought it did?
08:25 < BlueMatt> It used to at least be on-disk, too
08:25 < sipa> morcos: eh, yes, how does that matter?
08:25 < sipa> BlueMatt: yes, but that isn't uodated for every block
08:26 < BlueMatt> ahh, well, ok, lets update it (in memory) for every block :p
08:26 < sipa> agree
08:27 < morcos> sipa: if the wallet rpcs aren't synced using cory's mechanism then when you check the wallet you don't know if its in the middle of syncing some next block (that maybe you weren't waiting for)
08:27 < morcos> but actually, i guess you still don't know that
08:27 < morcos> shoot
08:29 < morcos> so maybe we need to lock the wallet around the SyncWithWallets loops?
08:30 < sipa> hmm?
08:30 < cfields> brb
08:32 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Remote host closed the connection]
08:32 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev
08:32 < morcos> sipa: isn't there nothing that stops a getbalance() call from happening in the middle of a SyncWithWallets() loop for a given blcok
08:33 < sipa> so i'm not sure the out of syncness matters to external observers... if you used to wait for a block and then later do and RPC query, it has always been possible that yet another block got processed in between
08:33 < morcos> yes
08:33 < morcos> but now half of another block could be processed
08:33 < sipa> what matters is consistency of wallet rpcs with its own state of the chain
08:33 < morcos> which seems somehow worse
08:33 < BlueMatt> sipa: its very, very, strange to get a balance response that is valid as of the middle of a block, but will change before the end of the block
08:33 < BlueMatt> I'm not sure that ever used to be pososible
08:33 < morcos> it didn't it was protected by cs_main previously
08:34 < sipa> what is the middle of a block?
08:34 < sipa> how can the middle of a block be observed?
08:34 < morcos> don't you just loop through the txs and call SyncWithWallets individually for each one
08:34 < sipa> the only problem is using main's tip to determine wallet confirmations etc
08:34 < sipa> the wallet should use its own tip idea to determine confirmations, instead of main's
08:34 < morcos> why can't you ask for the balance in the rpc thread while you are in the middle of that loop
08:35 < sipa> i think that's fine; it won't be counted as confirmed until it's done
08:35 < sipa> (with the change to use the wallet's idea of the tip)
08:36 < morcos> sipa: its hard to imagine an exact problem, but it just seems an odd change
08:36 < morcos> whats the downside to locking the wallet around that loop?
08:36 < sipa> ah, now i understand what you mean
08:36 < sipa> to prevent a partially updated wallet
08:37 < sipa> i think that's fine, yes
08:37 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]
08:37 < sipa> but i think it can be avoided
08:37 < morcos> now someone just has to remember these ideas we've discussed.  on that note, lunch time.  :)
08:37 < BlueMatt> indeed, but we should :)
08:37 < sipa> enjoy nourishment
08:42 < cfields> back. all fixed? :)
08:43 < cfields> morcos: lunch thought: i suppose we'll need the same fencing for individual transactions + wallet interactions
08:44 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
08:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
08:54 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.]
08:55 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
08:58 -!- AaronvanW [~ewout@77pc231.sshunet.nl] has joined #bitcoin-core-dev
08:58 -!- AaronvanW [~ewout@77pc231.sshunet.nl] has quit [Changing host]
08:58 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
09:02 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
09:03 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Ping timeout: 276 seconds]
09:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
09:13 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
09:18 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
09:34 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
09:39 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Read error: Connection reset by peer]
09:40 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
09:51 -!- vega4 [~pc_rafals@c0-100.icpnet.pl] has quit [Quit: Leaving]
10:11 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
10:15 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
10:19 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
10:22 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
10:27 -!- jtimon [~quassel@38.110.132.37.dynamic.jazztel.es] has quit [Remote host closed the connection]
10:29 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
10:30 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
11:00 < morcos> cfields: how do you mean?
11:04 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
11:08 -!- jyap [~jyap@unaffiliated/jyap] has quit [Ping timeout: 265 seconds]
11:11 < cfields> morcos: now that i'm poking around, i can't come up with a realistic example
11:12 < cfields> morcos: i was thinking about cases where the mempool holds a tx that the wallet isn't in sync with yet, where the mempool presence would lead the rpc caller to expect a wallet entry
11:16 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
11:19 -!- jtimon [~quassel@38.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
11:21 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
11:22 < sipa> i believe we've had a related discussion to this before
11:23 < sipa> about whether or not external notifications should be sent before or after wallet updates
11:23 < sipa> or something like that
11:23 < sipa> because in some cases you want the update as soon as possible, but if you're going to use it to trigger a wallet request, the wallet should be updated first
11:28 < wumpus> probably there should be an external notification for the core as well as the wallet
11:29 < wumpus> if you want to be updated of the wallet processing some information, you'd listen for the wallet notification, if you want to know as soon as possible after the core rpocessed something you'd listen for the core notification
11:30 < sipa> yup, agree
11:30 < sipa> if the wallet is going to be asynchronously updated from the rest, it should have independent notifications too
11:30 < wumpus> and in the hypothetical case with with multiple wallets you'd want to register for *that* wallet you're interested in
11:30 < wumpus> right
11:30 -!- jyap [~jyap@2604:180:1:7f5::b59a] has joined #bitcoin-core-dev
11:30 -!- jyap [~jyap@2604:180:1:7f5::b59a] has quit [Changing host]
11:30 -!- jyap [~jyap@unaffiliated/jyap] has joined #bitcoin-core-dev
11:31 < wumpus> it would make a lot of sense for wallet processing to be asynchronous
11:31 < wumpus> and indeed, in that case there's no use in getting a signal after the wallet got the signal
11:31 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Ping timeout: 255 seconds]
11:31 < wumpus> it still has to start processing
11:32 < wumpus> what you need is a notification from the wallet itself that it processed 
11:32 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
11:37 < jonasschnelli> we have one! -walletnotify *duck*
11:39 < sipa> yes, but we'd also need a notification from the wallet that it processed a block
11:40 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has quit [Ping timeout: 255 seconds]
11:41 < jonasschnelli> Yes. Maybe an signal short after when the wallet bestblock was updated.
11:41 < wumpus> right
11:42 < jonasschnelli> Though this works agains in the opposite direction then the possible plan of decoupling the wallet process.
11:42 < jonasschnelli> (if the core side is consuming the event)
11:42 < sipa> parse error
11:44 < jonasschnelli> In case we want the wallet be capable of running without the validation (utxo-set/mempool) we should be carefully add signals (or lets say additional coupling between those elements)
11:44 < wumpus> no, the wallet would be emitting the event
11:45 < jtimon> I'll be afk during the meeting but will read later
11:45 < wumpus> the core side doesn't subscribe to it or anything
11:45 < wumpus> 'has wallet processed block' is only something that external clients may care about, maybe the GUI, but certainly not the core
11:45 < kanzure> this seems to be someone from a law firm talking about "veil of decentralization" and fork types https://www.youtube.com/watch?v=7aV-k_6nZ8g&t=43m10s 
11:45 < kanzure> oh crud.
11:45 < jonasschnelli> Ok. Right. This would make sense.
11:45 < kanzure> please ignore.
11:46  * kanzure wanders off
11:47 -!- arubi_ [~ese168@unaffiliated/arubi] has quit [Ping timeout: 244 seconds]
11:50 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
11:50 -!- pmienk_ [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Quit: Leaving]
11:51 < GitHub36> [bitcoin] jl2012 opened pull request #8685: Discourage P2WSH with too big script or stack (master...bigp2wsh) https://github.com/bitcoin/bitcoin/pull/8685
11:54 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
11:55 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: ...]
11:56 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev
11:58 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev
11:59 < wumpus> meeting time?
11:59 < jonasschnelli> ack
11:59 < wumpus> #startmeeting
11:59 < lightningbot> Meeting started Thu Sep  8 18:59:58 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:59 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00 < 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
12:00 < morcos> here
12:00 < CodeShark> here
12:00 < jeremyrubin> here
12:00 < BlueMatt> topic: sing morcos happy birthday
12:00 < petertodd> here
12:00 < btcdrak> here
12:00 < cfields> thanks, here
12:00 < kanzure> here
12:00 < petertodd> BlueMatt: ack!
12:00 < wumpus> happy birthday morcos
12:00 < jeremyrubin> leaked PII
12:00 < btcdrak> gmaxwell you missed jl2012
12:00 < kanzure> wumpus: no doxxing :)
12:00 < jeremyrubin> Alex sing your ssn!
12:00 < petertodd> kanzure: lol
12:01 < michagogo> Happy birthday!
12:01 < luke-jr> morcos: happy birthday https://www.youtube.com/watch?v=dQw4w9WgXcQ
12:01 < morcos> thanks
12:01 < sipa> morcos: congrats
12:01 < jcorgan> here in spirit only
12:01 < btcdrak> saved by DCMA filters "The uploader has not made this video available in your country."
12:01 < jonasschnelli> morcos: hey! happy birthday.
12:01 < petertodd> kanzure: happy birthday to anyone who considers themselves born on this date
12:01 < kanzure> much better.
12:01 < petertodd> btcdrak: the copyright on happy birthday got overturned :)
12:01 < btcdrak> petertodd: click the link
12:02 < wumpus> anyone with proposed topics?
12:02 < petertodd> btcdrak: oh, that's a great song
12:02 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 240 seconds]
12:02 < sipa> wumpus: just one: we have quite a queue of things for 0.13.1, and i'd like to encourage people to review
12:02 < BlueMatt> real topic: segwit-cb bip
12:02 < btcdrak> wumpus: birthday cake
12:02 < kanzure> not a topic proposal, but i would like to eventually get a resolution on the after_failure weirdness
12:03 < jonasschnelli> I just wanted to let you know that there will be two hack days on monday and tuesday 10th and 11th of October after the SB conference in Milan.
12:03 < petertodd> jonasschnelli: I'll be there
12:03 < gmaxwell> btcdrak: the list was just based the top participants in the past.
12:03 < jonasschnelli> More info and registration will follow... 
12:03 < wumpus> yes last week there was an ACTION for "Support for compact blocks together with segwit" (#8393), there has been a bit of review activity in last days, what's the status there?
12:04 < gmaxwell> wumpus: I've been doing some testing. There aren't many segwit transactions on testnet currently. I was going to call for people to create more once I got more testing setup.
12:04 < sipa> BlueMatt: i haven't reviewed the changes for the bip you suggested - does it require any code changes to the bitcoin core pr?
12:04 < wumpus> #info jonasschnelli: I just wanted to let you know that there will be two hack days on monday and tuesday 10th and 11th of October after the SB conference in Milan. More info and registration will follow... 
12:04 < BlueMatt> sipa: possibly, two options, though, one minor, one slightly more
12:04 < btcdrak> maybe we can ask roasbeef to help tx generation there
12:04 < wumpus> gmaxwell: more segwit transactions would help, yes :)
12:05 < sipa> can we pick a topic?
12:05 < wumpus> #link re: queue of things for 0.13.1, link is https://github.com/bitcoin/bitcoin/milestones/0.13.1
12:06 < wumpus> #topic segwit-cb bip
12:06 < btcdrak> jl2012: is everything you are working correctly tagged (or not) for 0.13.1?
12:06 < BlueMatt> so, to quote github issue "The last commit changes the protocol entirely, adding a cmpctack message. This has the advantage that you could implement receiving of some version of compactlocks without implementing sending that encoding, as well as simplifying the protocol slightly (instead of having to check if the current protocol version is higher-priority according to your probably-compile-time list of supported version you know 
12:06 < BlueMatt> which version you're using directly from the ack message) at the expensee of complicating the implementation somewhat (now you have to add support for another message type and special-case version 1). The last commit is definitely not worth it if we dont anticipate adding more than one or so more versions, but might be worth it if we anticipate compact blocks version 4, 5, 6 at some point. I'll bring this up in the IRC meeting later 
12:06 < BlueMatt> today."
12:07 < BlueMatt> essentially, the current proposal is that you annoucne the set of compact block versions you want at startup (BIP text says before you send any pong or other compact block messages)
12:07 < BlueMatt> and each sendcmpct announce implies that you are willing to encode to those
12:07 < jl2012> btcdrak: including those already tagged, I think 8685, 8654 and 8635 are also for 0.13.1
12:07 < BlueMatt> and you send them in the priority of what you want to receive
12:07 < BlueMatt> and the version you use to send is the first one you receive from the other side that you also sent
12:08 < jl2012> at least we may consider to include in 0.13.1
12:08 < BlueMatt> and you use the highest-priority one the other side also announced to decode
12:08 < BlueMatt> (comment text from above link https://github.com/bitcoin/bips/pull/423#issuecomment-245629813 )
12:08 < sipa> i'm not a fan of changing the code again after all testing, but i do agree it's a cleaner solution, and will make things easier for future extensions
12:08 < BlueMatt> so this is obviously somewhat complicated
12:09 < BlueMatt> and the solution would be to introduce a cmpctack which you use to pick the one you want to encode to
12:09 < sipa> cmpctack containing the version you picked?
12:09 < wumpus> jl2012: (tagged. number of pulls for 0.13.1 does seem to be getting a bit out of hand)
12:09 < gmaxwell> can we have some discussion about this outside of the meeting, I want to ask some questions but I think it'll be a design rathole right now. :)
12:10 < BlueMatt> simplifying the which-do-i-use-to-decode code from "for each sendcmpct msg received, is this higher priority than the previously-highest-prirotiy one" to "the one I saw in a sendcmpct"
12:10 < BlueMatt> in practice the proposed cmpctack is way more code, but a bit simpler
12:10 < sipa> BlueMatt: ok, i'll review and adapt the pr
12:10 < BlueMatt> s/""the one I saw in a sendcmpct"/""the one I saw in a cmpctack"/g
12:10 < sipa> gmaxwell: ok
12:10 < BlueMatt> I, personally, dont really like the cmpctack idea
12:10 < sdaftuar> i do like the cmpctack idea!
12:10 < sipa> so what alternative do you propose?
12:10 < BlueMatt> certainly if we plan on having lots of versions, it is simpler protocol-wise
12:10 < jl2012> wumpus: most of mine are pretty trivial. I am no able to do more than that anyway
12:11 < BlueMatt> if we only ever have version 1 and 2 and maybe like a 3, then the previous proposal seems perfectly ok to me
12:11 < morcos> My viewpoint is that we suffer a history of technical debt, and we have a chance now while compact blocks are new to kind of clean up the protocol messages with a bit less fuss
12:11 < sipa> morcos: agree
12:11 < BlueMatt> sipa: either way I'm proposing to switch the priority order to first-is-highest from last-is-highest
12:11 < wumpus> jl2012: agreed
12:11 < morcos> so we shoudl take the added changes now to be happier later with a better design
12:11 < luke-jr> would it ever make sense to support a per-block encoding? for example, if nodes at some point want to pass blocks along as-is from peer A to other peers when possible
12:12 < BlueMatt> note that we have to introduce a backwards compatibility hack if we do cmpctack
12:12 < gmaxwell> I think it's fine to clean things up. But at some point the correct 'upgrade' is to just introduce a seperate mechenism sendcmpt2 and drop the old one, rather than extending.
12:12 < sipa> BlueMatt: just say that if no ack is ever sent, it is implicitly for v1
12:12 < luke-jr> BlueMatt: do we? old CBs will die with segwit anyway..
12:13 < BlueMatt> sipa: this implies you have to announce sendcmpct version 1
12:13 < gmaxwell> past some point trying to create a forever design just guarentees technical debt of a different kind. :)
12:13 < BlueMatt> which the proposal for creating a cmpctack would not do
12:14 < morcos> we should maybe do as gmaxwell said and discuss after meeting, but i don't think we actually need a hack, you just need to still tell 0.13 nodes that you support v1 and they only understand that by sending them a sendcmpct 1
12:14 < morcos> but it doesn't hurt to send that to everyone
12:14 < BlueMatt> alternatively: compact block version 3 can be called something other than compact blocks
12:14 < BlueMatt> then you can do whatever :P
12:14 < sipa> BlueMatt: hahaha
12:14 < sipa> i could live with that too.
12:14 < gmaxwell> BlueMatt: yea, thats what I was saying, effectively.
12:14 < gmaxwell> besides the general framework here has limitations, further latency optinization should basically be a non-goal, because the fiber approach is vastly better in that respect.
12:15 < BlueMatt> anyway, its taken 15 minutes to explain what the issues are, so maybe decide later, or let other topics go ahead first
12:15 < wumpus> I don't think any other topics have been (seriously) proposed
12:16 < wumpus> so go ahead
12:16 < jl2012> I got to go. See you
12:16 < morcos> proposed topic: picking a segwit rollout date and announcing this in a wider format
12:16 < wumpus> see you later jl2012
12:16 < sipa> jl2012: good night
12:16 < sipa> BlueMatt: how about just sending sendcmpct2 for v2 :)
12:17  * sipa hides
12:17 < gmaxwell> morcos: I think the blocker there was basically having all the things merged in 0.13 branch that we believe would be needed on our end.
12:17 < BlueMatt> alternatively: version negotiation protocol examples are at https://github.com/bitcoin/bips/blob/833dea41c4c757087ef4c35e3b19259ba2f80128/bip-0152.mediawiki#Sample_Version_Implementation and https://github.com/bitcoin/bips/blob/0d9b12cf285762e8ff661fe17e3261d014af1581/bip-0152.mediawiki#Sample_Version_Implementation
12:17 < cfields> topic suggestion: rpc sync assumptions
12:17 < btcdrak> need review of these backport #8679, should be simple enough
12:18 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
12:18 < BlueMatt> though I think the second misses the fact that you have to use sendcmpct instead of cmpctack if its version 1
12:18 < instagibbs_> oh hi. znc bouncer is broke or something.
12:18 < morcos> gmaxwell: yeah i've been a bit out of touch, and i can see that makes sense..   but i also think it would be nice to give as much warning to the community as possible as to when we are proposing to actually release this
12:19 < gmaxwell> morcos: yes, a message that says "This will happen soon, our side waiting for X" to give people a chance to raise any concerns would be reasonable, I think.
12:19 < instagibbs_>  /release/activate/ ?
12:19 < morcos> instagibbs_: yes, both
12:19 < CodeShark> we've been giving that message for several weeks already ;)
12:19 < wumpus> #topic picking a segwit rollout date and announcing this in a wider format
12:19 < instagibbs_> I've been pointing out the remaining milestone list, but it's a bit opaque for people who aren't actively reviewing stuff
12:19 < gmaxwell> I went around to soem forks and asked for what their scheduling looked like and the response I got was basically 'after it's deployed in the network'
12:20 < sipa> we can't propose a rollout date before knowing when we can have 0.13.1 out, and there are quite a few things to work out for that
12:20 < morcos> sipa: yeah i suppose i agree
12:20 < CodeShark> I'd rather not pile on additional scheduling issues externally unless we're confident
12:20 < achow101> is a 0.12.2 backport still happening?
12:21 < instagibbs_> Would the amount of lead time differ once we've merged all remaining issuess?
12:21 < wumpus> yes it seems 0.13.1 is a lot more work than expected
12:21 < wumpus> achow101: I don't think so
12:21 < btcdrak> achow101: segwit needs compact block relay, so very unlikely.
12:22 < achow101> ok
12:22 < luke-jr> "needs"?
12:22 < wumpus> achow101: getting this into 0.13 in the first place and assuring it is correct is a lot of work, I doubt anyone can pile up the extra work for 0.12
12:22 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
12:22 < BlueMatt> luke-jr: yea, what? segwit doesnt NEED it
12:23 < instagibbs_> And no one seems to be demanding it, more importantly
12:23 < BlueMatt> just might be painful if you dont have it
12:23 < btcdrak> unless you are happy with bigger blocks being relayed without it...
12:23 < btcdrak> anyway. weeds.
12:23 < sipa> yes, weeds
12:24 < instagibbs_> Which PRs need the most attention at this point
12:24 < gmaxwell> achow101: no we pretty much decided to not do a 0.12. backport over a month ago.
12:24 < wumpus> weeds?
12:24 < sipa> wumpus: "we're getting into the weeds"
12:24 < wumpus> ohh
12:24 < gmaxwell> achow101: not worth the risk and resource investment, and no one was jumping to do it. From measurements and feedback we've found that virtually no one uses backport releases.
12:24 < instagibbs_> mfw pieter is explaining English idioms 
12:24 < CodeShark> in the netherlands that might have a different meaning ;)
12:24 < jonasschnelli> heh
12:24 < wumpus> yes, 0.12 just isn't a very important topic right now, let's focus on moving forward
12:24 < wumpus> CodeShark: yes :)
12:25 < luke-jr> also, if someone really needs 0.12, they can put it behind a 0.13.1 node
12:25 < wumpus> next topic?
12:25 < wumpus> #topic rpc sync assumptions
12:25 < gmaxwell> luke-jr: precisely, and any sw backport would create the disruption people were trying to avoid in staying with an older version.
12:26 < gmaxwell> wumpus: I don't understand why people thought it was a problem that getbalance could return a "mid block" response.
12:26 < morcos> just to be clear, the change to reduce cs_main locks is only for 0.14, so we don't have to worry about rpc sync assumptions for 0.13.1 right?
12:26 < cfields> so, marcos pointed out that the reason that the rpc tests are failing and fix is needed is that we broke some timing assumptions by optimizing some stuff
12:27 < cfields> so the question is: are those assumptions ok to break (just fix the tests), or are they part of the api?
12:27 < cfields> wow, re-reading that, that's incredibly vague :)
12:27 < sipa> morcos: yes
12:27 < jonasschnelli> Can you make a clear example?
12:27 < gmaxwell> I think the question should be what do we think the best behavior is. And if the best behavior changes the API, we should do it and document the change.
12:27 < jeremyrubin> WalletSync expected to occur in test
12:28 < jonasschnelli> Do we assume the wallet has processed a transaction after getting informed of a blockupdate?
12:28 < jeremyrubin> *under the lock
12:28 < luke-jr> does "mid block" include "numbers are being changed, so the value is unlike either the previous OR the next correct value"?
12:28 < wumpus> gmaxwell: I don't know either, there's no guarantee that blocks are atomically processed by the wallet
12:28 < sipa> we can make it atomic, as pointed out by morcos earlier
12:28 < jonasschnelli> s/blockupdate/tipupdate
12:28 < wumpus> but is it necessary?
12:28 < morcos> luke-jr: it reflects the full effect of some of the txs in the block but not all
12:28 < gmaxwell> my understanding is that the tests are doing things like handing a node a block, then instantly checking the wallet, and expecting it to be fully consistent with the block right away. Is this understanding correct?
12:28 < sipa> my alternative is that we make the wallet aware of the current tip it knows about, and we let confirmations be computed based on that
12:29 < sipa> that means that mid-block update you can see unconfirmed transactions
12:29 < BlueMatt> jonasschnelli: ex: you do a getblockheight rpc call - under previous versions if you then do a getbalance that balance is up to date to that block, this is no longer true
12:29 < wumpus> the tests need proper synchronization commands, some of those need to be implemented, I don't think we need to change the whole API for that
12:29 < morcos> wumpus: well before we get to the atomic block question, there is the question of whether if you wait for the blockchain to be synced to some height, and then query the wallet whether you are getting wallet values of at least that height (mid-block or not)
12:29 < cfields> gmaxwell: correct. as soon as the height/hash is reflected, they assume the wallet is synced with that height/hash
12:29 < wumpus> (besides adding those syncronization commands)
12:29 < jonasschnelli> Can we not just have the wallets bestblock in getwalletinfo and use it for sync with getchaintips?
12:29 < BlueMatt> sipa: I think mid-block updates is a blatant violation of the "principal of least surprise"
12:29 < gmaxwell> morcos: okay, I think sipa's suggestion would address that esp with coupled with a way of asking for the wallet's tip.
12:30 < wumpus> morcos: well it would make sense for the wallet to track where it is, synchronization-wise, absolutely
12:30 < gmaxwell> BlueMatt: uh then we need to remove unconfirmed transactions too?!
12:30 < wumpus> morcos:  and for thtat info to be available externally
12:30 < luke-jr> showing a best-wallet-block would make the whole mid-block state even more broken IMO (what best-block will it show mid-state?)
12:30 < sipa> BlueMatt: there can always be unconfirmed transactions in the wallet
12:30 < BlueMatt> and, further, if wallet is allowed to return something that is not up to date with the start of the call, this changes literally our entire api....so now anyone using the rpc has to go re-audit all of their uses of it???
12:30 < sipa> luke-jr: the previous one
12:30 < BlueMatt> sipa: huh? I mean things mid-block...am I missing what you said?
12:31 < gmaxwell> luke-jr: it will update its state when its done processing updates, of course.
12:31 < morcos> fixing the mid-block thing seems pretty trivial to me, why wouldnt' we just do that
12:31 < jonasschnelli> luke-jr: the bestblock should only be updated after fully processing? Right?
12:31 < BlueMatt> sipa: i was under the impression you indicated that you would see txn which come later in that block as unconfirmed, while txn earlier in the block are marked confirmed
12:31 < gmaxwell> Why are people regarding mid block as a bug?!?
12:31 < sipa> BlueMatt: no
12:31 < gmaxwell> at _any_ time a transaction can show up and appear in the wallet, unrelated to any blocks.
12:31 < morcos> gmaxwell: b/c its not a feature?
12:31 < sipa> BlueMatt: mid-update you would see the transactions of the new block as unconfirmed
12:32 < luke-jr> that seems the most obvious behaviour, but if you look at bestblock+balance, I would think them a pair, yet balance might be bestblock+partOfNextBlock in reality?
12:32 < morcos> i mean does anyone want that
12:32 < BlueMatt> ahh, yes, ok, so i was just confused....txn which appear in wallet before the block has processed seems reasonable
12:32 < gmaxwell> Unless you want to remove unconfirmed transactions that will always happen.
12:32 < sipa> i also don't think there is any problem with grabbing a wallet lock during the update
12:32 < wumpus> so if changing the balance mid-block is regarded as a bug, that should apply to all other state too: the transaction list, for example. It should hold all updates until it processed the entire block
12:32 < sipa> which would prevent seeing a mid-update state
12:32 < sipa> i'm just questioning if it is necessary
12:32 < gmaxwell> it seems strange to me to hurt concurrency to protect a property that we don't actually have (due to unconfirmed transactions)
12:33 < wumpus> I don't think using the lock for that is a good thing
12:33 < wumpus> agree with gmaxwell
12:33 < jonasschnelli> From the wallet perspective processing doesn't matter, you just want to see confirmations... can slowly appear on a tx list IMO
12:33 < cfields> wumpus: right, that made me cringe. That seems like a major layer violation
12:33 < morcos> wumpus: gmaxwell: but can you explain what concurrency we are hurting?
12:33 < morcos> i'm not suggesting we put cs_main covering those again
12:33 < wumpus> morcos: you have to hold the lock *all* the time while processing the block
12:33 < BlueMatt> gmaxwell: if it were listing your *confirmed* balance as mid-block, then it would be an issue
12:33 < sipa> wumpus: no
12:34 < gmaxwell> Wallet processing shouldn't stall when the node is processing a block, at least not any more than strictly necessary.
12:34 < BlueMatt> which I believe is what people are worried about
12:34 < sipa> wumpus: the proposal is to grab cs_wallet during the wallet updating for the block
12:34  * luke-jr wonders if there's a good way to use listsinceblock
12:34 < sipa> wumpus: which happens in its entirety after main processes the block
12:34 < morcos> i'm just suggesting we use cs_wallet or some other lock that prevents a wallet specific call from returning until you are no longer in the middle of a loop that calls SyncWithWallets (on a given block)
12:34 < sipa> wumpus: cs_main isn't even held at the point
12:34 < wumpus> sipa: I know, but you'd still be holding the wallet lock longer than necessary
12:34 < BlueMatt> to be fair, all of this should move onto a background thread in the future anyway
12:34 < gmaxwell> morcos: so now wallet calls will stall block processing? (when the block processing waits to take that lock?)
12:34 < wumpus> BlueMatt: agreed on that
12:34 < sipa> yes, and it may be harder to maining if we parallellize/asynchronize things more
12:35 < wumpus> wallet block processing should be async at some point
12:35 < BlueMatt> so this would be a temporary fix that we should consider something which will happen on a background thread...lets not get too focused on blocking block processing with it
12:35 < sipa> morcos: do you think there is a problem with showing the transactions from the being-processed-block as unconfirmed during the update?
12:35 < morcos> gmaxwell: hmmm, yes i suppose while thats in the main thread thats a bad idea
12:35 < jonasschnelli> IMO the wallet should process a copy of the block on its own, own thread
12:35 < sipa> jonasschnelli: yes yes
12:35 < CodeShark> ^]
12:35 < wumpus> sipa: probably it will already be in the wallet as unconfirmed anyhow
12:35 < sipa> jonasschnelli: i think everyone agrees on that
12:35 < gmaxwell> BlueMatt: I'm fine with temporary fixes, I'm just confused as to why anything needs to be fixed here except some unrealistic expectations in the tests.
12:36 < sipa> gmaxwell: i believe the current situation is broken
12:36 < gmaxwell> sipa: great. I'd like to understand why.
12:36 < sipa> mid-update you can see half of the block reflected as confirmed transactions, and miss other transactions from that same block
12:36 < BlueMatt> gmaxwell: two issues: getbalance, by default, shows your *confirmed* balance, so you expect that to be consistent...right now it is not clear (I maybe wrong) that it might not show *half* of your actually confirmed balance
12:36 < morcos> sipa: i think i need to go look more carefully at what SyncWithWallets does with txs from the block, but for instance, coudl you end up removing a conflicted tx, then showing a balance, without having addd the replacement tx yet.  i think yes, and i think thats would be confusing
12:36 < gmaxwell> okay, I agree showing confirmed for some and not others is odd. Showing some and not others, however I think is fine, and consistent with the normal behavior.
12:37 < cfields> let's not focus on the details here. The question at hand (mine, anyway), is whether the blocking behavior from 0.13 is considered part of the api, or if it's ok to deviate. If the answer is the latter, we can just fix the tests and move on.
12:37 < sipa> cfields: blocking what behaviour?
12:37 < sipa> 0.13 does not have this change
12:37 < sipa> cfields: i think there is something that needs to be fixed in master, that is deeper than fixing up tests
12:37 < sipa> cfields: but it may not be much
12:38 < cfields> sipa: right, 0.13 doesn't give up the lock
12:38 < sipa> indeed, 0.13 is totally fine
12:38 < BlueMatt> gmaxwell: second, we are making an API change here, which it seems to me is probably going to break clients: previously if you called getblockheigh, and then getbalance, getbalance will be up-to-date at least as of that block...this is no longer true. I can absolutely see clients having assumed this
12:38 < wumpus> "okay, I agree showing confirmed for some and not others is odd" absolutely. This would break the assumption that curtip-block which tx was confirmed in is the number of confirmations
12:38 < gmaxwell> cfields: That the wallet blocks shouldn't be part of the api. Certian consistency properties might reasonably be.  I'm actually dubious that seeing confirmations incrementally is actually a problem.
12:38 -!- instagibbs_ [602c9182@gateway/web/freenode/ip.96.44.145.130] has quit [Ping timeout: 264 seconds]
12:38 < gmaxwell> BlueMatt: no, thats not really true either, since the chain can reorg between those two calls.
12:39 < cfields> sipa: right. and now master has changed that behavior. So if the behavior is considered to be part of the api, we need to revert it
12:39 < jonasschnelli> Why can't we not just use SyncWithWallets or mempool and add a SyncBlockWithWallet(blockcopy) for added and removed tips? Process it in a wallet-thread (similar to periodic flushes) and use cs_wallet there?
12:39 < morcos> ok, how about i write up an issue
12:39 < cfields> (I don't believe that and I'd -1 it. Just clarifying)
12:39 < morcos> i don't think we should revert the change
12:39 < wumpus> we shouldn't revert anything that prevents future paralellization/concurrency
12:40 -!- assder [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has quit [Ping timeout: 264 seconds]
12:40 < sipa> i think the step was a step in the right direction, and we should continue it
12:40 < sipa> but we have time in 0.14 to figure out exactly how
12:40 < wumpus> if there is a need to 'force everything to wait for thewallet' that's a big -1 from me too
12:40 < morcos> i think we should make it so that the existing rpc calls returns omething that make sense.  two issues 1) once you've waited for a certain height, that once you ask for balance you get a balance of at least that height 2) whether mid-block updates are ok
12:40 < gmaxwell> how does this concurrency interact with the wallet's mempool interaction. The wallet cares if tx are in mempool or not, will a wallet look unconfirmed and fallen out of the mempool briefly while it's confirming?
12:40 < morcos> 1) needs fixing, 2) needs more investigation
12:40 < cfields> agreed. ok, that answers my question.
12:41 < morcos> 1) can be fixed with cfields existing code from 8680 without harming any concurrency
12:41 < sipa> morcos: 1) is easily fixed by reporting the wallet height rather than the core height
12:41 < jonasschnelli> morcos: isn't 1) and 2) solvable from the wallet side?
12:41 < wumpus> wallet height and core height are different things
12:41 < sdaftuar> sipa: yes, but that would be api-breaking right?
12:41 < wumpus> it has always been possible to confound these, but that has to change
12:41 < sipa> sdaftuar: i believe not
12:41 < sdaftuar> i think that's the right idea though
12:41 < gmaxwell> Well it means that someone might need to look in a different place for the wallet height, no?
12:42 < sipa> sdaftuar: if we make 0.14 report the wallet height,  i believe it will look equivalent to 0.13
12:42 < wumpus> gmaxwell: yes, it'd need to be a wallet RPC
12:42 < morcos> sipa: the issue is people probably already use getblockcount and then ask for balances
12:42 < wumpus> either on getwalletinfo or getwalletblockcount
12:42 < morcos> but they do that in their code
12:42 < sipa> morcos: so, make getblockcount by default report the wallet height
12:42 < wumpus> bah
12:42 < morcos> that seems like a crazy change
12:42 < gmaxwell> morcos: thats okay, we would release note that in 0.14. If it's the right behavior to change we shouldn't hesitate to do so here.
12:42 < sipa> why? it's exactly what we've been doing all the time
12:43 < wumpus> change getblockcount to a wallet call?!
12:43 < jonasschnelli> no
12:43 < sdaftuar> that means you need wallet support to use that rpc?
12:43 < CodeShark> bad idea
12:43 < morcos> i think we're getting a bit too worked up
12:43 < sdaftuar> blech
12:43 < wumpus> what if there is no wallet built in?
12:43 < sipa> sigh
12:43 < jonasschnelli> no blockcount!
12:43 < gmaxwell> that woudl be kind of odd, but it's 99% of the time used as a wallet call, ... and we have getblockchaininfo....
12:43 < wumpus> what if there are multiple wallets? ask them all, return the max value?
12:43 < BlueMatt> gmaxwell: certain people have reorg handling code, this api change will not trigger their reorg handling code and will still break clients!
12:43 < sipa> so deprepcate the RPC
12:43 < jonasschnelli> Just give out the bestblockhash in getwalletinfo
12:43 < BlueMatt> it is absolutely not unreasonable for this change to break rpc clients
12:43 < sipa> and introduce a wallet-specific one and main-specific one
12:43 < morcos> its easy enough to make wallet balance calls wait on their own until either the wallet reports a height that matches chainactive height or using cfields mechanism, that slows nothing other than that wallet call and solves 1
12:43 < cfields> why not just have getblockcount block until the block is finished processing (all signals, not wallet specific)? New apis can be async
12:44 < wumpus> yes, there needs to be a wallet-specific one
12:44 < sipa> cfields: that's just delaying the problem
12:44 < BlueMatt> what morcos said
12:44 < gmaxwell> BlueMatt: look, the API is not, should not, and cannot be a suicide pact. We're talking about an change in a major version, and one that would only require minor changes. _WE CAN CHANGE THE API_. 
12:44 < sipa> cfields: because that's no longer possible if the wallet works asynchronously
12:44 < BlueMatt> just block wallet calls until they are caught up
12:44 < gmaxwell> Especially in a minor way like "get your height for purpose X this way instead of that"
12:44 < wumpus> wallet processing blocking wallet calls is OK
12:44 < BlueMatt> there is a simple solution to this that doesnt require all the users audit their codebase
12:44 < BlueMatt> that isnt even a big deal
12:44 < wumpus> wallet processing blocking core calls is not
12:45 < BlueMatt> but you're arguing we change the api because its simpler?
12:45 < BlueMatt> just block wallet rpc calls until its caught up at the start of the cs_wallet lock
12:45 < BlueMatt> yes, wumpus, dont think anyone is arguing for that
12:45 < gmaxwell> I haven't heard anything suggested that doesn't require having the wallet and block processing block each other.
12:45 < BlueMatt> noooo
12:45 < BlueMatt> wait, wut?
12:45 < morcos> wumpus: yes, see cory's code in 8680, can easily adopt all wallet calls to use that (or ask the wallet for its height but then they might have to poll) and weight until it hits what chainactive was at the start of the call
12:46 < BlueMatt> the proposal is that rpc calls might block until the wallet has caught up to where main chainstate is
12:46 < morcos> gmaxwell: yeah i think you're misunderstanding
12:46 < sipa> morcos: yup... but at some point we'd want to get rid of that too, i think
12:46 < BlueMatt> the wallet processing can still be in a background thread, or on the main thread, or whatever
12:46 < wumpus> morcos: yes, that makes sense
12:46 < gmaxwell> and I think it's insane to degrade concurrency for an obscure property that anyone who wants can retain by using an appropritate call to ask where the wallet is vs where the blockchain is.
12:46 < BlueMatt> it just has to catch up before the rpc will return
12:46 < BlueMatt> gmaxwell: we arent degregading concurrency except that rpc calls might block, afaict
12:46 < BlueMatt> and then we're returning more up-to-date info anyway
12:46 < BlueMatt> so thats not even so bad
12:46 < morcos> might block but would still return before they would have in 0.13!!!
12:47 < cfields> BlueMatt: and it only blocks as long sa it would've before
12:47 < BlueMatt> true
12:47 < gmaxwell> what was suggested above was the block processing taking the wallet lock; which would bidirectionally block each other.
12:47 < sipa> gmaxwell: no
12:47 < morcos> gmaxwell: that was a proposal to solve problem 2 (the mid block)
12:47 < BlueMatt> that was to a different issue
12:47 < BlueMatt> there are two issues
12:48 < BlueMatt> well, potential issues
12:48 < sipa> the proposal was that _the wallet_ would grab _the wallet lock_ while it was updating its state for a new block
12:48 < morcos> that problem needs more investigation to determine a) whether it needs solving and b) whether there is a simple solution.  i agree with your objection to my first suggested solution
12:49 < morcos> sipa: yes but thats only a good idea when thats not running in teh same thread as block processing in the middle of block processing, otherwise some other independent wallet call holds up block processing
12:49 < sipa> are there other topics? i don't think we need to figure this out completely right now
12:49 < gmaxwell> morcos: Sounds fine to me.
12:49 < wumpus> I think it's better to take this outside the meeting. Any other topics?
12:49 < morcos> wumpus: ha , too late!
12:49 < wumpus> morcos: heh same idea
12:50 < cfields> this can be handled with signals btw, no need to grab actual locks. StartProcessing() -> block rpc -> FinishedProcessing() unblock
12:50 < cfields> yes, later is fine. That got more heated than I expected :)
12:50 < cfields> though, we still have the question of what to do about the tests.
12:51 < sipa> morcos: yes, i'm not saying that's what we should or shouldn't do... just clarifying what the idea was
12:51 < morcos> does 8680 fix the tests or not really?
12:51 < wumpus> cfields: I think your pull is fine for that, as a temp fix at least
12:51 < morcos> i think 8680 seems reasonable to me
12:51 < wumpus> right
12:51 < sipa> let's merge 8680 to fix the annoyance with the test
12:51 < cfields> morcos: i believe so, but not 100% because of the nature
12:51 < sipa> but open a tracker issue to reconsider
12:51 < cfields> (i'm not 100%, sorry)
12:51 < wumpus> #action merge  8680 to fix the annoyance with the test
12:51 < michagogo> <i>8m warning</i>
12:52 < wumpus> michagogo: looks like we're out of topics sooner than out of time
12:52 < cfields> ok, I can slim that down to only the rpc used by the tests then
12:52 < wumpus> cfields: ack
12:52 < sipa> cfields: thanks
12:52 < wumpus> #endmeeting
12:52 < lightningbot> Meeting ended Thu Sep  8 19:52:49 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:52 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-08-18.59.html
12:52 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-08-18.59.txt
12:52 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-08-18.59.log.html
12:53  * michagogo wishes he had more time lately
12:53 -!- instagibbs_ [602c9182@gateway/web/freenode/ip.96.44.145.130] has joined #bitcoin-core-dev
12:53 < michagogo> 2-3 hour commutes are not very fun.
12:53 < wumpus> michagogo: yes we've been missing you lately!
12:54 < michagogo> (Where lately = >1 year, I think…)
12:54 < instagibbs_> michagogo: work from home, your hair will get fuller, and silkier with the reduced stress
12:54 < MarcoFalke> michagogo: Let someone drive for you and use the time to catch up on stuff.
12:54 < michagogo> It's a good thing I scripted gitian builds, so at least I can kick those off and let them run at home
12:55 < michagogo> instagibbs_: unfortunately that's not an option for various reasons
12:55 < michagogo> MarcoFalke: I wish that were feasible, but I'm provided with free public transportation and don't have a car
12:56 < phantomcircuit> which pr changed the wallet handling to be background?
12:56 -!- vega4 [~pc_rafals@c0-100.icpnet.pl] has joined #bitcoin-core-dev
12:56 < gmaxwell> Sorry for contributing to confusion above.  I probably misunderstood people, but it sounded to me that people were saying that the wallet operating non-concurrently was part of the API and that we couldn't change it.  I agree its a minor part of the api but think we must change it.  Making all the blocks 'confirmedness' updates to the wallet atomic seems reasonable to me (though I'm dubious anyt
12:56 < gmaxwell> hing would actually be broken by that which isn't already broken)
12:56 < jonasschnelli> phantomcircuit: i guess there is no PR for that?
12:56 < michagogo> I try to figure out how to get rides whenever I can, but that's not very often
12:56 < phantomcircuit> jonasschnelli: o.O ?
12:57 < jonasschnelli> It was just a discussion.
12:58 -!- vega4 [~pc_rafals@c0-100.icpnet.pl] has quit [Client Quit]
12:58 < gmaxwell> I don't think "would be an api change" should ever be an argument against something in a major release, and it was kind of worrying me to hear people talking that way... esp. since the current api stinks in a number of minor ways and needs improving. "Would be a rather disruptive API change relative to the benefits" would be a fine argument, but it wasn't what I was hearing, maybe it was implici
12:58 < gmaxwell> t. Though I think making the wallet and block processing mutually concurrent has a lot of obvious benefits.
12:58 < morcos> phantomcircuit: 7964 (its not background, it just happens outside of cs_main now)
12:58 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has joined #bitcoin-core-dev
12:59 < CodeShark> gmaxwell: if it breaks deployed apps, it's a potential issue - otherwise, it isn't
12:59 < sipa> gmaxwell: absolutely - i think everything that was proposed would never grab cs_main and cs_wallet at the same time (even though they're in the same thread for now)
12:59 < morcos> gmaxwell: i think thats a fair summary.   in the future it probably makes sense for someone (like me in this case) to write up a small issue before the meeting, so people aren't trying to read about a somewhat nuanced issue in interlaced realtime chat
13:00 < jonasschnelli> gmaxwell: I guess it depends from which angle you are looking at it. Current users expect (API) that getblockchaininfo represents the state of the wallet...
13:00 < jonasschnelli> Which I agree we should keep for 0.13.x
13:00 < phantomcircuit> morcos: that seems to be something about c++11 consistency
13:01 < jonasschnelli> But afterwards, I think is a good signal to have own wallet process state calls
13:01 < CodeShark> I'm in favor of any change that further decouples the wallet from the rest of the app ;)
13:01 < jonasschnelli> To slowly make people aware of that the wallet might gets more of its own state/processes
13:01 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
13:02 < michagogo> ??? https://usercontent.irccloud-cdn.com/file/JhPBIVrq/IMG_3841.PNG
13:03 < BlueMatt> gmaxwell: sorry, indeed that was my implied argument
13:03 < BlueMatt> gmaxwell: I agree, making an api change is generally fine
13:03 < BlueMatt> but making one that is pervasive across the entire api for such a minor gain seems insane
13:03 < BlueMatt> and generally making a massively pervasive change across the entire api isnt ideal unless its easy to explain how to change your clients to work with it
13:03 < gmaxwell> jonasschnelli: I think we should keep things for 0.13, sure.  though take care, there is no way to perform multiple RPCs atomically. So if you call getblockchaininfo then interact with the wallet, the world might have changed out from under you, .. in any version. :P
13:04 < BlueMatt> gmaxwell: and, generally, I'd prefer for things like that to have an -wrapentireapitomakeitbackwardscompatible option
13:05 < gmaxwell> BlueMatt: okay, my view is that having the wallet and node be concurrent is not a minor gain. (esp since that also means multiple wallets being concurrent with each other, ultimately)
13:05 < jonasschnelli> Yes. Indeed. But users expect – in normal non reorg operations – that getblockchaininfo at least reports a height already processed by a wallet
13:05 < jonasschnelli> *the wallet
13:05 < sipa> well, one question is where do people "wait" for getblockcount to go up, and then take wallet action based on it?
13:05 < sipa> i guess we don't know
13:05 < MarcoFalke> I am fine with breaking the wallet api, but we should make it explicit and not silent.
13:05 < BlueMatt> gmaxwell: oops, sure, I agree this case is a major gain
13:05 < sipa> but it seems much more something unit tests do, because they now exactly what is going to happen
13:05 < MarcoFalke> Eg. include the blockhash/height in every wallet call
13:05 < BlueMatt> if it werent also trivial to keep the api consistent I might have a different view
13:05 < cfields> gmaxwell: to be clear, I don't think the concern (from me, anyway) was "is this an api change", so I suppose I framed the question very poorly. The concern was more "did we break reasonable assumptions by making this more async?"
13:05 < jonasschnelli> I guess the problem really apperars when you listen to notifications (ZMQ)
13:06 < sipa> jonasschnelli: it does not
13:06 < jonasschnelli> Right.. we face the problem during the RPC tests...
13:06 < kanzure> if the wallet does its own block processing, that might be interesting, it could even consume the same notifications as third-party apps would be expected to (like zeromq or rpc communication)
13:06 < sipa> we can control when the notification is sent out
13:06 < jonasschnelli> But I guess you will run more often into this concurrency issues when calling RPC off a ZMQ not.
13:06 < morcos> phantomcircuit: oops.  7946
13:07 < sipa> i think it may be the case that the only ones affected by the asynchronicity is unit tests
13:07 < phantomcircuit> morcos: ty
13:07 < sipa> (that's independent from the partial update thing, which we can fix in various other ways)
13:07 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Remote host closed the connection]
13:08 < kanzure> wait why would anyone wait for getblockcount to go up...? there is no conceivable reason i could see to do that.
13:08 < sipa> "i do X, and i wait for Y to happen" is something you can't do in production env
13:08 < kanzure> we are talking about syncing two separate processes that are supposedly monitoring a blockchain right?
13:09 < sipa> no
13:09 < gmaxwell> cfields: basically the tests failing proved its an API change, maybe not an important one, but absolutely a change.
13:09 < sipa> we're even talking about something that happens entirely within one thread :)
13:09 < cfields> kanzure: quick example: tracking how many confirmations your txs have and displaying on your site
13:09 < kanzure> cfields: that would make sense to me, but sipa is talking about one thread?
13:09 < cfields> not saying it's wise, but I can imagine that happening in the wild
13:10 < phantomcircuit> kanzure: you need more imagination
13:10 < sipa> kanzure: oh, ignoring the external process of course
13:10 < phantomcircuit> listsinceblock
13:10 < kanzure> i have recently spent a bunch of time writing and validating software that does blockchain syncing between two stores where one is considered truthy and the other is considered a laggard
13:10 < sipa> kanzure: but all wallet updates and main updates happen within one thread in core
13:10 < kanzure> listsinceblock is also something you shouldn't use. you should instead compute the most recent common block and then get the list of different blocks that your laggy side needs to consider.
13:11 < phantomcircuit> kanzure: listsinceblock is the thing people (not me) have been suggesting for years
13:11 < kanzure> looking at a block counter is backwards because it could go up and down
13:11 < kanzure> and treating it as a monotonic clock is what i would expect most application developers to do heh
13:12 < kanzure> i didn't look at the origiating issue that brought up this topic, so i'm sure my context is wrong here
13:12 < kanzure> here is a toy i was writing a few days ago https://gist.github.com/kanzure/2fa531afaf03fddd6568eb0212ac8c4c
13:13 < phantomcircuit> kanzure: wallet processing of blocks is put into the background, wallet rpc calls can then return results reflecting a partial processing of a block
13:13 < CodeShark> fully async json-over-websockets API: https://github.com/ciphrex/CoinSocket ;)
13:13 < phantomcircuit> ie tx a/b are both in block c but only a shows in the rpc calls
13:14 < kanzure> btw when people above are talking about "unit tests" they mean the rpc tests right?
13:14 < sipa> kanzure: yes
13:14 -!- cryptapus_afk is now known as cryptapus
13:14 < cfields> kanzure: unit tests in bitcoind-speak :)
13:15 < kanzure> re: async, then yes i would suggest using zeromq notifications in the testing framework to get information about internal state or for how long to wait (instead of sleeps etc)
13:15 < phantomcircuit> kanzure: they're talking about the functional tests
13:15 < phantomcircuit> not the unit tests
13:16 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
13:17 < cfields> kanzure: the question isn't about how to get the info, it's about what the caller expects. you can query for the current height, then call into the wallet and expect to see tx's from that height, only to find that they haven't been processed yet.
13:17 < kanzure> right... so you could naively sleep to wait for the wallet to be done, or you can query the wallet state (instead of chain height of the non-wallet components)
13:17 < cfields> so who's wrong? the rpc for returning a height without fully processing? or the user for expecting them to be in sync?
13:18 < kanzure> er in this case isn't the rpc test also the user?
13:18 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
13:18 < sipa> so i believe there is a slight difference between normal users and the rpc tests
13:18 < cfields> yea, i was just phrasing more generally
13:19 < sipa> in that rpc tests control the entire world, and use more simplistic means to measure progress
13:19 < cfields> sipa: yes. i doubt many rpc users/scripts are hammering on block-height in tightish loops :)
13:19 < cfields> hope not, anyway
13:19 < kanzure> so- for example- imagine you are operating a lot of bitcoin infrastructure. you do a bunch of per-block processing. when you are running functional/integration tests, you can't run your test checks immediately after issuing a command because things take a while. so when do you expect to run? well you setup a hook and you ask your infrastructure to ping your tester as soon as the data's available, or you poll for some internal state.
13:20 < kanzure> (and polling is considered not ideal)
13:20 < sipa> and non-polling methods exist
13:21 < sipa> we have -walletnotify for exactly this
13:21 < kanzure> walletnotify should certainly be used by the rpc tests
13:22 < sipa> this raises another point: walletnotify should probably fire after all of a block's transactions are processed
13:23 < kanzure> i would like zeromq notifications and -*notify notifications to be unified somehow, and eventually have much more distinct notifications for different events going on
13:23 < kanzure> changing walletnotify behavior and when it fires is sort of unkind to the users that rely on its existing behavior :)
13:23 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
13:23 < cfields> kanzure: and #8680 introduces blocking calls. So you could "./bitcoin-cli waitfornewblock && ./dosomething.sh", which would essentially be blocknotify. Obviously the same could be done for wallet stuff
13:24 < CodeShark> I would like all pub/sub stuff in a separate layer ;)
13:24 < CodeShark> especially if it requires deep knowledge of account structure
13:24 < kanzure> i feel like users are going to not understand how to use waitfornewblock. how are you going to stop them from treating that as a monotonic counter for each new lbock...?
13:26 < cfields> kanzure: that's a hack, hidden for users, just for tests. It's a pretty bad idea to take action on an event so vague :)
13:26 < kanzure> btw i (sheepishly) made a one-line proposal about throwing a component into bitcoind to keep track of external application state, specifically to store a range or diff-set of blocks that an external application should be aware about, and then the implementation proposal would be "please integrate against this" and we give the user an endpoint for saying "my application has processed the latest diff-workload x".  but this might be too ...
13:26 < kanzure> ... kitchen-sinky.
13:27 < kanzure> oh it's for testing. hm.
13:27 < cfields> i was just using it as an example of an async approach.
13:29 < kanzure> (the "diff-workload x" is specifically referring to a set of new blocks some of hwich might override previous blocks the other application was aware about. this makes the interface explicitly expose a concept of reorgs.)
13:30 < kanzure> CodeShark: in your link i'm not seeing any tests for that library...
13:30 < CodeShark> the whole thing needs to be repackaged
13:32 < CodeShark> just giving it as an example of how I think an API should work
13:32 < kanzure> cfields: fwiw once i switched to notifications inside my own tests (for some external infrastructure) re: bitcoind integration, everything went much faster and i had much more information about failures. far less timeouts too.
13:32 < cfields> kanzure: what would bitcoind do with the knowledge that the application is done processing?
13:32 < sipa> can we talk about solutions instead of vague design concerns?
13:33 < kanzure> cfields: nothing. it's for the benefit of the application. once bitcoind is informed about the application's new state, it can discard the old diff information. that's about all it would do...
13:34 < CodeShark> two subscription layers - one low level, the other much higher level
13:35 < CodeShark> the low level layer only gives you basic events like new tip or new tx
13:35 -!- sipa [~pw@unaffiliated/sipa1024] has left #bitcoin-core-dev []
13:35 < CodeShark> dunno why sipa doesn't like to discuss architecture :(
13:36 < CodeShark> it
13:36 < CodeShark> it's a serious problem for the ecosystem right now that there's no good way for people to build apps
13:36 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []
13:37 -!- sipa [~pw@unaffiliated/sipa1024] has joined #bitcoin-core-dev
13:40 < cfields> sipa: the more I think about it, the more I think that there needs to be a wallet rpc for getbalanceat(height)
13:41 < cfields> i can't think of anything that doesn't introduce more problems except for explicit/atomic calls
13:41 < kanzure> should be a blockhash not a height
13:42 < cfields> sure
13:43 < sipa> cfields: that makes sense
13:43 < cfields> I think the reason today's discussion devolved so quickly is because "getblockcount" is impossible to define, because there's no global height. So the only fix is to ensure that we're asking a specific interface a specific question. Then there's no way of being out of sync because you've specified your constraints
13:43  * sipa goes for a walk, without phonr
13:44 < sipa> be back in a while
13:44 < cfields> cya
13:45 < CodeShark> cfields: right
13:46 < CodeShark> there's no such thing as "what's the current state of the network?"
13:46 < cfields> then it's just a matter of how to handle the api. returning "come back later", blocking until there's an answer, or some callback mechanism.
13:47 < cfields> arguably if you need a callback, you should be using a different interface. as kanzure suggested above. I'm of the opinion that blocking is the way to go because that lets the user chain his own callback
13:48 < kanzure> blocking in what context? rpc ?
13:48 < CodeShark> depends on what model you're after - I think async is generally cleaner but requires a bit more clientside framework
13:49 < cfields> kanzure: yes, rpc blocks for a specified time (or forever) and returns when it has an answer, or timeout, or shutdown
13:49 < kanzure> oh. i've had so may issues with rpc socket timeouts that i haven't traced down yet that i would recommend not considering that direction heh.
13:49 < kanzure> (but also i haven't been able to make good reports about these problems, so they don't really count.)
13:50 < cfields> kanzure: heh, i was actually surprised i didn't bump into those during testing. good to know :)
13:50 < kanzure> well i think what i was doing could be considered "torture testing" and weird stuff, so.... yeah..
13:51 < kanzure> to some degree aren't we already tracking peer state on the p2p layer? e.g. like which chains the peers seem to be following lately?
13:51 < kanzure> or is that purely a function of the banning behavior heh
13:53 < cfields> lately?
13:53 < kanzure> (by virtue that you could ban everyone feeding you unhelpful data, as opposed to tracking which blocks you think peers have already)
13:54 < kanzure> nevermind. just an abstract thought, it's not important, i was thinking that "peer communication" is sometimes similar to "application communication" but more one-way. anyway, just a minor distraction.
13:56 < cfields> we keep tabs on what they shouldn't be sending, but i don't remember to what extent
13:59 < CodeShark> a peer can query for inventory at any time regardless of whether it is in agreement with the node's best chain
13:59 -!- instagibbs_ [602c9182@gateway/web/freenode/ip.96.44.145.130] has quit [Ping timeout: 264 seconds]
13:59 -!- e4xit_ [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-core-dev
14:00 < CodeShark> I think peers get sent invs whenever there are tip changes regardless
14:00 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has quit [Ping timeout: 265 seconds]
14:01 -!- e4xit_ is now known as e4xit
14:01 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has quit [Remote host closed the connection]
14:15 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]
14:20 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
14:25 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
14:29 -!- cryptapus is now known as cryptapus_afk
14:53 < gmaxwell> "(and polling is considered not ideal)
14:53 < gmaxwell> "
14:53 < gmaxwell> This bugs me. Polling is highly reliable. And we're taking about things that have inherent latencies in real of seconds to tends of minutes.
14:54 < phantomcircuit> polling is the correct way to interact with the wallet
14:54 < gmaxwell> I do not know why people eschew polling as often as they do... there are contexts where its exactly the right tool and keeping track of a wallet state is likely one of them.
14:54 < phantomcircuit> if you're not polling you're doing it wrong
15:03 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: ZzzZZZzzzZzzzZZzZZzZzzzzzZZzzzzzzzzZZZZz]
15:08 < kanzure> well one trivial example is in scenarios where you have long-term polling, you will miss the update and spend extra time waiting
15:08 < kanzure> this is apparent in scenarios with, say, exponential backoff
15:11 < phantomcircuit> kanzure, call listtransactions
15:11 < phantomcircuit> does the list contain a transaction you have previously seen?
15:11 < kanzure> instead of hoping you catch wallet state transitions by polling, what about just having the wallet notify you directly of each change event? then you consume the feed/queue of events.
15:11 < phantomcircuit> yes? great do nothing
15:11 < phantomcircuit> no? increase the list size
15:12 < phantomcircuit> handle reorgs? need to call the blockchain things and do a bunch of work
15:12 < kanzure> which application are you imagining for listtransactions in particular?
15:12 -!- da2ce7_ [~da2ce7@opentransactions/dev/da2ce7] has quit [Ping timeout: 260 seconds]
15:13 < phantomcircuit> anything which needs to know that a payment has been made
15:13 < kanzure> i don't know what the behavior of listtransactions is. how does it behave when a transaction has been removed from your chaintip..?
15:14 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev
15:15 < phantomcircuit> kanzure: it's buried in the list and has -1 confirmations
15:15 < kanzure> for how long...? it occurs to me that listtransactions is probably a wallet-specific rpc command and that's why i know so little about it.
15:17 < kanzure> getting notified when a transaction is about to be permanently removed from that list sonuds like a useful thing, but you could probably infer that detail from polling regularly and knowing the lifecycle i guess.
15:17 < phantomcircuit> kanzure, listtransactions only shows you transactions in your wallet
15:17 < phantomcircuit> nothing is ever removed from the list there's just a parameter which truncates the list
15:18 < phantomcircuit> listtransactions "*" 4294967295
15:18 < phantomcircuit> will give you all the transactions your wallet has ever seen
15:19 < kanzure> incremental updates and messaging would not require so much data transfer all at once. :)
15:19 < phantomcircuit> kanzure, messaging is unreliable
15:19 < phantomcircuit> polling is inherently reliable
15:19 < phantomcircuit> fin
15:20 < sipa> we shouldn't make assumptions about how people use the api
15:21 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
15:23 < kanzure> my above concerns are mostly about polling interval
15:26 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
15:34 < kanzure> and blockheight can't be a heartbeat
15:52 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 255 seconds]
15:53 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]
15:54 < BlueMatt> sipa: https://github.com/TheBlueMatt/bitcoin/commit/96cef326f9184aefd1c562f64a21298a15f0adde simplifies the total diff from master to be more readable, to me...it matches the bip, but another way to look at it is that you have two booleans: which version of compact blocks they want (which you use to send to them) and whether they will send us segwit cmpctblocks...you simply introduce the the do-they-support-v2 bool as an additional 
15:54 < BlueMatt> check before requesting cmpcblocks and otherwise dont need the complicated other semantics
15:54 < BlueMatt> (warning: mostly untested...it compiles, though :p)
16:02 < BlueMatt> ehh, nvm, need to fix a bug there, but I'm tired so will do it later/tomorrow
16:06 -!- e4xit [~e4xit@cpc92302-cmbg19-2-0-cust1369.5-4.cable.virginm.net] has joined #bitcoin-core-dev
16:17 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
16:23 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
16:23 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
16:26 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wgsjxxbsndygdrip] has quit [Quit: Connection closed for inactivity]
16:28 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
16:37 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 276 seconds]
16:40 -!- jtimon [~quassel@38.110.132.37.dynamic.jazztel.es] has quit [Remote host closed the connection]
17:15 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds]
17:17 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer]
17:25 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
17:29 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
17:47 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
17:47 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-otfglfdrjaqxsnwa] has quit [Quit: Connection closed for inactivity]
17:55 < CodeShark> polling for things like balance make perfect sense - I was referring to things like getting notified of new blocks or transactions
17:55 < gmaxwell> polling makes sense for that in most contexts.
17:56 < gmaxwell> Blocks show up once per ten minutes on average, polling once a second adds a neglgible amount of overhead and delay, and you avoid any issues with corner cases where the notifcation gets lost.
17:57 < CodeShark> you can solve those issues with another protocol layer but yeah, it does add some complexity
17:58 < CodeShark> what I've usually done is open the connection and subscribe, then ping periodically
17:59 < CodeShark> the pings don't have to be every second
17:59 < CodeShark> you still get extremely low latency when it works correctly - and you detect malfunction fairly quickly
18:00 < CodeShark> this is all middleware, though
18:00 < CodeShark> app developers shouldn't have to deal with all the inner plumbing
18:00 < CodeShark> and the model of writing event handlers is a pretty nice one
18:01 < CodeShark> you can even have an event handler for when there's a connection error
18:01 < CodeShark> makes all the clientside logic easier to follow
18:01 < gmaxwell> the logic needed to handle a lost event is so hard that even experts usually don't get it right though.
18:01 < gmaxwell> (generally speaking)
18:02 < gmaxwell> there are plenty of places where you have no choice but to be event triggered-- when load and latency are critical.
18:02 < gmaxwell> but they result in a lot more exceptional conditions which are hard to reason about and hard to test.
18:02 < CodeShark> which is why it's the kind of stuff you want in a very well-tested library
18:03 < CodeShark> and not the kind of thing you want every app developer to be writing ad hoc
18:03 < CodeShark> but I agree that the general cases can be quite hard
18:04 < midnightmagic> it should then be in an external library. putting reliable message delivery into bitcoin core would also make the binary liable in the event something (inevitably) goes wrong.
18:04 < CodeShark> midnightmagic: agreed - that's what I do
18:04 < CodeShark> I have a process connect to bitcoin core via p2p which receives inv messages and sends getdata
18:05 < CodeShark> all the messaging stuff beyond that is entirely in the other process
18:10 < CodeShark> then the other process can be queried for its connection status - if it's connected, if it's synched, etc...
18:12 < CodeShark> https://github.com/ciphrex/mSIGNA/blob/master/deps/CoinQ/src/CoinQ_peer_io.h#L313
18:12 -!- vega4 [~pc_rafals@user-31-175-254-216.play-internet.pl] has joined #bitcoin-core-dev
18:14 < kanzure> i don't think it would be obvious to others to do application integration at the p2p layer.
18:14 < CodeShark> they wouldn't
18:14 < CodeShark> they only need to interact with this other process
18:14 -!- vega4 [~pc_rafals@user-31-175-254-216.play-internet.pl] has quit [Read error: Connection reset by peer]
18:14 < kanzure> i know. but i mean they wouldn't know to look for something that does this :).
18:15 < kanzure> the typical thing is to "use rpc" not "look for a p2p client that bridges events on the network to your own messaging system, without using bitcoind rpc".
18:15 < CodeShark> indeed - I'd like to see this kind of thing become more readily available
18:16 < CodeShark> in my ideal world, Bitcoin Core would just do peer discovery, validation, and relay
18:16 < CodeShark> and other processes would handle all app layer event processing
18:18 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has quit [Quit: ZNC]
18:18 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has joined #bitcoin-core-dev
18:19 < CodeShark> perhaps a shared block storage process could be incorporated into the design
18:20 < CodeShark> and shared utxo storage
18:20 < luke-jr> I'm tempted to work on multiwallet stuff. is anyone else? (poke CodeShark)
18:21 < CodeShark> heh
18:21 < CodeShark> I don't think what I had done will rebase too easily :p
18:22 < luke-jr> probably not, or I'd have been including it in Knots already :p
18:23 < luke-jr> assuming you didn't keep maintaining it privately
18:23 < CodeShark> nah, I decided to write my own wallet from scratch instead :p
18:24 < luke-jr> yeah, I figured :p
18:26 < CodeShark> if I were to attempt the multiwallet in Core again I would take a very different approach ;)
18:26 < CodeShark> especially in regards to the merge process
18:27 < CodeShark> I tried to do too much at once
18:28 < CodeShark> some of the hooks did get in, though
18:30 < CodeShark> https://github.com/bitcoin/bitcoin/commit/67155d9299ef75cc73272a259dbfbf72632c3020
18:30 < luke-jr> I'm doing tiny commits so far, mostly cleanups
18:30 < luke-jr> the difficult part I see (and may just skip) is closing/removing a wallet at runtime
18:31 < luke-jr> I'm not really sure our shutdown close is even safe
18:33 < CodeShark> you mean in terms of RPC?
18:34 < luke-jr> I mean shutdown deletes the wallet pointer, but who knows if another thread might still be using it
18:34 < CodeShark> reference counting? :)
18:34 < luke-jr> maybe it's safe, but it's far from clear that it is
18:35 < luke-jr> there is no refcounting right now
18:35 < luke-jr> I'll probably add something like that *if* I implement close
18:35 < luke-jr> (my main practical goal is to use JoinMarket without touching my real Core hot wallet, and without two node instances)
18:37 < CodeShark> simplest is to just provide a list of wallet files in the config and just have them all load for the duration of runtime
18:37 < luke-jr> oh, I guess that's a possibility
18:37 < luke-jr> -wallet exists, could just accept multiples
18:39 < CodeShark> from a GUI perspective it's nice to be able to open and close wallet files during runtime - but if you'll be using a specific setup and connecting via RPC it doesn't really matter
18:40 < CodeShark> in fact, being able to open and close wallet files via RPC is potentially exploitable
18:41 < luke-jr> only slightly more-so than backupwallet, I think? :p
18:41 < CodeShark> heh
18:45 < CodeShark> point is if your payment processing app is designed to deliberately open and close wallet files at runtime there's probably something wrong in your design ;)
18:46 < luke-jr> well, that's probably true as well
18:46 < luke-jr> maybe.
18:47 < luke-jr> it might make sense to do wallet rotation in some capacity
18:47 < CodeShark> yeah, you could have tools for such things
18:47 < CodeShark> but I think they should be conceptually separate from the business logic
18:47 < luke-jr> probably
18:47 < CodeShark> you have your business logic, then below that you have a policy layer
18:48 < CodeShark> specifying which wallet, which keys, which signing policies, etc... should be used is part of the policy layer
19:11 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
19:23 -!- baldur [~baldur@pool-72-69-25-42.nycmny.fios.verizon.net] has quit [Ping timeout: 244 seconds]
19:37 -!- baldur [~baldur@209.95.50.50] has joined #bitcoin-core-dev
19:45 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]
19:46 -!- baldur [~baldur@209.95.50.50] has quit [Ping timeout: 276 seconds]
19:58 -!- baldur [~baldur@pool-72-69-25-42.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
20:37 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
20:41 -!- Squidicuz [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has quit [Quit: Oh no, not again]
20:54 -!- Squidicuz [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has joined #bitcoin-core-dev
21:00 -!- dermoth [~thomas@dsl-66-36-143-95.mtl.aei.ca] has quit [Read error: Connection reset by peer]
21:01 -!- dermoth [~thomas@dsl-66-36-143-95.mtl.aei.ca] has joined #bitcoin-core-dev
21:14 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 250 seconds]
21:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
21:20 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
21:23 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
21:28 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:29 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:57 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
22:18 < GitHub90> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ddc308068d69...17347d6a5915
22:18 < GitHub90> bitcoin/master df2d2e7 Gaurav Rana: update name of file bitcoin.qrc
22:18 < GitHub90> bitcoin/master 17347d6 Wladimir J. van der Laan: Merge #8683: fix incorrect file name bitcoin.qrc...
22:18 < GitHub14> [bitcoin] laanwj closed pull request #8683: fix incorrect file name bitcoin.qrc  (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8683
22:19 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 265 seconds]
22:23 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
22:29 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 255 seconds]
22:41 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
22:44 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has quit [Quit: Verlassend]
22:48 < GitHub170> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/17347d6a5915...80a4f21d377a
22:48 < GitHub170> bitcoin/master 34521e4 Pieter Wuille: Do not store witness txn in rejection cache
22:48 < GitHub170> bitcoin/master ca10a03 instagibbs: Add basic test for IsStandard witness transaction blinding
22:48 < GitHub170> bitcoin/master 80a4f21 Wladimir J. van der Laan: Merge #8525: Do not store witness txn in rejection cache...
22:48 < GitHub131> [bitcoin] laanwj closed pull request #8525: Do not store witness txn in rejection cache (master...nowitnessreject) https://github.com/bitcoin/bitcoin/pull/8525
22:59 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-umqvfhiestmlvalq] has joined #bitcoin-core-dev
23:12 -!- assder [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has joined #bitcoin-core-dev
23:26 < GitHub190> [bitcoin] bitcoinsSG opened pull request #8686: translate to np (master...master) https://github.com/bitcoin/bitcoin/pull/8686
23:29 < GitHub50> [bitcoin] laanwj closed pull request #8686: translate to np (master...master) https://github.com/bitcoin/bitcoin/pull/8686
23:34 < GitHub118> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/80a4f21d377a...666eaf03cf25
23:34 < GitHub118> bitcoin/master d6a5dc4 Cory Fields: add waitfornewblock/waitforblock/waitforblockheight rpcs and use them for tests...
23:34 < GitHub118> bitcoin/master 666eaf0 Wladimir J. van der Laan: Merge #8680: Address Travis spurious failures...
23:34 < GitHub147> [bitcoin] laanwj closed pull request #8680: Address Travis spurious failures (master...rpc-waitforblock) https://github.com/bitcoin/bitcoin/pull/8680
23:43 < jonasschnelli> sipa: https://github.com/bitcoin/bitcoin/pull/8371#issuecomment-242719674
23:43 < jonasschnelli> any idea how to detect if a header-tip is to far in the past? Just comparing against <now>?
23:44 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 240 seconds]
23:45 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
23:48 -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-core-dev
23:56 < jl2012> what is the meaning of "false" in return state.DoS(0, false, REJECT_NONSTANDARD, reason) ?
23:56 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
23:59 < GitHub91> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/666eaf03cf25...7f8b677aeb79
23:59 < GitHub91> bitcoin/master 878faac Anthony Towns: Add configure check for -latomic
23:59 < GitHub91> bitcoin/master 7f8b677 Wladimir J. van der Laan: Merge #8563: Add configure check for -latomic...
23:59 < GitHub157> [bitcoin] laanwj closed pull request #8563: Add configure check for -latomic (master...autoconf-latomic) https://github.com/bitcoin/bitcoin/pull/8563