--- Day changed Thu May 31 2018 00:02 -!- lxer [~lx@ip5f5bd657.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev 00:02 < fanquake> cfields likely to tell us why it can't happen for another few years heh 00:02 < Randolf> I'm using Ubuntu 18.04 LTS on some systems already. Might it have a more updated compiler? Or is it the same as 16.04? 00:04 <@wumpus> fanquake: cfields and me take turns at being bad cop 00:05 <@wumpus> Randolf: 16.04 has "gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609", 18.04 has "gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0" 00:05 <@wumpus> FreeBSD 11.1 has "FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)" that seems like more of a problem 00:06 <@wumpus> OpenBSD 5.2 too "OpenBSD clang version 4.0.0 (tags/RELEASE_400/final) (based on LLVM 4.0.0)". What is it with BSDs and their clang4 obessesion. 00:08 < sipa> clang4 has c++14 00:08 <@wumpus> wumpus: gcc 5 or clang 3.4 ohh 00:08 <@wumpus> right. 00:08 < sipa> also, fwiw, our code compiles with c++14 without changes (haven't tested) 00:08 <@wumpus> c++14 is consistently older, version-wise, than I expect 00:09 < sipa> so c++11 took ages after standardization before it was available in compilers 00:09 < sipa> c++14 was a small change, and pretty much implemented before the spec was published 00:11 <@wumpus> it shows 00:11 < sipa> 18 months between c++11 published and gcc fully supporting it 00:12 < sipa> 4 months between c++14 published and gcc fully supporting it 00:12 < sipa> c++17 will take longer again (it's already 5 months, and gcc only has experimental support) 00:16 -!- CubicEar_ [~cubiceart@2600:100f:b001:e240:f1af:2cf4:51b:c21] has joined #bitcoin-core-dev 00:16 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer] 00:16 -!- CubicEar_ [~cubiceart@2600:100f:b001:e240:f1af:2cf4:51b:c21] has quit [Remote host closed the connection] 00:16 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 00:20 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Client Quit] 00:23 < fanquake> Decent speedups in #13309. Few ACKs if you want to take a look wumpus 00:23 < gribble> https://github.com/bitcoin/bitcoin/issues/13309 | Directly operate with CMutableTransaction in SignSignature by martinus · Pull Request #13309 · bitcoin/bitcoin · GitHub 00:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 00:31 <@wumpus> fanquake: yes I need to have a look at that one, it seemed quite tricky,but agree it's probably worth it 00:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds] 00:32 <@wumpus> sipa: running c++14 experiments, on clang 7.0 the build passes with -std=c++14, no changes necessary 00:34 < fanquake> At least we'd only have to bump Clang to 3.4 (from 3.3) for ++14 support 00:35 <@wumpus> (that's my straight-from-git build environment though, let's wait for openbsd clang4 results...) 00:39 -!- LeMiner [~LeMiner@unaffiliated/leminer] has joined #bitcoin-core-dev 00:47 <@wumpus> (passed too) 00:49 <@wumpus> fanquake: I wonder if we can get anyone to test with clang/llvm 3.4 00:49 <@wumpus> I don't seem to have that installed anywhere 00:50 <@wumpus> in an case, this is the trivial build system patch for building with c++14: https://gist.github.com/laanwj/e84d17412a5811ef4b7bd7512218c01a 00:52 <@wumpus> building with c++17 does give some errors, last time I tried, although if that support is still experimental it's not clear that should be our problem or the compiler's 00:52 < sipa> configure or compile errors? 00:53 < sipa> that CXX version script does not support c++17 yet 00:53 <@wumpus> I had updated that - yes, compile errors 00:59 <@wumpus> some fairly silly stuff, I can't find the patch stack right now 01:02 < sipa> well, we're not going to adopt c++17 so who cares 01:03 <@wumpus> exactly 01:03 < fanquake> fwiw That's the first error error I see passing in c++17 https://gist.github.com/fanquake/2342c585c43f945428d0f20eb1d8a1d6 01:04 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 01:05 <@wumpus> that random_shuffle wasn't even there yet when experimented with c++17 last year 01:06 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 01:06 < fanquake> Looks like it was deprecated, in c++ 14, must have been removed in ++17 01:07 <@wumpus> tfw you learn that a function exists in the C++ library and it's already deprecated 01:12 <@wumpus> at least it's not as bad as with rust 01:15 <@wumpus> (or *cringe* swift... nice that you just wrote this software, here's a new major release of your language, you can basically just throw away everything and start over) 01:16 < fanquake> wumpus your patch + stdcxx m4 changes all that was required to make check with c++14 01:16 -!- LeMiner [~LeMiner@unaffiliated/leminer] has quit [Read error: Connection reset by peer] 01:17 < fanquake> Don't bring up swift here, btc dev is one place I don't have to deal with that :p 01:17 <@wumpus> sorry 01:18 <@wumpus> just trying to put c++ in perspective, that the process they follow for changes is quite reasonable 01:21 < fanquake> Reasonable, but is it really "disruptive/10x/webscale" enough? 01:22 < sipa> we need an deep learning blockchain in the cloud 01:23 <@wumpus> fanquake: hah, the kind of words that make you know for sure you want to avoid something 01:24 <@wumpus> machine learning developments are going too fast, we need a block chain to anchor them down and make them less efficient 01:25 < fanquake> They'd just figure out how to escape the blockchain. Probably solve the oracle problem while they are at it. 01:27 <@wumpus> heh, right, just a matter of the right incentives. If they figure out how to escape the blockchain so we can follow :) 01:32 < bitcoin-git> [bitcoin] practicalswift opened pull request #13355: Fix "gmake check" under OpenBSD 6.3 (probably *BSD): Avoid using GNU grep specific regexp handling (master...openbsd-gmake-check) https://github.com/bitcoin/bitcoin/pull/13355 01:34 <@wumpus> fanquake: unless I've somehow messed up my methodology, #13309 takes test_bitcoin from 1m10.831s to 0m39.323s here 01:34 < gribble> https://github.com/bitcoin/bitcoin/issues/13309 | Directly operate with CMutableTransaction in SignSignature by martinus · Pull Request #13309 · bitcoin/bitcoin · GitHub 01:34 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 01:34 < fanquake> wumpus isn't that what is expected? 01:35 < fanquake> Or just more speed up than you thought? 01:35 <@wumpus> it's more than I thought 01:35 < sipa> "sorry, NACK, this makes the tests too fast" 01:36 <@wumpus> exactly :) 01:37 <@wumpus> just like with cryptography, tests need to be slow to convince it's being done properly 01:40 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/472fe8a2ce9f...36fc8052f62b 01:40 < bitcoin-git> bitcoin/master 6b8b63a Martin Ankerl: Generic TransactionSignatureCreator works with both CTransaction and CMutableTransaction... 01:40 < bitcoin-git> bitcoin/master 36fc805 Wladimir J. van der Laan: Merge #13309: Directly operate with CMutableTransaction in SignSignature... 01:41 < bitcoin-git> [bitcoin] laanwj closed pull request #13309: Directly operate with CMutableTransaction in SignSignature (master...SignSignature-with-CMutableTransaction) https://github.com/bitcoin/bitcoin/pull/13309 01:47 < fanquake> Opened #13356 for some C++14 thoughts. Will add some more info shortly. 01:47 < gribble> https://github.com/bitcoin/bitcoin/issues/13356 | RFC: C++14 Requirement · Issue #13356 · bitcoin/bitcoin · GitHub 01:51 -!- b [2d40a1f0@gateway/web/freenode/ip.45.64.161.240] has joined #bitcoin-core-dev 01:51 -!- b is now known as Guest47199 01:51 <@wumpus> fanquake: awesome! 01:52 -!- Guest47199 [2d40a1f0@gateway/web/freenode/ip.45.64.161.240] has quit [Client Quit] 01:55 <@wumpus> it's really useful to create tracking issues for things like this 01:57 < fanquake> Yes, easy for useful info to get lost in multiple different discussions 01:58 < fanquake> pkg_add autoconf 01:58 <@wumpus> looks like wikipedia has an ok overview of what is new in c++14, maybe useful to link too: https://en.wikipedia.org/wiki/C%2B%2B14, and mention that we already use the shared mutex 01:59 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 02:03 < fanquake> Added. Will link to code soon. 02:09 <@wumpus> I vaguely remember there are plans to use more shared mutexes in more places, from BlueMatt probably 02:10 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 02:12 <@wumpus> "Tuple addressing via type" some of these have a high risk of obfuscating code when used irresponsibly 02:17 <@wumpus> std::exchange and std::make_unique seem nice, small things 02:17 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/36fc8052f62b...24f70118414f 02:17 < bitcoin-git> bitcoin/master 493a166 Wladimir J. van der Laan: bench: Don't return a bool from main... 02:17 < bitcoin-git> bitcoin/master 24f7011 MarcoFalke: Merge #13349: bench: Don't return a bool from main... 02:18 -!- rex4539 [~textual@2a02:587:3501:ea00:d0d5:81ca:db7f:2cf9] has quit [Quit: Textual IRC Client: www.textualapp.com] 02:18 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #13349: bench: Don't return a bool from main (master...2017_05_bench_warning) https://github.com/bitcoin/bitcoin/pull/13349 02:19 -!- ExtraCrispy [~ExtraCris@185.9.18.150] has joined #bitcoin-core-dev 02:20 -!- rex4539 [~textual@2a02:587:3501:ea00:d01a:8a7c:8460:17d8] has joined #bitcoin-core-dev 02:23 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/24f70118414f...87a9d03c0c1e 02:23 < bitcoin-git> bitcoin/master fa2d83e MarcoFalke: travis: Skip cache for lint stage 02:23 < bitcoin-git> bitcoin/master 87a9d03 MarcoFalke: Merge #13347: travis: Skip cache for lint stage... 02:24 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #13347: travis: Skip cache for lint stage (master...Mf1806-travisLintNoCache) https://github.com/bitcoin/bitcoin/pull/13347 02:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:32 -!- BCBot_ [~BCBot@46.101.246.115] has quit [Remote host closed the connection] 02:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds] 02:33 -!- BCBot [~BCBot@46.101.246.115] has joined #bitcoin-core-dev 03:10 -!- JackH [~laptop@79-73-185-29.dynamic.dsl.as9105.com] has quit [Quit: Leaving] 03:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 03:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:42 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 03:43 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 03:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 03:50 -!- drizztbsd is now known as timothy 03:59 -!- Krellan [~Krellan@2601:640:4000:9258:ec29:b128:9f50:93bd] has quit [Read error: Connection reset by peer] 04:00 -!- Krellan [~Krellan@2601:640:4000:9258:e55b:614d:5741:5b9d] has joined #bitcoin-core-dev 04:10 -!- Randolf [~randolf@96.53.47.38] has quit [Ping timeout: 240 seconds] 04:11 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev 04:16 < bitcoin-git> [bitcoin] jl2012 opened pull request #13357: Accurately determine the use of SIGHASH_SINGLE in signing (master...signsingle) https://github.com/bitcoin/bitcoin/pull/13357 04:24 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 04:24 -!- jchysk [~yo@63.147.87.170] has quit [Ping timeout: 248 seconds] 04:37 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 04:37 -!- jchysk [~yo@63.147.87.170] has joined #bitcoin-core-dev 04:49 -!- keymone [~keymone@ip1f13761c.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev 04:56 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 260 seconds] 05:07 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev 05:08 -!- zivl [~zivl@2601:19a:837f:e4e1:9048:ca91:b1ac:55f9] has joined #bitcoin-core-dev 05:12 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 244 seconds] 05:16 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 256 seconds] 05:20 -!- rex4539 [~textual@2a02:587:3501:ea00:d01a:8a7c:8460:17d8] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 05:56 -!- frog_ [~frog@103.198.138.179] has joined #bitcoin-core-dev 06:03 -!- zautomata [~zautomata@41.232.215.223] has joined #bitcoin-core-dev 06:04 -!- zautomata [~zautomata@41.232.215.223] has quit [Changing host] 06:04 -!- zautomata [~zautomata@unaffiliated/zautomata] has joined #bitcoin-core-dev 06:08 -!- Krellan [~Krellan@2601:640:4000:9258:e55b:614d:5741:5b9d] has quit [Read error: Connection reset by peer] 06:09 -!- Krellan [~Krellan@2601:640:4000:9258:e55b:614d:5741:5b9d] has joined #bitcoin-core-dev 06:14 -!- jtimon [~quassel@226.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 06:14 -!- frog_ [~frog@103.198.138.179] has quit [Quit: Leaving] 06:18 -!- laurentmt [~Thunderbi@185.94.189.189] has joined #bitcoin-core-dev 06:25 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 06:26 -!- laurentmt [~Thunderbi@185.94.189.189] has quit [Quit: laurentmt] 06:31 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 06:42 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 276 seconds] 06:43 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [] 06:55 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 07:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 07:18 < MarcoFalke> jonasschnelli: I can see my review on https://github.com/bitcoin/bitcoin/pull/12196/files#diff-2497f9b95fc934233daa9cb4a45a9df2 07:23 -!- m8tion [~Agence@abo-134-110-68.mrs.modulonet.fr] has joined #bitcoin-core-dev 07:44 -!- Sinclair6 [sinclair6@gateway/vpn/privateinternetaccess/sinclair6] has joined #bitcoin-core-dev 07:54 -!- sunitram [~yaaic@91-114-168-240.adsl.highway.telekom.at] has joined #bitcoin-core-dev 07:59 -!- sunitram [~yaaic@91-114-168-240.adsl.highway.telekom.at] has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org] 07:59 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 245 seconds] 08:06 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev 08:08 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #13359: wallet: Directly operate with CMutableTransaction (master...Mf1806-avoidTxConstuctor) https://github.com/bitcoin/bitcoin/pull/13359 08:13 < bitcoin-git> [bitcoin] jl2012 opened pull request #13360: [Policy] Reject SIGHASH_SINGLE with output out of bound (master...insecure_single) https://github.com/bitcoin/bitcoin/pull/13360 08:16 -!- Krellan [~Krellan@2601:640:4000:9258:e55b:614d:5741:5b9d] has quit [Read error: Connection reset by peer] 08:17 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 244 seconds] 08:17 -!- Krellan [~Krellan@2601:640:4000:9258:e55b:614d:5741:5b9d] has joined #bitcoin-core-dev 08:30 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev 08:32 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 08:32 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 256 seconds] 08:36 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 08:40 < Chris_Stewart_5> can miners set their own sequence number in their coinbase input? 08:41 -!- timothy [~tredaelli@redhat/timothy] has quit [Ping timeout: 240 seconds] 08:42 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 08:43 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 244 seconds] 08:46 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 08:48 < echeveria> Chris_Stewart_5: yes, there's no restriction on that. 08:49 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 08:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds] 08:53 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev 09:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 09:01 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 09:05 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 244 seconds] 09:06 <@wumpus> Chris_Stewart_5: there's no requirement on the coinbase data except for BIP34 afaik 09:07 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 09:08 -!- laurentmt [~Thunderbi@185.94.189.189] has joined #bitcoin-core-dev 09:08 < Chris_Stewart_5> Thanks guys 09:10 < sipa> also the length of the coinbase scriptSig is between 2 and 100 bytes 09:10 < sipa> that's also a consensus rule; no idea why it's there 09:11 -!- nekotribal [~nekotriba@host-89-230-96-42.dynamic.mm.pl] has quit [Remote host closed the connection] 09:11 -!- zivl [~zivl@2601:19a:837f:e4e1:9048:ca91:b1ac:55f9] has quit [Ping timeout: 260 seconds] 09:12 <@wumpus> oh! 09:12 -!- rex4539 [~textual@2a02:587:3501:ea00:48af:5cc6:d36f:2b10] has joined #bitcoin-core-dev 09:13 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev 09:16 -!- jhfrontz1 [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has quit [Quit: Leaving.] 09:17 < echeveria> sipa isn't it more than 2 now with BIP30? 09:17 < TheCharlatan> How is glibc, for example libm.so, back-compatibility for a normal 64bit Linux binary achieved, if the gitian builder is updated to Ubuntu 18.04? A standard 64 bit static build on 18.04 for example does not seem compatible with anything below. 09:19 < cfields> TheCharlatan: symbols must be added for glibc funtions introduced since our minimum version 09:24 < sipa> echeveria: you mean BIP34 i assume; yes, except for the first few blocks 09:25 <@wumpus> TheCharlatan: indeed, see src/compat/glibc_compat.cpp 09:26 <@wumpus> it's a matter of not using symbols that have been defined since, we have a symbol checker script under contrib/devtools to check that 09:26 <@wumpus> (glibc symbols are versioned) 09:29 -!- nekotribal [~nekotriba@host-89-230-96-42.dynamic.mm.pl] has joined #bitcoin-core-dev 09:31 -!- ExtraCrispy [~ExtraCris@185.9.18.150] has quit [Remote host closed the connection] 09:34 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 268 seconds] 09:35 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 240 seconds] 09:41 < TheCharlatan> so future gitian Bionic builds will all have to be configure with --enable-glibc-back-compat ? 09:41 -!- dcousens [~dcousens@110.140.174.10] has quit [Ping timeout: 248 seconds] 09:42 -!- dcousens [~dcousens@110.140.174.10] has joined #bitcoin-core-dev 09:44 -!- Krellan [~Krellan@2601:640:4000:9258:e55b:614d:5741:5b9d] has quit [Remote host closed the connection] 09:54 -!- Randolf [~randolf@S0106c8fb26572f40.vc.shawcable.net] has joined #bitcoin-core-dev 09:55 <@wumpus> all linux gitian builds have always been built with thta 09:56 <@wumpus> (well, to be correct, since 0.9.2) 09:56 -!- jhfrontz [~Adium@165.171.225.5] has joined #bitcoin-core-dev 10:00 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev 10:05 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 268 seconds] 10:15 <@wumpus> the gitian linux build even calls the symbol checker and fails if there are unexpected symbols 10:16 <@wumpus> it should be pretty fool-proof 10:24 -!- jtimon [~quassel@226.110.132.37.dynamic.jazztel.es] has quit [Ping timeout: 256 seconds] 10:25 -!- brianhoffman [~brianhoff@pool-173-66-26-200.washdc.fios.verizon.net] has joined #bitcoin-core-dev 10:27 -!- goatpig [56f75200@gateway/web/freenode/ip.86.247.82.0] has joined #bitcoin-core-dev 10:30 -!- m8tion [~Agence@abo-134-110-68.mrs.modulonet.fr] has quit [Read error: Connection reset by peer] 10:38 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 10:41 -!- jhfrontz [~Adium@165.171.225.5] has quit [Quit: Leaving.] 10:45 -!- jhfrontz [~Adium@165.171.225.5] has joined #bitcoin-core-dev 11:08 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev 11:08 -!- mode/#bitcoin-core-dev [-b *!~arowser@45.32.248.113] by wumpus 11:09 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 11:10 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev 11:10 -!- zivl [~zivl@2601:19a:837f:e4e1:647c:7cb5:6008:e2ce] has joined #bitcoin-core-dev 11:12 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 11:13 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 11:13 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 11:14 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Remote host closed the connection] 11:14 < jonasschnelli> Thanks MarcoFalke, found it 11:16 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 11:16 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev 11:16 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 11:18 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 11:18 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 11:20 -!- jhfrontz [~Adium@165.171.225.5] has quit [Quit: Leaving.] 11:21 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 11:21 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 11:23 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 11:24 -!- arowser_ [~arowser@45.32.248.113] has joined #bitcoin-core-dev 11:26 -!- arowser_ [~arowser@45.32.248.113] has quit [Remote host closed the connection] 11:26 -!- mode/#bitcoin-core-dev [+b *!~arowser@45.32.248.113] by wumpus 11:32 -!- Randolf [~randolf@S0106c8fb26572f40.vc.shawcable.net] has quit [Ping timeout: 244 seconds] 11:38 -!- jhfrontz [~Adium@165.171.225.5] has joined #bitcoin-core-dev 11:38 -!- Randolf [~randolf@S0106c8fb26572f40.vc.shawcable.net] has joined #bitcoin-core-dev 11:42 -!- promag [~promag@83.223.250.124] has joined #bitcoin-core-dev 11:42 -!- nmnkgl [~nmnkgl@c-73-189-35-88.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 11:47 -!- Randolf [~randolf@S0106c8fb26572f40.vc.shawcable.net] has quit [Ping timeout: 256 seconds] 11:55 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev 12:01 * jonasschnelli *cough* 12:01 < luke-jr> don't die on us, jonasschnelli 12:01 * sipa *sneeze* 12:02 < jonasschnelli> heh.. meeting? 12:02 <@wumpus> #startmeeting 12:02 < lightningbot> Meeting started Thu May 31 19:02:19 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:02 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:02 < jonasschnelli> hi 12:02 < promag> hi 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 mi 12:02 <@wumpus> chagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator 12:03 <@wumpus> proposed topics? 12:04 < sipa> c++14 12:04 < kanzure> hi. 12:05 < sipa> high-priority prs 12:05 < MarcoFalke> Is the rc1 out with an email? 12:05 < cfields> MarcoFalke: yes 12:05 <@wumpus> I have one of my own: new "addr" P2P message to support 256-bit addresses, for TorV3 and I2P 12:05 <@wumpus> yes, rc1 is out with email to bitcoin-core-dev mailing list 12:06 <@wumpus> #topic High priority for review 12:06 < sipa> i'd like #13026 on the list 12:06 < gribble> https://github.com/bitcoin/bitcoin/issues/13026 | Fix include comment in src/interfaces/wallet.h by promag · Pull Request #13026 · bitcoin/bitcoin · GitHub 12:06 < sipa> eh 12:06 < sipa> #13062 12:06 < gribble> https://github.com/bitcoin/bitcoin/issues/13062 | Make script interpreter independent from storage type CScript by sipa · Pull Request #13062 · bitcoin/bitcoin · GitHub 12:06 <@wumpus> https://github.com/bitcoin/bitcoin/projects/8 12:07 <@wumpus> sipa: added 12:07 < sipa> dank 12:07 < jonasschnelli> +e 12:07 <@wumpus> anything/anyone else? 12:07 < promag> #13111 12:07 < gribble> https://github.com/bitcoin/bitcoin/issues/13111 | Add unloadwallet RPC by promag · Pull Request #13111 · bitcoin/bitcoin · GitHub 12:07 < promag> please 12:08 <@wumpus> ok 12:08 < promag> 1 per developer right? 12:08 < luke-jr> I'm trying to rebase rwconf today 12:08 <@wumpus> promag: yes 12:08 < luke-jr> that seems like it's desirable, so we can get the GUI pruning in 12:08 < jonasschnelli> Thanks luke-jr 12:08 <@wumpus> luke-jr: nice 12:09 < luke-jr> #11082 IIRC 12:09 < gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub 12:09 -!- Nun [ac754c6e@gateway/web/freenode/ip.172.117.76.110] has joined #bitcoin-core-dev 12:09 < jonasschnelli> #13058 is a quick review (in high prio), has already two tested ACKs. Plz anyone. 12:09 < gribble> https://github.com/bitcoin/bitcoin/issues/13058 | [wallet] `createwallet` RPC - create new wallet at runtime by jnewbery · Pull Request #13058 · bitcoin/bitcoin · GitHub 12:09 < jonasschnelli> This opens the door for a lot of things 12:10 -!- Kvaciral [~Kvaciral@5ED6B9A2.cm-7-7c.dynamic.ziggo.nl] has joined #bitcoin-core-dev 12:10 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev 12:10 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 268 seconds] 12:11 <@wumpus> luke-jr: yes, that one needs rebase 12:11 -!- Nun [ac754c6e@gateway/web/freenode/ip.172.117.76.110] has quit [Client Quit] 12:12 <@wumpus> but added, also jnewbery's 13058 12:12 <@wumpus> I think that's enough for this week :) 12:12 <@wumpus> #topic C++14 (sipa) 12:12 < jonasschnelli> 13058 is already there.. just wanted to make people aware that its a easy review 12:13 < sipa> given that travis, and soon gitian, will be built on bionic, that may open the door to using more modern compilers, which support c++14 12:13 -!- wintercooled [56a36ec2@gateway/web/freenode/ip.86.163.110.194] has joined #bitcoin-core-dev 12:13 < sipa> gcc 5 and clang 3.4 fully implement it 12:14 < sipa> debian stable and ubuntu 16.04+ have gcc 5 - though as luke-jr points out, RHEL does not yet 12:14 -!- promag [~promag@83.223.250.124] has quit [Read error: Connection reset by peer] 12:14 <@wumpus> ref: #13356, as well as earlier discussion on IRC today 12:14 < gribble> https://github.com/bitcoin/bitcoin/issues/13356 | RFC: C++14 Requirement · Issue #13356 · bitcoin/bitcoin · GitHub 12:14 < gmaxwell> Any idea when RHEL will? 12:14 < sipa> RHEL 8 will ship with GCC 7 12:14 < sipa> but when...? 12:14 < gmaxwell> I mean we basically have a half year lag on major versions... 12:14 <@wumpus> yes so this would be 0.18 at soonest 12:15 < MarcoFalke> Agree with wumpus 12:15 < sipa> yeah, true - which would be released... march 2019? 12:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 12:15 <@wumpus> sipa: yes. that's the 0.17 planned release date + 6 months 12:16 < sipa> by that time probably most distro limitation concerns will have disappeared 12:16 < gmaxwell> also, whats in RHEL7 ? does it support enough of C++14 to cover the features we want? 12:16 < sipa> gmaxwell: RHEL7 has gcc 4.9... which barely supports c++11 12:17 < cfields> looks like 4.9 doesn't have relaxed constexpr, which is one of the big features 12:17 -!- retrop99 [~retrop99@cpc98334-croy25-2-0-cust202.19-2.cable.virginm.net] has joined #bitcoin-core-dev 12:17 < cfields> generally though, +1 for c++14 as soon as reasonably possible. It's mostly a cleanup of c++11, and used for development of lots of dev tools themselves. Also the default now for gcc/clang. 12:17 <@wumpus> yep 12:17 -!- promag_ [~promag@188.250.246.197] has joined #bitcoin-core-dev 12:18 < ajtowns[m]> Ugh, did lightningbot die on me? 12:18 <@wumpus> ajtowns[m]: don't die on us during the meeting! 12:19 < luke-jr> wumpus: (re rwconf, I'll ping you after I rebase it for the flag) 12:19 <@wumpus> ok, so I think everyone agrees C++14 is a good thing for 0.18 (given RHEL at the time)? 12:20 < gmaxwell> I think we saw with the move to C++11 that basically people seemed to fall into two groups: No problem (e.g. they'd upgrade or use binaryies compiled on another system), or completely unreasonable and basically looking for an excuse to not run newer software. 12:20 < luke-jr> gmaxwell: well, that was after waiting for C++11 to be reasonably available ofc 12:20 < ajtowns[m]> No seems like matrix is just not seeing everything so flowing the meeting on my phone will be hopeless :( 12:20 <@wumpus> yes, I was especially worried about debian stable, but apparently that's no problem this time 12:21 < luke-jr> btw, should we concern with CentOS or other RHEL respins? 12:21 < luke-jr> if RHEL 8 is just barely out, they might lag.. 12:21 < gmaxwell> luke-jr: yes but even where it wasn't most people just solved it with binaries built on another system. 12:21 < cfields> gmaxwell: the second group also included many who refused to _run_ a c++11 binary, despite -static-libstdc++ negating abi issues. 12:21 <@wumpus> debian stable has gcc *6* which is very good 12:22 < luke-jr> gmaxwell: I'm not sure that's viable for GUI 12:22 < BlueMatt> wait, when does previous rhel stop getting support? 12:22 <@wumpus> 08:49 < sipa> https://packages.debian.org/stretch/gcc-6 12:22 < luke-jr> BlueMatt: a long long time AFAIK 12:22 < BlueMatt> I dont think we can force people to upgrade, though I also doubt we have almost any rhel users 12:22 < luke-jr> BlueMatt: even RHEL 5 from 2007 still has support 12:23 < BlueMatt> how long is opensuse supported? 12:23 <@wumpus> luke-jr: -static-libstdc++ works fine if you link qt statically as well. 12:23 < BlueMatt> we may actually have opensuse users 12:23 <@wumpus> luke-jr: (which is the default for depends builds) 12:23 < luke-jr> wumpus: but that breaks platform plugins? 12:23 <@wumpus> luke-jr: who cares 12:23 <@wumpus> luke-jr: we already ignore this, with building gitian qt executables statically against qt 12:24 < luke-jr> but people shouldn't be using those ideally 12:24 < luke-jr> BlueMatt: RHEL 5 support ends in 2020 12:24 < gmaxwell> when we made the c++11 upgrade anyone I encountered using old RHEL just used binaries built elsewhere. 12:24 <@wumpus> luke-jr: and anyhow the only major user of that was ubuntu unity, which supported qt4 well only... 12:24 < sipa> RHEL 7 support is until 2024 12:24 < gmaxwell> The only people that were an issue were running two version old outdated debian stable, and just refused to deal with it. 12:25 < luke-jr> I don't think it's realistic to wait on "oldest supported RHEL" 12:25 < BlueMatt> gmaxwell: lol sounds like debian users 12:25 <@wumpus> gmaxwell: I doubt c++14 will be more of a problem to them than c++11 12:25 < BlueMatt> luke-jr: no, I dont think it is either, was just asking 12:25 <@wumpus> anyhow this is almost a year away 12:25 < sipa> there are rumors about RHEL 8 beta this month 12:25 < BlueMatt> is supported-ubuntu or supported-debian still not gonna support c++14 for 0.18? 12:25 < gmaxwell> So basically what I was arguing was that for C++11 it seemed most people that had isuses were fine using binaries built elsewhere (either by us or elsewhere)... so it's fine. It just needs to be good enough to not exclude developers. 12:25 < BlueMatt> it does seem a bit premature imho 12:26 <@wumpus> clang4 is the most common on BSDs, and it supports C++14 already now 12:26 < BlueMatt> do we mostly just want it for shared mutex? 12:26 < BlueMatt> seems like we can do a mutex-wrapped shared_mutex pretty easily? 12:26 < luke-jr> gmaxwell: I don't agree with the conclusion. If we relax the criteria, we may (hopefully!) find users who didn't have a problem now do 12:26 <@wumpus> I was really surprised about that and that caused me to drop all my reservations about it 12:27 * cfields wants generic lambdas and relaxed constexpr 12:28 < cfields> iirc there are also several handy container cleanups. Like try_emplace(). 12:28 <@wumpus> BlueMatt: we can use shared mutex right now through boost - optional c++14 support would be a possibility too, but sipa was not sure it's worth it 12:29 < luke-jr> something to consider if it really is worth it, we could release 0.18.0 requiring it, and then if there's trouble, a 0.18.1 not needing it 12:29 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 260 seconds] 12:29 < sipa> yeah, we're not going to write code where one version uses a generic lambda, and then have a longer additional version for pre-c++14 systems 12:29 < luke-jr> it's not a big deal if people can't update right away.. 12:29 <@wumpus> so we can just move this to 0.19 12:29 < morcos> another 10 months seems long enough to me... we can't always be all things to all people 12:29 <@wumpus> if 0.18 is controversial. 12:29 < sipa> how about we see after 0.17 branches off 12:29 <@wumpus> yes 12:29 < sipa> or even later in the 0.18 cycle 12:30 <@wumpus> that was my proposal too, let's make it depend on RHEL 12:30 < BlueMatt> yea 12:30 < BlueMatt> agreed 12:30 < luke-jr> I expect it won't be controversial 12:30 < sipa> there's nothing we can decide here right now - just bringing up potential issues is good in advance 12:30 < luke-jr> we're almost there already 12:30 < BlueMatt> well I dunno about depending on rhel, certainly if there's no version of rhel that supports c++14 we shoudlnt do it, but its more than that 12:30 <@wumpus> in any case I tried building with -std=c++14 on various platforms today, works without any compile issues. 12:30 < BlueMatt> its also a question of people running like one-version-back distro X 12:30 <@wumpus> so there's really nothing to be done there 12:30 < BlueMatt> and if that breaks that'd be bad 12:30 < BlueMatt> cause shitloads of people do that 12:31 < luke-jr> BlueMatt: trusty isn't just one version back, is it? 12:31 <@wumpus> with that reasoning, we shouldn't even require c++11 yet 12:31 < sipa> last *two* ubuntu LTSs are fine 12:31 < BlueMatt> I dont really care about tursty anymore, it was released in fucking 2014 12:31 <@wumpus> there's no end to that - why not rewrite bitcoin core in C89 while you're at it :) 12:31 < BlueMatt> it would be nice to support xenial 12:31 <@wumpus> it supports xenial 12:32 < BlueMatt> I mean I was mostly worried about debian anyway 12:32 <@wumpus> xenial is gcc 5.4.0 12:32 < BlueMatt> but, yea 12:32 < sipa> debian oldstable is 4.8 12:32 < BlueMatt> when does debian oldstable stop? 12:32 < BlueMatt> like 1.5 years or something? 12:32 < sipa> when there is a new stable 12:32 < luke-jr> BlueMatt: Debian has an oldoldstable now :P 12:32 <@wumpus> I even *tried* building c++14 bitcoin core on xenial today, it worked 12:32 <@wumpus> let alone in march 2019... 12:32 < BlueMatt> luke-jr: yea, ok, fuck oldoldstable 12:33 < luke-jr> :D 12:33 < BlueMatt> sipa: yea, that was my question 12:33 < sipa> anyway, next topic? 12:33 < BlueMatt> mid-2019 12:33 < BlueMatt> which would imply like 0.19 12:33 < BlueMatt> depending on timeline 12:34 < sipa> i'm fine with not being able to *build* on debian oldstable 12:34 <@wumpus> yes... 12:34 < BlueMatt> I'm not a fan of it, unless we have a super huge win we want right away, though if its like "debian oldstable will be eol in like a month after release" its a rather moot point 12:34 < cfields> any update on github unicorns? I don't remember seeing any this week, though something about my browser must make them rare for me. 12:34 < sipa> cfields: they're fixed 12:35 < cfields> woohoo! 12:35 <@wumpus> github unicorns seem to be fixed 12:35 <@wumpus> haven't encountered any this week, I think 12:35 < sipa> don't remember who commented about it here, but they received a mail from github saying they did some software updated that added caching 12:35 < jonasschnelli> Yes. They wrote back that they have deployed a fix 12:35 < sipa> ah, it was mr schnelli 12:35 <@wumpus> cool. 12:36 < cfields> jonasschnelli: thanks for nagging :) 12:36 < sipa> wumpus: you had a topic? 12:36 <@wumpus> #topic new "addr" P2P message to support 256-bit addresses (wumpus) 12:36 <@wumpus> so I'd like to work on this 12:36 < sipa> concept ack 12:36 < BlueMatt> for new-style tor services, I presume? 12:36 < luke-jr> is 256- bit enough? 12:36 < BlueMatt> sounds like a good idea to me 12:37 < roasbeef> wumpus: +1 12:37 <@wumpus> first a BIP, of course. Anything special I should take into account? my idea would be to introduce a new ADDR message with more space for the network address, simply. 12:37 <@wumpus> this is to support I2P 12:37 <@wumpus> and the new TorV3 hidden services 12:37 < luke-jr> 256+8 seems better for future-proofing (8 bits to select a network schema) 12:37 <@wumpus> yes, both use 256 bit 12:37 <@wumpus> luke-jr: yes 12:37 <@wumpus> that's my idea, also have a network id 12:37 < sipa> 256 bit + network class byte 12:37 < luke-jr> sgtm 12:37 < BlueMatt> + port? I know they dont need them but other things...who knows? 12:37 < sipa> so we can stop using onioncat embedding in ipv6 12:37 < BlueMatt> I mean whats an extra 4 bytes 12:37 < jonasschnelli> Not sure what plans sipa and gmaxwell may have with authentication.. not sure if that is overlapping with addr 12:37 < BlueMatt> err 2 bytes 12:37 < sipa> jonasschnelli: no overlap 12:38 < roasbeef> idk where bip 151 (and it's auth companion) is at atm, but could also use it to propagate pubkeys as well so initial conn handshake can be fully encrypted 12:38 <@wumpus> BlueMatt: yes, the port should still be there, good point 12:38 < luke-jr> could do a variable length :P 12:38 < jonasschnelli> Yes. I mean what roasbeef just said 12:38 < jonasschnelli> *meant 12:38 < sipa> roasbeef: that seems to defeat the purpose :( 12:38 <@wumpus> roasbeef: should that be gossiped? 12:38 < roasbeef> how so? 12:38 < roasbeef> depends... 12:38 < sipa> that leaks identity 12:38 < sdaftuar> could this overlap with NODE_NETWORK_LIMITED etc to gossip block ranges that nodes might store and serve to the network? 12:38 < cfields> wumpus: any changes to serviceflags logic while you're at it? 12:38 <@wumpus> cfields: no 12:38 < luke-jr> wumpus: please add multi-bit service flags 12:38 <@wumpus> (preferably not) 12:38 < luke-jr> :x 12:38 <@wumpus> I don't want too much scope creep 12:38 < cfields> heh 12:39 < sipa> roasbeef, jonasschnelli: oh! 12:39 < sipa> wait, are you just saying a bit to indicate "this peer supports encryption"? 12:39 < sipa> or rumouring pubkeys? 12:39 <@wumpus> cfields: at least not as in "extend the service flags to arbitrary text" or something like that 12:39 <@wumpus> cfields: if you need some more bits there, sure 12:39 < sipa> (i'm in favor of the first, against the latter) 12:39 < jonasschnelli> sdaftuar: don't we already pass around the service bits? Or can you be more specific about the NODE_NETWORK_LIMITED flag? 12:39 < roasbeef> i was saying rumouring pubkeys 12:39 < sipa> yeah, no 12:39 < roasbeef> how do you stop MiTM otherwise? 12:39 < BlueMatt> roasbeef: nooooo, we dont want to leak identity 12:40 <@wumpus> cfields: the data to be gossiped should be fairly compact, after all 12:40 < sipa> roasbeef: out of band 12:40 < jonasschnelli> roasbeef: manual pairing only for now 12:40 <@wumpus> cfields: but I'm interested in hearing your ideas 12:40 < luke-jr> jonasschnelli: there was an issue with NNL defining the 2-3 bits as having 2^N meanings due to nodes combining the set bits 12:40 < jonasschnelli> ? 12:40 < sipa> roasbeef: most connections don't need MitM protection, as there is no identity of the peer they're connecting yo 12:41 < roasbeef> true, and the ones that do can use an ssh like auth_keys structure i guess 12:41 < luke-jr> might be good to add a node seed of some sort; eg, so we can do a deterministic "don't prune these blocks" 12:41 < sipa> only situations where you're connecting to a friend's peer or a node you run yourself need authentication 12:41 <@wumpus> sdaftuar: seems like something that will get outdated really soon 12:41 < cfields> wumpus: I was just curious as now would be the obvious time to make improvements. Can't really think of anything off the top of my head though. 12:41 < luke-jr> sipa: well, keys can ensure the age of your peers, so the ISP can't MITM *everything* 12:41 <@wumpus> sdaftuar: what you'd want to gossip is block storage policy, not range, I think 12:42 < luke-jr> sipa: eg, if you're on an untrusted wifi, it'd be nice to know you have peers you found at home 12:42 < jimpo> Wouldn't Tor v3 address leak identity? 12:42 <@wumpus> cfields: ok well if you have any ideas, feel free to let me know, but I think there's danger in trying to do too much at once 12:42 < roasbeef> jimpo: no more than tor v2 12:42 <@wumpus> cfields: I really just want to support torv3 and I2P asap :) 12:42 < jonasschnelli> luke-jr: but how could you make sure those peers are trustworthy? They could even sell their auth-key, etc. 12:42 < sdaftuar> wumpus: yes, this is premature but i had imagined that we might store block heights % N or something, and communicate that 12:42 < sipa> jimpo: as much as IP addresses are an identity, yes 12:43 < cfields> wumpus: one potential improvement would be filtering based on specified nets. I don't think we can do that now, can we? 12:43 < luke-jr> jonasschnelli: you can't in any case; it just ensures some wifi access point isn't sybil'ing you 12:43 < jonasschnelli> sdaftuar, wumpus: do we have stats (impossible) how deep pruned peers do prune? 12:43 <@wumpus> cfields: no, I don't think so 12:43 < jimpo> That seems similar to IP + BIP 151 pubkey then? 12:43 < cfields> (obviously we can/do after receipt) 12:43 < sipa> jimpo: the issue is being able to correlate multiple IP addresses belonging to the same node 12:43 -!- jtimon [~quassel@226.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 12:43 < sdaftuar> jonasschnelli: for something like this i think we'd first need a new pruning mode where instead of just keeping the last 2 days of blocks, you keep some fraction of all blocks 12:43 <@wumpus> cfields: clients use some weird heuristic to determine what peers to send AFAIK 12:43 < jimpo> Could BIP 151 blind pubkeys with the hash of the IP/port? 12:44 < luke-jr> sdaftuar: that was my idea with the seed 12:44 < jonasschnelli> jimpo: BIP 151 has no authentication 12:44 < sipa> jimpo: that's one possibility, yes - but even better is a technique that doesn't reveal pubkeys at all 12:44 <@wumpus> issue for this is #2091 12:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 12:44 < gribble> https://github.com/bitcoin/bitcoin/issues/2091 | Binding to multiple anonymous networks (esp. I2P) · Issue #2091 · bitcoin/bitcoin · GitHub 12:45 < cfields> sipa: speaking of which, any updates on the scheme you're scheming? 12:45 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev 12:45 < sipa> cfields: no, sorry 12:45 < cfields> np 12:45 < sipa> jimpo: https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b has some arguments in favor 12:46 < jonasschnelli> however, to not distract, the 256+bit addr proposal should be written and discussion should continued on the ML 12:46 < sipa> agree 12:46 <@wumpus> jonasschnelli: yes 12:46 < sipa> but it's something i've wanted to do since 2012 :) 12:46 <@wumpus> jonasschnelli: I was just asking for ideas. 12:47 <@wumpus> any other topics? 12:47 < jonasschnelli> Maybe a quick dive into seeder hardening? 12:48 <@wumpus> #topic Seeder hardening (jonasschnelli) 12:48 < jonasschnelli> It seems like that most active DNS seeds pass around ABC/BCash peers... 12:48 < jonasschnelli> It's a cat and mouse game... but we could tighten the screws 12:48 < jonasschnelli> By checking for a recent block during crawling (expansive) or avoid protocol version >80000 12:49 < cfields> jonasschnelli: didn't they change magic? 12:49 < jonasschnelli> cfields: not sure,... maybe, but then there are still some zombies around. 12:49 <@wumpus> it's kind of a difficult compromise, on one hand you want a cheap heuristic, on the other hand it should be expensive to work around 12:49 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 244 seconds] 12:49 <@wumpus> having to run a bitcoind on seeder nodes sounds like prohibitively expensive 12:49 < jonasschnelli> But if they are dishonest, they will just serve the correct block to the all-known seeder ips, and cheat with all other IPs 12:50 < jonasschnelli> wumpus: yeah.. I dislike that as well 12:50 < sipa> my seeder node has a bitcoind... i'm more worried about the bandwidth increase from asking for blocks 12:50 < jonasschnelli> Maybe we should just keep an eye on it and start to form some thoughts 12:50 < sipa> asking for headers may be better 12:50 <@wumpus> sipa: good point. 12:50 < sipa> i don't seem to have many ABC nodes 12:50 < jonasschnelli> Yeah. Bandwith... although you could disconnect after the header+a couple of txns 12:51 < sipa> 30 in my top 100k IPs 12:51 <@wumpus> jonasschnelli: but how would you verify, if you don't actually receive the data? 12:51 < sipa> 13 in my top 10k 12:51 <@wumpus> jonasschnelli: also it increases load on the nodes you're probing 12:51 < sipa> 1 in my top 1000 12:52 < jonasschnelli> Okay. Yes. That is a different image... 12:52 < jonasschnelli> Well,.. then nm.. 12:52 <@wumpus> jonasschnelli: the difference is strange 12:53 < jonasschnelli> I need to check my mainnet seed. I played with some options on the testnet seed... there its def. worse 12:53 <@wumpus> jonasschnelli: you should probably check what your configuration differences with sipa are 12:53 < jonasschnelli> Indeed 12:53 < jonasschnelli> or if someone is trying to sybil my crawler. :) 12:54 <@wumpus> hehe, probe through tor :) 12:54 < jonasschnelli> I guess that is the difference... my provider stoped my seeder a couple of times because it tested some invalid IP ranges a lot 12:54 < jonasschnelli> since then I mostly crawl via tor 12:54 <@wumpus> ohh maybe they're sybilling tor exit nodes then 12:55 < jonasschnelli> however, I double check and report back IF it is an issue 12:55 < jonasschnelli> wumpus: or that, yeah. 12:55 <@wumpus> though I somehow doubt that would take the form of ... more ABC nodes 12:55 < cfields> jonasschnelli: you're filtering out non-segwit? 12:56 < jonasschnelli> cfields: I use the standard parameters of an up to date version of sipa seeder... I don't think it filters out non SW peers if a client don't ask for it via x.seed 12:56 < BlueMatt> my seeder has /always/ asked for one block 12:57 < BlueMatt> (but does not need a full node) 12:57 < sipa> BlueMatt: nice 12:57 <@wumpus> BlueMatt: the only reason it would need a node is to ask for a recent one 12:57 < jonasschnelli> BlueMatt: hopefully your not asking for the genesis. :) 12:57 < BlueMatt> wumpus: I mean its an spv client so it does ask for a recent one 12:57 <@wumpus> but asking after the ABC and gold forks it would be ok I guess 12:58 < jonasschnelli> BlueMatt: nice. 12:58 <@wumpus> yes 12:59 < jonasschnelli> cat dnsseed.dump | grep "Bitcoin ABC" | grep " 1 " | wc -l 12:59 < jonasschnelli> 207 ips 12:59 < sipa> and: cat dnsseed.dump | head -n 1000 | grep ABC | wc ? 12:59 < jonasschnelli> 58 762 9526 12:59 < sipa> significantly more than for me 13:00 < sipa> (i have 1 with that command line) 13:00 < jonasschnelli> Strange... just checked... I don't crawl anymore via tor 13:00 < sipa> well, time's up 13:00 <@wumpus> #endmeeting 13:00 < lightningbot> Meeting ended Thu May 31 20:00:20 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:00 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-31-19.02.html 13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-31-19.02.txt 13:00 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-31-19.02.log.html 13:00 < jonasschnelli> however,.. I'll investigate. If sipas seeder "is clean", then I guess its handable. 13:00 <@wumpus> it's really strange 13:01 -!- nmnkgl [~nmnkgl@c-73-189-35-88.hsd1.ca.comcast.net] has quit [] 13:02 < jonasschnelli> Would removing the database and "give-it-a-fresh-start" may help? 13:02 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 13:02 < achow101> can someone help me fix travis for #12136. I can't replicate its failure locally and the log for it makes no sense to me as to why it is failing 13:02 < gribble> https://github.com/bitcoin/bitcoin/issues/12136 | Implement BIP 174 Partially Signed Bitcoin Transactions by achow101 · Pull Request #12136 · bitcoin/bitcoin · GitHub 13:03 < jonasschnelli> doneing.. 13:03 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 13:03 < aj> wumpus: so matrix was managing to show me what you were saying, but nothing from anyone else 13:04 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 13:06 < cfields> achow101: the logs were nuked when the build was restarted. got a copy? 13:06 < achow101> No, but the first error was about TransactionSignatureCreator at sign.cpp:48 13:07 < achow101> it couldn't find TransactionSignatureCreator 13:08 -!- grubles [~grubles@unaffiliated/grubles] has quit [Ping timeout: 240 seconds] 13:09 < achow101> cfields: well all of the builds are still failing, so you have the logs now 13:09 <@wumpus> aj: lol, weird, maybe becuase I have +o? 13:09 < cfields> ah, there we go 13:10 -!- mode/#bitcoin-core-dev [-o wumpus] by ChanServ 13:10 < wumpus> aj: can I be invisible too now? 13:11 < MarcoFalke> achow101: Fails locally for me as well 13:12 < achow101> oh 13:12 < ajtowns[m]> Wumpus: nope your words still cross the ethereal boundaries 13:12 < achow101> MarcoFalke: works fine for me, and it worked fine before the changes I made, and those didn't touch the code that travis says the error is on 13:13 < wumpus> ajtowns[m]: darn! 13:13 < MarcoFalke> achow101: Note that you have to rebase 13:14 < aj> wumpus: promag also makes it through, so you're not totally special fwiw 13:14 < MarcoFalke> This is a merge conflict (silent) 13:14 < MarcoFalke> travis always runs against merge(master, pull) 13:14 < achow101> MarcoFalke: I thought I rebased. maybe I didn't rebase far enough 13:14 < MarcoFalke> heh 13:14 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 13:15 < MarcoFalke> git rebase 36fc8052f62b87b11b0366fefee5f38dc886aefd 13:15 < cfields> achow101: wow, that's a lot of inheritance. Try calling the parent instead of great-grandparent? 13:16 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has joined #bitcoin-core-dev 13:16 < achow101> ok, now I see the problem. 13:17 < achow101> cfields: originall TransactionSignatureCreator was the parent.. 13:17 < achow101> *originally 13:17 < cfields> achow101: I haven't really looked, but could you possibly inherit directly from the interface instead? 13:18 < achow101> cfields: the problem is that someone got rid of TransactionSignatureCreator in master and I hadn't rebased to that 13:18 < cfields> ah, ok 13:25 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev 13:29 -!- Lauda_ [~quassel@unaffiliated/lauda] has quit [Ping timeout: 244 seconds] 13:30 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 13:30 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 13:41 -!- retrop99 [~retrop99@cpc98334-croy25-2-0-cust202.19-2.cable.virginm.net] has quit [Read error: Connection reset by peer] 13:42 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 13:42 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 13:46 < echeveria> 2018-05-31 19:45:07.675057 Potential stale tip detected, will try using extra outbound peer (last tip update: 2128 seconds ago) 13:46 < echeveria> this seems pretty eager 13:47 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 13:47 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 13:47 < wumpus> ok wrote a post on the new addr message discussion: https://github.com/bitcoin/bitcoin/issues/2091#issuecomment-393673952 13:47 < wumpus> echeveria: on the other hand adding an extra outbound peer is not exactly a drastic measure 13:49 < echeveria> true. 14:04 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has quit [] 14:17 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 14:17 -!- promag_ [~promag@188.250.246.197] has quit [Remote host closed the connection] 14:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds] 14:26 -!- wintercooled [56a36ec2@gateway/web/freenode/ip.86.163.110.194] has quit [Ping timeout: 260 seconds] 14:33 < sipa> jonasschnelli: any reasons why the "address/script/xpub/derivation" descriptor can't be a single string? 14:34 < sipa> something like "address:..." or "script:..." or "p2wpkh:xpub..../0-2000" 14:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 14:39 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds] 14:40 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds] 14:47 -!- laurentmt [~Thunderbi@185.94.189.189] has quit [Quit: laurentmt] 15:01 -!- echonaut7 [~echonaut@46.101.192.134] has quit [Remote host closed the connection] 15:01 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev 15:04 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 15:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds] 15:07 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 15:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 15:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 15:28 -!- Joqer [08212189@gateway/web/freenode/ip.8.33.33.137] has joined #bitcoin-core-dev 15:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 15:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 15:37 -!- rex4539 [~textual@2a02:587:3501:ea00:48af:5cc6:d36f:2b10] has quit [Quit: Textual IRC Client: www.textualapp.com] 15:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 15:48 -!- promag [~promag@188.250.246.197] has joined #bitcoin-core-dev 15:49 -!- zivl [~zivl@2601:19a:837f:e4e1:647c:7cb5:6008:e2ce] has quit [Quit: zivl] 15:54 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev 15:57 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds] 16:09 -!- Joqer [08212189@gateway/web/freenode/ip.8.33.33.137] has quit [Quit: Page closed] 16:21 -!- Dizzle [~dizzle@108.171.182.16] has quit [Ping timeout: 260 seconds] 16:28 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 256 seconds] 16:29 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Remote host closed the connection] 16:31 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev 16:33 -!- promag [~promag@188.250.246.197] has quit [Remote host closed the connection] 16:34 -!- lxer [~lx@ip5f5bd657.dynamic.kabel-deutschland.de] has quit [Ping timeout: 240 seconds] 16:37 -!- lxer [~lx@ip5f5bd657.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev 16:37 -!- promag [~promag@188.250.246.197] has joined #bitcoin-core-dev 16:39 -!- promag_ [~promag@188.250.246.197] has joined #bitcoin-core-dev 16:40 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-ejfvwxdknkelaoob] has joined #bitcoin-core-dev 16:42 -!- promag [~promag@188.250.246.197] has quit [Ping timeout: 256 seconds] 16:43 -!- promag_ [~promag@188.250.246.197] has quit [Remote host closed the connection] 16:51 -!- murrayn [~dafuq@unaffiliated/murrayn] has quit [Ping timeout: 244 seconds] 16:52 -!- murrayn [~dafuq@unaffiliated/murrayn] has joined #bitcoin-core-dev 17:03 -!- niska [~niska@68.ip-149-56-14.net] has quit [Quit: Leaving] 17:09 -!- lxer [~lx@ip5f5bd657.dynamic.kabel-deutschland.de] has quit [Ping timeout: 260 seconds] 17:17 -!- niska [~niska@68.ip-149-56-14.net] has joined #bitcoin-core-dev 17:18 -!- goatpig [56f75200@gateway/web/freenode/ip.86.247.82.0] has quit [Ping timeout: 260 seconds] 17:53 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev 17:58 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 18:07 -!- jtimon [~quassel@226.110.132.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] 18:26 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 240 seconds] 18:29 -!- Randolf [~randolf@96.53.47.38] has joined #bitcoin-core-dev 18:37 -!- jhfrontz [~Adium@165.171.225.5] has quit [Quit: Leaving.] 18:50 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-ejfvwxdknkelaoob] has quit [Quit: Connection closed for inactivity] 19:06 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 19:06 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 19:10 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 244 seconds] 19:34 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 19:34 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 19:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 19:42 -!- TheV01d [thev01d@btc.mining.ga] has quit [Ping timeout: 260 seconds] 19:47 -!- TheV01d [thev01d@btc.mining.ga] has joined #bitcoin-core-dev 19:51 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has joined #bitcoin-core-dev 20:09 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 20:12 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Client Quit] 21:36 -!- Jackpot1136 [495d9aeb@gateway/web/freenode/ip.73.93.154.235] has joined #bitcoin-core-dev 21:43 -!- Jackpot1136 [495d9aeb@gateway/web/freenode/ip.73.93.154.235] has quit [Ping timeout: 260 seconds] 21:51 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has quit [Ping timeout: 240 seconds] 21:53 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 22:12 < kallewoof> I'm a bit surprised at the concerns with people running distros from 2007 not being able to run the latest & greatest version of bitcoin core. Does such a person actually exist? 22:13 < kallewoof> Also amazed at how long RHEL support lasts. :O 22:20 < mryandao> enterprise would be running the oldest version of bitcoin possible 22:21 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 22:24 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 248 seconds] 22:40 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 22:42 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev 22:53 < kallewoof> mryandao: Yeah, so even if RHEL 8 was released with C++14 support it wouldn't really matter cause its users would be running bitcoin core 0.3 or something, anyway... 22:55 -!- harrymm [~harrymm@104.207.83.39] has quit [Ping timeout: 240 seconds] 23:08 -!- harrymm [~harrymm@104.207.83.39] has joined #bitcoin-core-dev 23:24 < jonasschnelli> sipa: Yes. Possible,... but seems like we re-inventing a description language like JSON. :) 23:24 < jonasschnelli> I like such compact forms though,.. but they tend to fail once extended to the max 23:25 < jonasschnelli> Maybe it makes more sense to use JSON as the container/desciption format rather then inventing a custom CSV 23:26 < jonasschnelli> not sure though,.. the compact string format would be used at various places,.. like importmulti, etc. 23:26 < jonasschnelli> We just need to make sure it works for all possible extensions 23:41 < sipa> jonasschnelli: i'm worrier about introducing too many formats 23:48 < sipa> jonasschnelli: my idea is that the "records" that eventually will constitute a wallet will consist of a) a descriptor of script(s) and (b) birthdate (c) watchonly or not (d) private key optionally 23:48 < jonasschnelli> Yes. I think that is a very good idea.. 23:48 < sipa> the (a) part is something that should be shared with scanutxo and perhaps some other things 23:48 < jonasschnelli> My concerns are more about the format 23:49 < sipa> so it would be nice of it's a nice and self contained thing 23:49 < sipa> it could be json 23:49 < sipa> that was what i was thinking too... but it's kind of unwieldy too 23:49 < jonasschnelli> Not sure what would make more sense... 23:49 < sipa> so i'm considering a single string thing 23:50 < jonasschnelli> If the use cases are beyond JSON RPC, then I think a "new" format may make sense 23:50 < jonasschnelli> JSON is very extensible... 23:51 < sipa> dump files 23:51 < jonasschnelli> Yes... 23:51 * jonasschnelli thinking... 23:52 < jonasschnelli> The whole dump file is another things... I'm currently not sure what the purpose of a dump file is, and if it is "a backup", if it is the right format 23:52 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 23:52 < jonasschnelli> But I kinda like a string based descriptor,... lets do that 23:53 < jonasschnelli> sipa: have you done a short spec on it already? 23:53 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 23:54 < jonasschnelli> Would it be k/v or fix order/index? Would the xpub ckd range also be possible to describe? 23:54 < sipa> yes, it needs to be 23:55 < jonasschnelli> What is "(c) watchonly or not"? 23:55 < sipa> jonasschnelli: read my.gist 23:55 < sipa> i've linked to it many times :) 23:55 < jonasschnelli> heh.. okay. I shoud re-read you wallet gist, yes. 23:56 < sipa> jonasschnelli: the idea is that watchonly should not be tied to whether or not you happen to ha e the private key 23:56 < jonasschnelli> We should that probably stick to the channel topic. :) 23:56 < jonasschnelli> hmm... 23:56 < jonasschnelli> But I guess senseless for primitive scripts like P2WPKH? 23:56 < sipa> no 23:57 < sipa> for example if your private key is in a hardware wallet 23:57 < sipa> that shouldn't be treated as watchonly 23:57 < sipa> it is yours 23:57 < jonasschnelli> Aha... you look at it from an overall perspective... I was looking from a pure "wallet" perspective 23:57 < sipa> watchonly is for multisig things that you participate in, but don't want counted towards your balance 23:58 < sipa> so my view is that private key or not should be independent from "counted towards balance" ("watch only") or not 23:58 < jonasschnelli> So then there would be 3 categories, hot keys (default), non-private-key-keys (HWW) and watch only? 23:59 < sipa> no, there are "yours" records and "non-yours records" ("watch only") 23:59 < jonasschnelli> When I did a primitive PoC with Core and the Bitbox, I came to the conclusion that three categories may make sense... 23:59 < sipa> in addition, you have private keys... in various places; some can be in your wallet, some are not