--- Log opened Thu Mar 14 00:00:15 2019 00:01 -!- d_t [~d_t@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 00:21 -!- booyah_ is now known as booyah 00:22 -!- d_t [~d_t@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 250 seconds] 00:34 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #bitcoin-core-dev 00:40 < Sentineo> MarcoFalke: did not understand you finding about those gpg keys. Is the issue with the key itself or something else? I did not open an issue yet, I can if it is just not my noobness what causes it not working :) 00:41 < gmaxwell> Sentineo: run gpg --recv-key AC6626172E00A82CFFAE8972A636E97631F767E0 00:42 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection] 00:42 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-supfixrqyicexeob] has joined #bitcoin-core-dev 00:43 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #bitcoin-core-dev 00:59 < midnightmagic> w/w 3 01:00 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 252 seconds] 01:03 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 01:05 -!- harding [~quassel@li1258-130.members.linode.com] has quit [Ping timeout: 246 seconds] 01:07 -!- harding [~quassel@li1258-130.members.linode.com] has joined #bitcoin-core-dev 01:20 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 01:26 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev 01:34 -!- DougieBot5000_ [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-core-dev 01:34 -!- DougieBot5000 is now known as Guest58108 01:34 -!- Guest58108 [~DougieBot@unaffiliated/dougiebot5000] has quit [Killed (livingstone.freenode.net (Nickname regained by services))] 01:34 -!- DougieBot5000_ is now known as DougieBot5000 01:57 -!- anome [~anome@unaffiliated/anome] has quit [] 02:17 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 255 seconds] 02:22 -!- owowo [~ovovo@185.9.18.115] has joined #bitcoin-core-dev 02:22 -!- owowo [~ovovo@185.9.18.115] has quit [Changing host] 02:22 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 02:31 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 02:35 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 02:37 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev 03:00 -!- anome [~anome@unaffiliated/anome] has quit [] 03:01 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 03:06 < Sentineo> gmaxwell: thanks, that seemed to help. As it is still working, it took about a minute for it to fail before. I wonder where you got the key ID from though. Mind explaining so I can fix the issue later myself if happens again? 03:12 < provoostenator> Sentineo the fingerprint of sipa's key, that you just downloaded, is in trusted-keys here: https://github.com/bitcoin/bitcoin/tree/master/contrib/verify-commits 03:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds] 03:12 -!- anome [~anome@unaffiliated/anome] has quit [] 03:16 < Sentineo> oh I see, ok. Thanks provoostenator! 03:19 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 03:22 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 03:24 -!- anome [~anome@unaffiliated/anome] has quit [Client Quit] 03:25 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 03:32 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 03:39 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 04:10 -!- anome [~anome@unaffiliated/anome] has quit [] 04:14 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev 04:20 -!- zhangzf [~zhangzf@106.38.157.147] has quit [Remote host closed the connection] 04:20 -!- zhangzf [~zhangzf@106.38.157.147] has joined #bitcoin-core-dev 04:21 -!- zhangzf [~zhangzf@106.38.157.147] has quit [Remote host closed the connection] 05:37 -!- zhangzf [~zhangzf@120.244.113.158] has joined #bitcoin-core-dev 05:45 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 272 seconds] 05:49 -!- rex4539 [~rex4539@ppp-2-84-169-44.home.otenet.gr] has joined #bitcoin-core-dev 05:49 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 05:50 -!- jonatack [52661bc3@gateway/web/freenode/ip.82.102.27.195] has joined #bitcoin-core-dev 05:50 -!- shesek [~shesek@151.64.2.189] has joined #bitcoin-core-dev 05:50 -!- shesek [~shesek@151.64.2.189] has quit [Changing host] 05:50 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev 06:14 -!- darosior [~darosior@37.173.196.19] has joined #bitcoin-core-dev 06:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 06:30 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 250 seconds] 06:31 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 06:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 06:41 < bitcoin-git> [bitcoin] luke-jr opened pull request #15600: lockedpool: When possible, use madvise to avoid including sensitive information in core dumps or forked process memory spaces (master...lockedpool_dontdump) https://github.com/bitcoin/bitcoin/pull/15600 06:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 06:55 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection] 06:56 < provoostenator> Does the MSVC build ignore configure.ac? 06:57 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #bitcoin-core-dev 07:02 -!- deepakkathayat [0e8b5206@gateway/web/freenode/ip.14.139.82.6] has joined #bitcoin-core-dev 07:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 07:06 < bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/232ef630ecd3...a01925c1502a 07:06 < bitcoin-git> bitcoin/0.18 a01925c Wladimir J. van der Laan: doc: Pre-rc2 translations update 07:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 07:10 -!- jungly [~quassel@79.8.200.97] has quit [Remote host closed the connection] 07:17 -!- jarthur [~jarthur@2605:6000:1019:41ab:14fb:394b:c577:7329] has quit [Ping timeout: 252 seconds] 07:23 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 250 seconds] 07:28 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 07:55 -!- zhangzf [~zhangzf@120.244.113.158] has quit [Remote host closed the connection] 07:56 -!- zhangzf [~zhangzf@223.72.65.242] has joined #bitcoin-core-dev 08:01 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Quit: leaving] 08:05 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 08:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds] 08:13 < wumpus> provoostenator: I think so, yes 08:13 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 08:16 -!- darosior [~darosior@37.173.196.19] has quit [Remote host closed the connection] 08:19 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #bitcoin-core-dev 08:26 < provoostenator> Actually I don't think it's ignored. It's just that .appveyor.yml doesn't bust the cache when it changes. Fixed as part of #15457 (hopefully) 08:26 < gribble> https://github.com/bitcoin/bitcoin/issues/15457 | Check std::system for -[alert|block|wallet]notify by Sjors · Pull Request #15457 · bitcoin/bitcoin · GitHub 08:27 < provoostenator> I'm trying to get Visual Studio setup on a Windows 10 VM on my Mac. It's insanely slow, but getting there... 08:27 < provoostenator> I like how PowerShell supports "ls" in addition to "dir" :-) 08:28 < Sentineo> does it make sense to try to do a gitian build now, or wait till official release? 08:31 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has joined #bitcoin-core-dev 08:33 -!- Aaronvan_ is now known as AaronvanW 08:37 -!- darosior [~darosior@37.173.78.147] has joined #bitcoin-core-dev 08:45 < provoostenator> Sentineo: I believe v0.18.0rc2 will be tagged later today, so that's a good one to build. 08:45 < provoostenator> (see https://github.com/bitcoin-core/docs/blob/master/gitian-building.md) 08:46 -!- lxleuser [chatzilla@nat/iiit/x-comchjpngljuobnc] has joined #bitcoin-core-dev 08:47 -!- lxleuser is now known as deepakmkathayat 08:47 < Sentineo> ok great, I will try it tomorrow. Hopefully I can build it. 08:58 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 09:00 -!- jonatack [52661bc3@gateway/web/freenode/ip.82.102.27.195] has quit [] 09:04 < hebasto> Sentineo: using gitian-build.py with Docker is probably the easiest way. 09:08 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has joined #bitcoin-core-dev 09:09 -!- Deinogalerix21 [~Deinogale@81.92.202.18] has joined #bitcoin-core-dev 09:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 252 seconds] 09:13 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 09:24 -!- ExtraCrispy [~ExtraCris@gateway/tor-sasl/extracrispy] has joined #bitcoin-core-dev 09:26 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Remote host closed the connection] 09:26 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev 09:27 -!- zhangzf [~zhangzf@223.72.65.242] has quit [Remote host closed the connection] 09:31 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev 09:38 -!- BEEN [31e639fa@gateway/web/freenode/ip.49.230.57.250] has joined #bitcoin-core-dev 09:40 -!- BEEN [31e639fa@gateway/web/freenode/ip.49.230.57.250] has quit [Client Quit] 09:43 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Ping timeout: 246 seconds] 09:47 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 09:50 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [] 09:54 -!- deepakmkathayat [chatzilla@nat/iiit/x-comchjpngljuobnc] has quit [Quit: ChatZilla 0.9.93 [SeaMonkey 2.49.4/20180711183816]] 09:54 -!- deepakkathayat [0e8b5206@gateway/web/freenode/ip.14.139.82.6] has quit [Quit: Page closed] 10:05 -!- darosior [~darosior@37.173.78.147] has quit [Remote host closed the connection] 10:18 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-dev 10:24 < provoostenator> How do I produce the right config.ini for the Visual Studio build? Normally AppVeyor performs some magic on config.ini.in it seems. 10:30 -!- promag [~promag@83.223.251.241] has joined #bitcoin-core-dev 10:33 -!- jhfrontz1 [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has joined #bitcoin-core-dev 10:33 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/] 10:33 -!- cyber55 [~cyber55@unaffiliated/cyber55] has quit [Ping timeout: 252 seconds] 10:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds] 10:42 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-pjlhkzjejohtpqkw] has joined #bitcoin-core-dev 10:42 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 10:52 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Remote host closed the connection] 10:54 < promag> anything left to do in #15583? 10:54 < gribble> https://github.com/bitcoin/bitcoin/issues/15583 | wallet: Log and ignore errors in ListWalletDir and IsBerkeleyBtree by promag · Pull Request #15583 · bitcoin/bitcoin · GitHub 10:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 10:59 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8e1704c01537...7fa1f6258c05 10:59 < bitcoin-git> bitcoin/master 15c69b1 João Barbosa: wallet: Log and ignore errors in ListWalletDir and IsBerkeleyBtree 10:59 < bitcoin-git> bitcoin/master 7fa1f62 Wladimir J. van der Laan: Merge #15583: wallet: Log and ignore errors in ListWalletDir and IsBerkele... 10:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 10:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 10:59 < bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/a01925c1502a...ef27a060ac0d 10:59 < bitcoin-git> bitcoin/0.18 ef27a06 João Barbosa: wallet: Log and ignore errors in ListWalletDir and IsBerkeleyBtree 11:00 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 11:00 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 11:00 < bitcoin-git> [bitcoin] laanwj merged pull request #15583: wallet: Log and ignore errors in ListWalletDir and IsBerkeleyBtree (master...2019-03-fix-listwalletdir) https://github.com/bitcoin/bitcoin/pull/15583 11:00 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 11:00 < kanzure> meeting time? 11:00 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 11:00 < bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/ef27a060ac0d...85f1755163a1 11:00 < bitcoin-git> bitcoin/0.18 85f1755 Wladimir J. van der Laan: build: bump to rc2 11:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 11:01 < sipa> kanzure: one hour from now 11:01 < achow101> kanzure: in an hour, dst 11:02 < achow101> dst changed last weekend 11:02 < promag> wumpus: that was fast 11:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 11:06 < bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/85f1755163a1...889af0eaacd9 11:06 < bitcoin-git> bitcoin/0.18 889af0e Wladimir J. van der Laan: doc: Update manpages 11:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 11:09 -!- Deinogalerix21 [~Deinogale@81.92.202.18] has quit [Quit: WeeChat 2.4] 11:11 -!- promag [~promag@83.223.251.241] has quit [Remote host closed the connection] 11:15 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 11:17 -!- d_t [~d_t@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 11:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds] 11:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 11:25 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 11:39 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 245 seconds] 11:41 -!- vexbuy [~vexbuy@212.88.56.119] has joined #bitcoin-core-dev 11:44 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 11:54 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 12:00 < wumpus> meeting time? 12:00 < jnewbery> hi 12:00 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb 12:00 < wumpus> #startmeeti 12:00 < provoostenator> hi 12:00 < wumpus> #startmeeting 12:00 < achow101> hi 12:00 < lightningbot> Meeting started Thu Mar 14 19:00:55 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:01 < instagibbs> oh hi 12:01 < luke-jr> hi 12:01 < dongcarl> oh hi mark 12:01 < instagibbs> topic: 0.18 release progress (I'm a bit out of loop on what needs backport etc) 12:01 < wumpus> we're pretty much ready to tag 0.18.0rc2 12:01 < instagibbs> \o/ 12:01 < kanzure> hi 12:02 < wumpus> any topics? 12:02 < cfields> hi 12:02 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection] 12:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 12:02 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #15601: build: depends: Switch to python3 (take 3) (master...1903-buildPy3) https://github.com/bitcoin/bitcoin/pull/15601 12:02 < meshcollider> hi 12:02 < kanzure> mailing list still in flux, no updates really 12:02 < jamesob> hi 12:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 12:02 < sipa> hi 12:02 < moneyball> 4 straight weeks no #proposedmeetingtopics :) 12:03 < wumpus> thanks moneyball 12:03 < wumpus> #topic high priority for review 12:03 < instagibbs> I'd like #15557 to get in that list 12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/15557 | Enhance `bumpfee` to include inputs when targeting a feerate by instagibbs · Pull Request #15557 · bitcoin/bitcoin · GitHub 12:03 < instagibbs> preferably before next fee event ;P 12:03 < wumpus> https://github.com/bitcoin/bitcoin/projects/8 three PRs on here #15141 #10973 #14856 12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/15141 | Rewrite DoS interface between validation and net_processing by sdaftuar · Pull Request #15141 · bitcoin/bitcoin · GitHub 12:03 < wumpus> instagibbs: ok 12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/10973 | Refactor: separate wallet from node by ryanofsky · Pull Request #10973 · bitcoin/bitcoin · GitHub 12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/14856 | net: remove more CConnman globals (theuni) by dongcarl · Pull Request #14856 · bitcoin/bitcoin · GitHub 12:04 < wumpus> instagibbs: added 12:04 < achow101> #15006 for me pls 12:04 < gribble> https://github.com/bitcoin/bitcoin/issues/15006 | Add option to create an encrypted wallet by achow101 · Pull Request #15006 · bitcoin/bitcoin · GitHub 12:04 < cfields> I for sure owe review on 14856. Will do today. 12:05 < wumpus> cfields: thanks ! 12:05 < jonasschnelli> hi 12:06 < jonasschnelli> Can I add #15512 to the high prio list? 12:06 < gribble> https://github.com/bitcoin/bitcoin/issues/15512 | Add ChaCha20 encryption option (XOR) by jonasschnelli · Pull Request #15512 · bitcoin/bitcoin · GitHub 12:06 < jonasschnelli> (if we are fine with adding crypto primitives) 12:06 < wumpus> jonasschnelli: yes 12:06 < wumpus> at least if there's concept ACK agreement to add it 12:07 < jonasschnelli> Okay... added to the list. So waiting for Concept reviews 12:09 < wumpus> other topics? 12:09 < sipa> instagibbs had a topic 12:09 < gmaxwell> RC2 is tagged. hurrah 12:10 < instagibbs> any "needs" for 0.18 being the topic, in other words 12:10 < wumpus> #topic 0.18.0rc2 12:10 < wumpus> it's not tagged yet but intend to do so after the meeting, if no one complains 12:10 < gmaxwell> oh. :P 12:11 < gmaxwell> Well great, that would be a good time for people to start building too, I guess? 12:11 < instagibbs> as an aside I think HWI is near 1.0, 1 open issue right achow101 ? 12:11 -!- F1nny [~f1nny@96-64-197-190-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 12:11 < sipa> i'm a bit surprised by the amount of people (claiming to) use the reject message on the ML... should we proceed with making it default off in 0.18? 12:11 -!- promag [~promag@83.223.251.241] has joined #bitcoin-core-dev 12:11 < achow101> instagibbs: yeah, just one thing needs review 12:11 < wumpus> #topic reject message default 12:12 < wumpus> sipa: I've alwys been divided on removing it to be honest 12:12 < sipa> i would very much like to disappear, but my assumption was that it was much less used than people are claiming now 12:12 < gmaxwell> The comments on the list have, once you sort through the speculative claims, all been "I use it for debugging" 12:12 < wumpus> that makes sense, that's what it's for 12:13 < gmaxwell> I'm still confused by those however, -- because is it also "I want to debug a lite wallet without running a full node myself?" 12:13 < wumpus> then again disabling it by default wouldn't affect that use case, just make sure it's enabled on the node used for debugging 12:13 < gmaxwell> Right. 12:13 < instagibbs> right I don't really get it. 12:13 < instagibbs> have a full node for debugging?!? 12:13 < gmaxwell> I think its unfortunate that that this has come up in the context of removing it entirely. 12:13 < achow101> gmaxwell: istm it's debugging user submitted bug reports, not the developer debugging his own app 12:13 < sipa> yeah that's the case in the schildbach wallet 12:13 < promag> hi 12:14 < MarcoFalke> the neutrino wallet is using them as well, apparently 12:14 -!- F1nny is now known as Guest79138 12:14 -!- Hazey1111 [~f1nny@96-64-197-190-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 12:14 -!- Guest79138 [~f1nny@96-64-197-190-static.hfc.comcastbusiness.net] has quit [Killed (weber.freenode.net (Nickname regained by services))] 12:14 -!- Hazey1111 is now known as F1nny 12:14 < gmaxwell> achow101: Yes, but capturing the transaction itself would seem to be strictly superior for that. 12:14 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 12:15 < gmaxwell> MarcoFalke: along with a bunch of other assumptions about trusting the nodes its communicating with. 12:15 < gmaxwell> Which is already a security model we've made a conscious decision to not add support for. 12:15 < gmaxwell> MarcoFalke: and clearly not using them with existing nodes, since they require other protocol extensions. 12:15 < achow101> gmaxwell: certainly. but at the same time, having the reject message can provide better ux as the user can see why their transaction was rejected (in theory) 12:15 < MarcoFalke> They way one wallet makes it trustworthy is to send the tx to all nodes and see if at least half of them report the same reject reason 12:16 < gmaxwell> MarcoFalke: that doesn't make it trustworthy. 12:16 < MarcoFalke> Yeah, I am not going to start to explain what is wrong with that, even 12:16 < gmaxwell> Right... 12:16 < sipa> i'm just bringing it up because i think this ML discussion should have happened before making it disabled by default, rather than before removing it entirely 12:16 < MarcoFalke> sipa: You are right 12:17 < MarcoFalke> It is sort of pointless to make them disabled by default, but then not remove them 12:17 < moneyball> agree with sipa 12:17 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 12:17 < MarcoFalke> So they should probably be enabled by default again for now. Not sure if that makes it into 0.18.0 12:18 < jnewbery> it's not too late to revert #13134 12:18 < gribble> https://github.com/bitcoin/bitcoin/issues/13134 | net: Add option `-enablebip61` to configure sending of BIP61 notifications by laanwj · Pull Request #13134 · bitcoin/bitcoin · GitHub 12:18 < jnewbery> or just change the default to 0 12:18 < gmaxwell> It was covered in the optech newsletter, but I don't see a prior ML discussion of it. 12:18 < MarcoFalke> yeah, just change the default 12:18 < MarcoFalke> No need to remove the option 12:18 < gmaxwell> MarcoFalke: it's not pointless to disable them by default but not remove them. 12:18 < gmaxwell> MarcoFalke: they're a source of a non-trivial amount of junk protocol chatter. 12:18 < gmaxwell> MarcoFalke: and the reliance on them creates its own problems. 12:18 -!- Hazey1111 [~f1nny@96-64-197-190-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 12:19 -!- Hazey1111 [~f1nny@96-64-197-190-static.hfc.comcastbusiness.net] has quit [Client Quit] 12:19 < jnewbery> sorry, I mean revert #14054 12:19 < gribble> https://github.com/bitcoin/bitcoin/issues/14054 | p2p: Disable BIP 61 by default by MarcoFalke · Pull Request #14054 · bitcoin/bitcoin · GitHub 12:19 < gmaxwell> (including incentives to sybil attack the network) 12:19 -!- F1nny [~f1nny@96-64-197-190-static.hfc.comcastbusiness.net] has quit [Ping timeout: 245 seconds] 12:20 < MarcoFalke> In light of the spv wallets that use them, default by off is the same as having them removed 12:20 < sipa> ideally we can convince people to switch to more reliable methods before disabling support for it 12:20 < gmaxwell> I don't see anything terrible about delaying disabling it. But I am also not sure what is going to change. 12:20 < gmaxwell> sipa: there isn't anything to switch. 12:20 -!- F1nny [~F1nny11@96-64-197-190-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 12:20 < gmaxwell> sipa: the two respondands saying they're using it (1) only log it, (2) don't work against bitcoin core already. 12:20 < sipa> gmaxwell: ? 12:21 < gmaxwell> sipa: android wallet doesn't actually do anything with the messages but log them, the neutrino wallet requires protocol extensions that are only in btcd. 12:21 < sipa> right, for now 12:21 < gmaxwell> so whats there to switch? 12:22 < sipa> ou suggested logging the tx itself instead of the reject message, for example 12:22 < gmaxwell> Okay, fair point! 12:22 < sipa> plus there are other methods like seeing transactions announced back to yourself (okay, not very reliable either) 12:22 < sipa> i just wish this discussion was more resolved before we possibly anger people needlessly by ripping something out they stubbornly rely on now 12:23 < gmaxwell> sipa: one client does that but sends their txn to all peers :) ... 12:23 < gmaxwell> 12:20:11 < gmaxwell> I don't see anything terrible about delaying disabling it. But I am also not sure what is going to change. 12:23 < jnewbery> sounds like the action item is to revert #14054 before 0.18 12:23 < gribble> https://github.com/bitcoin/bitcoin/issues/14054 | p2p: Disable BIP 61 by default by MarcoFalke · Pull Request #14054 · bitcoin/bitcoin · GitHub 12:23 < sipa> yeah, it's a fair point that delaying may just literally mean delaying it 12:23 < sipa> but perhaps it does resolve the discussion further 12:24 < gmaxwell> I think we should probably make it clear that we still intend to disable it by default. 12:24 < MarcoFalke> jnewbery: I am fine with that, but I hope that doesn't give a signal that they are encouraged 12:24 < MarcoFalke> They should still go in the long term 12:24 < sipa> agree 12:24 < gmaxwell> I mean I think it was clear years ago that these shouldn't be used the way people are advocating using them... like on day one. 12:24 < sipa> i doubt that was clear to everyone :) 12:25 < cfields> Hasn't our unwritten policy always been to deprecate in one release, and non-default/remove in the next? 12:25 < MarcoFalke> cfields: I tried to do that, but apparently people only picked up on this when I wanted to remove them 12:25 < sipa> cfields: for RPC that works... for P2P services it's harder 12:25 < jnewbery> That's easier for RPCs because deprecation is immediately obvious to the user 12:25 < gmaxwell> some of the things people are reporting doing with them haven't worked right for a long time (or ever)... (like trying to differentiate between already spent and other causes of invalidity) 12:26 < moneyball> It would also help to better educate what they should do as an alternative. My reading of the thread still has me uncertain, and they also do not seem to know what to do. 12:26 < gmaxwell> Actually disabling it in a release has that effect somewhat, as it'll be years before it's gone completely on the network. 12:26 < cfields> sipa: I just meant that if it's going to be non-defaulted in one version, seems only fair to put it through a deprecation cycle in the preceding one. 12:26 < jnewbery> how do you deprecate a P2P message in a way that users notice? 12:26 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 268 seconds] 12:26 < moneyball> Good next steps IMO would be 1) revert in v0.18 2) communicate this to the list but also emphasize the long-term plan 3) educate on alternatives for these users 12:26 < sipa> cfields: right, but what does 'deprecation' mean here? if it's not disabled by default, it's not even observable 12:26 < gwillen> cfields: but I think sipa's point is that deprecation doesn't notify the people who care 12:27 < gmaxwell> moneyball: to some extent what wants to be done just can't be done, even with rejects. You can't find out if the network is taking your transaction, it's just not something anyone can tell. 12:27 < cfields> Just in the release notes.. we intend to flip this to disabled-by-default in the next release. 12:27 < sipa> cfields: sgtm 12:27 < cfields> that's all I meant by "deprecate". 12:27 < gmaxwell> cfields: ack. 12:27 < wumpus> so I guess this does hold up rc2 tagging then 12:27 < jnewbery> I'm happy to open that PR now, unless MarcoFalke wants it 12:28 < MarcoFalke> jnewbery: go for it 12:28 < gmaxwell> jnewbery: go do it. 12:28 < jnewbery> I'll do it today 12:28 < provoostenator> You can make it noticable by always returning reject :-) 12:28 < gmaxwell> lol 12:28 < gmaxwell> provoostenator: nope, in fact. 12:28 < sipa> reject 00 "The operation completed succesfully" 12:29 < gmaxwell> provoostenator: because reject isn't doing anything in existing software except ending up burried in some logs. 12:29 < gmaxwell> so even that would be hit or miss. 12:30 < sipa> https://www.medo64.com/content/media/errortheoperationcompletedsuccessfully.png 12:31 < achow101> what's the long term plan for removal? default disable in 0.19, remove in 0.20? 12:31 < gwillen> I think starting mailing list discussion of what the alternatives are, and getting moneyball to spread it in the newsletter, is probably the best way to spread the good word :-) 12:31 < MarcoFalke> achow101: Something like that 12:31 < MarcoFalke> [15:26] Good next steps IMO would be 1) revert in v0.18 2) communicate this to the list but also emphasize the long-term plan 3) educate on alternatives for these users 12:32 < gmaxwell> gwillen: right, what I would recommend for these logging cases is that they log the transaction and current block height. 12:32 < MarcoFalke> gmaxwell: you mean the full tx in hex? 12:32 < sipa> base85 FTW 12:32 < moneyball> fyi harding referred to the PR commit in the sep 18 newsletter https://bitcoinops.org/en/newsletters/2018/09/18/ 12:33 < cfields> MarcoFalke: where do I point my DoS? :) 12:33 < moneyball> and the discussion that marco started in the mar 12 newsletter https://bitcoinops.org/en/newsletters/2019/03/12/ 12:33 < gmaxwell> MarcoFalke: whatever is required for them to be able to reproduce! in some applications it might be less than the full tx. 12:33 < gmaxwell> cfields: you're misunderstanding, the wallet should log its own transaction. 12:33 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds] 12:33 < MarcoFalke> Yeah, its only the own wallets txs 12:33 < cfields> gmaxwell: I was, thanks. 12:33 < gmaxwell> MarcoFalke: e.g. if the wallet always stores the tx like bitcoin core, the current block and txid are enough. 12:34 < gmaxwell> cfields: basically the debugging case is "User says my transaction was never confirming" ... what do you do? Andreas is pointing out that reject messages have been helpful. 12:35 < gmaxwell> Another thing is that I see no feefilter support in that software... so obviously processing feefilters would allow them to locally learn about some of the failure cases they care about. 12:36 < gmaxwell> right now reject basically only tells you didn't meet minfee vs "something else happened at the first hop", feefilter + listen to hear it back gets you essentially that, but more reliable. 12:37 -!- vexbuy [~vexbuy@212.88.56.119] has quit [] 12:37 < sipa> gmaxwell: though feefilter can't be relied upon either in an adverserial setting 12:37 < sipa> it is less DoS risk though 12:37 < gmaxwell> sipa: no but it's probably better than reject messages. 12:38 < gmaxwell> esp if you obey it, e.g. don't send a txn that would violate the filter to a particular peer. 12:40 < sipa> end topic? 12:40 < gmaxwell> ack 12:40 < wumpus> other topics? 12:40 < wumpus> #endmeeting 12:40 < lightningbot> Meeting ended Thu Mar 14 19:40:57 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 12:40 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-14-19.00.html 12:40 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-14-19.00.txt 12:40 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-14-19.00.log.html 12:41 < sipa> #lunch 12:41 < gmaxwell> [outside of meeting now] 12:41 < gmaxwell> Can someone explain this tweet people were passing around? https://twitter.com/pierre_rochard/status/1104785795523719169 I don't understand how fullblock spv mode and the BIP157 related PRs are at all compariable/substutiable for each other. 12:42 -!- F1nny_ [~F1nny@96-64-197-190-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 12:42 -!- F1nny [~F1nny11@96-64-197-190-static.hfc.comcastbusiness.net] has quit [Killed (orwell.freenode.net (Nickname regained by services))] 12:42 -!- F1nny_ is now known as F1nny 12:42 < gmaxwell> (someone in #bitcoin tried asking me my opinion about that debate earlier, and I thought it would be nice to actually understand it before responding...) 12:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 12:42 < bitcoin-git> [bitcoin] jnewbery opened pull request #15602: [p2] Enable reject messages by default (0.18...reject_message_by_default) https://github.com/bitcoin/bitcoin/pull/15602 12:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 12:44 -!- F1nny is now known as Guest40521 12:44 -!- F1nny_ [~F1nny@96-64-197-190-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 12:44 -!- Guest40521 [~F1nny@96-64-197-190-static.hfc.comcastbusiness.net] has quit [Killed (livingstone.freenode.net (Nickname regained by services))] 12:44 -!- F1nny_ is now known as F1nny 12:45 < moneyball> My understanding is that pierre_rochard is focused on onboarding new Bitcoin users via Lightning (with his Lightning Powered Users), and he would like as many of them as possible to run full nodes, but he wants them to be able to use Bitcoin immediately so wants to support BIP157 style light clients. He's also saying if Core doesn't merge support for BIP157, he'd maintain a version of Core with it merged, and run 12:45 < moneyball> it himself to support his users 12:45 < harding> gmaxwell: pierre_rochard maintains an installer that installs Bitcoin Core, LND, and a LN wallet that's capable of using BIP157/158. I think his desire is to allow people to immediately start using LND and the LN wallet using BIP157 filters served from his node while their Bitcoin Core node syncs. That is, I don't think he's talking about hybrid SPV in Bitcoin Core by hybrid SPV via LND/Neutrino/some other wallet. 12:45 -!- promag [~promag@83.223.251.241] has quit [Read error: Connection reset by peer] 12:45 < harding> s/by hybrid/but hybrid/ 12:46 < gmaxwell> harding: for that sort of thing, just fetching the blocks seems completely reasonable even ideal.. 12:46 < provoostenator> harding: that seems a plausible interpretation 12:47 < harding> gmaxwell: I agree. 12:47 < gmaxwell> So then I guess the confusion there would be that what he'd really want as the alternative is 'hybrid spv mode' in the ln wallet? not in bitcoin core. 12:47 < sipa> only partially related, i think there is a lot of confusion about what "bip157" means; there is (a) the spec, allowing software to implement the filters in a private protocol like wasabi does (b) support for it in bitcoin core via RPC (what the current PRs do) (c) exposing it in core and other software via P2P for trusting peers to use (d) exposing it in core via P2P for non-trusting peers (e) a 12:47 < sipa> softfork to prevent non-trusting peers from... 12:48 < sipa> lying about filters (assuming trust in hashrate majority) 12:48 < gmaxwell> indeed. 12:48 < sipa> there seems to be a lot of antagonism on twitter against (d) 12:48 -!- F1nny [~F1nny@96-64-197-190-static.hfc.comcastbusiness.net] has quit [Client Quit] 12:49 -!- F1nny [F1nny@gateway/vpn/privateinternetaccess/f1nny] has joined #bitcoin-core-dev 12:49 < gmaxwell> I'm not really aware of the twitter stuff (other than having been given that link) ... but my thought for many months is that I'm super excited about having the filters to make rescans usable again... and super concerned about them starting a new wave of bip37 like wallets that just blindly trust things. 12:49 < harding> gmaxwell: AFAIU, he just wants some way for people to start using an LN wallet in the SPV trust model while their node syncs. I'm not sure he cares how it happens. I myself don't know why BIP157/158 is entangled in this, except that he might think it's necessary to accomplish that. 12:49 < echeveria> sipa: (f) using it for wallet rescans. 12:49 < sipa> echeveria: good point; i'd put it under (b) as trust model, but agree 12:50 < echeveria> (f) ii. using it for wallet rescans while pruned. 12:50 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev 12:50 < gmaxwell> harding: yea okay, I'd even say BIP157/158 is a pretty weak way to accomplish that particular case. ... deploying a new protocol would take a lot of time in the best case, while just fetching the blocks works now against the existing network. 12:50 < harding> I've been trying to use "BIP157" for the filters themselves and "BIP158" for the P2P parts, but it's not always that clearcut. 12:51 < sipa> harding: it's the other way around :p 12:51 < gmaxwell> Fetchign the blocks has better security/reliablity properties. It uses more bandwidth, but that doesn't seem terribly important in the "while the user's node syncs" case. 12:51 < harding> gmaxwell: yeah, and any client that supports BIP157 must, by necessity, also support grabbing and parsing full blocks anyway, so supporting grabbing all blocks after a certain height ought to be a trivial addition. 12:52 < harding> sipa: is it really? /me facepalms 12:52 < gmaxwell> the bandwidth usage isn't even all that great if you're also just talking about now-forward and not the history. (14kbit/sec whoppie) 12:52 < sipa> harding: yeah 158 defines the filters, 157 is the p2p protocol to expose it 12:54 < gmaxwell> echeveria: (f) ii. -- thats cute. 12:55 < gmaxwell> being able to rescan with a pruned wallet would be pretty nice... though carring around the filters is a pretty big hit on top of pruning (2x disk space usage maybe?) 12:56 < gmaxwell> probably worth it, just because a lot more users could prune, which is becoming increasingly critical as the history is now getting larger than the most popular SSD sizes. 12:56 < sipa> iirc the filters are around 20 KiB per block? 12:57 < gmaxwell> they're smaller for earlier blocks, but not as much smaller as the blocks are. 12:57 -!- keymone [~keymone@ip1f10c1a7.dynamic.kabel-deutschland.de] has quit [Ping timeout: 250 seconds] 12:58 < echeveria> gmaxwell: one PR has a comment that it's about 10GB today. 12:59 < gmaxwell> ouch, a bit worse than I thought. 12:59 < echeveria> so pruned would be 10GB + 3GB UTXO + 0.6GB blocks, but allows wallet rescan. 12:59 < gmaxwell> yeah.... 12:59 < instagibbs> this is where commitments would help i guess 12:59 < gmaxwell> instagibbs: I don't think so, actually. 13:00 < instagibbs> oh? 13:00 < echeveria> unpruned would be 10GB + 220GB, so a 5% hit for significantly faster imports. 13:00 < gmaxwell> I mean, having to fetch 10GB+growing of data every time you want to rescan isn't really "recan supported" :P 13:00 < instagibbs> oh hah right 13:00 < instagibbs> well, you could forget filters on a rolling basis 13:00 < instagibbs> but i guess the same logic applies 13:00 < instagibbs> for just redownloading them :) 13:00 < gmaxwell> yes, though we've not yet really figured out how to make time windowed rescan work well for people. 13:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 13:01 < bitcoin-git> [bitcoin] gwillen opened pull request #15603: docs: Add more tips to productivity.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15603 13:01 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 13:01 < gmaxwell> instagibbs: if "rescan by fetching 10gb" is okay, then probably rescan via PIR query would be better. 13:01 < instagibbs> for me I just want for wallet rescan... 13:02 < gmaxwell> likewise. having an extra 10GB on top of 220GB that makes rescan usable is well worth it. 13:02 < gmaxwell> (well it was more well worth it when I thought it was 3gb. :P) 13:03 < jonasschnelli> do you need all filters? 13:03 < gmaxwell> now actually on the host I most frequently use, I wouldn't acutally have room for that. 13:03 < gmaxwell> oh is the 10gb more than just the output filter? the output filter is the only one I think is at all useful. 13:04 -!- keymone [~keymone@ip1f10c1a7.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev 13:05 -!- F1nny_ [F1nny@gateway/vpn/privateinternetaccess/f1nny] has joined #bitcoin-core-dev 13:06 -!- F1nny is now known as Guest57196 13:06 -!- Guest57196 [F1nny@gateway/vpn/privateinternetaccess/f1nny] has quit [Killed (asimov.freenode.net (Nickname regained by services))] 13:06 -!- F1nny_ is now known as F1nny 13:07 < instagibbs> what's the PR for 158(7?) 13:08 < jonasschnelli> #14121 13:08 < gribble> https://github.com/bitcoin/bitcoin/issues/14121 | Index for BIP 157 block filters by jimpo · Pull Request #14121 · bitcoin/bitcoin · GitHub 13:08 < sipa> it should be called BIP158, there is no p2p protocol support in there :) 13:08 < jonasschnelli> indeed 13:09 < jonasschnelli> "Total index size is 3.8 GiB"... echeveria: where did you get the 10GB from? 13:09 -!- keymone [~keymone@ip1f10c1a7.dynamic.kabel-deutschland.de] has quit [Ping timeout: 245 seconds] 13:17 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Remote host closed the connection] 13:18 -!- keymone [~keymone@31.16.193.167] has joined #bitcoin-core-dev 13:22 < echeveria> jonasschnelli: misreading, apparently. 13:22 < echeveria> gmaxwell: sipa: looks better with 3.8GB. same size as the UTXO give or take. 13:23 < gmaxwell> echeveria: yeah, for the moment.. 2x. not terrible. 13:24 -!- Damiano_ [92f19a50@gateway/web/freenode/ip.146.241.154.80] has joined #bitcoin-core-dev 13:28 -!- Damiano_ [92f19a50@gateway/web/freenode/ip.146.241.154.80] has quit [Client Quit] 13:31 -!- shesek [~shesek@151.64.2.189] has joined #bitcoin-core-dev 13:31 -!- shesek [~shesek@151.64.2.189] has quit [Changing host] 13:31 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev 13:32 -!- obsrver [~quassel@p5DC6BB91.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 13:34 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Remote host closed the connection] 13:38 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev 13:42 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has quit [Quit: (https://github.com/mmgen) leaving] 13:42 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev 13:43 -!- F1nny_ [F1nny@gateway/vpn/privateinternetaccess/f1nny] has joined #bitcoin-core-dev 13:45 < roasbeef> i think in that tweet pierre is just saying that if bitcoind doesn't get fully p2p support eventually, he'd maintain a fork that implemented it, as earlier in the thread ppl proposed full block download as an alternative 13:46 -!- F1nny [F1nny@gateway/vpn/privateinternetaccess/f1nny] has quit [Ping timeout: 272 seconds] 13:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 13:46 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to 0.18: https://github.com/bitcoin/bitcoin/compare/889af0eaacd9...d3a038200709 13:46 < bitcoin-git> bitcoin/0.18 da14d90 John Newbery: [p2p] Enable BIP 61 REJECT messages by default 13:46 < bitcoin-git> bitcoin/0.18 a756363 John Newbery: [docs] document BIP 61 deprecation 13:46 < bitcoin-git> bitcoin/0.18 d3a0382 MarcoFalke: Merge #15602: 0.18: [p2p] Enable reject messages by default 13:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 13:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 13:46 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15602: 0.18: [p2p] Enable reject messages by default (0.18...reject_message_by_default) https://github.com/bitcoin/bitcoin/pull/15602 13:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 13:59 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 14:00 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-pjlhkzjejohtpqkw] has quit [Quit: Connection closed for inactivity] 14:01 -!- newbie2019258_ [c3b5d3c6@gateway/web/freenode/ip.195.181.211.198] has quit [Ping timeout: 256 seconds] 14:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 14:04 < bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/7fa1f6258c05...b83c6f79400f 14:04 < bitcoin-git> bitcoin/master bf12093 Sjors Provoost: [doc] productivity: fix broken link 14:04 < bitcoin-git> bitcoin/master 3a21905 Sjors Provoost: [doc] devtools: mention clang-format dependency 14:04 < bitcoin-git> bitcoin/master ff7f31e Sjors Provoost: [doc] productivity: more advanced git range-diff 14:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 14:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 14:05 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15444: [docs] Additional productivity tips (master...2019/02/typo-productivity) https://github.com/bitcoin/bitcoin/pull/15444 14:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 14:08 < pierre_rochard> gmaxwell: "for that sort of thing, just fetching the blocks seems completely reasonable even ideal.." agree, and c-lightning does that with spruned. This would work for LND as well, but ZMQ emulation needs to be added to spruned. I would get busy working on that, but I hear LND mainnet neutrino + btcd isn't far off. 14:10 < pierre_rochard> My activism for serving up filters with bitcoind is because I'd rather be running bitcoind than btcd, just for historical reasons 14:11 < pierre_rochard> "I think his desire is to allow people to immediately start using LND and the LN wallet using BIP157 filters served from his node while their Bitcoin Core node syncs." 14:11 < pierre_rochard> This is exactly right 14:12 < pierre_rochard> people who have to wait hours/days for IBD to be able to use LND often end up just taking the shortcut to a custodial lightning wallet. We can have both rapid onboarding and full nodes if we use a light client as a stopgap 14:20 < MarcoFalke> rc2 ready to tag? 14:30 -!- jonatack [b9cee133@gateway/web/freenode/ip.185.206.225.51] has joined #bitcoin-core-dev 14:43 < achow101> provoostenator: what tests do you have that require importing private keys into the keypool? 14:43 < achow101> I would rather not add such a feature just so a test can work easier 14:43 -!- webuser3254 [3e1cd796@gateway/web/freenode/ip.62.28.215.150] has joined #bitcoin-core-dev 14:44 < webuser3254> hello, I have a question regarding pruned mode and importprivkey. I have just imported hundreds of privkeys from my electrum wallet to bitcoin gold core pruned wallet but I can't see any addresses or balances. I can't seem to be able to do rescan on pruned mode. Is there a way to see my balance or move ALL the coins to a new address? 14:44 -!- F1nny__ [F1nny@gateway/vpn/privateinternetaccess/f1nny] has joined #bitcoin-core-dev 14:44 < webuser3254> I appologise for posting it here but I can't do it #bitcoin for some reason :/ 14:45 < echeveria> what reason? the channel doesn't require registration. 14:45 < webuser3254> "Cannot send to nick/channel: #bitcoin" 14:45 < jimpo> sipa: The line between BIP 157 and 158 is kind of muddied, but the notion of filter types and a chain of headers is in 157. 158 is just the specification of the construction of the basic filter type. 14:46 < jimpo> Since the index supports multiple filter types (ish), I feel like it's more related to 157 than 158 14:46 -!- F1nny_ [F1nny@gateway/vpn/privateinternetaccess/f1nny] has quit [Ping timeout: 246 seconds] 14:46 < sipa> jimpo: fair 14:47 < sipa> still, the actual filter is in 158 14:50 < jimpo> Eh, the data type corresponding to the BlockFilter struct is in 157 (the cfilter response) 14:50 < achow101> webuser3254: rescanning requires the full blockchain. if you are pruned, you don't have the full blockchain so you can't rescan. you could use scantxoutset to get all of the utxos for our private keys and then create a raw transaction using those 14:50 < jimpo> and the index PR only never does any encoding/decoding of the filter byte vector 14:51 < jimpo> but I agree it's kind of in the middle of the two 14:51 < sipa> yeah 14:57 -!- ThomasLuong [~ThomasLuo@139.178.69.71] has joined #bitcoin-core-dev 14:58 < webuser3254> achow101, thank you but somehow craeting raw transaction sounds complicated to me right now... my bad again for spamming this channel. 14:59 < webuser3254> thanks for all the work guys! 15:01 -!- obsrver [~quassel@p5DC6BB91.dip0.t-ipconnect.de] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 15:04 -!- webuser3254 [3e1cd796@gateway/web/freenode/ip.62.28.215.150] has quit [] 15:07 -!- F1nny_ [F1nny@gateway/vpn/privateinternetaccess/f1nny] has joined #bitcoin-core-dev 15:10 -!- F1nny__ [F1nny@gateway/vpn/privateinternetaccess/f1nny] has quit [Ping timeout: 272 seconds] 15:14 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Read error: Connection reset by peer] 15:22 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection] 15:26 -!- ThomasLuong [~ThomasLuo@139.178.69.71] has quit [Ping timeout: 246 seconds] 15:28 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has quit [Remote host closed the connection] 15:28 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has joined #bitcoin-core-dev 15:29 -!- ctrlbreak_MAD is now known as ctrlbreak 15:32 -!- ThomasLuong [~ThomasLuo@96.79.113.225] has joined #bitcoin-core-dev 15:34 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has quit [Read error: Connection reset by peer] 15:36 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has joined #bitcoin-core-dev 15:41 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 15:44 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev 15:44 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Remote host closed the connection] 15:52 -!- mol [86ffafa7@gateway/web/freenode/ip.134.255.175.167] has joined #bitcoin-core-dev 15:53 -!- mol is now known as Guest61154 15:53 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 15:56 -!- Guest61154 [86ffafa7@gateway/web/freenode/ip.134.255.175.167] has quit [Ping timeout: 256 seconds] 15:59 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev 16:05 -!- makey40 [~jodie@24.215.123.241] has quit [Read error: Connection reset by peer] 16:07 -!- F1nny__ [F1nny@gateway/vpn/privateinternetaccess/f1nny] has joined #bitcoin-core-dev 16:10 -!- F1nny_ [F1nny@gateway/vpn/privateinternetaccess/f1nny] has quit [Ping timeout: 252 seconds] 16:11 -!- jarthur [~jarthur@207.114.244.5] has quit [] 16:11 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev 16:13 -!- makey40 [~jodie@24.215.123.241] has joined #bitcoin-core-dev 16:13 -!- makey40 [~jodie@24.215.123.241] has quit [Read error: Connection reset by peer] 16:15 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 16:16 -!- makey40 [~jodie@24.215.123.241] has joined #bitcoin-core-dev 16:17 -!- makey40 [~jodie@24.215.123.241] has quit [Read error: Connection reset by peer] 16:19 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 16:20 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 16:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 16:20 < bitcoin-git> [bitcoin] jnewbery opened pull request #15604: [docs] release note for disabling reject messages by default (master...release_notes_bip61) https://github.com/bitcoin/bitcoin/pull/15604 16:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 16:21 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 16:21 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 16:27 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 16:31 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection] 16:32 -!- makey40 [~jodie@24.215.123.241] has joined #bitcoin-core-dev 16:32 -!- makey40 [~jodie@24.215.123.241] has quit [Read error: Connection reset by peer] 16:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 16:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 16:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 16:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 16:39 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 16:43 -!- F1nny_ [F1nny@gateway/vpn/privateinternetaccess/f1nny] has joined #bitcoin-core-dev 16:43 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 16:43 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 16:44 -!- F1nny_ [F1nny@gateway/vpn/privateinternetaccess/f1nny] has quit [Remote host closed the connection] 16:45 -!- F1nny__ [F1nny@gateway/vpn/privateinternetaccess/f1nny] has quit [Ping timeout: 252 seconds] 16:45 -!- makey40 [~jodie@24.215.123.241] has joined #bitcoin-core-dev 16:46 -!- makey40 [~jodie@24.215.123.241] has quit [Read error: Connection reset by peer] 16:47 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 16:47 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 16:50 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 16:50 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 16:51 -!- makey40 [~jodie@24.215.123.241] has joined #bitcoin-core-dev 16:51 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 16:51 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 16:51 -!- makey40 [~jodie@24.215.123.241] has quit [Read error: Connection reset by peer] 16:52 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 245 seconds] 16:53 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 16:53 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 16:53 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 16:54 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 16:56 -!- makey40 [~jodie@24.215.123.241] has joined #bitcoin-core-dev 16:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 16:58 -!- makey40 [~jodie@24.215.123.241] has quit [Read error: Connection reset by peer] 16:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 16:59 -!- makey40 [~jodie@24.215.123.241] has joined #bitcoin-core-dev 16:59 -!- makey40 [~jodie@24.215.123.241] has quit [Read error: Connection reset by peer] 17:00 -!- makey40 [~jodie@24.215.123.241] has joined #bitcoin-core-dev 17:00 -!- makey40 [~jodie@24.215.123.241] has quit [Read error: Connection reset by peer] 17:02 -!- makey40 [~jodie@24.215.123.241] has joined #bitcoin-core-dev 17:02 -!- makey40 [~jodie@24.215.123.241] has quit [Read error: Connection reset by peer] 17:03 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 17:05 -!- ThomasLuong [~ThomasLuo@96.79.113.225] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 17:07 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 17:07 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds] 17:08 -!- zhangzf [~zhangzf@120.244.113.158] has joined #bitcoin-core-dev 17:12 -!- zhangzf [~zhangzf@120.244.113.158] has quit [Ping timeout: 246 seconds] 17:13 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 17:14 -!- OneFive [~OneFive@cpc87991-haye25-2-0-cust817.17-4.cable.virginm.net] has joined #bitcoin-core-dev 17:14 -!- millerti [~millerti@cpe-66-24-91-119.stny.res.rr.com] has quit [Quit: Textual IRC Client: www.textualapp.com] 17:20 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Remote host closed the connection] 17:20 -!- makey40 [~jodie@24.215.123.241] has joined #bitcoin-core-dev 17:21 -!- makey40 [~jodie@24.215.123.241] has quit [Read error: Connection reset by peer] 17:23 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 272 seconds] 17:32 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 17:32 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 17:35 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has quit [Remote host closed the connection] 17:42 -!- makey40 [~jodie@24.215.123.241] has joined #bitcoin-core-dev 17:42 -!- makey40 [~jodie@24.215.123.241] has quit [Read error: Connection reset by peer] 17:43 -!- jonatack [b9cee133@gateway/web/freenode/ip.185.206.225.51] has quit [] 17:44 -!- makey40 [~jodie@24.215.123.241] has joined #bitcoin-core-dev 17:44 -!- makey40 [~jodie@24.215.123.241] has quit [Read error: Connection reset by peer] 17:47 -!- makey40 [~jodie@24.215.123.241] has joined #bitcoin-core-dev 17:47 -!- makey40 [~jodie@24.215.123.241] has quit [Read error: Connection reset by peer] 17:50 -!- makey40 [~jodie@24.215.123.241] has joined #bitcoin-core-dev 17:54 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Ping timeout: 246 seconds] 17:56 -!- deepakmkathayat [chatzilla@nat/iiit/x-ncbadwklwgddfybm] has joined #bitcoin-core-dev 17:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 17:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 17:57 -!- deepakmkathayat is now known as dmkathayat 18:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 18:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 18:21 -!- zhangzf [~zhangzf@106.38.157.147] has joined #bitcoin-core-dev 18:22 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 18:24 < dmkathayat> Just getting started on core development and while reading through the functional tests, found a test rpc_net that isn't following the code style guidelines. 18:25 < sipa> dmkathayat: that is definitely possible 18:25 < dmkathayat> run_test() must come towards the end of the subclass? This one has it somewhere in the middle before helper methods. I can submit a Trivial PR. 18:26 < sipa> i'm glad to see your enthousiasm, but please don't 18:26 < sipa> from https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md: 18:26 < sipa> * Do not submit patches solely to modify the style of existing code. 18:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 245 seconds] 18:26 < dmkathayat> Got it! 18:27 < dmkathayat> I might pool it in with the long-term PR I'm starting on. 18:28 < fanquake> dmkathayat What are you working on in the long term PR? 18:29 < dmkathayat> sdaftuar has raised this issue in the past: https://github.com/bitcoin/bitcoin/issues/14210 18:30 < dmkathayat> I'm just starting to look at it. A testnet that could spin up a bunch of nodes with random IPs to test communication with outbound peers? 18:30 < fanquake> dmkathayat cool 18:31 < dmkathayat> Right now, I have a rudimentary setup using Docker containers. But here's an initial approach: 18:32 < dmkathayat> 1) Create example_testnet.py in functional tests 18:32 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 18:33 < dmkathayat> 2) Configure a Dockerfile and docker-compose.yml to have a bunch of nodes(initially a fixed number) and put them inside data/ 18:33 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 18:34 < dmkathayat> 3) Run example_testnet.py that would start a docker instance as a subprocess, with each node running a sample test. 18:36 < dmkathayat> If this is vague to understand, I'm finishing a PR that'd explain it in more detail. Please bear with me. 18:39 -!- ThomasLuong [~ThomasLuo@c-71-193-183-116.hsd1.or.comcast.net] has joined #bitcoin-core-dev 18:40 -!- ThomasLuong [~ThomasLuo@c-71-193-183-116.hsd1.or.comcast.net] has quit [Client Quit] 18:55 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 18:55 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 18:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 18:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 18:59 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 18:59 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 19:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 19:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 19:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 19:02 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 19:03 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 19:03 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 19:07 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 255 seconds] 19:10 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 19:10 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 19:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 19:20 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev 19:21 < dongcarl> dmkathayat: I think it'd be better if the tests were runnable even on machines that don't have docker installed 19:21 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 252 seconds] 19:22 < dongcarl> One route I was looking at today was doing this thru network namespaces 19:23 < dongcarl> Then on top of that, we basically want to do what Jepsen does, but perhaps without the Clojure dependency: https://github.com/jepsen-io/jepsen 19:24 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 19:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 19:25 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Ping timeout: 272 seconds] 19:29 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 19:34 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 252 seconds] 19:37 < dmkathayat> dongcarl: thanks for your comment 19:37 < dmkathayat> Could there be a hard limit to how complex a topology can be if we use network namespaces? 19:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 19:38 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 19:39 < dmkathayat> I imagine a docker-like solution could scale to any number of nodes and allow for all sorts of complex behavior 19:39 < dongcarl> dmkathayat: Hahaha the point of the network namespace _is_ so that we can make the topology as complex as we want 19:42 < dmkathayat> dongcarl: Hmm. So you're suggesting one could scale to a complex enough topology on their machine if they wanted? 19:42 < dongcarl> But maybe docker can work just as well, we need to think about how we'd interrupt comms between containers or simulate packet loss and such 19:42 -!- jarthur [~jarthur@2605:6000:1019:41ab:49ef:13c6:b980:b1de] has joined #bitcoin-core-dev 19:42 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 250 seconds] 19:42 < dongcarl> By the way... 19:42 < dongcarl> docker is using network namespaces behind the scenes 19:43 < dongcarl> with a veth to your default route iface I think 19:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 19:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 19:44 < dmkathayat> I was coming from the fact that docker would allow anyone to do that (take it to a cloud if they want and do advanced stuff). If namespaces can still do it, sure. 19:47 < dmkathayat> I don't know much about network namespaces, but I guess there should be a hard limit if you're just limited to one machine? Got to read up more on it 19:48 < dongcarl> dmkathayat: Well if you look deep enough, docker doesn't scale to "any number of nodes," it uses network namespaces as a backend 19:49 < dongcarl> Also nodes have to refer to each other by their IP addresses, so that's inherently limited 19:50 < dongcarl> I think by default every new namespace has loopback 19:50 < dongcarl> so that's a /8 for you 19:51 < dmkathayat> It may be the other way round. Docker allows you to refer other nodes by their hostname. That's how I've used it in the past. 19:51 < dmkathayat> IP addrs work as well 19:51 < dongcarl> hostnames are resolved to IPs 19:52 < sipa> dmkathayat: they may have a hostname each, but they still need a unique ip address too 19:52 < sipa> i also don't think you'll be running 256 bitcoinds on any reasonably-sized machine any time soon... 19:52 < sipa> so i doubt this is a problem 19:53 < dongcarl> Haha true 19:53 < dmkathayat> sure, yeah. I was wondering how big this needs to be. You said it! :) 19:53 < sipa> (or would there just be a single actual bitcoind, and a bunch of python-backed simulations for the other IP addresses?) 19:54 < gmaxwell> I'm not entirely sure how useful that sort of thing is, since those hosts will be in private space (e.g. RFC1918) and bitcoind handles those addresses specially. 19:54 < dongcarl> The other thing to consider is the issue brought up by sdaftuar, that bitcoind behaves differently when connecting to nodes on private/local subnets thru `IsLocal` detection 19:54 < gmaxwell> jinx 19:54 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds] 19:54 < dongcarl> Yup 19:55 < dongcarl> But perhaps in your own namespace you can just assign IPs to whatever you want? 19:55 < sipa> i'm sure things can be coerced to look like routable IPs 19:55 < gmaxwell> they can, at some risk of breakign crap for people running the tests. 19:55 < dongcarl> Not if they're in their own namespace! 19:56 < dongcarl> If they're in the root namespace... of course 19:56 < gmaxwell> well okay true, but then causing kind of inexplicable behavior when you can't reach the nodes you're testing because they're namespaced. :P 19:56 * gmaxwell proposes to assign them to the subnets of popular ad networks so at least if they leak they'll improve your browsing expirence by being unreachable on port 80/443. 19:57 < sipa> hahaha 19:57 < dongcarl> lolll 19:57 < dongcarl> we'll just document it well, and it'll be fine I think 19:57 < dmkathayat> I guess having some kind of isolation definitely helps 19:58 < dongcarl> I really wish we could integrate something like Jepsen, it seems quite flexible, but the extra dependency for people who want to test might be a no-go 19:59 < gmaxwell> please don't make some kind of vm/system image/anything that requires root be a pre-req for tests in general. For a special test that not everyone has to run, okay dokie, I'll just never run it. 20:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 20:01 < dongcarl> Yup, agreed 20:01 < dmkathayat> dongcarl: wouldn't you rather prefer having a docker dependency? And if docker uses namespaces anyway, why should we reinvent the wheel? 20:03 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 20:03 < dongcarl> dmkathayat: network namespaces ship with most Linux kernels 20:03 < dmkathayat> gmaxwell: thanks for chiming in with `isLocal` reference. 20:03 < dongcarl> docker does not and requires root 20:04 < dongcarl> (actually not sure if network namespaces require root but at least no dependency) 20:06 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 20:06 < sipa> pretty sure they do 20:06 < dongcarl> Ah, they require you to be added to `netns` group 20:06 < sipa> ah 20:07 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 20:08 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 20:08 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 20:08 < dmkathayat> dongcarl: are you working on network namespaces already? I'd love to help anyway I can. Tbh, I just wanted to get started on bitcoin 20:10 < dmkathayat> (if the `consensus` is not to go after docker.. haha) 20:10 < dongcarl> dmkathayat: Haven't started on it yet, feel free to do it 20:11 * sipa sees the word docker and gets an irrational "why does everything need to be in vms/containers/...?" reaction 20:11 < dmkathayat> dongcarl: sure 20:11 < sipa> (but given that i hardly know anything about it, you should probably disregard my opinion) 20:11 < jarthur> With network namespaces, do you get your own abstract namespace as well in Linux? You'd get a few million network addresses in that namespace once linux abstract sockets are supported. 20:12 < dongcarl> Not sure I understood the question 20:13 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 20:13 < sipa> jarthur: you're referring to unix sockets? they're not really a solution here, as the goal is testing a.o. the addrman peer selection logic etc 20:13 < sipa> which is specific to the public internet 20:14 < jarthur> got it, am still curious re the abstract namespace :) 20:15 < dongcarl> I don't know much about abstract namespaces sry 20:15 < dongcarl> Perhaps you can enlighten? 20:16 < dongcarl> Ah wait 20:16 < dongcarl> http://man7.org/linux/man-pages/man7/network_namespaces.7.html 20:17 < jarthur> They're like file path Unix sockets, except are known only to the networking stack and not the file system, and are permisionless. Very high performance to work with and you get a massive number of possible address combinations, but in the end, yea, Unix socket family and not applicable to this use case. 20:17 < jarthur> Not supported by Windows unix sockets or macOS either 20:18 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 20:18 < dongcarl> "network namespaces isolate the UNIX domain abstract socket namespace" 20:18 < jarthur> sweet 20:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 20:20 < dmkathayat> sipa: the issue sdaftaur had created (14210) had "containers" somewhere in there. I translated that to mean docker :P 20:23 < sipa> dmkathayat: ha, that's fait 20:36 < jarthur> I'm taking a look at unix socket support for RPC again, am trying to figure out the best way to convey an abstract socket in bitcoind.conf or at the command line. In Linux, you prepend the socket path name with a null byte to hint to the kernel that it's abstract, but it seems wrong to have folks enter a control char at the command line or in the conf file even if it is valid UTF-8. 20:42 < jarthur> Maybe better to not support it at first, figure it out later. 20:43 < dongcarl> jarthur: Maybe take a look at how ssh does it? 20:45 < dongcarl> I know some apps use `unix://` vs `tcp://` to differentiate 20:46 < dongcarl> but you probably just add a separate option if you want 20:47 < jarthur> Looks like procfs and curl use @ symbol. Couldn't find an escape sequence for OpenSSH; it may not support it officially. 20:51 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 20:54 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 20:55 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 20:59 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 255 seconds] 21:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 21:08 -!- Deadhand [~deadhand@kntaon1614w-grc-11-76-66-96-100.dsl.bell.ca] has quit [Ping timeout: 258 seconds] 21:08 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Ping timeout: 256 seconds] 21:09 -!- ExtraCrispy [~ExtraCris@gateway/tor-sasl/extracrispy] has quit [Ping timeout: 256 seconds] 21:09 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 256 seconds] 21:09 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 256 seconds] 21:09 -!- arubi_ [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 256 seconds] 21:10 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 21:10 -!- Deadhand [~deadhand@kntaon1614w-grc-11-76-66-96-100.dsl.bell.ca] has joined #bitcoin-core-dev 21:10 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev 21:11 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 21:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 21:13 < bitcoin-git> [bitcoin] ken2812221 closed pull request #14464: refactor: make checkqueue manage the threads by itself (also removed some boost dependencies) (master...drop-boost-cond) https://github.com/bitcoin/bitcoin/pull/14464 21:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 21:15 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev 21:15 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 252 seconds] 21:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 21:27 -!- jimmysong [~jimmysong@72-48-253-51.dyn.grandenetworks.net] has quit [Read error: Connection reset by peer] 21:27 -!- jimmysong [~jimmysong@72-48-253-51.dyn.grandenetworks.net] has joined #bitcoin-core-dev 21:28 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 252 seconds] 21:31 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev 21:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 21:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 21:39 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 21:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 21:45 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 272 seconds] 21:56 -!- mesnia [49d333bb@gateway/web/freenode/ip.73.211.51.187] has joined #bitcoin-core-dev 21:57 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 21:57 -!- mesnia [49d333bb@gateway/web/freenode/ip.73.211.51.187] has quit [Client Quit] 22:00 -!- AndroUser [androirc@nat/iiit/x-wjsvdhpvnyblsaqm] has joined #bitcoin-core-dev 22:01 -!- dmkathayat [chatzilla@nat/iiit/x-ncbadwklwgddfybm] has quit [Quit: ChatZilla 0.9.93 [SeaMonkey 2.49.4/20180711183816]] 22:02 -!- AndroUser is now known as dmkathayat 22:09 -!- dmkathayat [androirc@nat/iiit/x-wjsvdhpvnyblsaqm] has quit [Ping timeout: 245 seconds] 22:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds] 22:11 -!- jimmysong [~jimmysong@72-48-253-51.dyn.grandenetworks.net] has quit [Read error: Connection reset by peer] 22:12 -!- AndroUser [~androirc@2405:204:6287:2698::1874:28a0] has joined #bitcoin-core-dev 22:15 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection] 22:23 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 22:24 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 22:25 -!- Woodsy [~Woodsy@101.161.80.236] has joined #bitcoin-core-dev 22:25 -!- Woodsy [~Woodsy@101.161.80.236] has quit [Client Quit] 22:26 -!- Woodsy [~Woodsy@101.161.80.236] has joined #bitcoin-core-dev 22:28 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 22:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 22:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 22:32 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 22:35 -!- Woodsy [~Woodsy@101.161.80.236] has quit [] 22:35 -!- Woodsy [~Woodsy@101.161.80.236] has joined #bitcoin-core-dev 22:37 -!- AndroUser [~androirc@2405:204:6287:2698::1874:28a0] has quit [Ping timeout: 252 seconds] 22:42 < fanquake> Have i jumped the gun with #15584 ? Otherwise looking for a Concept ACK 22:42 < gribble> https://github.com/bitcoin/bitcoin/issues/15584 | build: disable BIP70 support by default by fanquake · Pull Request #15584 · bitcoin/bitcoin · GitHub 22:49 -!- dmkathayat [~androirc@167.220.238.187] has joined #bitcoin-core-dev 22:56 < fanquake> wumpus Are we going straight to rc3 given that #15602 has been merged? 22:56 < gribble> https://github.com/bitcoin/bitcoin/issues/15602 | 0.18: [p2p] Enable reject messages by default by jnewbery · Pull Request #15602 · bitcoin/bitcoin · GitHub 22:57 < fanquake> eh, guess we dont actually have to skip ahead. 23:15 -!- tianling [2a784a68@gateway/web/freenode/ip.42.120.74.104] has joined #bitcoin-core-dev 23:16 -!- tianling [2a784a68@gateway/web/freenode/ip.42.120.74.104] has quit [Client Quit] 23:18 < wumpus> huh no I didn't tag rc2 yet did I? 23:18 < wumpus> everyone seems to be so convinced that I did that I'm starting to doubt myself lol 23:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 23:28 < gmaxwell> lol 23:28 < gmaxwell> sorry, my fault I saw you bump the version and thought that was the tagging. 23:32 < fanquake> wumpus yea I thought it'd been done after seeing the version bump in the branch, sorry 23:42 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds] 23:45 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 23:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds] 23:57 < gmaxwell> hurrah, I'm not the only gun jumper --- Log closed Fri Mar 15 00:00:16 2019