--- Day changed Thu Oct 05 2017 00:06 -!- protomar [~protomar@109.232.227.133] has joined #bitcoin-core-dev 00:06 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 00:21 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 00:25 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:44 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-cmlxatxckhkovedg] has joined #bitcoin-core-dev 00:46 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has joined #bitcoin-core-dev 00:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 01:01 -!- DrOlmer [~DrOlmer@unaffiliated/drolmer] has joined #bitcoin-core-dev 01:17 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:31 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev 01:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 01:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 01:45 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-akykpqrnnxtyxzqk] has quit [Quit: Connection closed for inactivity] 01:46 -!- arubi [~ese168@unaffiliated/ese168] has joined #bitcoin-core-dev 01:57 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 02:07 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Quit: Leaving] 02:08 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 02:08 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 02:15 -!- pigeons [~pigeons@94.242.209.214] has quit [Remote host closed the connection] 02:16 -!- rabidus [~rabidus@91-145-115-22.bb.dnainternet.fi] has quit [Ping timeout: 240 seconds] 02:18 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 02:21 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 02:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer] 02:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:44 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 02:46 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 02:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Client Quit] 02:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 02:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:53 -!- wxxs [~chatzilla@184.75.212.76] has joined #bitcoin-core-dev 02:54 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 02:55 -!- Lesley [~Lesley@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev 03:21 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 03:22 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 03:26 -!- W4RL0RD [~W4RL0RD@jh147.perfectdeals.xyz] has joined #bitcoin-core-dev 03:27 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds] 04:16 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 04:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 04:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 04:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 04:22 < sturles> I have a problem with boost after upgrading to Debian 9. I did an apt-get --reinstall install libboost-all-dev to be sure I have everything, but it still fails: https://0bin.net/paste/NjYBdILEZBChNmbI#rsDCuSOm7iKfR-UZj7ytJdxoAYMLRdB3szd43qbZmvH 04:23 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 04:24 < sturles> Any ideas? 04:28 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 248 seconds] 04:40 -!- protomar [~protomar@109.232.227.133] has quit [Quit: Leaving] 04:52 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 248 seconds] 04:53 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev 05:00 -!- wxxs [~chatzilla@184.75.212.76] has quit [Ping timeout: 248 seconds] 05:00 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 248 seconds] 05:01 -!- wxxs [~chatzilla@184.75.212.76] has joined #bitcoin-core-dev 05:03 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev 05:08 -!- rabidus [~rabidus@91-145-115-22.bb.dnainternet.fi] has joined #bitcoin-core-dev 05:10 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Ping timeout: 258 seconds] 05:15 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 248 seconds] 05:16 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 05:17 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 05:22 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 05:34 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-cmlxatxckhkovedg] has quit [Quit: Connection closed for inactivity] 05:40 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 05:42 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 06:09 < bitcoin-git> [bitcoin] MarcoFalke pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/167cef8082e2...e93fff1463ae 06:09 < bitcoin-git> bitcoin/master 58d91af MeshCollider: Fix race for mapBlockIndex in AppInitMain 06:09 < bitcoin-git> bitcoin/master 35aeabe MeshCollider: Make fReindex atomic to avoid race 06:09 < bitcoin-git> bitcoin/master 731065b MeshCollider: Consistent parameter names in txdb.h 06:09 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #11107: Fix races in AppInitMain and others with lock and atomic bools (master...fix_mapBlockIndex_race) https://github.com/bitcoin/bitcoin/pull/11107 06:36 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 06:48 -!- pigeons [~pigeons@static.208.136.40.188.clients.your-server.de] has joined #bitcoin-core-dev 06:51 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 240 seconds] 06:52 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev 07:03 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 255 seconds] 07:05 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev 07:05 -!- Emcy [~MC@unaffiliated/emcy] has joined #bitcoin-core-dev 07:30 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds] 07:38 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit [Ping timeout: 248 seconds] 07:39 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 07:44 -!- wraithm [~wraithm@unaffiliated/wraithm] has joined #bitcoin-core-dev 07:49 -!- arubi [~ese168@unaffiliated/ese168] has quit [Ping timeout: 258 seconds] 07:50 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 08:00 -!- deltaT [569a8763@gateway/web/freenode/ip.86.154.135.99] has joined #bitcoin-core-dev 08:01 < deltaT> simple question i hope, when i created my bitcoin core wallet i didnt write down the private key, how do i find it now? 08:02 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 258 seconds] 08:06 < jonasschnelli> deltaT: which Bitcoin Core version? 08:07 < jonasschnelli> deltaT: did you lost you wallet.dat? file.... also, this question should be asked in #bitcoin (this here is the development channel) 08:07 < deltaT> 0.14.2 08:07 < BlueMatt> wumpus: #9572 looks relatively merge-able...it is consensus so if you want to ack first that'd also be nice, but its simple and has 4 already 08:07 < gribble> https://github.com/bitcoin/bitcoin/issues/9572 | Skip witness sighash cache for non-segwit transactions by jl2012 · Pull Request #9572 · bitcoin/bitcoin · GitHub 08:08 -!- deltaT [569a8763@gateway/web/freenode/ip.86.154.135.99] has quit [Quit: Page closed] 08:11 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-core-dev 08:13 < bitcoin-git> [bitcoin] mess110 opened pull request #11455: CTxMemPool::GetMinFee should not return CFeeRate(0) (master...fix_mempool_GetMinFee_bug_returning_below_minRelayTxFee) https://github.com/bitcoin/bitcoin/pull/11455 08:16 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 08:17 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit [Ping timeout: 258 seconds] 08:18 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #11456: Replace relevant services logic with a function suite. (master...2017-09-service-flags-cleanups) https://github.com/bitcoin/bitcoin/pull/11456 08:20 < bitcoin-git> [bitcoin] mess110 closed pull request #11410: [rpc] [tests] mempoolminfee should not drop below minRelayTxFee (master...add_minrelaytxfee_to_getmempoolinfo) https://github.com/bitcoin/bitcoin/pull/11410 08:26 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 258 seconds] 08:28 -!- tloriato [8b52fce7@gateway/web/freenode/ip.139.82.252.231] has joined #bitcoin-core-dev 08:31 < tloriato> Good afternoon. I was looking into BIP45, that tries to standardize the Structure for Deterministic P2SH Multisignature Wallets, but I've read the emails discussing it and seems to have a little or disagreement between the need for this particular BIP. I'm wondering if there is another standard way to generate a Deterministic Multisig Wallet? I was inclined to generate a standard Mnemonic (BIP39) and split it using Shamir 08:33 -!- arubi [~ese168@unaffiliated/ese168] has joined #bitcoin-core-dev 08:36 < BlueMatt> sipa: did you find time to write up the segwit wallet tradeoffs between the various ways of doing it and making an argument for why your pr is your preferred version? 08:36 < BlueMatt> sipa: I believe you said you were gonna do that last meeting 08:48 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 08:50 < jonasschnelli> tloriato: AFAIK BIP45 is the only "standard" to create multisig addresses with a set of given pubkeys. 08:50 < jonasschnelli> *extended pubkeys 08:53 < tloriato> jonasschnelli: thanks 08:55 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has quit [] 08:56 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 09:00 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 09:00 -!- tloriato [8b52fce7@gateway/web/freenode/ip.139.82.252.231] has quit [Ping timeout: 260 seconds] 09:00 * BlueMatt has a super interesting C++ performance puzzle if someone wants it: https://github.com/bitcoinfibre/bitcoinfibre/blob/matts-servers/src/udprelay.cpp#L501 sometimes (about once every 2nd or 3rd day's worth of blocks) takes on the rorder of 30ms on dedicated hardware (!!!), but all it does is allocate 09:00 < BlueMatt> nothing else does anything close 09:01 -!- DrOlmer [~DrOlmer@unaffiliated/drolmer] has quit [Ping timeout: 240 seconds] 09:02 -!- DrOlmer [~DrOlmer@unaffiliated/drolmer] has joined #bitcoin-core-dev 09:05 -!- Emcy [~MC@unaffiliated/emcy] has quit [Read error: Connection reset by peer] 09:05 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 09:05 -!- Emcy [~MC@unaffiliated/emcy] has joined #bitcoin-core-dev 09:05 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 09:06 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/e93fff1463ae...becbd71b0c16 09:06 < bitcoin-git> bitcoin/master 4f890ba Donal OConnor: Add new step to clean $PATH var by removing /mnt specific Window's %PATH% paths that cause issues with the make system 09:06 < bitcoin-git> bitcoin/master 696ce46 fanquake: [Docs] Update Windows build instructions for using WSL and Ubuntu 17.04 09:06 < bitcoin-git> bitcoin/master becbd71 Wladimir J. van der Laan: Merge #11437: [Docs] Update Windows build instructions for using WSL and Ubuntu 17.04... 09:07 < bitcoin-git> [bitcoin] laanwj closed pull request #11437: [Docs] Update Windows build instructions for using WSL and Ubuntu 17.04 (master...windows-build-1704) https://github.com/bitcoin/bitcoin/pull/11437 09:08 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/becbd71b0c16...9e8ef9d99179 09:08 < bitcoin-git> bitcoin/master f3ba869 practicalswift: [tests] Add libFuzzer support.... 09:08 < bitcoin-git> bitcoin/master 9e8ef9d Wladimir J. van der Laan: Merge #10440: [tests] Add libFuzzer support... 09:08 < bitcoin-git> [bitcoin] laanwj closed pull request #10440: [tests] Add libFuzzer support (master...libfuzzer) https://github.com/bitcoin/bitcoin/pull/10440 09:10 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds] 09:17 < sipa> BlueMatt: i've been distracted by something else 09:18 -!- jb55 [~jb55@208.98.200.100] has joined #bitcoin-core-dev 09:35 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 09:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds] 09:40 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds] 09:42 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 09:45 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 09:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 10:02 < bitcoin-git> [bitcoin] sdaftuar closed pull request #10200: Mining: Skip recent transactions if fee difference is small (master...2017-04-dont-mine-recent-tx) https://github.com/bitcoin/bitcoin/pull/10200 10:06 -!- Emcy [~MC@unaffiliated/emcy] has quit [Read error: Connection reset by peer] 10:06 -!- Emcy [~MC@unaffiliated/emcy] has joined #bitcoin-core-dev 10:12 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 10:12 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 10:13 -!- timothy [tredaelli@redhat/timothy] has quit [Ping timeout: 248 seconds] 10:14 -!- Emcy [~MC@unaffiliated/emcy] has quit [Read error: Connection reset by peer] 10:14 -!- Emcy [~MC@unaffiliated/emcy] has joined #bitcoin-core-dev 10:14 -!- kingjockey [6a332541@gateway/web/freenode/ip.106.51.37.65] has joined #bitcoin-core-dev 10:15 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 10:16 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 10:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds] 10:19 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 10:25 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-aqseljxufwftnbkx] has joined #bitcoin-core-dev 10:26 -!- Emcy [~MC@unaffiliated/emcy] has quit [Read error: Connection reset by peer] 10:27 -!- Emcy [~MC@unaffiliated/emcy] has joined #bitcoin-core-dev 10:30 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 260 seconds] 10:44 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 10:48 -!- RealM9 [~androirc@balticom-142-92-236.balticom.lv] has joined #bitcoin-core-dev 10:48 < RealM9> Hello, how long until meeting starts? At what time it starts? 10:49 < sipa> 11 minutes from now 10:49 < sipa> sorry, 71 minutes 10:50 < sipa> it's at 7pm UTC 10:50 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9e8ef9d99179...17f2acedbe07 10:50 < bitcoin-git> bitcoin/master 0da49b5 Johnson Lau: Skip precompute sighash for transactions without witness 10:50 < bitcoin-git> bitcoin/master 17f2ace Wladimir J. van der Laan: Merge #9572: Skip witness sighash cache for non-segwit transactions... 10:50 < bitcoin-git> [bitcoin] laanwj closed pull request #9572: Skip witness sighash cache for non-segwit transactions (master...nocache) https://github.com/bitcoin/bitcoin/pull/9572 10:51 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 10:51 < RealM9> Ok, thnx sipa 10:57 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 10:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 10:58 -!- kingjockey [6a332541@gateway/web/freenode/ip.106.51.37.65] has quit [Ping timeout: 260 seconds] 10:58 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 10:59 < jl2012> why do we need a vector of PrecomputedTransactionData here? https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1755 10:59 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 11:00 < sipa> jl2012: what alternative do you suggest? 11:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 11:00 < jl2012> why couldn't we just have a PrecomputedTransactionData for each transaction? 11:00 < sipa> we do? 11:00 < sipa> that's just the vector that holds them 11:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 11:01 < jl2012> yes, but why need to hold them all? 11:01 < sipa> variables need to exist somewhere... 11:03 < jl2012> yes, I mean, why not just have a line PrecomputedTransactionData txdata(tx); inside the loop "for (unsigned int i = 0; i < block.vtx.size(); i++)"? 11:03 < sipa> jl2012: oh, i read "why need to them *at* all", sorry 11:04 < sipa> the reason is that they're used from other threads during parallel validation 11:05 < jl2012> ok...so without the vector, each thread will re-compute the hashes once? 11:06 < sipa> depends how you do it 11:06 < sipa> if you do what you suggest, you'd get undefined behaviour 11:06 < jl2012> why? 11:06 < sipa> as the precomputation data would be out of scope before it's accessed from the validation threads 11:07 -!- Emcy [~MC@unaffiliated/emcy] has quit [Read error: Connection reset by peer] 11:08 -!- W4RL0RD [~W4RL0RD@jh147.perfectdeals.xyz] has quit [Remote host closed the connection] 11:08 < sipa> most of the validation happens after that loop exits, and before the queue's wait call returns 11:08 -!- Emcy [~MC@unaffiliated/emcy] has joined #bitcoin-core-dev 11:10 < JeremyRubin> jl2012: I have a patch that makes them shared_ptrs 11:10 < BlueMatt> sipa: not anymore (tx script caching) :p 11:10 < JeremyRubin> conceptually, that's what you want 11:10 < JeremyRubin> performance wise, a vector is better 11:12 < jonasschnelli> gmaxwell: for the notification system, you had concerns about the reliability.. would a long poll queue that only removes elements from the queue on an ack from the client be something that would defeat your concerns? 11:13 < jonasschnelli> With that concept, loosing notifications would be very unlikely 11:13 < sipa> BlueMatt: ok, i reformulate - most of the validation, if it happens, happens after that loop exits 11:15 < jl2012> oh, I thought all script validation is done with CheckInputs? 11:15 < sipa> jl2012: yes and no 11:16 < sipa> CheckInputs returns a vector of CScriptCheck objects, which represent validation that will happen on another thread 11:16 < sipa> those get pushed to the checkqueue, where validation threads pick them up 11:16 -!- Emcy [~MC@unaffiliated/emcy] has quit [Ping timeout: 240 seconds] 11:16 < jl2012> ontrol.Add(vChecks); ? 11:16 < jl2012> control.Add(vChecks); ? 11:16 < JeremyRubin> yes 11:17 < gmaxwell> jonasschnelli: it would but wumpus pointed out that that queue would potentially grow without bound if the client stops acking entirely. 11:17 < sipa> jl2012: and the CScriptCheck objects have a pointer to the precomputation data 11:18 < JeremyRubin> control.Add returns immediately 11:18 < wumpus> yes, 100% reliable notification given any behavior of the receiver is not possible given finite space 11:18 < jonasschnelli> gmaxwell: a queue limit is unavoidable... if you poll to lazy and the queue limit is to little, the only way to detect would be via the sequence number 11:18 < sipa> jl2012: which means we must guarantee that that precomputation data remains alive as long as other threads may dereference the pointer 11:18 < wumpus> some notification queue middleware logs events to disk in that case 11:18 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 11:18 < jonasschnelli> wumpus: in long polling, the queue must be finite because we don't know when the client polls next,... 11:19 < wumpus> e.g. rabbitmq etc, not by any means suggesting we take that up 11:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 11:19 < wumpus> jonasschnelli: I agree there needs to be a limit realistically, it's enough if a client can detect missed events to resync 11:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 11:20 < jonasschnelli> I personally think acking notifications is unnecessary,.. making it configurable seems also an overkill... so unsure. 11:20 < JeremyRubin> jl2012: this is why I say a shared_ptr is what you really want, because the lifetime is automatically handled for you, whereas the vector is only by careful programming. However, that careful programming is currently correct :) 11:21 < sipa> jonasschnelli: if you don't ask notifications, then your clients must manually deal with restarts... which implies having a way to ask for all events since some time... which, if you have it, removes the need for an event log entirely, as you can just use that all the time 11:21 < jl2012> JeremyRubin, sipa: thanks. I'm thinking how I could do this: https://github.com/bitcoin/bitcoin/pull/9572#issuecomment-334282408 11:21 < wumpus> what's important is to document the limitations of the notification system in that regard 11:22 < sipa> jl2012: do what? 11:22 < jl2012> "I'd be a little more comfortable with this if PrecomputedTransactionData were passed around as const, so nobody's tempted to mess with "ready" for some crazy reason. But that can always be done later." 11:22 < gmaxwell> shared_ptrs are a way to produce a software engineering disaster, because they let you be sloppy with ownership. There are cases of frestanding objects that don't have organized ownership but they are relatively rare. They also have non-trivial overhad. 11:23 < sipa> jl2012: seems trivial? 11:23 -!- Emcy [~MC@unaffiliated/emcy] has joined #bitcoin-core-dev 11:23 < sipa> i think you're overthinking it 11:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 11:24 < jl2012> I'm thinking something like "const PrecomputedTransactionData txdata(tx);" 11:25 < sipa> jl2012: cfields is only asking to pass it around as const; not to make the entire object const 11:26 < cfields> ^^ yep 11:27 < cfields> though i think making the members const would be trivial too 11:27 < cfields> either way, it's not really important for that PR. just an observation. 11:27 -!- Emcy_ [~MC@unaffiliated/emcy] has joined #bitcoin-core-dev 11:27 < jl2012> it's even better if we could make the object const? There is no reason to make any modification 11:28 < JeremyRubin> gmaxwell: am aware, but strictly speaking that is the point here: they are designed to track the actual needed lifetime, and are a 'tighter fit' to the problem in this situation. That they have problems is why I didn't PR my patch. 11:28 < cfields> jl2012: just make the members const, then. use initializers rather than setting them in the function body 11:29 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds] 11:29 < JeremyRubin> jl2012: I think that we shouldn't make it const, because there will be in the future per-tx state that we'll modify 11:29 < JeremyRubin> e.g., if at some point in the future signature agg ends up needing a per-tx mutable struct that each input modifies 11:29 < gmaxwell> JeremyRubin: in the case of the validation the ownership is just a straght line though, the creating code owns it, then the ownership is passed to the queue, then the ownership passes to the verifier thread.. 11:30 < JeremyRubin> Maybe it should be a different struct, but I think (to me), changing PreComputedTxData to PerTxData is straightforward. 11:30 < sipa> JeremyRubin: i think that should be separate 11:31 < sipa> if you want to avoid locking on the precomputed data 11:31 -!- Emcy [~MC@unaffiliated/emcy] has quit [Ping timeout: 248 seconds] 11:31 < JeremyRubin> gmaxwell: yes, and then they are kept alive for longer than strictly needed. After the last scriptcheck executes for that tx, they can be freed. 11:31 < cfields> agree. It'd be nice to keep the factual data separate from what's aggregated/stateful 11:31 < sipa> JeremyRubin: yes, so? it doesn't change the worst case resource consumption 11:32 < JeremyRubin> cfields: all the data should be factual in consensus? 11:33 < jonasschnelli> sipa: persist the notification queue (with it's sequence numbers) to make it restart-safe? 11:33 < JeremyRubin> sipa: I'm really only trying to talk about lifetimes here, which is the core of what jl2012 is discussing 11:33 < JeremyRubin> sipa: asking 11:35 < sipa> JeremyRubin: i'm just trying to point out that minimizing the time an object lives is not always wanted 11:35 < cfields> JeremyRubin: i just meant that it can be safely computed ahead of time and seen as immutible after that. 11:35 < cfields> factual was the wrong word, i suppose. 11:36 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 11:37 < JeremyRubin> sipa: of course 11:38 < sipa> jonasschnelli: that's one way (but it has pretty bad costs, if you want to make it durable - now you need synchronization across all files/databases) 11:39 < sipa> jonasschnelli: another model is that you just have RPCs like listsinceblock, where the client tells the server effectively what it already knows 11:39 < sipa> jonasschnelli: and then all you need is a notification like "there's something for you to look at" 11:40 < jonasschnelli> sipa: by a rolling hash? 11:40 < sipa> jonasschnelli: wut? 11:40 < sipa> no, just like listsinceblock 11:40 < jonasschnelli> how would the client tell the server what notfications it has... just the sequence number? 11:40 < jonasschnelli> (need to check that) 11:40 < jonasschnelli> thanks 11:40 < sipa> no, i'm saying there are no notification 11:40 < sipa> there are just state changes 11:41 < sipa> and the client can ask "i've synced up to block X" or "i've seen transactions up to timestamp Y", or "the last balance update i saw was Z" 11:42 < sipa> because most data has inherent sequencing anyway already 11:42 < jonasschnelli> could it also do long polling? ... because IMO that is what users want (not const. polling) 11:42 < sipa> yes, but the long poll just returns "there is something you should look at", not what 11:43 < jonasschnelli> ah. And then the state update call. 11:43 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 11:43 < sipa> ... no 11:43 < sipa> i mean *exactly* like listsinceblock 11:43 < jonasschnelli> heh.. okay let me dive into there first 11:43 < sipa> it has no sequence numbers, or notifications 11:44 < sipa> it's a call where the client tells the server "hey, i've seen all transactions up to block X. what new transactions are there" 11:44 < sipa> the next time the client calls, it uses the block hash at the time of its previous call 11:44 < sipa> the server doesn't need to keep track of anything 11:45 < jonasschnelli> would that also work with non block/tx data? Like new wallet txns (locally injected) or bandwith watermarks? 11:46 < jonasschnelli> although not sure if there is a need for that 11:46 < sipa> perhaps - maybe it's not possible for everything 11:46 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev 11:46 < sipa> bandwidth watermarks are easy... the client doesn't care if he misses one 11:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 11:47 < sipa> for wallet txn you can use the txid of the last seen tx 11:47 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 11:48 < sipa> jonasschnelli: my point is that you probably need something like that anyway, at least for when a new client starts up or went offline for a while 11:49 < jonasschnelli> sipa: Yes. Your idea make sense. 11:49 < sipa> and when you do, why bother with a separate event queue - all events could just be "hey something happened, you should check what" 11:49 < sipa> that's a big concern i had with ZMQ... as it passes the actual new tx and blocks, but without guarantees that it delivers all 11:49 < sipa> it was fixed with sequence numbers 11:49 < jonasschnelli> maybe you should be able to not get such notifications on new mempool txns 11:50 < sipa> but it could also have been fixed by not having it at all, and making clients query for the data they didn't have after every notifications" 11:50 < sipa> anyway, just an idea 11:51 < jonasschnelli> Thanks for sharing... need to think about it a bit more 11:51 < sipa> having events you can subscribe to individually that persist etc... is certainly more convenient for clients 11:51 < sipa> but it makes bitcoin core responsible for tracking who knows what, instead of leaving that up to clients (who are arguably in a better position to know what they already know) 11:52 < jonasschnelli> Indeed. And also the ressources. 11:52 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 11:55 < sipa> it would be pretty nice if there was a way to subscribe to "hey, let me know when txid X gets Y confirmations or gets reorged", but perhaps that could be done in a python script that just uses a simpler interface with bitcoidn 12:00 < achow101> meeting? 12:00 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-zpyokzzgeayfvamd] has joined #bitcoin-core-dev 12:00 < instagibbs> yes 12:01 < sipa> yes 12:02 < jonasschnelli> #startmeeting 12:02 < lightningbot> Meeting started Thu Oct 5 19:02:18 2017 UTC. The chair is jonasschnelli. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:02 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:02 < wumpus> yes 12:02 < jonasschnelli> Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier 12:02 < kanzure> hi. 12:02 < jonasschnelli> wumpus: sry: though your where OL 12:02 < cfields> hi 12:02 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 12:02 < meshcollider> Hello 12:02 < achow101> hi 12:02 < luke-jr> hi 12:03 < wumpus> jonasschnelli: yes I was a bit late, sorry 12:03 < wumpus> #topic high-priority for review 12:03 < michagogo> Huh? 12:03 < jonasschnelli> #chair wumpus 12:03 < achow101> #10637 please? 12:03 < lightningbot> Current chairs: jonasschnelli wumpus 12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub 12:04 < michagogo> Oh, right 12:04 < michagogo> It's actually Thursday 12:04 -!- jb55 [~jb55@208.98.200.100] has quit [Ping timeout: 264 seconds] 12:04 < wumpus> achow101: ok 12:05 < wumpus> I also added #11389 today as it's blocking segwit wallet support 12:05 * jtimon locks at #8498 and hides for the rest of the meeting 12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/11389 | Support having SegWit always active in regtest by sipa · Pull Request #11389 · bitcoin/bitcoin · GitHub 12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Near-Bugfix: Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub 12:05 < meshcollider> #11403 itself should be in there too probably? 12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub 12:06 < sipa> wumpus: i haven't had the time to work further on 11403, though concept review is certainly welcome 12:06 < jnewbery> I've been reviewing 11389 this afternoon. It looks generally good, but breaks assumevalid.py, which I'm trying to fix now 12:06 < jtimon> s/locks/looks/ 12:06 < BlueMatt> sipa: I think we need a document on the various possible approaches, tbh 12:06 < sipa> BlueMatt: yes, i'll work on that soon 12:07 < BlueMatt> there are a few and talking through all of them is going to need something more formal 12:07 < BlueMatt> thanks 12:07 < morcos> achow101: does 10637 implement all the coin selection logic we discussed in SF or only BnB? Is there a high level description somewhere of what the PR is purporting to accomplish and what else will need to be done before 0.16? 12:07 < achow101> morcos: only BnB 12:07 < achow101> morcos: IIRC Murch is working on all of the coin selection stuff that we discussed 12:07 < wumpus> btw I posted a proposed release schedule for 0.16.0 yesterday 12:07 < wumpus> #link https://github.com/bitcoin/bitcoin/issues/11449 12:08 < morcos> achow101: ok.. i've already forgotten what that is, so might be nice to have that written up in an issue or something so we remember the goal and can think about how this BnB implementation is going to fit into the big picture 12:09 < achow101> morcos: the description of what 10637 does is in the first comment. 12:09 < achow101> I can make an issue for coin selection changes in general 12:09 < achow101> *to keep track of 12:10 -!- jtimon [~quassel@199.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] 12:10 < wumpus> ok, I think that concludes high priority for review proposals 12:10 < wumpus> any other topics? 12:11 < achow101> topic suggestion: bad block interrogation/invalid block peer banning 12:11 < wumpus> #action achow101 make an issue for coin selection changes in general 12:11 < wumpus> #topic bad block interrogation/invalid block peer banning 12:11 < achow101> relevant PR is #11446 (I did this in class so it kinda sucks) 12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/11446 | [WIP] Bad block interrogation by achow101 · Pull Request #11446 · bitcoin/bitcoin · GitHub 12:12 < Murch> hey, sorry, was still in a meeting 12:12 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 12:12 < achow101> basically the idea is gmaxwell's. when we receive an invalid block, we want to make sure that all of our peers would also reject that block as invalid. If they don't ban them 12:12 < Murch> I've been working on it, but since I do that in my free time in the evenings, it's been rather slow. 12:12 < luke-jr> wumpus: this feels delayed? 12:13 < gmaxwell> The general idea is that we aren't sufficiently agressive about punting peers on different consensus rules, so they can DOS attack us by sucking up slots, potentially hours per peer leaving us isolated... So there are number of things we can to do seek and destroy to speed up up. 12:13 < wumpus> luke-jr: what feels delayed? 12:13 < luke-jr> wumpus: 0.16 12:13 < Murch> @achow101: If you want to collaborate on a write-up, I'd make myself available for that. 12:13 < gmaxwell> luke-jr: release schedule is delayed because of 0.15.1 12:13 < achow101> Murch: ok 12:13 < luke-jr> i c 12:13 < wumpus> luke-jr: yes, two months extra added, I mention that in the issue 12:13 < achow101> what I wanted to discuss was the way to actually go about determining who to ban 12:14 < Murch> @achow101: Gonna be traveling the next three weeks, so I might actually have more time. ;) 12:14 < sipa> what is the issue with just looking at headers? 12:14 < gmaxwell> achow101: I was kinda hoping we could implement something just from the messages we already get, it's my belief (could be wrong) that effectively we always learn the peers best header chain-- so we can begin kicking off peers based on that, as a first pass. 12:14 < luke-jr> achow101: this contradicts the fixes in #10593 12:14 < gribble> https://github.com/bitcoin/bitcoin/issues/10593 | Relax punishment for peers relaying invalid blocks and headers by luke-jr · Pull Request #10593 · bitcoin/bitcoin · GitHub 12:14 < gmaxwell> achow101: I think we should be also drawing a distinction between inbound and outbound: the issue is what if we have a peer that accepts a broader set of blocks but would switch to our chain after learning of it. 12:15 < achow101> gmaxwell: that's what I am not sure about. I don't think we necessarily know our peer's best header chain. suppose both us and them are fully synced, how do we know their best header chain until a new block appears? 12:15 < wumpus> luke-jr: maybe two months is too much, but we'll see... 12:16 < luke-jr> wumpus: nah, that sounds reasonable 12:16 < sipa> achow101: when a new block appears, assuming it's PoW-valid to us, we'll learn about it through inv/headers/cb/... 12:16 < jonasschnelli> Yes. +2 M seems okay to me 12:16 < gmaxwell> sipa: but I believe he's right, we would have to wait for a new block, which is among the situations we're trying to resolve. 12:17 < achow101> sipa: right, but I'm concerned about before a new block appears. we just connected to them or they just connected to us. we want to know then if we should ban them or not 12:17 < luke-jr> IMO the desirable logic would be: for outbound connections, disconnect (don't ban) peers that aren't on the same chain; for inbound, tolerate it unless they reject a known-valid block 12:17 < sdaftuar> we send getheaders messages on connect, typically 12:17 < gmaxwell> For example say we are surrounded by ForkCoin peers, they are rejecting all bitcoin blocks. There are few forkcoin miners so they only get blocks once per day. 12:18 < gmaxwell> We don't want to wait for them to get a new block just to figure out our current batch of peers are already on a chain we reject. 12:18 < achow101> sdaftuar: are you sure? all I could find is that we sometimes send getheaders, not all the time 12:18 < sdaftuar> achow101: we send getheaders messages to all our peers at some point after startup, but they might ignore them 12:18 < cfields> sdaftuar: not to incoming light clients, i think? 12:18 < sdaftuar> eg if they are doing ibd themselves or something 12:18 < sdaftuar> not to light clients, correct 12:18 < sipa> light clients don't matter here 12:18 < sdaftuar> but to inbound node_network ndoes we do 12:19 < gmaxwell> If we _always_ sent getheaders and then kicked outbound peers whos chain has a block we've rejected, then I think that is the best we can do per that concern (still not a perfect fix, since you're isolated until forkcoin finds at least one block) 12:19 < achow101> sdaftuar: if we are sending getheaders, if they are on a different chain, we still wouldn't necessarily know because our start block may not be on their best chain 12:19 < gmaxwell> oh hm. then perhaps we already do where it matters. 12:19 < sdaftuar> gmaxwell: the difficult part might be that you don't know the chain they're on is invalid 12:19 < sdaftuar> if it's got less work than yours 12:19 < RealM9> Topic suggestion: s2x 12:20 < jonasschnelli> RealM9: no 12:20 < luke-jr> sdaftuar: do you care? 12:20 < luke-jr> if they're rejecting your better chain, you want to disconnect them anyway 12:20 < gmaxwell> sdaftuar: seems like a seperate concern, we should also be kicking outbound peers that have less work than us, I think. 12:20 < RealM9> Ok, but community is pretty interested. Are you going to change POW? 12:20 < sdaftuar> gmaxwell: i think that would be a good idea, yeah 12:20 < gmaxwell> But it would be silly to be overly agressive. 12:20 < sipa> RealM9: us? 12:20 < achow101> sdaftuar: gmaxwell what I propose is that we send a getheaders for our earliest known invalid block (within a certain time frame) and see if they respond with invalid blocks 12:21 < luke-jr> RealM9: that's a decision for the community, not for developers. anyhow, ask on #bitcoin if you really want to discuss it 12:21 < gmaxwell> achow101: I don't think we need to do that: for sync purposes any outbound peer we should be makign sure we learn their headers chain period (they may have a better chain than us and we should sync up ASAP) 12:21 < sdaftuar> achow101: i'm not sure that's necessary? 12:21 < morcos> RealM9: we're in a meeting , but please see: https://bitcoincore.org/en/2017/08/18/btc1-misleading-statements/ 12:21 < gmaxwell> achow101: if we're already doing that we'll notice known invalid block in their header chaip (well we will once we have code for that) 12:21 < sdaftuar> i think if we do gmaxwell's suggestion of booting inbound peers who are on less work chains, then we'd be in good shape 12:21 < sdaftuar> s/inbound/outbound/ 12:22 < luke-jr> I think we may actually want to track the headers of invalid chains.. 12:22 < achow101> what about inbound peers? 12:22 < gmaxwell> For _inbound_ I think we should be setting a flag that they're consensus inconsistent which excludes them from the inbound peer management connection reservation. 12:22 < sdaftuar> achow101: i think we should more aggerssively evict inbound peers if they appear to be on invalid chains 12:22 < gmaxwell> so they'll get kicked off in favor of other inbound peers. 12:22 < meshcollider> Agreed 12:23 < gmaxwell> so we don't need to be agressive: they'll just get pushed out by other inbound peers. 12:23 < luke-jr> consider: if an invalid chain has higher hashrate than the real chain, and then suddenly the invalid chain's hashrate drops off, without an equivalent increase on the main chain, we should consider that a possible attack and hold back on confirming transactions until it is resolved 12:23 < sdaftuar> gmaxwell: yes i agree with you 12:23 < achow101> my point is how do we know that an inbound peer is on an invalid chain? 12:24 < gmaxwell> luke-jr: I think there is some need for smarter wallet confirmation logic but I think thats a seperate matter. (there was a paper 6-ish months ago that also points out the the reorg probablity math in the whitepaper is somewhat incomplete) 12:24 < sdaftuar> achow101: set a flag if they relay an invalid block/blockheader 12:24 < luke-jr> gmaxwell: right, but this is relevant because we can't assume "relays invalid headers" means the other node *accepts* the invalid block 12:24 < gmaxwell> and we still interogate their headers if they're NODE_NETWORK/NODE_LIMITED 12:24 -!- RoyceX [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev 12:24 < luke-jr> sdaftuar: we intentionally relay blocks before checking validity now 12:25 < achow101> sdaftuar: that requires them to have a block to relay to us, which could take hours or days 12:25 < gmaxwell> luke-jr: the protocol does not have you realying a header of a block you haven't accepted. If you do that you risk dos attacking peers already. 12:25 < sdaftuar> achow101: i don't think we need to worry as much about inbound peers 12:25 < sdaftuar> achow101: for instance an attacker can already try to use all your inbound slots and not send you anything 12:25 < gmaxwell> luke-jr: the only place that happens in the protocol is HB BIP152 messages. 12:25 < achow101> sdaftuar: right, ok 12:25 < luke-jr> gmaxwell: which may be all you see from CB peers 12:26 < gmaxwell> sdaftuar: yes, for inbound we can just deprive them of reservations. 12:26 < sdaftuar> luke-jr: even with bip152 the headers need to be valid 12:27 < luke-jr> sdaftuar: yes, the header itself; but it can be a valid header for an invalid block 12:27 < gmaxwell> yes, though we'd catch it on the _next_ block. 12:27 < sdaftuar> luke-jr: if it builds on an invalid chain, i believe the header would be invalid 12:27 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 12:27 < achow101> so when we connect to an outbound peer, we will send them a getheaders so we know their best headers chain and ban accordingly 12:27 < luke-jr> (note I tried to keep track of peer bestblocks in #10512 and basically gave up) 12:27 < gribble> https://github.com/bitcoin/bitcoin/issues/10512 | Rework same-chain from abusing DoS banning, to explicit checks by luke-jr · Pull Request #10512 · bitcoin/bitcoin · GitHub 12:27 < gmaxwell> when they relay a CB message for a child of an invalid block. 12:27 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 240 seconds] 12:28 < gmaxwell> achow101: yes, but based on the above I believe we already always send it. 12:28 < achow101> the other part of 11446 is to ban other peers for relaying us an invalid block for which we already know is invalid 12:28 < gmaxwell> achow101: because we send it to nodenetwork peers and outbound always are (or or disconnected) 12:28 < achow101> but I'm not sure how that interacts with compact blocks 12:28 < gmaxwell> achow101: FWIW, I think we should probably be just disconnecting and not banning. 12:28 < sdaftuar> achow101: oh that interaction might be tricky 12:28 < achow101> gmaxwell: why not ban? 12:29 < gmaxwell> I think the interaction isn't too bad, for this purpose a BIP152 CB HB block is relaying you the header of its parent. 12:29 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 12:29 < luke-jr> achow101: in a softfork, old nodes will send invalid blocks 12:29 < luke-jr> potentially 12:29 < gmaxwell> achow101: because it's hardly any better and it means that when some dimbulb tries running forkcoin it results in him being unable to run Bitcoin (perhaps concurrently) on the same host. 12:30 < achow101> gmaxwell: ok 12:30 < gmaxwell> it also blocks inbound from that peer, which we'd be find allowing. 12:30 < gmaxwell> s/find/fine/ 12:30 < gmaxwell> In general we should be moving away from bans except when the thing we banned for was expensive for us. 12:31 < achow101> so 11446 can really just be reduced to an ~1 line change to disconnect on a header for a block we already know is invalid 12:31 < BlueMatt> yea, that 12:31 < sdaftuar> achow101: agree, though we have to be careful about compact blocks i think 12:31 < luke-jr> achow101: aka #10593 … 12:31 < gribble> https://github.com/bitcoin/bitcoin/issues/10593 | Relax punishment for peers relaying invalid blocks and headers by luke-jr · Pull Request #10593 · bitcoin/bitcoin · GitHub 12:31 < gmaxwell> achow101: yes, but for compact block interactions (HB mode will relay us blocks that are invalid). 12:32 < achow101> gmaxwell: so we would have to check the specific type of invalidness and whether it was a CB? 12:32 < gmaxwell> luke-jr: IIRC when you proposed that before you got squaked at that it would undermine our protection against isolation... 12:33 < gmaxwell> achow101: or just don't do it for the peers maked for HB CBs for now 12:33 < achow101> gmaxwell: isn't that likely to be most peers though 12:33 < achow101> ? 12:33 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 12:33 < gmaxwell> No, it's at most three. 12:33 < luke-jr> gmaxwell: I don't see how. It's literally what achow101 was just describing. 12:34 < luke-jr> gmaxwell: maybe you're thinking of the predecessor 10512? 12:34 < achow101> luke-jr: it doesn't look like you are handling invalid duplicates? 12:34 < gmaxwell> probably. 12:34 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 12:34 < gmaxwell> achow101: in any case, we can pick this up on a PR and later discussion. 12:35 < achow101> gmaxwell: ok 12:36 -!- wraithm [~wraithm@unaffiliated/wraithm] has quit [Ping timeout: 240 seconds] 12:36 < achow101> next topic then? 12:36 < wumpus> any other topics? 12:36 < luke-jr> achow101: IIRC it does, we can go over it later if you like 12:36 < achow101> luke-jr: ok 12:37 < jnewbery> luke-jr: any progress on multiwallet GUI without the rpcauth parts? 12:37 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 12:37 < wumpus> #topic multiwallet ui 12:37 < luke-jr> jnewbery: not yet, I'll plan to push the update later today 12:38 < jnewbery> great! I had a look myself, and I think it's just a one-line change to the debug console commit 12:38 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/11383 12:38 < sipa> topic suggestion: dealing with platform-specific code 12:38 < jonasschnelli> luke-jr: I can continue to work on 11383 if you want? 12:38 < jonasschnelli> (remove the auth stuff :P) 12:38 < luke-jr> jnewbery: certainly not that simple.. still need to resolve wallet name to CWallet earlier 12:39 < jnewbery> ok, well I've got a branch that works with just that change. Happy to share with you 12:39 < gmaxwell> Sounds good. 12:40 < luke-jr> jnewbery: push it and I'll take a look 12:40 < jnewbery> thanks 12:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 12:41 < wumpus> #topic dealing with platform-specific code (sipa) 12:41 < sipa> i've recently been looking into faster parallel hashing code 12:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 12:41 < wumpus> hashing as in sha256? 12:41 < sipa> in particular, for 8-way parallel SHA256 (which would be useful in merkle root computation and block deserialization), a 5x speedup is doable with AVX2 12:42 < sipa> and maybe 2.5x with SSE2 12:42 < wumpus> and parallel in this case means computing multiple hashes of multiple pieces of data at once? 12:42 < sipa> correct 12:42 < luke-jr> how much speedup is this for the entire IBD? 12:42 < gmaxwell> luke-jr: It saves something like 10 minutes on IBD. But the greater impact is in block relay. 12:43 < wumpus> (I guess there are constraints there, do all the inputs need to be the same size?) 12:43 < luke-jr> I imagine merkle root is a tiny fraction of the overall process, but otoh it's also possibly a blocker on parallelization 12:43 < gmaxwell> Where hash tree computation is most of the time. 12:43 < luke-jr> gmaxwell: it is? :O 12:43 < sipa> wumpus: yes and no; for now, it's just a primitive that you give a pointer to N 64-byte inputs, and produces 32-byte outputs 12:43 < luke-jr> oh, because the signature checks are cached? 12:43 < BlueMatt> in terms of compact block relay, merkle root calculation and deserialize are about the only big timesinks before you can relay 12:43 < sipa> wumpus: which is specific for merkle root computation 12:43 < gmaxwell> luke-jr: yes for HB BIP152 we don't to validation except hashing! 12:43 < sipa> but it can certainly be adapted 12:44 < wumpus> sipa: ok 12:44 < cfields> sipa: i had a scare when reviewing some new leveldb crc32 changes that i thought (at first glance) could be a consensus issue. I was very angry at myself at that point for not adding a fallback un-optimized verification of the optimized path. 12:44 < sipa> anyway, there are multiple ways to integrate this: separate asm code, inline asm blocks, or code using intrinsics (my preference, it's much more easy to review, and has no OS-specific warts like the L label prefix...) 12:44 < gmaxwell> sipa has actually implemented the 8-way AVX2 sha2 and a hash tree computation that uses it... along with specialized implementation of 64-byte input double sha2.. which affords an addition 20%-ish speedup over generic sha2. 12:45 < cfields> very cool :) 12:45 < wumpus> I prefer intrinsics 12:45 < wumpus> (except for arm32 whre they suck) 12:45 < sipa> so, for intrinsics... do we want to have a separate LIBCRYPTO_AVX2 LIBCRYPTO_SSE2 LIBCRYPTO_... with different compile flags each? 12:46 < gmaxwell> Historically, For some code you cannot achieve equivilent performance w/ intrinsics because you must manage register allocation precisely for things to work, but that isn't the case here.... 12:46 < sipa> or could we rely on __attribute__((target("avx2"))) 12:46 < wumpus> but 64 bit platforms the SIMD instructions have been specially tweaked to work well with compilers and intrinsics 12:46 < sipa> (which works on both clang and gcc) 12:46 -!- EricCartman [~EricCartm@81.202.149.143.dyn.user.ono.com] has quit [Quit: Leaving] 12:46 < cfields> sipa: i think we should test for the target attribute and use it if possible, but not completely rely on it 12:46 < cfields> iirc that improves dispatching time as well? 12:46 < sipa> cfields: no 12:46 < wumpus> different compile flags for different compile units, that's the only portable way 12:47 < luke-jr> sipa: I think we can't assume intrinsics for all platforms, so we want the separate lib route 12:47 < gmaxwell> dispatching is via a function pointer ultimately in all those cases. 12:47 < wumpus> luke-jr: you're confusing, that's not about intrinsics 12:47 < sipa> the only difference is avoiding the need for build system complication 12:47 < wumpus> intrinsics inthis case are headers like xmmintr.h which provides functions that work on vector types 12:47 < sipa> exactly 12:47 < luke-jr> wumpus: __attribute__((target("avx2"))) isn't an option for separate asm code, though, right? 12:48 < sipa> luke-jr: it also isn't needed for asm code 12:48 < cfields> gmaxwell: isn't there elf data that allows them to be setup at load time? 12:48 < wumpus> oh no no ELF magic please 12:48 < luke-jr> hmm 12:48 < cfields> not by hand, i thought __attribute__(target) did that behind the scenes 12:48 < sipa> target("avx2") just means "this function is compiled as if -mavx2 was passed on the command line 12:49 < sipa> cfields: GCC also has target("default"), where you can have multiple versions of the same function... which causes automatic dispatch to be added 12:49 < sipa> that's non-portable and has other issues 12:49 < gmaxwell> cfields: they're setup at load time, yes-- but they're still just a function pointer, which we could also have setup at load time. Though it is nice that the function override trick can make them run before main. 12:49 < wumpus> I'm normally not scared of low level ELF hacking, but for bitcoin, let's try to keep it safe and portable 12:49 < luke-jr> sipa: how does it behave if I have an explicit -mno-avx2? 12:49 < sipa> (in particular clang doesn't have that) 12:49 < cfields> sipa: ah yes, that's what i was thinking of. 12:49 < sipa> cfields: so i'm not suggesting using that 12:49 < sipa> luke-jr: i assume it overrides it 12:49 < cfields> ok 12:50 < luke-jr> I suppose I can test it 12:50 < wumpus> yes, gcc can do it automatically on some platforms, but I'm afraid the only portable way is to make our own dispatch logic 12:50 < sipa> yes, we'll want our own dispatch logic anyway 12:50 < wumpus> we already have some CPUID bits checking 12:50 < sipa> so we can test things 12:50 < wumpus> so it's nothing new erally 12:50 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 246 seconds] 12:50 < sipa> and report which version is being chosen 12:50 < cfields> np, i wasn't suggesting. just trying to understand the advantages of one vs the other. 12:50 < wumpus> yes, exactly 12:51 < sipa> but if possible i'd like to avoid the overhead of needing half a dozen libcrypto_XXX.a things that need to be linked in everywhere 12:51 < sipa> though that's really the only advantage 12:51 < wumpus> so I'd say: yes, use intrinsics instead of inline/offline asm, and use our own dispatching, and compile units compiled with appropriate compiler flags 12:51 < sipa> okay. 12:52 < gmaxwell> can we say prefer intrinsics instead of use? :) I don't think we'd eschew inline asm if we thought it was better in a particular case. 12:52 < wumpus> yes regarding build system it's just verbose, not really complex 12:52 < cfields> sipa: see my point above about a fallback, though. In the case of mismatch hashes, i think it's worthwhile to re-check with a generic implementation before deciding it's failed. 12:53 < gmaxwell> cfields: we should be testing these things in startup tests. 12:53 < luke-jr> (yes, it seems to override -mno-* 12:53 < wumpus> gmaxwell: well if there's a case you can do much better than the compiler, sure... 12:53 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 12:53 * BlueMatt has a weak preference for compile units, but only cause I'd use them in FIBRE for my FEC stuff, too, but thats not much of a reasoning 12:54 * luke-jr hopes we can have POWER9 asm in 0.16 <.< 12:54 * BlueMatt agrees 12:54 < cfields> gmaxwell: an implementation bug in some branch of one optimized path is scary... 12:54 < gmaxwell> cfields: try differently if it fails is just not reasonable in a lot of cases; and often would add a lot of complexity (now you have to not cache hashes, but instead only use hash-verify methods) ... and we don't have expected values for thigns like single transaction hashes, just hash roots. 12:54 < cfields> gmaxwell: in particular, the crc issue had to do with incoming data alignment on x86_64 12:55 < wumpus> cfields: I agree 12:55 < wumpus> cfields: I think we should only do asm optimization in cases where it really makes a lot of difference, for that reason, ther risk has to be worth it 12:56 < gmaxwell> cfields: yes, thats something that always needs careful review and we should have unit tests that also stress alignment. 12:56 < wumpus> special-casing everything makes things a lot harder to review, and test, especially when it starts to need different kinds of hardware 12:56 < wumpus> but for testable low-level primitives like SHA256 I'd say it's ok 12:57 < gmaxwell> good thing no one is talking about special casing everything. :) 12:57 < gmaxwell> yea, sha2 etc have simple testable interfaces. 12:57 < wumpus> no, that's just one extreme, I've seen soome graphics drivers which are scary in that regard :) 12:58 < gmaxwell> But benchmarks! 12:58 < wumpus> oh let's special case 4x4 tiles, 4x5 tiles, 4x6 tiles, ... for 3 different architectures 12:58 < wumpus> right :) 12:58 < cfields> mmm. I don't see the harm in doing a quick re-check in a few certain cases (merkle mismatch is a good example) 12:58 < wumpus> special-casing benchmarks is a curious form of over-learning 12:58 < cfields> anyway, i've made my case 12:59 < gmaxwell> cfields: because it requires restructing the code to not return hashes but instead only have uncachable hash_Verify methods. 12:59 < wumpus> cfields: re-check in what case? 12:59 < luke-jr> although someone did manage to screw up xpub serialisation at one point IIRC 12:59 < wumpus> cfields: you mean re-run the validation w/ different implementations if an incoming block fails? 12:59 < wumpus> (what about false positives?) 13:00 < cfields> wumpus: that's a big hammer, but yes-ish 13:00 < gmaxwell> cfields: and for small functions like a hash a check in an innerloop will measurably lower performance. ... and you also create the opposite problem, what if the alternative function is the wrong one? 13:00 < gmaxwell> (I'd actually consider whole block level more reasonable) 13:00 < wumpus> gmaxwell: I think he means on a high level 13:01 < wumpus> on the inner level it's just NASA-level crazy, let's run three implementations and see which ones agree 13:01 < sipa> i think re-checking a block if it fails is reasonable... but why switch hash functions? it's massively more likely your CPU is fried than that the hash function implementation is wrong all along and you never noticed 13:01 < gmaxwell> but then the dispatch is mutable not just set once at init. :( 13:01 < wumpus> yeah ... I think we're overdesigning this 13:01 < gmaxwell> right we have a constant slow stream of complaints from users whos hosts have falsely rejected the blockchain. 13:01 < wumpus> just continue with what you were doing sipa :) 13:01 < cfields> gmaxwell: just have a generic non-dispatchable one 13:01 < gmaxwell> I would like to see that improved somehow. 13:01 < wumpus> any other topics? 13:01 < wumpus> oh wait, it's time 13:01 < wumpus> #endmeeting 13:01 < lightningbot> Meeting ended Thu Oct 5 20:01:57 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:01 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-10-05-19.02.html 13:01 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-10-05-19.02.txt 13:01 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-10-05-19.02.log.html 13:02 < sipa> #lunch 13:02 < meshcollider> And for anyone who doesn't know yet, hacktoberfest = free t-shirt for 4 PRs in october 13:02 < meshcollider> https://hacktoberfest.digitalocean.com 13:03 < sipa> if someone is interested: https://github.com/sipa/bitcoin/commits/201709_dsha256_64 <- 64-byte specialzed SHA256 and AVX2 code 13:03 < gmaxwell> sneaky way to learn developers mailing addresses. 13:03 < sipa> (way too WIP to PR) 13:03 < achow101> ooh free t-shirts 13:03 * sipa found the student 13:03 < meshcollider> gmaxwell: Heh true 13:03 < cfields> sipa: very cool. didn't mean to rain on your parade. 13:03 < luke-jr> gmaxwell: never got any spam that I can tell came from last year's 13:04 < luke-jr> just don't use your home address for mailing address ;) 13:04 < wumpus> sipa: nice 13:04 -!- jb55 [~jb55@208.98.200.100] has joined #bitcoin-core-dev 13:05 < gmaxwell> cfields: so imagine that sha2 implementation isn't alignment safe. you get a block and miscompute one of the hashes due to alignment. ... I don't see any way of efficiently accomplishing your 'try another function' approach that would stop the false rejection. 13:05 < sipa> wumpus: too bad the 64-byte specialized generic-x86 code is slower than the generic-data-size SSE4-specialized version 13:06 < sipa> wumpus: otherwise i'd straight up PR the 64-byte specialized code 13:06 < wumpus> the avx code looks very recognizable 13:06 < sipa> wumpus: it's pretty much search replace on SSE4 code 13:06 < wumpus> heh 13:06 < gmaxwell> it's only detectable at the hash root check at the end a long computation pipeline... when that fails do we just go back and re-deseralize the entire block with different code to compute new hashes in the CTransactions? 13:07 < gmaxwell> (and if we do, we magnify a DOS vector for someone sending us invalid blocks, though perhaps not enough to worry about) 13:07 < wumpus> that's another advantage of intrinsics, it's usually easier to review than straight up asm 13:08 < sipa> wumpus: absolutely 13:08 < wumpus> no need to keep track in your head where all the registers go 13:08 < cfields> gmaxwell: addmittedly that's ugly, but yes, i think that's worth considering 13:08 < sipa> which may be a good thing or a bad thing 13:08 < sipa> 1) no need to keep in your head where the registers go! 13:08 < sipa> 2) no way to tell the compiler to keep a certainly value in a register! 13:09 < wumpus> well combined with the pipelining/interleaving that optimized code needs, and the large number of registers that SIMD architectures have, that can be quite difficult 13:09 < gmaxwell> I wish you could assign variables to registers, and have the compiler yell at you if you tried to assign two live variables to the same register. 13:10 < wumpus> usually there's so many registers that it would be good to be able to tell that something is *not* worth storing in a register 13:10 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has joined #bitcoin-core-dev 13:10 < sipa> i believe there is actually a way (in GCC) to force a particular variable into a particular register 13:11 < sipa> int x asm("%edx"); 13:11 < gmaxwell> cfields: and still doesn't help with accepting something we shouldn't, which is usually a more serious issue. 13:12 < gmaxwell> cfields: if we had some generic infrastructure to retry a failed validation (e.g. to cope with lossy hardware) then perhaps what you're thinking about could be dropped into it. 13:12 < cfields> gmaxwell: i'm not saying it's something we have to do, or something that wouldn't be ugly. I'm moreso coming from a place where I was in full-out panic for a few hours because I thought newer x86_64 machines were about to start diverging... 13:12 < sipa> https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html#Local-Register-Variables 13:13 < cfields> so you're right, (good!) testing should negate those worries. 13:13 < gmaxwell> Well, in particular runtime tests... since they'll catch failures on the actual hardware the user has. 13:13 < cfields> gmaxwell: for reference: https://github.com/google/leveldb/commit/2964b803b857932ff7499d7bebb61dc5514dab7c 13:13 < cfields> yes 13:14 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 13:15 -!- Emcy_ [~MC@unaffiliated/emcy] has quit [Read error: Connection reset by peer] 13:15 -!- Emcy_ [~MC@unaffiliated/emcy] has joined #bitcoin-core-dev 13:16 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 13:17 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 240 seconds] 13:19 < morcos> I also don't want to rain on anyone's parade, and this is OSS so people work on what they find interesting, but I think we shoudl be careful to think about what are priorities for the project 13:19 < morcos> More importantly however, we shoudl be careful about making changes that are not easily reviewable by more than 1 or 2 people unless they are really warranted 13:20 < morcos> I've been thinking more about this since bech32. I think bech32 is completely awesome, I'm super happy we're doing it and imo its a good priority project. But it essentially got no review. Did anyone other than sdaftuar review it? 13:21 < morcos> Sometimes things will have to be like that, but it shoudl be a tradeoff we consider carefully... how tricky are we trying to be vs how much is it warranted 13:22 * BlueMatt tends to agree, though noting that a part of my agreement is my different priorities from some others - performance is maybe much more of a concern for many others in the project more than I 13:22 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev 13:22 < morcos> I haven't evaluated that in the context of the parallelized hashing, but its something I think we should 13:25 < gmaxwell> morcos: bech32 had more review then it appeared because we solicited extensive review before publishing the bip.. what didn't get review was the checksum itself other than myself and pieter, until sdaftuar. ... but who reviewed the prior address checksum? 13:25 < gmaxwell> Clearly no one, because it needlessly sucked. :P 13:25 < sipa> well it was too late to review it by the time any of us were around 13:26 < luke-jr> I didn't review Bech32 because I figured it was over my head (especially magic checksum stuff). 13:26 < gmaxwell> There were many design changes to the earliest Bech32 proposal that arose out of review, e.g. the delimiter character. 13:27 < morcos> Yes and of course the 2 people that can't be blamed are you and pieter since you did the work. But I don't want us to fall into a trap of just assuming if something is too difficult or outside of our field to review properly that someone else must be doign a good job with it 13:28 < morcos> gmaxwell: and yes i was referring to the checksum 13:28 < morcos> but thats a good point... 13:29 < gmaxwell> We deal with this for libsecp256k1 too, that fact that it's in a different repo is just enabling you to ignore it. :) 13:29 < gmaxwell> Though we do have effective review there too. 13:30 < gmaxwell> Though not as much as I'd like. 13:30 < sipa> but at least for secp256k1 it's clear what the goal is (implement secp256k1 EC correctly), so someone could review e.g. just the test and judge that they're sufficient for that goal 13:30 < cfields> morcos: yes, well said. I think that's why I find the asm changes scary. I spent a full day trying to learn and understand the sse42 optimized sha2, and only because it was failing some tests. At best, I agree that it looks right, but I could never say it with any degree of certainty. I deferred to "it passes all the tests". 13:31 < sipa> with bech32, the effort is in the design, not the implementation, and there is relatively little proof that the design actually has the properties it claims to have 13:31 < gmaxwell> But thats the same thing as reviewing the bech32 checksum. and fwiw, if feedback on bech32 we got was we needed more reviewers for the checksum, I would have gone and asked a libsecp256k1 contributor to do it. 13:32 < gmaxwell> because I know e.g. andrew (or peter dettman) aren't frightened off by math. 13:32 < morcos> I think my feedback is one meta level up. There should have been more people that questioned how much reivew it got 13:32 < gmaxwell> yes, agreed. 13:32 < gmaxwell> well I was thinking that before you commented. Started thinking it as soon as I saw other bitcoin software had merged it. 13:32 < morcos> so i know i'm not going to review the hashing stuff, just want to make sure other peopel are going to ensure it is properly reviewed 13:33 < morcos> i'm frightened off by code. :) 13:34 < gmaxwell> had someone commented on that earlier, I would have agreed. I reviewed the checksum work too, but pieter and I worked a lot togeather on it, and if he screwed up he probably would have tained me. 13:34 < sipa> the cool thing about hash functions is that they have essentially no branches... so it's very hard (though not impossible, see the alignment issue) to make it be incorrect only for a hard-to-detect small subset of inputs 13:35 < gmaxwell> yes on hash function correctness, but that doesn't help with BECH32 design, which I guess as your point above. It's easy to be confident a new implementation of it is conformant... not so much that the design is good. 13:35 < sipa> right 13:36 < gmaxwell> and still no one has basically reviewed our decision to use a cyclic code -- perhaps if we were call coding theorists someone would have known an even better tool... but there is a limit to how far down a rabbit hole we can go. 13:36 < morcos> gmaxwell: but part of my point was the tradeoff on how important the feature is. i am definitely +1 on bech32. and not negative on parallel hashing just raising points for us to think about 13:36 < morcos> anyway, got to run 13:52 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 14:04 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 14:07 -!- ybit [~ybit@unaffiliated/ybit] has quit [Ping timeout: 248 seconds] 14:07 -!- ybit [~ybit@unaffiliated/ybit] has joined #bitcoin-core-dev 14:26 -!- wraithm [~wraithm@unaffiliated/wraithm] has joined #bitcoin-core-dev 14:26 -!- jtimon [~quassel@199.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 14:29 -!- RoyceX [~Cheeseo@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer] 14:33 < BlueMatt> someone wanna close 11454? 14:52 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev 14:56 < gmaxwell> morcos: I think you can decompose your concerns into two folks-- people will work on whatever they like, but if it's going to get merged it needs to deserve the required review attention, since that isn't just an indivigual decision. 14:56 < gmaxwell> forks* 14:56 < gmaxwell> morcos: and then unrelated, we shouldn't be in a state where people don't review or even provide meta review of things which are two mathy or too low level and so they assume that they won't be of use. 14:57 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 14:57 < gmaxwell> And the thing to encourage there is that even if its over your head you can still ask some of the right meta questions. 15:12 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer] 15:13 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev 15:14 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 15:19 -!- wraithm [~wraithm@unaffiliated/wraithm] has quit [Ping timeout: 240 seconds] 15:29 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer] 15:29 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev 15:30 -!- echonaut1 [~echonaut@46.101.192.134] has joined #bitcoin-core-dev 15:31 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection] 15:36 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds] 16:08 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 258 seconds] 16:15 < bitcoin-git> [bitcoin] theuni opened pull request #11457: Introduce BanMan (master...move-bandb) https://github.com/bitcoin/bitcoin/pull/11457 16:20 -!- vicenteH [~user@93.104.135.37.dynamic.jazztel.es] has quit [Ping timeout: 258 seconds] 16:29 < luke-jr> jnewbery: your version seems to pass the wallet by name instead of CWalletRef 16:36 -!- stevenroose [~steven@vps.weuste.club] has quit [Ping timeout: 246 seconds] 16:38 -!- stevenroose [~steven@vps.weuste.club] has joined #bitcoin-core-dev 16:49 -!- Emcy_ [~MC@unaffiliated/emcy] has quit [Read error: Connection reset by peer] 16:49 -!- Emcy_ [~MC@unaffiliated/emcy] has joined #bitcoin-core-dev 16:58 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 17:02 -!- DrOlmer [~DrOlmer@unaffiliated/drolmer] has quit [Ping timeout: 258 seconds] 17:03 -!- DrOlmer [~DrOlmer@unaffiliated/drolmer] has joined #bitcoin-core-dev 17:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 17:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 17:17 -!- jb55 [~jb55@208.98.200.100] has quit [Ping timeout: 258 seconds] 17:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 17:43 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds] 17:44 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-aqseljxufwftnbkx] has quit [Quit: Connection closed for inactivity] 17:51 < karelb> what is the meeting schedule here, so I can watch? :) 17:52 < karelb> nevermind I see here https://bitcoincore.org/en/meetings/ 17:57 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev 18:01 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 18:03 -!- karelb [~karelb@li1380-211.members.linode.com] has quit [Quit: Bye!] 18:05 -!- moctos [~moctos@cpe-107-9-138-59.neo.res.rr.com] has joined #bitcoin-core-dev 18:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 18:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds] 18:25 -!- owowo [ovovo@gateway/vpn/mullvad/x-cyazibzdnppcrxim] has quit [Ping timeout: 260 seconds] 18:26 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 18:27 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds] 18:31 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-core-dev 18:32 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 18:34 -!- jtimon [~quassel@199.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 258 seconds] 18:35 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 18:49 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Quit: WeeChat 1.9] 18:52 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has quit [Ping timeout: 240 seconds] 18:53 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has joined #bitcoin-core-dev 19:04 -!- michagogo [uid14316@wikia/Michagogo] has quit [Ping timeout: 255 seconds] 19:05 -!- hsmiths [uid95325@gateway/web/irccloud.com/x-tzsfdirxrshjzmkq] has quit [Ping timeout: 255 seconds] 19:05 -!- ndrst [~ndrst@unaffiliated/ndrst] has quit [Ping timeout: 255 seconds] 19:06 -!- xHire [~xHire@kos.paskuli.cz] has quit [Ping timeout: 255 seconds] 19:06 -!- hkjn0 [~hkjn@102.84.211.130.bc.googleusercontent.com] has quit [Ping timeout: 255 seconds] 19:07 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev 19:08 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.] 19:08 -!- xHire [~xHire@kos.paskuli.cz] has joined #bitcoin-core-dev 19:08 -!- hkjn0 [~hkjn@102.84.211.130.bc.googleusercontent.com] has joined #bitcoin-core-dev 19:09 -!- mappum_ [sid43795@gateway/web/irccloud.com/x-kafrymrgfiqzktje] has joined #bitcoin-core-dev 19:09 -!- ibrightly_ [sid113387@gateway/web/irccloud.com/x-esbfixqqpnjuovzr] has joined #bitcoin-core-dev 19:09 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has quit [Disconnected by services] 19:09 -!- NicolasDorier_ [sid129442@gateway/web/irccloud.com/x-jpopikbjechzhyur] has joined #bitcoin-core-dev 19:10 -!- mariorz_ [sid490@gateway/web/irccloud.com/x-idmjrgzohhjmsivi] has joined #bitcoin-core-dev 19:11 -!- pindarhk__ [sid105966@gateway/web/irccloud.com/x-tzwzhnnmekyfrtwr] has joined #bitcoin-core-dev 19:11 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev 19:12 -!- Pat_Boy [xyz@192.99.249.194] has joined #bitcoin-core-dev 19:12 -!- Lightsword_ [~Lightswor@107.170.253.193] has joined #bitcoin-core-dev 19:12 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-wzsgdxpmtlpwiywz] has quit [Ping timeout: 255 seconds] 19:12 -!- pindarhk_ [sid105966@gateway/web/irccloud.com/x-taaylkoxllhcdjnk] has quit [Ping timeout: 255 seconds] 19:12 -!- mariorz [sid490@gateway/web/irccloud.com/x-puluuednduwvrfcu] has quit [Ping timeout: 255 seconds] 19:12 -!- mappum [sid43795@gateway/web/irccloud.com/x-hktzatbysxntmjil] has quit [Read error: Connection reset by peer] 19:12 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-nocnqhokvrquwhrk] has quit [Read error: Connection reset by peer] 19:12 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has quit [Ping timeout: 255 seconds] 19:12 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-zpyokzzgeayfvamd] has quit [Ping timeout: 255 seconds] 19:12 -!- sipa [~pw@unaffiliated/sipa1024] has quit [Remote host closed the connection] 19:12 -!- PatBoy [xyz@192.99.249.194] has quit [Ping timeout: 255 seconds] 19:12 -!- rodarmor [sid210835@gateway/web/irccloud.com/x-dukpphxnmnlefytb] has quit [Ping timeout: 255 seconds] 19:12 -!- TheLive1 [~TheLive1@unaffiliated/thelive1] has quit [Ping timeout: 255 seconds] 19:12 -!- NicolasDorier_ is now known as NicolasDorier 19:12 -!- Pat_Boy is now known as PatBoy 19:12 -!- mariorz_ is now known as mariorz 19:12 -!- pindarhk__ is now known as pindarhk_ 19:12 -!- mappum_ is now known as mappum 19:12 -!- ibrightly_ is now known as ibrightly 19:13 -!- Lightsword_ is now known as Lightsword 19:13 -!- moctos [~moctos@cpe-107-9-138-59.neo.res.rr.com] has quit [Quit: moctos] 19:13 -!- rodarmor [sid210835@gateway/web/irccloud.com/x-igszrqgdkewhgxyv] has joined #bitcoin-core-dev 19:13 -!- moctos [~moctos@cpe-107-9-138-59.neo.res.rr.com] has joined #bitcoin-core-dev 19:15 -!- Guest7085 [~ndrst@2a01:4f8:130:53ec::2] has joined #bitcoin-core-dev 19:15 -!- Dyaheon [~Dya@dsl-trebng21-58c183-118.dhcp.inet.fi] has quit [Ping timeout: 260 seconds] 19:15 -!- TheLive1 [~TheLive1@45.76.39.44] has joined #bitcoin-core-dev 19:15 -!- TheLive1 [~TheLive1@45.76.39.44] has quit [Changing host] 19:15 -!- TheLive1 [~TheLive1@unaffiliated/thelive1] has joined #bitcoin-core-dev 19:19 -!- Dyaheon [~Dya@dsl-trebng21-58c183-118.dhcp.inet.fi] has joined #bitcoin-core-dev 19:25 -!- sipa [~pw@2001:19f0:ac01:2fb:5400:ff:fe5b:c3ff] has joined #bitcoin-core-dev 19:35 -!- arubi [~ese168@unaffiliated/ese168] has quit [Ping timeout: 255 seconds] 19:37 -!- arubi [~ese168@unaffiliated/ese168] has joined #bitcoin-core-dev 19:39 -!- lifeofguenter [~lifeofgue@bnc.pro.to.co.ls] has quit [Ping timeout: 260 seconds] 19:40 -!- lifeofguenter [~lifeofgue@bnc.pro.to.co.ls] has joined #bitcoin-core-dev 20:14 -!- wxxs [~chatzilla@184.75.212.76] has quit [Remote host closed the connection] 20:16 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-dbxamxkhehjiygrz] has joined #bitcoin-core-dev 20:19 -!- tknp [~tknp@unaffiliated/tknp] has joined #bitcoin-core-dev 20:29 -!- RealM9 [~androirc@balticom-142-92-236.balticom.lv] has quit [Remote host closed the connection] 20:44 -!- RealM9 [~androirc@balticom-142-92-236.balticom.lv] has joined #bitcoin-core-dev 21:04 -!- hsmiths [uid95325@gateway/web/irccloud.com/x-ugtvednrgxpztmnt] has joined #bitcoin-core-dev 21:32 -!- RealM9 [~androirc@balticom-142-92-236.balticom.lv] has quit [Quit: bb nibbas] 21:32 -!- Emcy_ [~MC@unaffiliated/emcy] has quit [Read error: Connection reset by peer] 21:38 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 21:41 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 21:41 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Client Quit] 21:42 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 22:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 22:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 22:23 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ezawbjyaonzzbazx] has joined #bitcoin-core-dev 22:37 -!- Guest7085 is now known as ndrst 22:37 -!- ndrst [~ndrst@2a01:4f8:130:53ec::2] has quit [Changing host] 22:37 -!- ndrst [~ndrst@unaffiliated/ndrst] has joined #bitcoin-core-dev 22:38 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 246 seconds] 23:16 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds] 23:17 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has quit [Ping timeout: 260 seconds] 23:18 -!- zxzzt_ [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 260 seconds] 23:18 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 23:19 -!- sdaftuar [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 23:19 -!- sdaftuar [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Changing host] 23:19 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev 23:20 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 23:20 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-dbxamxkhehjiygrz] has quit [Quit: Connection closed for inactivity] 23:22 -!- tknp [~tknp@unaffiliated/tknp] has quit [Quit: tknp] 23:33 -!- Booxie [aede815d@gateway/web/freenode/ip.174.222.129.93] has joined #bitcoin-core-dev 23:34 < Booxie> Hello I'm on the developing repository on github username booxie , profile hidden cuz some1 flagged me on github. I need food please donate money to me at www.paypal.me/Bukoski 23:39 -!- Booxie [aede815d@gateway/web/freenode/ip.174.222.129.93] has quit [Ping timeout: 260 seconds] 23:48 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 23:58 < bitcoin-git> [bitcoin] benma closed pull request #11434: Add m_bantime to Connman options (master...bantime) https://github.com/bitcoin/bitcoin/pull/11434