--- Day changed Thu Dec 14 2017
00:02 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-npacjptaivvdesbu] has joined #bitcoin-core-dev     
00:04 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
00:26 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-npacjptaivvdesbu] has quit [Ping timeout: 240 seconds]     
00:27 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
00:55 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 252 seconds]     
00:55 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
00:56 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
00:56 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
00:58 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev     
00:59 -!- tiagotrs [~tiago@pD9FD6A94.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
00:59 -!- tiagotrs [~tiago@pD9FD6A94.dip0.t-ipconnect.de] has quit [Changing host]     
00:59 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-core-dev     
01:02 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Ping timeout: 256 seconds]     
01:02 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
01:04 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Remote host closed the connection]     
01:08 -!- Xanukkah [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Read error: Connection reset by peer]     
01:08 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
01:10 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Read error: Connection reset by peer]     
01:11 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
01:13 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
01:13 -!- JackH [~laptop@cbg156.neoplus.adsl.tpnet.pl] has quit [Ping timeout: 240 seconds]     
01:16 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-core-dev     
01:17 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
01:18 -!- xmsx [4e24bd68@gateway/web/freenode/ip.78.36.189.104] has quit [Quit: Page closed]     
01:27 -!- JackH [~laptop@91.189.61.70] has joined #bitcoin-core-dev     
01:28 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
01:29 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev     
01:29 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has joined #bitcoin-core-dev     
01:31 < promag> wumpus: I guess #11864 is ready
01:31 < gribble> https://github.com/bitcoin/bitcoin/issues/11864 | Make CWallet::FundTransaction atomic by promag · Pull Request #11864 · bitcoin/bitcoin · GitHub
01:34 < wumpus> thanks, will take a look
01:39 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/d4991c0cbb8a...2ae58d5bfb76
01:39 < bitcoin-git> bitcoin/master 95d4450 João Barbosa: [wallet] Tidy up CWallet::FundTransaction
01:39 < bitcoin-git> bitcoin/master 03a5dc9 João Barbosa: [wallet] Make CWallet::FundTransaction atomic
01:39 < bitcoin-git> bitcoin/master 2ae58d5 Wladimir J. van der Laan: Merge #11864: Make CWallet::FundTransaction atomic...
01:39 < bitcoin-git> [bitcoin] laanwj closed pull request #11864: Make CWallet::FundTransaction atomic (master...2017-12-atomic-fundtransaction) https://github.com/bitcoin/bitcoin/pull/11864
01:42 -!- mrfrasha_ [~mrfrasha@66.188.250.34] has quit [Quit: mrfrasha_]     
01:45 -!- BGL [fourty@75-149-171-58-Washington.hfc.comcastbusiness.net] has quit [Ping timeout: 255 seconds]     
02:01 < bitcoin-git> [bitcoin] JavadSM closed pull request #11843: Use python not 'python2' (master...master) https://github.com/bitcoin/bitcoin/pull/11843
02:06 < bitcoin-git> [bitcoin] JavadSM opened pull request #11895: Moving to python3 (master...master) https://github.com/bitcoin/bitcoin/pull/11895
02:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:09 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds]     
02:13 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 240 seconds]     
02:16 -!- quantbot [~quantbot@ool-2f125d98.dyn.optonline.net] has joined #bitcoin-core-dev     
02:19 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
02:20 < promag> can I get your attention to #11041 ?
02:20 < gribble> https://github.com/bitcoin/bitcoin/issues/11041 | Add LookupBlockIndex by promag · Pull Request #11041 · bitcoin/bitcoin · GitHub
02:21 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Read error: Connection reset by peer]     
02:22 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
02:26 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
02:28 < wumpus> sure
02:30 < promag> ty     
02:34 -!- quantbot [~quantbot@ool-2f125d98.dyn.optonline.net] has quit [Remote host closed the connection]     
02:41 < wumpus> promag: you add some lock(cs_main), were these missing before?
02:41 < wumpus> you don't mention any lock bug fixes, which is why I ask
02:44 -!- kiss- [~kiss@84.232.203.232] has joined #bitcoin-core-dev     
02:45 -!- xmsx [5c65b5b7@gateway/web/freenode/ip.92.101.181.183] has joined #bitcoin-core-dev     
02:48 -!- alfa [uid11513@gateway/web/irccloud.com/x-axjgczrwriikiprh] has joined #bitcoin-core-dev     
02:57 -!- Kozuch [~Kozuch@81.0.198.168] has joined #bitcoin-core-dev     
02:58 -!- quantbot [~quantbot@ool-2f125d98.dyn.optonline.net] has joined #bitcoin-core-dev     
03:02 -!- BGL [ninety@75-149-171-58-Washington.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
03:08 -!- whphhg [~whphhg@unaffiliated/whphhg] has quit [Remote host closed the connection]     
03:08 -!- whphhg [~whphhg@unaffiliated/whphhg] has joined #bitcoin-core-dev     
03:10 -!- BGL [ninety@75-149-171-58-Washington.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds]     
03:11 -!- Deadhand [~deadhand@CPE6038e0be3871-CMf0f249a14e40.cpe.net.cable.rogers.com] has quit [Ping timeout: 260 seconds]     
03:11 -!- Deadhand [~deadhand@CPE6038e0be3871-CMf0f249a14e40.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev     
03:12 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
03:13 -!- quantbot [~quantbot@ool-2f125d98.dyn.optonline.net] has quit [Remote host closed the connection]     
03:24 -!- quantbot [~quantbot@ool-2f125d98.dyn.optonline.net] has joined #bitcoin-core-dev     
03:25 < promag> wumpus: yes missing locks
03:26 < promag> not sure if all are bugs because some come from the init & load block index etc
03:26 < wumpus> ok, please mention that in the issue, we should mark it as bugfix and not only refactor
03:27 < wumpus> yes the ones in init are probably not so relevant, but there is one in wallet too
03:27 < promag> but FindForkInGlobalIndex I think it's a bug
03:28 < wumpus> good, thanks for finding and fixing
03:34 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
03:38 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
03:50 < JackH> is there a limitation to how many addresses Bitcoin Core can generate for a given wallet? We issue about 500 new addresses per day, some which are used, some which are not, but is there a limit per wallet? 
03:51 < wumpus> the software has no limit
03:51 < xmsx> I tested a wallet with 300k addresses once
03:53 < wumpus> at some point you might run into resource issues, things going slower
03:55 < JackH> we thought about 300k actually being where we would see problems
03:55 < JackH> we are soon hitting that
03:55 < JackH> would there be any difference between HD wallets and non HD wallets in terms of speed?
03:56 < wumpus> I'd be more worried about the amount of transactions, not so much the number of keys, keys are small
03:56 < JackH> so about 40% are transactions
03:56 < JackH> meaning roughly 120k transactions are stored right now
03:57 < JackH> do we know the bottleneck?
03:57 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 256 seconds]     
03:58 < wumpus> bitcoin core's wallet is not optimized for handling huge numbers of transactions, for example it keeps them all in memory, and doesn't at the moment have an utxo index. There has been work in that direction but any help is welcome.
03:59 < wumpus> as for what the limits are for your cpu/amount of memory, try it out on a development machine
04:02 < xmsx> Also, I would suggest discussing these questions from throwaway account (No one really needs to know that you store all addresses in single wallet) :)
04:05 < wumpus> e.g. using regtest, you can generate tons of transactions and blocks in a relatively small time
04:05 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
04:05 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
04:08 < promag> wumpus: JackH: actually the number of addresses has a great impact on performance
04:09 < wumpus> it has an impact on performance, but what he asked is whether there's a limit
04:09 -!- BGL [twenty@75-149-171-58-Washington.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
04:10 -!- kiss- [~kiss@84.232.203.232] has quit []     
04:12 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Remote host closed the connection]     
04:32 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Ping timeout: 264 seconds]     
04:46 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]     
04:48 < JackH> we are looking to run multiple daemons as a solution
04:49 -!- gmaxwell [gmaxwell@wikimedia/KatWalsh/x-0001] has quit [Ping timeout: 240 seconds]     
04:49 < JackH> and retire daemons as they hit performance issues
04:49 < JackH> daemons//wallets
04:50 -!- gmaxwell [gmaxwell@mf4-xiph.osuosl.org] has joined #bitcoin-core-dev     
04:51 -!- gmaxwell is now known as Guest52242     
04:51 -!- guest123 [509914bd@gateway/web/freenode/ip.80.153.20.189] has joined #bitcoin-core-dev     
04:53 -!- guest123 [509914bd@gateway/web/freenode/ip.80.153.20.189] has left #bitcoin-core-dev []     
04:56 < kabaum_> Is it possible that there are other yet unknown ways to malleate a signature than the "-S" trick? Or maybe even known ones? I refer only to inherent ECDSA signature malleability.
05:07 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
05:10 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
05:13 -!- Pavle [~pavle_@unaffiliated/pavle/x-4679000] has joined #bitcoin-core-dev     
05:13 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-core-dev     
05:18 < xmsx> Could anyone review changes to segwitsupport.csv (bitcoincore.org repo) please? Using P2SH-P2WPKH addresses atm but will add bech32 soon too :)
05:18 < wumpus> kabaum_: yes that is possible (might be better to ask in #bitcoin-wizards)
05:19 -!- PaulCapestany [~PaulCapes@ip68-100-207-91.dc.dc.cox.net] has joined #bitcoin-core-dev     
05:24 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds]     
05:37 -!- To7 [~theo@68.129.242.238] has joined #bitcoin-core-dev     
05:37 -!- kuldeeps48 [9d77aa37@gateway/web/freenode/ip.157.119.170.55] has joined #bitcoin-core-dev     
05:40 -!- kuldeeps48 [9d77aa37@gateway/web/freenode/ip.157.119.170.55] has quit [Client Quit]     
05:43 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-core-dev     
05:50 < kabaum_> wumpus: thanks
05:51 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
05:53 < Varunram> promag: http://www.kumobius.com/2013/08/c-string-to-int/ might help for #11897, comparing between various alternatives
05:53 < gribble> https://github.com/bitcoin/bitcoin/issues/11897 | Replace atoi64 with ParseInt64 · Issue #11897 · bitcoin/bitcoin · GitHub
05:53 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has quit []     
05:54 < Varunram> oh wait, disregard that, my bad
05:56 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-hepmstwikhajqboh] has quit [Quit: Connection closed for inactivity]     
05:57 -!- xmsx [5c65b5b7@gateway/web/freenode/ip.92.101.181.183] has quit [Quit: Page closed]     
05:58 -!- alfa [uid11513@gateway/web/irccloud.com/x-axjgczrwriikiprh] has quit [Quit: Connection closed for inactivity]     
06:00 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
06:05 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has joined #bitcoin-core-dev     
06:13 -!- PaulCapestany [~PaulCapes@ip68-100-207-91.dc.dc.cox.net] has quit [Ping timeout: 256 seconds]     
06:19 -!- Mlkk [~Mlk@145.129.219.245] has joined #bitcoin-core-dev     
06:22 -!- Mlkk is now known as Mlk     
06:38 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
06:45 -!- bgtc [5e8bca23@gateway/web/freenode/ip.94.139.202.35] has joined #bitcoin-core-dev     
06:47 -!- PaulCapestany [~PaulCapes@68.100.207.91] has joined #bitcoin-core-dev     
06:51 -!- JackH [~laptop@91.189.61.70] has quit [Quit: Leaving]     
06:52 -!- bgtc [5e8bca23@gateway/web/freenode/ip.94.139.202.35] has quit [Quit: Page closed]     
07:02 -!- Pavle [~pavle_@unaffiliated/pavle/x-4679000] has quit [Ping timeout: 260 seconds]     
07:09 -!- Mlk [~Mlk@145.129.219.245] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
07:26 -!- PaulCapestany [~PaulCapes@68.100.207.91] has quit [Quit: .]     
07:27 -!- freeark1 [75e2a6e5@gateway/web/freenode/ip.117.226.166.229] has joined #bitcoin-core-dev     
07:27 -!- Pavle [~pavle_@unaffiliated/pavle/x-4679000] has joined #bitcoin-core-dev     
07:28 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-core-dev     
07:31 -!- PaulCapestany [~PaulCapes@ip68-100-207-91.dc.dc.cox.net] has joined #bitcoin-core-dev     
07:32 -!- whphhg [~whphhg@unaffiliated/whphhg] has quit [Quit: Leaving]     
07:33 -!- whphhg [~whphhg@unaffiliated/whphhg] has joined #bitcoin-core-dev     
07:35 -!- PaulCapestany [~PaulCapes@ip68-100-207-91.dc.dc.cox.net] has quit [Quit: .]     
07:37 -!- Matt__ [48265b9e@gateway/web/freenode/ip.72.38.91.158] has joined #bitcoin-core-dev     
07:42 -!- PaulCapestany [~PaulCapes@68.100.207.91] has joined #bitcoin-core-dev     
07:42 -!- satoshi_1iv3s [8ac5a85a@gateway/web/freenode/ip.138.197.168.90] has joined #bitcoin-core-dev     
07:43 -!- satoshi_1iv3s [8ac5a85a@gateway/web/freenode/ip.138.197.168.90] has quit [Client Quit]     
07:45 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Quit: Leaving.]     
07:47 -!- mrfrasha_ [~mrfrasha@66.188.250.34] has joined #bitcoin-core-dev     
07:48 -!- CubicEarth [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
07:49 -!- CASEgezadthfr [~ZZXv@lmcfwa.ericsson.ca] has joined #bitcoin-core-dev     
07:51 -!- CubicEarth [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Client Quit]     
07:53 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 272 seconds]     
07:54 -!- edman80 [~edman80@pool-173-70-115-60.nwrknj.fios.verizon.net] has quit [Quit: Leaving]     
07:55 -!- pkx2 [~pkx@unaffiliated/pkx] has joined #bitcoin-core-dev     
07:55 -!- freeark1 [75e2a6e5@gateway/web/freenode/ip.117.226.166.229] has quit [Ping timeout: 260 seconds]     
07:55 < BlueMatt> #11884 looks merge-able
07:55 < gribble> https://github.com/bitcoin/bitcoin/issues/11884 | Remove unused include in hash.cpp by kallewoof · Pull Request #11884 · bitcoin/bitcoin · GitHub
07:57 -!- Szadek [~Szadek@2001:ac8:28:d::3e] has joined #bitcoin-core-dev     
08:01 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2ae58d5bfb76...66479c0e611a
08:01 < bitcoin-git> bitcoin/master 3f09e03 Karl-Johan Alm: Remove unused include in hash.cpp
08:01 < bitcoin-git> bitcoin/master 66479c0 Wladimir J. van der Laan: Merge #11884: Remove unused include in hash.cpp...
08:01 -!- macumba [55de6626@gateway/web/freenode/ip.85.222.102.38] has joined #bitcoin-core-dev     
08:02 < bitcoin-git> [bitcoin] laanwj closed pull request #11884: Remove unused include in hash.cpp (master...20171213-unneeded-include-hash-cpp) https://github.com/bitcoin/bitcoin/pull/11884
08:02 < wumpus> yep     
08:03 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
08:09 -!- macumba [55de6626@gateway/web/freenode/ip.85.222.102.38] has quit [Quit: Page closed]     
08:21 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-core-dev     
08:24 -!- rfdavid_ [~rfdavid@ip-45-3-15-253.user.start.ca] has quit [Quit: Lost terminal]     
08:33 < BlueMatt> if someone wants to kill uselessly-trivial prs: #10839 could be merged
08:33 < gribble> https://github.com/bitcoin/bitcoin/issues/10839 | Dont use pass by reference to const for cheaply-copied types (bool, char, etc.) by practicalswift · Pull Request #10839 · bitcoin/bitcoin · GitHub
08:39 < cfields> #11842 is trivial and merge-ready too
08:39 < gribble> https://github.com/bitcoin/bitcoin/issues/11842 | [build] Add missing stuff to clean-local by kallewoof · Pull Request #11842 · bitcoin/bitcoin · GitHub
08:39 -!- promag [~promag@2.83.247.244] has joined #bitcoin-core-dev     
08:43 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/66479c0e611a...3c8f0a3b8e67
08:43 < bitcoin-git> bitcoin/master b341143 Karl-Johan Alm: [build] Add missing stuff to clean-local...
08:43 < bitcoin-git> bitcoin/master 3c8f0a3 Wladimir J. van der Laan: Merge #11842: [build] Add missing stuff to clean-local...
08:43 < bitcoin-git> [bitcoin] laanwj closed pull request #11842: [build] Add missing stuff to clean-local (master...buildsys-cleanup) https://github.com/bitcoin/bitcoin/pull/11842
08:50 -!- promag [~promag@2.83.247.244] has quit [Remote host closed the connection]     
09:14 -!- Pavle [~pavle_@unaffiliated/pavle/x-4679000] has quit [Ping timeout: 272 seconds]     
09:21 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has joined #bitcoin-core-dev     
09:28 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3c8f0a3b8e67...c66adb286a89
09:28 < bitcoin-git> bitcoin/master 99ba0c3 practicalswift: Don't use pass by reference to const for cheaply-copied types (bool, char, etc.).
09:28 < bitcoin-git> bitcoin/master c66adb2 Wladimir J. van der Laan: Merge #10839: Don't use pass by reference to const for cheaply-copied types (bool, char, etc.)...
09:28 < bitcoin-git> [bitcoin] laanwj closed pull request #10839: Don't use pass by reference to const for cheaply-copied types (bool, char, etc.) (master...dont-pass-by-reference-for-cheaply-copied-types) https://github.com/bitcoin/bitcoin/pull/10839
09:29 -!- Matt__ [48265b9e@gateway/web/freenode/ip.72.38.91.158] has quit [Quit: Page closed]     
09:35 -!- xmsx [5c65b5b7@gateway/web/freenode/ip.92.101.181.183] has joined #bitcoin-core-dev     
09:35 -!- timothy [tredaelli@redhat/timothy] has quit [Ping timeout: 240 seconds]     
09:42 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 255 seconds]     
09:50 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Ping timeout: 256 seconds]     
09:51 -!- Guest52242 [gmaxwell@mf4-xiph.osuosl.org] has quit [Changing host]     
09:51 -!- Guest52242 [gmaxwell@wikimedia/KatWalsh/x-0001] has joined #bitcoin-core-dev     
09:51 -!- Guest52242 is now known as gmaxwell     
09:55 -!- jtimon [~quassel@37.134.31.164] has joined #bitcoin-core-dev     
09:58 -!- maaku [~maaku@173.234.25.100] has joined #bitcoin-core-dev     
09:59 < maaku> the implementation of BIPs 98, 116, 117 could use some review:
09:59 < maaku> https://github.com/maaku/bitcoin/tree/merkle-branch-verify
09:59 < maaku> https://github.com/maaku/bitcoin/tree/tail-call-semantics
10:00 -!- jadee_ [~Jadee@50-248-173-75-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
10:00 < maaku> (together they implement the features needed for MAST, currently policy-only)
10:00 < wumpus> would be good to bring up in the meeting
10:02 < maaku> I believe kallewoof is going to make a PR when he's done reviewing it himself, but no harm in others taking a peek too
10:02 < Chris_Stewart_5> maaku: What's up with the goto in the tail-call-semantics? Isn't that pretty ill advised? 
10:04 < maaku> Chris_Stewart_5: goto is a funny thing. this is actually the one application goto is the best solution for, where the semantics are well-defined and is the easiest way to accomplish what is desired
10:04 < maaku> it's not possible to do tail-call recursion otherwise, and to my knowledge that's basically the reason goto still exists all these iterations of the C++ standard later
10:05 < Chris_Stewart_5> maaku: So I might be getting my 'tail-calls' mixed up, but does this goto keep a stack frames allocated during the recursive step? 
10:06 < Chris_Stewart_5> like tail recursion in a functional lang
10:07 < maaku> A new stack frame is not created for the call itself. Any changes to the stack are properly unwound, with destructors called for things that fall out of scope, or stack allocations made and constructors called for things you skip over in other applications of goto (not here)
10:07 -!- jamesob [~james@199.230.10.198] has joined #bitcoin-core-dev     
10:08 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Quit: laurentmt]     
10:08 < maaku> for example, if the `if {}` statement that had the goto had its own variable that was an instance of the class, the goto would have called the destructor and deallocated it before jumping up to the start of the function
10:09 < maaku> or as an actual example, vfExec is destroyed as part of the goto
10:09 < maaku> (and then recreated when execution reaches it again)
10:09 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ffghqbcwirlejdhg] has joined #bitcoin-core-dev     
10:11 -!- alreadylate [~textual@37-247-1-221.customers.ownit.se] has quit []     
10:11 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-ofwpdbqjqvhicyel] has joined #bitcoin-core-dev     
10:12 < maaku> from cppreference:
10:12 < maaku> > If transfer of control exits the scope of any automatic variables (e.g. by jumping backwards to a point before the declarations of such variables or by jumping forward out of a compound statement where the variables are scoped), the destructors are called for all variables whose scope was exited, in the order opposite to the order of their construction.
10:16 < Chris_Stewart_5> maaku: so why can't we just recursively call `EvalScript` inside of VerifyScript? 
10:16 < Chris_Stewart_5> and have a counter or whatever of how many recursive calls we have made
10:16 < Chris_Stewart_5> now that I re-read that i'm not sure if that made sense. 
10:16 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
10:17 < maaku> (1) that would require refactoring the EvalScript API to carry extra parameters (like the alt stack) as arguments; (2) that would not be safe if/when the limitation of single-recursion is dropped
10:18 < maaku> this is an easier, more targetted change that enables just the functionality required without large code changes, with well defined semantics (even if the use of goto is unusal)
10:18 -!- wxss [~user@184.75.212.158] has joined #bitcoin-core-dev     
10:18 < sipa> why not wrap the part you're jumping over in a loop?
10:18 < Chris_Stewart_5> ^     
10:19 < Chris_Stewart_5> or just recursively call EvalScript here? https://github.com/maaku/bitcoin/blob/tail-call-semantics/src/script/interpreter.cpp#L1050
10:19 < Chris_Stewart_5> maybe I am missing some goto functionality here, but it seems like it would be almost identical to just call EvalScritp() instead of using goto
10:20 < sipa> i admit there are use cases for goto, and dismissing it unconditionally is very much a cargo cult thing to do
10:20 < sipa> but i don't think you need it here
10:20 -!- jadee_ [~Jadee@50-248-173-75-static.hfc.comcastbusiness.net] has quit [Quit: This computer has gone to sleep]     
10:20 -!- xmsx [5c65b5b7@gateway/web/freenode/ip.92.101.181.183] has quit [Quit: Page closed]     
10:20 < maaku> Chris_Stewart_5: look at the altstack and nOpCount variables
10:22 < maaku> sipa: a do-while would be equivalent, if slightly more verbose, at the additional review cost of indenting 1000 lines of code
10:22 < maaku> that's up to kallewoof
10:23 < Chris_Stewart_5> maaku: Ah ok I think i see what you are saying. C++ allows for default args right? But I guess that is still pretty unfortunate 
10:23 < sipa> review with ?w=1 (in github) or -w (in git) makes indentation changes trivial to review
10:27 < maaku> sipa: I'm sure it would be a stumbling block for many still, unfortunately.
10:28 < sipa> maaku: i expect that a goto would be even more so
10:28 < sipa> the altstack trick is neat; it allows doing this without any new script versioning at all
10:28 < maaku> re: goto I guess it comes down to encoding semantic intent. a do {} while(!done) construct where done is a boolean variable set inside the loop under complex conditions is not a clearer encoding of the semantic intent, which is to restart execution of the function from the beginning
10:29 < maaku> this is why I am handing it over to kallewoof though, who will make the call on making such changes
10:29 < sipa> ok     
10:30 < maaku> yes, and I have another simple soft-fork that recovers script versioning inside the witness itself, which would allow us to later remove the altstack trick without needing a new "script version" as presently defined
10:32 < sipa> i'm still very unconfortable with needing code execution before knowing what code is executable, though
10:33 < maaku> ?     
10:34 < sipa> you don't distinguish code and data
10:35 < sipa> anything can be either, up to the end of the (top level) program
10:35 < maaku> I mean what are your concerns?
10:35 < sipa> static analysis
10:35 < maaku> (as a lisper I have no sympathy for that general concern ;) )
10:35 < sipa> haha
10:35 < maaku> static analysis of what, limits? those are gone in this iteration
10:36 < sipa> can you enumerate all possible code paths ahead of time?
10:36 -!- jadee_ [~Jadee@50-248-173-75-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
10:39 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Ping timeout: 256 seconds]     
10:42 < maaku> yes     
10:43 < maaku> I'm not sure if that's generally provable in the sense that you can show non-decidable scripts aren't possible to write
10:43 < maaku> but the way this is anticipated to be used, and especially with only single recursion, it is straightforward to show all possible code paths
10:43 < sipa> well there are certainly trivial counterexamples, like just "OP_0 OP_TOALTSTACK"
10:44 < sipa> which permits executing anything?
10:45 < maaku> I expect actual deployment to be of the form [root 1 MERKLEBRANCHVERIFY 2DROP 2DROP N*TOALTSTACK] with [argN ... arg1 script proof] as the witness
10:45 < maaku> it's trivial to show all code paths there -- expand the merkle tree
10:45 < sipa> fair enough
10:46 < sipa> i would just be more confortable with having that property guaranteed
10:46 < maaku> (actually [root 2 MERKLEBRANCHVERIFY] for anyone paying close attention)
10:47 < maaku> it's guaranteed in that construct, or related constructs
10:48 -!- jadee_ [~Jadee@50-248-173-75-static.hfc.comcastbusiness.net] has quit [Quit: This computer has gone to sleep]     
10:48 < maaku> I guess I'm not understanding why this is a concern -- is there something you are worried about? witness malleability?
10:49 < sipa> i'm not worried, i'm uneasy
10:49 < sipa> just the thought of having code be subject to other code seems so hard to reason about
10:50 < maaku> well keep in mind that tail recursion can only add spend conditions
10:50 < sipa> but counts towards sigops
10:51 -!- jadee_ [~Jadee@50.248.173.75] has joined #bitcoin-core-dev     
10:51 < maaku> nope
10:51 < sipa> nope?
10:52 < maaku> tail recursion policy scripts do not add to any aggregate limits, including sigops. see bip 117
10:52 < sipa> ouch
10:53 < maaku> not really. the worst you could possibly do with a 4MB block is 30s of signature verification, which could be dropped to 1-2s with a reasonable fix
10:53 < maaku> so why do we maintain these limits going forward?
10:53 < sipa> that's utterly unacceptable
10:54 < maaku> it's less than other attack vectos we can't do much about, with the fix in place at least, and it costs 1 block's worth of fee income to perform
10:54 < jonasschnelli> sipa: when I'm scanning the UTXO set with the CCoinsViewCursor (while, cursor.Next()) is there a way to calculate the progress? Similar to your https://github.com/bitcoin/bitcoin/blob/master/src/txdb.cpp#L387?
10:55 < maaku> sipa: I suggest actually running the numbers and seeing how much of an issue it is for yourself
10:55 < sipa> maaku: *seconds* of CPU time?
10:55 < sipa> for a block?
10:55 < sipa> what other attack vectors
10:56 < maaku> conservative (high) estimates for a worst-case adversarially constructed block that is nothing but signature verifications
10:56 < maaku> I'm not sure why this is surprising You can fit 64k signatures in a 4MB block
10:57 < maaku> it would take a few seconds to verify 64k signatures
10:57 < sipa> well the concern is that you may construct signatures in less than 70ish byte per check
10:58 < sipa> but i guess your fix is relying on caching to avoid that
10:58 < sipa> which probably works
10:58 < maaku> or the trivial fix I alluded to above -- a per-script sigop limit of size(script+witness)/72
10:58 < sipa> ah, i missed that
10:59 < maaku> I didn't say it, but that's what I was alluding to. Might not be easy to be per-input with sigagg, but could still be a per-tx limit
10:59 < sipa> still, if i'm reading things correctly, it's the outer script's sigop limit that is discarded; the inner sceipt still counts?
11:00 < wumpus> #startmeeting
11:00 < lightningbot> Meeting started Thu Dec 14 19:00:30 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:00 < maaku> opposite. the sigops are picked up by static analysis of the outer script, which if it only contains a NOP4 (MBV) and stack oeprations is 0
11:00 < jtimon> hi     
11:00 -!- jadee_ [~Jadee@50.248.173.75] has quit [Quit: This computer has gone to sleep]     
11:00 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag
11:00 < jonasschnelli> hi     
11:00 < achow101> hi     
11:01 < kanzure> hi.     
11:01 < cfields> hi     
11:01 < wumpus> #topic high priority for review
11:01 < wumpus> #link https://github.com/bitcoin/bitcoin/projects/8
11:01 < Provoostenator> hi     
11:01 < sipa> hi     
11:01 < luke-jr> multiwallet gui can be added back in
11:01 < BlueMatt> #11639
11:01 < gribble> https://github.com/bitcoin/bitcoin/issues/11639 | Rewrite the interface between validation and net_processing wrt DoS by TheBlueMatt · Pull Request #11639 · bitcoin/bitcoin · GitHub
11:02 < wumpus> I think we managed to merge two high-priority PRs this week, woohoo
11:02 < sipa> woohoo
11:02 < wumpus> now all we really want is #11403 :)
11:02 < gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
11:02 < jnewbery> hi     
11:02 < jonasschnelli> Added #11383 to the high prio project
11:02 < gribble> https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub
11:03 < cfields> should've named it "trivial SegWit wallet support". Those get merged quicker :)
11:03 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
11:03 < jonasschnelli> hah     
11:03 < wumpus> segwit wallet before multiwallet please :)
11:03 < promag> hi     
11:03 < jonasschnelli> Yes. 11383 needs more reviews first
11:03 < achow101> I'll actually start working on #10367 again after finals this week
11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/10367 | [test] Test abortrescan command. by kallewoof · Pull Request #10367 · bitcoin/bitcoin · GitHub
11:04 < achow101> *#10637
11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub
11:04 < BlueMatt> we're getting really close on #11281 which is also high-prio and I think also #10387
11:04 < BlueMatt> so thats nice
11:04 < wumpus> added BlueMatt #11639
11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/10387 | Eventually connect to NODE_NETWORK_LIMITED peers by jonasschnelli · Pull Request #10387 · bitcoin/bitcoin · GitHub
11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/11639 | Rewrite the interface between validation and net_processing wrt DoS by TheBlueMatt · Pull Request #11639 · bitcoin/bitcoin · GitHub
11:05 < wumpus> yep, getting there
11:05 < BlueMatt> ryanofsky: asked for #11687
11:05 < gribble> https://github.com/bitcoin/bitcoin/issues/11687 | External wallet files by ryanofsky · Pull Request #11687 · bitcoin/bitcoin · GitHub
11:06 < wumpus> added
11:06 < wumpus> but let's focus on segwit wallet please
11:06 < BlueMatt> yea, I mean there's also like 3 or 4 bugs on master that need fixing for 0.16...
11:06 < wumpus> all the other things are nice but what people really want at this point is segwit wallet
11:07 < wumpus> I get bothered a lot about it so I'm happy to pass it on :p
11:07 < wumpus> other topics?
11:08 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
11:08  * BlueMatt notes that things needed for 0.16 are at least #11888 (does not yet have pr), #11822 (pr 11824) and #11512
11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/11888 | Prevent Opening Wallets Simultaneously in Two Instances · Issue #11888 · bitcoin/bitcoin · GitHub
11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/11822 | Severe memory leak on current master · Issue #11822 · bitcoin/bitcoin · GitHub
11:08 < promag> will sipa include Qt changes in #11403?
11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/11512 | Use GetDesireableServiceFlags in seeds, dnsseeds, fixing static seed adding by TheBlueMatt · Pull Request #11512 · bitcoin/bitcoin · GitHub
11:08 < wumpus> #action merge segwit wallet
11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
11:08 < jnewbery> Quick topic: can I shill for the Coredev tech days in New York, March 5th-7th?
11:09 < wumpus> #topic coredev tech announcement
11:09 < BlueMatt> jnewbery: I think you just did
11:09 < cfields> woohoo!
11:09 < jnewbery> I've sent invites to everyone I think contributes regularly to Bitcoin Core or lightning implementations. If you think you should have got an invite and haven't, plese message me
11:09 < BlueMatt> put it on your calendar! week after fc so book your flights back via ny!
11:09 < jonasschnelli> I think I should merge https://github.com/coredev-tech/coredev-dot-tech/pull/1
11:10 < achow101> is it up on coredev.tech yet?
11:10 < jnewbery> jonasschnelli: yes please!
11:10 < jonasschnelli> jnewbery: have you invited promag?
11:10 < jnewbery> jonasschnelli: yes
11:10 -!- alreadylate [~textual@customer-46-39-118-13.stosn.net] has joined #bitcoin-core-dev     
11:11 < promag> yes he did
11:11 < jnewbery> that's all my shilling :)
11:11 < luke-jr> proposed topic: status of meeting summaries on the website
11:11 < jonasschnelli> Thanks for organising jnewbery! To bad I can't attend.... 
11:12 < maaku> jnewbery: New York is a big place. Where is it?
11:12 < wumpus> BlueMatt: seems they were already tagged for 0.16 except #11824
11:12 < gribble> https://github.com/bitcoin/bitcoin/issues/11824 | Block ActivateBestChain to empty validationinterface queue by TheBlueMatt · Pull Request #11824 · bitcoin/bitcoin · GitHub
11:12 < sipa> that needs tagging
11:12 < jnewbery> sorry jonas :( 
11:12 < jonasschnelli> jnewbery: keep the location discolued
11:12 < luke-jr> maaku: "We're still working on final confirmation for the location, but it's almost certain to be in Lower Manhattan, close to The Battery."
11:12 < jonasschnelli> *disclosed
11:12 < luke-jr> oops
11:12 < wumpus> better to send the address in private 
11:12 < BlueMatt> wumpus: yes, I'm aware, I was pointing out that those three are issues which fix current master bugs ie are blocking 0.16, unlike much of the 0.16 tagged things
11:12 < maaku> "Lower Manhatten, close to The Battery" was all I was looking for
11:12 < luke-jr> hopefully that wasn't too much detail
11:13 < wumpus> BlueMatt: yeah if there's things tagged 0.16 that shouldn't be, let me know
11:13 < wumpus> BlueMatt: I'll bump them to 0.17
11:13 < BlueMatt> "whatever makes it in", right? :p
11:14 < instagibbs> oh meeting, hi
11:14 < wumpus> yes, but if it shouldn't hold up the release it shouldn't really be tagged w/  specific release
11:14 < jtimon> so after #11403 gets merged, what's the timeline for "whatever makes it in" ?
11:14 < gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
11:14 -!- TheSadFace [~TheSadFac@unaffiliated/thesadface] has joined #bitcoin-core-dev     
11:14 < luke-jr> wumpus: then why tag anything? :p
11:14 < BlueMatt> wumpus: heh, ok, so lets see, untag 7664, 7729, 7949, 7955, 8501, 9502, 9728....yea, pretty much everything there
11:14 -!- bule [~bule@gateway/tor-sasl/bule] has joined #bitcoin-core-dev     
11:15 < wumpus> after 11403 makes it in we should go to bugfixing only
11:15 < luke-jr> even Segwit wallet is a "early release trigger", not a blocker ;)
11:15 < jtimon> wumpus: I see
11:15 < BlueMatt> most 0.16-tagged things really dont need a tag
11:15 < sipa> wumpus: i guess that means we shouldn't have tags for future releases
11:15 < sipa> only for backport branches
11:15 < BlueMatt> we should just have a "fixes current master bug" tag which has to be cleared for each release
11:15 < wumpus> sipa: unless they're bugfixes that really need to get in
11:16 < BlueMatt> or i guess stop tagging things that dont fit into that category
11:16 < jonasschnelli> Mabe a tag for "aims for next release"?
11:16 < wumpus> well, github has milestones, not 'current master'
11:16 < BlueMatt> jonasschnelli: doesnt everything aim for next release?
11:16 < wumpus> at least now they will stick which is useful for historical reference
11:16 < BlueMatt> i mean occasionally not, but its rare
11:16 < jonasschnelli> BlueMatt: that is a good questions... or "candidate for next release"?
11:17 < wumpus> the 'future' milestone is for unlikely things that need a lot more work
11:17 < wumpus> so probably not next release
11:18 < gmaxwell> release candidate on tuesday then?
11:18 < sipa> wumpus: perhaps a tag "release blocker" rather than a spdcific version milestone is better for those?
11:18 < jonasschnelli> Usually agile development works with "priorities"..
11:18 < luke-jr> jonasschnelli: everything is a candidate if it gets enough review ;p
11:18 -!- jadee_ [~Jadee@50-248-173-75-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
11:18 < wumpus> sipa: I prefer a milestone, we have too many tags already
11:18 < sipa> ok     
11:18 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 264 seconds]     
11:18 < wumpus> sipa: at least this is displayed in a different place
11:18 < luke-jr> jonasschnelli: that assumes someone gets to decide priorities for other people
11:18 < sipa> right
11:18 < wumpus> ok, any real topics?
11:18 < jonasschnelli> luke-jr: Yes. Agree. It's kinda impossible
11:19 < wumpus> luke-jr: we have 'high priority' which we already discuss every week
11:19 < wumpus> there's no point in other priorities really
11:19 < luke-jr> [19:11:35] <luke-jr> proposed topic: status of meeting summaries on the website
11:19 < luke-jr> wumpus: sure, just pointing out it has its limits
11:19 < wumpus> #topic meeting summaries
11:19 < gmaxwell> I've been seeing highish connection counts, appears to be organic.  Non-listening nodes appear to have grown a lot in the last three months.
11:19 < achow101> luke-jr: what about the meeting summaries
11:19 < gmaxwell> Who called this meeting?
11:20 < sipa> ?     
11:20 < luke-jr> I don't actually know what's up with meeting summaries, but the last one was 2 months ago (with a huge gap before that), and people are wondering
11:20 < achow101> TheSadFace is the person I got to write them
11:21 < achow101> he's been doing them slowly
11:21 < BlueMatt> https://github.com/bitcoin-core/bitcoincore.org/pulls
11:21 < BlueMatt> I mean there are ones sitting there ready to merge
11:21 < BlueMatt> so...that sounds like a first step
11:21 < TheSadFace> Hello everyone, yeah sorry about how slow it's going... After finals I plan to catch up to the present time
11:21 < achow101> the last few weeks have been slightly busy because of exams, so meeting notes haven't really gotten written. but hopefully a bunch will be written in the next few weeks
11:21 < wumpus> oh right I'm allowed to merge things on the bitcoincore.org site now
11:21 < wumpus> :D     
11:22 < BlueMatt> lol after you broke the site!
11:22 < luke-jr> ok, so basically it's taken care of, just a matter of time
11:22 < achow101> luke-jr: yes
11:22 < TheSadFace> luke-jr: Yeah just had a crazy last bit of the semester 
11:22 < wumpus> well the site was still working :)
11:22 < Provoostenator> I think just posting the chat log quickly after the meeting is better than nothing.
11:22 < sipa> TheSadFace: very happy that someone's doing that
11:22 < wumpus> Provoostenator: the bot uploads the chat log
11:22 < sipa> even if it takes a while
11:23 < wumpus> e.g. http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-07-19.00.log.html for last meeting
11:23 < Provoostenator> But those don't show up here: https://bitcoincore.org/en/meetings/
11:23 < TheSadFace> sipa: Thanks!
11:23 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
11:23 < Provoostenator> For the RSS folks out there...
11:23 < wumpus> TheSadFace: yes, thanks a lot
11:23 < luke-jr> Provoostenator: wouldn't that make RSS more complex? if it shows up with the log, but then the summary added later.,.
11:23 < achow101> Provoostenator: "To view more recent logs, all meeting logs and raw minutes can be found here."
11:24 < bitcoin-git> [bitcoin] instagibbs opened pull request #11900: [policy] simplify CheckMinimalPush checks, add safety assert (master...checkminimal) https://github.com/bitcoin/bitcoin/pull/11900
11:24 < achow101> here links to http://www.erisian.com.au/meetbot/bitcoin-core-dev/
11:24 -!- jadee_ [~Jadee@50-248-173-75-static.hfc.comcastbusiness.net] has quit [Quit: This computer has gone to sleep]     
11:24 < Provoostenator> It might be better to just always generate a post on /meetings, edit the post later.
11:24 < luke-jr> I don't personally use RSS, but I would imagine it would be better if the post only showed when the summary is done
11:24 < luke-jr> otherwise people will try to read, see no summary, and forget to go back later
11:24 < Provoostenator> True, maybe have a second RSS feed with just the logs?
11:25 < Provoostenator> For people who want them fast.
11:25 < achow101> also, who owns the meetbot and the site where all of the meeting logs and stuff go?
11:25 < wumpus> aj does
11:25 < luke-jr> why not they just connect to the webchat? :P
11:25  * aj waves
11:25 < MarcoFalke> Provoostenator: Scroll back on botbot?
11:25 -!- pkx2 [~pkx@unaffiliated/pkx] has quit [Read error: Connection reset by peer]     
11:26 -!- pkx2 [~pkx@unaffiliated/pkx] has joined #bitcoin-core-dev     
11:26 < cfields> very quick topic suggestion: toolchain builder progress
11:26 -!- jadee_ [~Jadee@50-248-173-75-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
11:26 < wumpus> #topic toolchain builder progress
11:26 < luke-jr> actually, maybe we should link the webchat on the page?
11:27 < wumpus> is a read-only link to the webchat possible?
11:27 < cfields> i'm knee-deep in compiler builds. slowly taking shape. that is all :)
11:27 < BlueMatt> pr in time for 0.16 to replace gitian for 0.16, right?
11:27 < wumpus> if not, please don't do it 
11:27 < cfields> heh     
11:27 < achow101> wumpus: could link to botbot which is read only
11:27 -!- StopAndDecrypt_ [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has joined #bitcoin-core-dev     
11:27 < wumpus> achow101: +1
11:27 < luke-jr> wait, replacing gitian? :/
11:27 -!- Murch [~murch@96.82.80.28] has joined #bitcoin-core-dev     
11:28 < cfields> first step will just be a toolchain that we use in gitian rather than whatever ubuntu ships
11:28 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Ping timeout: 264 seconds]     
11:28 < cfields> that will mean that we can very easily use whatever compilers/versions we want for gitian/travis
11:28 < wumpus> that would help in cases like we have with ubuntu 16.04, where the mingw64 compiler is completely broken
11:28 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
11:28 < cfields> right
11:29 < sipa> wow, even in travis?
11:29 -!- jadee_ [~Jadee@50-248-173-75-static.hfc.comcastbusiness.net] has quit [Client Quit]     
11:29 < Chris_Stewart_5> cfields: nice! 
11:29 < cfields> after that, I'd like to discuss something more long-term. But replacing Gitian would still be a long way away
11:29 < luke-jr> within gitian sgtm, although hopefully only as-needed for Travis since it's already slow
11:29 < BlueMatt> #link http://vxer.org/lib/pdf/Reflections%20on%20Trusting%20Trust.pdf
11:30 < gmaxwell> luke-jr: the would it be slow in travis? it would get cached.
11:30 < cfields> luke-jr: the idea would be to host our toolchains somewhere, so that travis just pulls them like anything else
11:30 < cfields> right
11:30 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
11:30 < BlueMatt> will this make bitcoin core the first open source project to do releases using the 1984-suggested toolchain system? =D
11:31 < sipa> BlueMatt: we don't ship with our own CPU microcode yet :(
11:31 < cfields> gmaxwell: also, the clang/gcc thing is kinda moot. We'll want to build them with each-other anyway, so going clang-only wouldn't make things any easier
11:31 < wumpus> 1984 toolchain system doesn't have a good ring to it
11:31 < luke-jr> sipa: yet.
11:31 < BlueMatt> sipa: lol, ok, fair
11:31 < BlueMatt> wumpus: all the better to spy on you with
11:31 < wumpus> BlueMatt: :D
11:32 < achow101> is the goal to eventually get rid of gitian?
11:32 < gmaxwell> BlueMatt: IIRC diverse double compilation was not suggested by KT.
11:32 < cfields> BlueMatt: heh yes. The initial toolchain will likely take ages and ages to build. But after it's done once, updates are quick and easy
11:33 < luke-jr> achow101: I would hope not. Gitian is handy.
11:33 < wumpus> good to hear you're making progress cfields
11:33 < BlueMatt> gmaxwell: oh? how did I get that confused...who suggested it?
11:33 < luke-jr> achow101: at least not unless there's an alternative that isn't Bitcoin/Core-specific
11:33 < achow101> luke-jr: same, although it does need a bit of fixing I think
11:33 < gmaxwell> KT made the problem statement, I don't think DDC was suggested until david wheeler's thesis in the mid-oughts.
11:33 < BlueMatt> ah, ok
11:34 < wumpus> I think abstractly gitian as a launcher for deterministic containers that build is a good concept
11:34 < luke-jr> (and also not distro-specific ;)
11:35 < jtimon> what would be the advantageof getting rid of gitian?
11:35 < wumpus> it does have too much overhead (runnig a full ubuntu VM inside, which upgrades everyt ime), and is pretty hard to initially set up
11:35 < cfields> wumpus: agreed that the concept is good. It's just got lots of rough edges
11:36 < wumpus> the advantage is not in getting rid in it, but building something better
11:36 < luke-jr> wumpus: even making the updates persistent might be an improvement there
11:36 < achow101> I think that setting up a new gitian environment has been slowly getting harder
11:36 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 248 seconds]     
11:36 < cfields> luke-jr: with the toolchain stuff done, we won't need to do the updates anymore
11:36 < cfields> it'll be distro-agnostic
11:36 < wumpus> cfields: what about the windows installer stuff
11:37 < luke-jr> building NSIS should be trivial I'd think
11:37 < wumpus> cfields: I mean NSIS - we should probably build that too, then
11:37 < wumpus> oh no building NSIS is not trivial :(
11:37 < luke-jr> Gentoo has an ebuild, so just port that
11:37 < cfields> wumpus: right, i haven't gotten that far yet. But I suspect we'll just need to suck it up and build it
11:37 < wumpus> the problem is that it's a mix of cross compield windows code and native code, and has a sucky build system
11:38 < wumpus> yes     
11:38 < luke-jr> correction: Gentoo *used* to have an ebuild :x
11:38 < cfields> have no alternatives cropped up in the last ~10 years?
11:38 < wumpus> using the one in 12.04 isn't acceptable anymore at least
11:38 < wumpus> eh, 14.04
11:38 < luke-jr> I have a copy of the last ebuild in my overlay, it's only 111 lines
11:39 < cfields> luke-jr: that assumes you already have scons built and working
11:39 < wumpus> windows has a native installer db system that would be preferable to use
11:39 < wumpus> but porting the installer over to that would be... work
11:39 < luke-jr> yes :p
11:40 < cfields> well we can always take the toolchain stuff but still rely on a few bits and pieces from ubuntu until we get it all worked out
11:40 < wumpus> sure
11:41 < luke-jr> doesn't the toolchain stuff depend on a native autotools/make anyway?
11:41 < luke-jr> what harm in using native scons?
11:41 < wumpus> ah yes window's own system is msi
11:41 < cfields> luke-jr: depends how deep we want to go
11:41 < wumpus> thinking of it, might not be that easy to make those in cross-build
11:41 < maaku> wumpus: building a gitian vm can be easily scriptable. I had vagrant scripts for doing this since 2013, but weren't upstreamed out of lack of interest
11:42 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
11:42 < wumpus> maaku: there is a script for that now
11:42 < maaku> maintaining a script to construct a gitian vm solves the accessibilty problem (and gets more people using gitian)
11:42 < cfields> wumpus: msi's? IIRC gnu ld can target them, at least
11:43 < sipa> i also have brief libsecp256k1 update
11:43 < wumpus> contrib/gitian-build.sh
11:43 < wumpus> cfields: ok, so if we can get someone to make a msi installer for us, we could use that instead
11:43 < achow101> maaku: unfortunately sometimes gitian doesn't get setup even with a script
11:43 < achow101> it might fail at some random point in the process for some unknown reason
11:43 < cfields> wumpus: sure, something to look into
11:43 < wumpus> the problem is that it has a lot to accomodate, because setting up the kvm/lxc is slightly different on differnt systems
11:44 -!- alx [510271c6@gateway/web/freenode/ip.81.2.113.198] has joined #bitcoin-core-dev     
11:44 < wumpus> anyhow we'll figure it out, time for next topic
11:44 < wumpus> #topic libsecp256k1 update (sipa)
11:44 < luke-jr> doesn't KVM just work on all modern systems?
11:44 < wumpus> luke-jr: not inside VMs
11:44 < cfields> luke-jr: nested is a pain
11:44 < sipa> in the past week we've finally merged multi-multiplication support in libsecp256k1: https://github.com/bitcoin-core/secp256k1/pull/486
11:44 < maaku> wumpus: which is why you outsource the vm maintenance to an existing cross-platform vm management tool, like vagrant, and then do lxc-gitian within that vm
11:44 < jonasschnelli> sipa; what are the benefits?
11:45 < achow101> sipa: that's the pippenger thing?
11:45 < sipa> this is the low-level functionality for efficiently computing a*A + b*B + c*C + ..., with a,b,c scalars and A,B,C points
11:45 < sipa> it is not exposed currently (except for tests and benchmarks)
11:45 < cfields> ah, nice :)
11:45 < sipa> but it's the basis for efficiently building signature aggregation, batch validation, bulletproofs, ...
11:45 < jonasschnelli> nice
11:46 < wumpus> maaku: ok, maybe discuss with cfields
11:46 < wumpus> sipa: congrats!
11:46 < sipa> it doesn't currently affect anything in bitcoin, but i thought about mentioning it here as it's under the bitcoin-core repo and all that
11:47 < cfields> sipa: how do you picture that working with threading?
11:47 < cfields> batches of batches?
11:47 < sipa> cfields: split up the problem in N parts, run each part on one thread, and add the results together
11:47 < cfields> (I realize that's still a ways out)
11:48 < cfields> roger
11:48 < sipa> there are algorithms to actually be more efficient than that, but they need high communication across threads
11:48 < sipa> which may or may not be worth it
11:48 < sipa> (and be much harder to do API-wise)
11:48 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 248 seconds]     
11:48 < wumpus> one step at a time
11:49 < sipa> anyway, thanks to andytoshi and nickler, and peterdettman who all contributed optimizations
11:49 -!- alx [510271c6@gateway/web/freenode/ip.81.2.113.198] has quit [Quit: Page closed]     
11:49 < michagogo> Sorry I'm late. IIRC a while back I made a gitian-building appliance with video instructions for recreating it from scratch
11:49 < cfields> nice work
11:50 < sipa> and of course gmaxwell for all imput and discussions :)
11:50 < sipa> *input
11:50 < achow101> sipa: so what do we need to be able to use this in Bitcoin?
11:50 < sipa> achow101: ECDSA can't really take advantage of it in its current form
11:50 < michagogo> (Wow, apparently that was over a year ago: https://1drv.ms/f/s!AvCguGMVwWzLgxJPeXdvaQVJ2WJq )
11:50 < cfields> a use-case
11:51 < BlueMatt> ok, any last-minute topics/
11:51 < BlueMatt> ?     
11:51 < gmaxwell> well I tried to talk about connection slot saturation earlier.
11:51 < sipa> achow101: slightly modified ECDSA would permit batch validation, but there's no reason to choose that over some form of Schnorr-based signatures
11:51 < maaku> achow101: bitcoin doesn't do multi-generator arithmetic
11:51 < maaku> but it's useful for CT/CA
11:52 < achow101> oh, ok. cool.
11:52 < BlueMatt> gmaxwell: was there much to discuss? thanks for the notice, encourage people to run nodes/increase -maxconnections if possible?
11:52 < sipa> </endtopic>
11:52 < gmaxwell> We need to start looking into reenabling some kind of port forwarding I think.
11:52 < wumpus> so does anyone really get a lot of connections?
11:52 < gmaxwell> the number of non-listning nodes as increased by 50% in the last six months.
11:53 < wumpus> I have maxconnections at 500 on one node and have never got more than 100
11:53 < achow101> wumpus: I have 120 right now
11:53 < sipa> i'm at 124 connections
11:53 < gmaxwell> wumpus: when I was commenting a day ago I had confirmations of >110 on 6 nodes.
11:53 < Provoostenator> Are we sure UDNP works?
11:53 < wumpus> on the other node I'm happy to get more than 10
11:53 -!- Murch [~murch@96.82.80.28] has quit [Quit: Snoozing.]     
11:53 < achow101> Provoostenator: it's currently disabled by default
11:53 < sipa> Provoostenator: UPNP?
11:53 < gmaxwell> you'll see less if you're in a /16 with many other nodes in it.
11:53 < jonasschnelli> does NODE_NETWORK_LIMITED helps in this case?
11:53 < sipa> jonasschnelli: perhaps!
11:54 < wumpus> well the netherlands has lots of nodes so I've heard :-)
11:54 < gmaxwell> probably not much.
11:54 < Provoostenator> sipa: that one
11:54 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
11:54 < wumpus> they're not *all* mine :p
11:54 < gmaxwell> Running short on inbounds is the reasonable and expected outcome from not having automatic port forwarding... it's obviously not critical currently, but I think it's becoming more important.
11:55 < achow101> gmaxwell: do you think it would be safe to re-enable UPnP?
11:55 < Provoostenator> Maybe BitcoinQT can encourage users to use UPnP with a little nag?
11:55 < achow101> IIRC it was disabled because of vulnerabilities
11:55 < luke-jr> Provoostenator: better to just make it default then..
11:55 < wumpus> any plans for bitcoin over udp? much easier to port fw there
11:55 < gmaxwell> achow101: bleh. I dunno. that codebase sucks.
11:55 < wumpus> yes, UPNP is not going to be enabled by default again as long as I have a say, I have no confidence in that codebase
11:55 < gmaxwell> achow101: but there are other portforwarding protocols that we could support that are simple.
11:56 < BlueMatt> I believe wumpus has investigated it the most, sadly :(
11:56 < luke-jr> wumpus: what if someone ports it to another UPnP lib? (are there any good ones?)
11:56 -!- Kozuch [~Kozuch@81.0.198.168] has quit [Ping timeout: 248 seconds]     
11:56 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev     
11:56 < Provoostenator> Without UPnP, we could at least show some instructions that they need to perform the port forwarding ritual.  
11:56 < wumpus> wasn't there a better replacement for upnp gmaxwell?
11:57 < luke-jr> other protocols won't help with routers being UPnP..
11:57 < gmaxwell> Yes, there are several.
11:57 < wumpus> something that didn't rely on variable buffers and xml parsing
11:57 -!- TheSadFace [~TheSadFac@unaffiliated/thesadface] has quit [Ping timeout: 264 seconds]     
11:57 < jonasschnelli> Provoostenator: a "connectable" green/read flag and some instruction is probably simple
11:57 < gmaxwell> not as widely supported as UPNP but e.g. all apple networking appliances support the one whos name I can't remember.
11:57 < cfields> Bonjour?
11:57 < gmaxwell> where the protocol is just a trivial struct sent over usp.
11:57 < jonasschnelli> Bonjour is mDNS (that is different)
11:57 < sipa> DLNA?
11:58 < gmaxwell> I'm thinking of NAT-PMP
11:58 < Provoostenator> As well as a P2P message like "please try to connect to me", so it's easier to see if the port is open? 
11:58 < luke-jr> does anyone actually use Apple networking appliances? :/
11:58 < sipa> ah yes, that
11:58 -!- pkx2 [~pkx@unaffiliated/pkx] has quit [Ping timeout: 272 seconds]     
11:58 < wumpus> NAT-PMP is quite common these days, not only in apple
11:58 < gmaxwell> luke-jr: yes, though I'm sure they're not the most popular... NAT-PMP has support beyond apple of course.
11:59 < Provoostenator> The current instruction says "go to 21 and enter your IP there"
11:59 -!- alreadylate [~textual@customer-46-39-118-13.stosn.net] has quit []     
11:59 < gmaxwell> I just mentioned apple as a concrete example that it is widely supported.
11:59 < luke-jr> would be nice to find a quality library that can do both
11:59 < sipa> Provoostenator: ?
11:59 < gmaxwell> Provoostenator: wtf? what "the current instructions" say that?
11:59 < gmaxwell> luke-jr: there is not really a reason for a library for nat-pmp. You send a dozen byte packet over UDP.
11:59 < wumpus> I'd be ok with NAT-PMP on by default
12:00 < gmaxwell> And if you want to know your IP you listen for a similarly structured dozen by UDP reply.
12:00 < achow101> gmaxwell: I think Provoostenator is talking about https://bitcoin.org/en/full-node#port-forwarding
12:00 < wumpus> but no C/C++ xml parser crap again please
12:00 < wumpus> we've pretty much dodged a bullet last time
12:00 < BlueMatt> achow101: oh ffs, can we get that fixed?
12:00 < Provoostenator> (trying to find where I saw that)
12:00 < BlueMatt> <dong>
12:00 < wumpus> #endmeeting
12:00 < lightningbot> Meeting ended Thu Dec 14 20:00:49 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:00 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-14-19.00.html
12:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-14-19.00.txt
12:00 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-14-19.00.log.html
12:00 < gmaxwell> So in any case, we should look into it more. I don't think we need something as widespread (and poorly implemented) as UPNP.
12:00 < luke-jr> gmaxwell: that explains why I didn't see any libs :P
12:00 < luke-jr> maaku: VM maintenance is exactly what gitian is handy for.. vagrant on the other hand has a ton of deps, one of which is non-free :/
12:01 < jonasschnelli> sipa: when I'm scanning the UTXO set with the CCoinsViewCursor (while, cursor.Next()) is there a way to calculate the progress? Similar to your https://github.com/bitcoin/bitcoin/blob/master/src/txdb.cpp#L387?
12:01 < gmaxwell> I think NAT-PMP would probably help a lot and wouldn't be a risk.
12:01 < sipa> jonasschnelli: you can assume the txids and uniformly distributed
12:01 < wumpus> not sure if I ever made it public, but I could own every bitcoin node starting up in a LAN
12:01 < achow101> Provoostenator: this: https://bitcoin.org/en/full-node#testing-connections
12:01 < achow101> I think that's what you were looking for
12:01 < cfields> wumpus: yikes!
12:01 < sipa> maaku: multi-multiplication is useful even for cryptographic systems that don't use multiple generators
12:01 < Provoostenator> achow101 yes
12:02 < Provoostenator> So now they just need some browser fingerprinting et voila.
12:02 < sipa> maaku: e.g. Schnorr batch validation
12:02 < Provoostenator> Next time you go to a shop, they'll offer you a bitcoin payment option. Super convenient!
12:02 < jonasschnelli> sipa: thanks... 
12:02 < jonasschnelli> wumpus: oh.. due to UPnP?
12:02 < achow101> wumpus: how so?
12:02 < wumpus> cfields: was a combination of a heartbleed-like leak (to get the ASLR addresses) and the known vulnerability, both are patched now in any case
12:02 < gmaxwell> sipa: in fact it would be perfectly useful in bitcoin for batch validation if but for the ecda reduction of R.x mod P and the lack of R's sign.
12:03 < sipa> jonasschnelli: so take the top 64 bits of the txid, and convert it to a double... that should increase at a constant rate
12:03 < maaku> luke-jr: there are alternatives to vagrant, but I think you missed the point. use a vagrant-like tool to make a linux vm (centos, ubuntu, I don't care). on THAT system make the gitian VM using the usual scripts
12:03 < gmaxwell> do not just cast the bits to a double, as that could constract signaling nans and other baddness.
12:04 < wumpus> achow101: there was a buffer overflow bug in the miniupnp library at some point, don't have the CVE at hand
12:04 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
12:04 < sipa> gmaxwell: it also wouldn't work
12:04 < gmaxwell> There was more than one.  We'd previously noted that the code smelled.
12:04 < jonasschnelli> sipa: int percentageDone = (int)(high * 100.0 / 65536.0 + 0.5) (can you explain why 65536.0 + 0.5?)
12:04 < cfields> maaku: that's pretty much Gitian's utility though. I'd argue that if you need a vm builder to run the vm builder, one of them needs some love :)
12:04 < sipa> jonasschnelli: i assume that's just looking at the top 16 bits?
12:05 < sipa> jonasschnelli: 16 bits have 65536 possibilities
12:05 < luke-jr> Gentoo let the CVE sit until just a few weeks ago. My workaround was to depend on the fixed version explicitly. :/
12:05 < sipa> 0.5 is for rounding
12:05 < jonasschnelli> sipa: okay. I see
12:05 < luke-jr> anyhow, bbl
12:05 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
12:05 < maaku> cfields: how is that gitian's utility? I'm not sure why it should be our business to maintain the gitian setup procedure on every development environment out there
12:06 < wumpus> the vuln was: TALOS-2015-0035 (CVE-2015-6031)
12:06 < wumpus> had to badger ubuntu day in day out to put up an updated libupnpc library
12:06 < sipa> badger badger badger
12:07 < wumpus> bitcoin wasn't the only affected program, but one of the worst, because it had the upnp structures on the stack
12:07 -!- Kozuch [~Kozuch@81.0.198.168] has joined #bitcoin-core-dev     
12:08 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-core-dev     
12:08 < achow101> what if we just removed UPnP entirely? It's not like people actually seem to be using it.
12:08 < cfields> maaku: right, Gitian's tasked with abstracting that away. But in reality it only behaves on Linux environments that look as it expects. If something like vagrant/docker/etc. does it better, it may make sense to outsource some of it.
12:08 < wumpus> sure, but please implement an alternative first
12:09 < wumpus> NAT-PMP is great but someone has to do it :)
12:09 < gmaxwell> achow101: I think we need at least some kind of internal traversal, perhaps NAT-PMP is enough.
12:12 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev     
12:12 < wumpus> I'll create an issue for it
12:13 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Ping timeout: 248 seconds]     
12:13 < maaku> cfields: gitian is not designed to work on windows or mac os x or bsd or even non-mainstream linux environments. it expects a standard linux environment. so give it one: use gitian-lxc inside of a vm or container made with more traditional cross-platform support
12:13 < maaku> i'm not saying replace any aspect of gitian. these are totally different problems, and gitian only tackles one of them
12:14 < cfields> maaku: it is intended to work on osx
12:15 < sipa> looking at RFC 6886, NAT-PNP looks absolutely trivial
12:17 < gmaxwell> I think if we didn't care about learning our external IP (we do) it would be a dozen lines of code to support.
12:17 < sipa> oh, you need to know your gateway address
12:17 < sipa> that looks slightly nontrivial, especially across platforms
12:17 < aj> supa: http://miniupnp.free.fr/nat-pmp.html laims it's superceded by rfc6887 "port control protocol"
12:17 < aj> sipa even
12:17 < gmaxwell> aj: yes, though PCP is fully backwards compatible with PMP I believe.
12:18 < cfields> maaku: its primary task is to kick off a vm, run a script, and gather the results. imo the creation of that vm is out of its scope.
12:18 < gmaxwell> and just supports additional features we don't really need (well, IPv6 is among them I think)
12:18 < maaku> cfields: i seem to be failing at comunication with you. i give up, sorry.
12:18 < cfields> sipa: multicast to 0.0.0.0 :p
12:19 < Provoostenator> gmaxwell what do you mean by "care about learning our external ip"?
12:20 < sipa> Provoostenator: NAT-PMP has a way to know what your external IP is
12:20 < sipa> we need that for announcements in addr messages
12:20 < gmaxwell> Provoostenator: we use UPNP for two things: to open the port, and to learn our IP so we can announce it.
12:20 < gmaxwell> there are workarounds we have for the latter, but they're kinda lame, it's much better to learn it from the router.
12:21 < Provoostenator> I see. One (lame) workaround could be to ask another peer I assume?
12:21 < gmaxwell> we do that but the result isn't something we can trust.
12:21 < sipa> very early versions of bitcoin used whatismyip.com, no joke :)
12:22 < sipa> or some site like that
12:22 < Provoostenator> Can't you verify this untrusted IP by pinging it?
12:22 < cfields> maaku: sorry for steamrolling. I'd like to understand the role you see for something like Vagrant.
12:23 < wumpus> #11902
12:23 < gribble> https://github.com/bitcoin/bitcoin/issues/11902 | NAT-PMP port forwarding support · Issue #11902 · bitcoin/bitcoin · GitHub
12:23 < sipa> Provoostenator: so a peer would tell you, "hey, your IP is 192.168.1.1!" and you'd try to ping it, and indeed, it works!
12:23 -!- To7 [~theo@68.129.242.238] has quit [Ping timeout: 272 seconds]     
12:23 < Provoostenator> You can't send a payload along with that ping?
12:24 < sipa> Provoostenator: you miss my point
12:24 < gmaxwell> Provoostenator: actually usually from inside nat you can't reach the external IP.
12:24 < Provoostenator> sipa: oh wait, I think I see your point
12:24 < gmaxwell> but what you're thinking of doesn't work either because the peer can mitm anything you do.
12:24 < Provoostenator> Exactly
12:25 < gmaxwell> besides, supporting the discovery part of PMP isn't that much harder.
12:25 < Provoostenator> Sure, just trying to understand why. But that makes sense.
12:26 < Provoostenator> IPv6 is still scheduled for 2008, right?
12:26 < maaku> cfields: setup a standard linux environment in which gitian is run
12:27 < BlueMatt> Provoostenator: yep, we're all preparing to deploy on schedule!
12:27 < sipa> Provoostenator: i had an IPv6 address in 2005 ;)
12:27 < maaku> on any platform, with ~no maintenence burden to bitcoin core
12:28 < maaku> cfields: like this did, although I'd change the approach if I re-did it in 2017 : https://github.com/bitcoin/bitcoin/pull/1597
12:28 < wumpus> lol yes I also had an IPv6 address in the past, but no longer, seems IPv6 support by the big providers in the Netherlands has been postponed indefinitely, they announce and postpone every time
12:28 -!- alreadylate [~textual@customer-46-39-118-13.stosn.net] has joined #bitcoin-core-dev     
12:28 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
12:29 < wumpus> one provider acquired another provider, cancelling their ongoing ipv6 rollout
12:29 < gmaxwell> lol     
12:29 < BlueMatt> lol, monopolistic practices to prevent ipv6 rollout?
12:29 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
12:29 < sipa> apparently my home desktop, behind a NAT, has a global IPv6 address that works :o
12:30 < BlueMatt> my home internet does as well
12:30 < gmaxwell> SURPRISE.
12:30 < gmaxwell> just when you thought you didn't have to worry much about security on random hosts in your home...
12:30 < sipa> it's firewalled of course
12:30 < BlueMatt> InternetOfShitTakesRevenge
12:31 < BlueMatt> heh, my default garbage isnt
12:31 < cfields> maaku: I see
12:31 -!- alreadylate [~textual@customer-46-39-118-13.stosn.net] has quit [Client Quit]     
12:32 < sipa> gmaxwell: my machine is reachable in other ways too - i'm just surpised that ISP, router, OS, ... all support IPv6 without any configuration
12:32 -!- Kozuch [~Kozuch@81.0.198.168] has quit [Ping timeout: 272 seconds]     
12:33 < wumpus> yes, hardware and software support for ipv6 support is very good these days
12:33 < wumpus> that's no longer the bottleneck
12:33 -!- games [bc4d0df9@gateway/web/freenode/ip.188.77.13.249] has joined #bitcoin-core-dev     
12:33 < Provoostenator> Wumpus: seems Ziggo is experimenting with IPv6 again though.
12:33 -!- games is now known as Guest66654     
12:33 < Provoostenator> Top hit on Google is people trying to downgrade to IPv4 because [something bad].
12:34 -!- alreadylate [~textual@customer-46-39-118-13.stosn.net] has joined #bitcoin-core-dev     
12:34 -!- maaku [~maaku@173.234.25.100] has left #bitcoin-core-dev ["http://quassel-irc.org - Chat comfortably. Anywhere."]     
12:38 < wumpus> Provoostenator: you mean, to IPv6 only?
12:39 < Provoostenator> Yes, I'll just email them to see if that's possible. Then I'll find out how it works and what breaks.
12:39 < wumpus> I'd not be happy with that either, would just like the choice to use IPv6 as well
12:41 < BlueMatt> wumpus: I mean, hey, from a network-management perspective I do get why one might want to drag their feet on ipv6 rollout...the possibility that your users end up joining a DDoS attack because you host garbage IoT devices all over the place that get pop'ed via IPv6 is....much too high. ofc its something they need to deal with *either way*, but...ehh
12:43 < wumpus> BlueMatt: yes, having all devices reachable for incoming connections from outside by default is one of the things I like less about IPv6, although that's not the fault of the protocol but of router's default firewall configuration
12:43 < BlueMatt> indeed
12:43 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
12:44 < Provoostenator> Can't a standard cable modem just block all ports by default?
12:44 < BlueMatt> should, probably, but wont in my experience
12:44 < Provoostenator> So the user just needs to open them, but not forward. Although that's probably still too much of a barrier.
12:44 < wumpus> blocking incoming TCP SYN packets to the entire range would be a start
12:45 < wumpus> but I don't think any routers do that by default
12:45 < gmaxwell> internet of terror
12:45 -!- alreadylate [~textual@customer-46-39-118-13.stosn.net] has quit []     
12:47 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has quit [Quit: Leaving.]     
12:47 < wumpus> then again, that would defeat its entire purpose for things like bitcoin and P2P programs, again requiring the users to manually change a setting
12:47 -!- PaulCapestany [~PaulCapes@68.100.207.91] has quit [Quit: .]     
12:47 < BlueMatt> gmaxwell: internet of shit!
12:47 -!- PaulCapestany [~PaulCapes@ip68-100-207-91.dc.dc.cox.net] has joined #bitcoin-core-dev     
12:48 < BlueMatt> wumpus: yea, but upnp and auto-forwarding is easy to get right and implement!
12:49 -!- alreadylate [~textual@customer-46-39-118-13.stosn.net] has joined #bitcoin-core-dev     
12:50 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
12:50 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev     
12:50 < wumpus> BlueMatt: not quite, though well at least for ipv4 there are protocols for that, I'm not sure what a ipv6 'please allow this port' request would look like
12:51 < BlueMatt> wumpus: I was joking......
12:51 < sipa> wumpus: PCP supports IPv6 IIRC
12:51 < wumpus> in principle it would be the application requesting global scope for a port instead of LAN scope, of course, it's dangerous to allow applications to make those decisions in general
12:54 < sipa> well UPnP/NAT-PMP aren't designed to bypass firewalls, they're to inform the router of port mappings
12:54 < sipa> in IPv6 those should just not be needed anymore
12:54 -!- Guest16 [~textual@188.77.13.249] has joined #bitcoin-core-dev     
12:54 < wumpus> yeah, 'should'
12:55 < sipa> unfortunately, many people treat the lack of a mapping as a substitute for a firewall, where of course those protocols effectively become a way for application to bypass security
12:55 < wumpus> right
12:56 < wumpus> another problem is that applications and operating systems open all kinds of ports, expecting them to be only open to a LAN instead of to the whole world, whereas most users don't really configure a firewall
12:56 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-ofwpdbqjqvhicyel] has quit [Quit: Connection closed for inactivity]     
12:56 -!- Guest16 is now known as xames     
12:57 < xames> not possible to use port 80 like skype...
12:57 < wumpus> NAT made developers and users lazy in that way
12:57 < xames> like teamviewer
12:59 -!- Guest66654 [bc4d0df9@gateway/web/freenode/ip.188.77.13.249] has quit [Quit: Page closed]     
12:59 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
13:01 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
13:06 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #11903: [trivial] Add required package dependencies for depends cross compilation (master...2017/12/depends_pkg) https://github.com/bitcoin/bitcoin/pull/11903
13:08 -!- alreadylate [~textual@customer-46-39-118-13.stosn.net] has quit []     
13:09 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
13:11 -!- propumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-core-dev     
13:12 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Ping timeout: 240 seconds]     
13:14 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-tgpwvnvnigftvbwt] has joined #bitcoin-core-dev     
13:15 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
13:29 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
13:30 -!- TheSadFace [~TheSadFac@unaffiliated/thesadface] has joined #bitcoin-core-dev     
13:31 -!- TheSadFace [~TheSadFac@unaffiliated/thesadface] has quit [Client Quit]     
13:31 < meshcollider> Ah I missed the meeting oops
13:32 -!- xames [~textual@188.77.13.249] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
13:32 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 248 seconds]     
13:32 -!- bule [~bule@gateway/tor-sasl/bule] has quit [Remote host closed the connection]     
13:33 -!- alreadylate [~textual@customer-46-39-118-13.stosn.net] has joined #bitcoin-core-dev     
13:35 < BlueMatt> meshcollider: tsk tsk, no more getting your prs reviewed this week, then :p
13:36 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
13:36 -!- alreadylate [~textual@customer-46-39-118-13.stosn.net] has quit [Client Quit]     
13:37 -!- timothy [~tredaelli@redhat/timothy] has quit [Client Quit]     
13:37 < meshcollider> BlueMatt: how is that different from every other week though ;)
13:37 < BlueMatt> meshcollider: heh, try the high priority review queue, it at least usually gets you one or two reviews in a week :p
13:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
13:42 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
13:44 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
13:45 -!- shesek [~shesek@bzq-84-110-54-147.red.bezeqint.net] has joined #bitcoin-core-dev     
13:45 -!- shesek [~shesek@bzq-84-110-54-147.red.bezeqint.net] has quit [Changing host]     
13:45 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev     
13:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]     
13:49 -!- jb55 [~jb55@S0106c05627ce55f2.vc.shawcable.net] has joined #bitcoin-core-dev     
13:49 -!- Guest16 [~textual@249.13.77.188.dynamic.jazztel.es] has joined #bitcoin-core-dev     
13:50 -!- jadee_ [~Jadee@50-248-173-75-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
14:00 -!- alreadylate [~textual@customer-46-39-118-13.stosn.net] has joined #bitcoin-core-dev     
14:04 < MarcoFalke> re: jonasschnelli: [OT] what is the fastest way to amend commit the current changes into a non HEAD commit? 
14:04 < MarcoFalke> git commit --fixup=${that_non_head_commit} && git rebase --interactive --autosquash ${that_non_head_commit}~
14:07 < wumpus> huh autosquash is nice, so it will automatically mark commits whose message start with squash! as squash and same with fixup!, didn't know about that one
14:07 < BlueMatt> heh, cool
14:08 < meshcollider> You can also turn on autosquash by default with  git config --global rebase.autosquash true
14:08 < meshcollider> so you don't have to use --autosquash every time
14:10 < BlueMatt> I really want a fixup! "Title of Commit to Squash Into"
14:10 < meshcollider> that is what it does?
14:11 < BlueMatt> oh, heh, nice
14:11 < meshcollider> ;)     
14:11 -!- jb55 [~jb55@S0106c05627ce55f2.vc.shawcable.net] has quit [Ping timeout: 240 seconds]     
14:14 -!- CASEgezadthfr [~ZZXv@lmcfwa.ericsson.ca] has quit [Ping timeout: 260 seconds]     
14:15 < MarcoFalke> promag: re ParseInt64
14:15 < MarcoFalke> Imo it should be done at init and then throw an error
14:15 -!- jb55 [~jb55@S0106c05627ce55f2.vc.shawcable.net] has joined #bitcoin-core-dev     
14:16 < meshcollider> MarcoFalke: I'm going to work on some stronger argument checking as soon as I can
14:16 < MarcoFalke> When your node is running for a day and you sendtoaddress, it is too late to crash on "Wrong tx fee set on command line"
14:16 < MarcoFalke> meshcollider: Cool
14:16 < wumpus> that's what I also said, we should have some options mechanism that parses all options at init time, 
14:17 < MarcoFalke> wumpus: Jup, like python :)
14:17 < wumpus> it's crazy to parse options every time in a loop anyway
14:17 < wumpus> or every time a RPC command is called
14:18 < MarcoFalke> It is still good to have the GetArg in place, but internally they might use some sort of caching
14:18 < wumpus> just call the getarg in init
14:18 < meshcollider> GetArg just looks up in mapArgs
14:18 < wumpus> then assign to a global
14:18 < wumpus> or have some automatic system to do that
14:19 < wumpus> caching is also unnecessary, it can just be a variable
14:19 < wumpus> no need for any lookup at all
14:19 < meshcollider> wumpus all args are parsed in ArgsManager::ParseParameters
14:19 < MarcoFalke> wumpus: You'd have to sprikle the code with locks in case we allow args to change at run time, no?
14:19 < wumpus> we don't allow that
14:19 < MarcoFalke> There is a pull to do that, though
14:19 < meshcollider> which one?
14:19 < wumpus> well yes in that case you'd have to protect the values with a lock
14:20 < wumpus> it's tsill better than parsing every time
14:20 < MarcoFalke> wumpus: My style preferense would be to put the lock in the GetArg
14:20 < wumpus> but most settings don't really make sense to change at run time
14:20 < MarcoFalke> The getarg can return the variable
14:20 < wumpus> using strings to refer to variables just doesn't make sense when you know what you're accessing
14:20 < MarcoFalke> jup     
14:20 < wumpus> there's this whole hash lookup every time that makes no sense
14:20 < jnewbery> wumpus: Perhaps #11415 is ready for merge?
14:20 < gribble> https://github.com/bitcoin/bitcoin/issues/11415 | [RPC] Disallow using addresses in createmultisig by achow101 · Pull Request #11415 · bitcoin/bitcoin · GitHub
14:22 < wumpus> jnewbery: thanks
14:22 < meshcollider> wumpus: so you suggest adding a private variable inside ArgsManager for each argument?
14:22 < meshcollider> I can probably work on this today
14:23 < wumpus> meshcollider: I'm not sure that's a good idea, because that makes argmanager have to know about all options in the entire program
14:23 < wumpus> meshcollider: ideally there would be some way to register arguments with the argument manager
14:23 < wumpus> meshcollider: same as we do with RPC methods
14:23 < meshcollider> wumpus: ah yes that's a cool idea
14:23 -!- alreadylate [~textual@customer-46-39-118-13.stosn.net] has quit [Ping timeout: 272 seconds]     
14:23 < wumpus> meshcollider: this information could include the name, documentaion, type, as well as a pointer to the variable to update
14:24 < MarcoFalke> and valid ranges for integers, e.g.
14:24 < wumpus> meshcollider: well it's pretty much what quake already did in 1995 or so :)
14:24 < wumpus> yep     
14:24 < meshcollider> MarcoFalke: do you know what PR is the one which allows changing them at runtime? I'd like to take a quick look at it
14:24 -!- YellowSphere [~YellowSph@95-37-194-52.dynamic.mts-nn.ru] has joined #bitcoin-core-dev     
14:24 < MarcoFalke> it could be one of luke's
14:24 < aj> meshcollider: having a table of argument name -> reference to global that gets populated with value by parseargs+config?
14:24 < MarcoFalke> might be closed
14:25 < wumpus> MarcoFalke: yep a range or if that's not enough, a functor that does checking
14:25 < meshcollider> do we want to add a whole lot more global variables though 
14:25 < wumpus> you could put them in a structure per module
14:25 < aj> wumpus, meshcollider, *: happy with the overall approach of #11862 at this point, btw?
14:25 < gribble> https://github.com/bitcoin/bitcoin/issues/11862 | [concept] Network specific conf sections by ajtowns · Pull Request #11862 · bitcoin/bitcoin · GitHub
14:26 < YellowSphere> Hi there.
14:26 < wumpus> e.g. a module could register its own globals, so they're only global static in that compilation unit
14:26 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
14:26 < wumpus> same as the RPC registration
14:27 < wumpus> aj: ACK on the conept, haven't reviewed the code
14:27 < meshcollider> aj: so far yep it looks sensible
14:27 < MarcoFalke> meshcollider: Maybe this one https://github.com/bitcoin/bitcoin/pull/7510/files ?
14:27 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
14:27 < aj> wumpus: cool, i'll review the code, add some tests and maybe even docs then
14:27 -!- danklasson [3131eec6@gateway/web/freenode/ip.49.49.238.198] has joined #bitcoin-core-dev     
14:28 < aj> wumpus: modules registering their own options/globals would fit well with declaring some options as needing to be specified per network
14:28 < wumpus> aj: yes, that could be one of the registration parameters
14:28 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
14:28 < aj> wumpus: maybe help text could be one of the params too?
14:29 -!- Guest16 [~textual@249.13.77.188.dynamic.jazztel.es] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
14:29 < wumpus> aj: absolutely, yes
14:29 < meshcollider> aj: he already mentioned that ;)
14:29 < MarcoFalke> falls under "documentation"
14:29 < meshcollider> Ok I'll get started then
14:30 < meshcollider> aj's PR should be merged first but I won't base mine on top of it until its been more thoroughly reviewed / less likely to drastically change
14:30 < wumpus> meshcollider: the idea would be that everything about the option is specified at registration, so that it's in one place and that's the module where it gets used
14:30 < danklasson> I don't know if you guys know. But supposedly this guy set up this fund where you can apply for 1 million dollars donation. Would you guys say that could be used to hire a bunch of devs working on several projects related to Bitcoin, such as segwit supported wallets and LN. What's your thoughts regarding this? https://pineapplefund.org/
14:32 < meshcollider> danklasson: I don't think bitcoin core counts as a charity ;)
14:33 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
14:34 < danklasson> meshcollider: I know but I'm guessing they would be willing to make an exception 
14:34 < wumpus> yeah, I've had the question before 'how can I pay to help lightning development', I had no idea
14:36 -!- scoooobydooo [68b59ecd@gateway/web/freenode/ip.104.181.158.205] has quit [Ping timeout: 260 seconds]     
14:36 < danklasson> wumpus: I read that few people are working on LN. If we had a bunch of money we could hire a bunch of devs to work on it. I bet I can get a bunch of guys on board to get the ball rolling 
14:36 < wumpus> in open source it's individual developers working on things, there's no one dealing out work items, and allocating resources
14:36 < ryanofsky> imo, gflags has a good model for registering options. lets you declare options where used, creates variables to avoid lookups, and combines with documentation: https://gflags.github.io/gflags/#define
14:37 < danklasson> wumpus: not necessarily. a lot of companies contribute to open source too
14:37 < wumpus> sure you could ask individual developers for donation address
14:38 < danklasson> i was thinking something more like setting up a foundation that hires people and allocates them to different projects
14:38 < wumpus> heh that didn't go too well with the bitcoin foundation... anyhow off topic here
14:39 < danklasson> is there a better channel to discuss this?
14:39 < wumpus> #bitcoin
14:39 < Deacyde>  /join #bitcoin
14:39 < Deacyde> :) \
14:40 < danklasson> ok, thanks  
14:41 < wumpus> ryanofsky: agree, looks decent
14:41 -!- jadee_ [~Jadee@50-248-173-75-static.hfc.comcastbusiness.net] has quit [Quit: This computer has gone to sleep]     
14:42 -!- jadee_ [~Jadee@50-248-173-75-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
14:43 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has quit []     
14:52 -!- jb55 [~jb55@S0106c05627ce55f2.vc.shawcable.net] has quit [Ping timeout: 265 seconds]     
14:54 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
14:54 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...]     
14:55 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
14:57 -!- jb55 [~jb55@S0106c05627ce55f2.vc.shawcable.net] has joined #bitcoin-core-dev     
14:59 < phantomcircuit> i've got a node in blocks only mode with a peer that claims to be 0.15.1 sending transactions in violation of the protocol
15:00 < phantomcircuit> lol i also have a peer claiming to be 0.15.0.1
15:00 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 264 seconds]     
15:01 -!- quantbot [~quantbot@ool-2f125d98.dyn.optonline.net] has quit [Remote host closed the connection]     
15:02 < BlueMatt> yea, thats been a common complaint, dont know that anyone has reproduced it with their own nodes, but people seem to pop up claiming that every now and again
15:02 < BlueMatt> I'm betting its random garbage nodes hacked to relay lots of shit, cause several people have gone looking for a bug there and failed to find one, afair
15:03 < BlueMatt> err...not *common*, but it gets mentioned once or twice every now and again
15:03 < BlueMatt> we should probably just ban peers for that
15:03 < phantomcircuit> possibly nodes that have whitelisted 0.0.0.0/0
15:07 -!- jb55 [~jb55@S0106c05627ce55f2.vc.shawcable.net] has quit [Ping timeout: 260 seconds]     
15:11 -!- photonclock_ [~photonclo@47.37.153.193] has joined #bitcoin-core-dev     
15:15 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
15:16 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
15:20 -!- Pavle [~pavle_@unaffiliated/pavle/x-4679000] has joined #bitcoin-core-dev     
15:21 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Quit: leaving]     
15:22 -!- Kozuch [~Kozuch@81.0.198.168] has joined #bitcoin-core-dev     
15:25 -!- roadcrap [~roadcrypt@unaffiliated/roadcrap] has quit [Remote host closed the connection]     
15:26 < bitcoin-git> [bitcoin] MeshCollider opened pull request #11904: Add a lock to the wallet directory (master...201712_walletdir_lock) https://github.com/bitcoin/bitcoin/pull/11904
15:26 < meshcollider> BlueMatt: ^
15:26 < meshcollider> wumpus: that needs a 0.16 milestone
15:31 -!- quantbot [~quantbot@ool-2f125d98.dyn.optonline.net] has joined #bitcoin-core-dev     
15:32 -!- quantbot [~quantbot@ool-2f125d98.dyn.optonline.net] has quit [Remote host closed the connection]     
15:32 -!- quantbot [~quantbot@ool-2f125d98.dyn.optonline.net] has joined #bitcoin-core-dev     
15:36 -!- quantbot [~quantbot@ool-2f125d98.dyn.optonline.net] has quit [Remote host closed the connection]     
15:36 -!- quantbot [~quantbot@ool-2f125d98.dyn.optonline.net] has joined #bitcoin-core-dev     
15:37 -!- jb55 [~jb55@216-71-192-56.dyn.novuscom.net] has joined #bitcoin-core-dev     
15:41 -!- roadcrap [~roadcrypt@unaffiliated/roadcrap] has joined #bitcoin-core-dev     
15:53 -!- mrfrasha_ [~mrfrasha@66.188.250.34] has quit [Quit: mrfrasha_]     
15:54 -!- Pavle [~pavle_@unaffiliated/pavle/x-4679000] has quit [Quit: Leaving]     
15:56 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
15:57 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection]     
15:58 -!- vicenteH [~user@35.233.15.37.dynamic.jazztel.es] has quit [Ping timeout: 272 seconds]     
15:59 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
16:02 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
16:04 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
16:04 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
16:15 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
16:15 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 272 seconds]     
16:18 -!- GV [4c110bda@gateway/web/freenode/ip.76.17.11.218] has joined #bitcoin-core-dev     
16:19 < bitcoin-git> [bitcoin] himatripuramallu opened pull request #11905: done (master...master) https://github.com/bitcoin/bitcoin/pull/11905
16:19 < GV> Hi, does anyone know any references on how to validate a P2SH BTC address?
16:19 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
16:20 < bitcoin-git> [bitcoin] fanquake closed pull request #11905: done (master...master) https://github.com/bitcoin/bitcoin/pull/11905
16:21 < GV> I have a validator but I only works with the older addresses. I heard that the byte version is different but the implementation is not that different
16:21 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
16:21 < GV> it*     
16:21 < meshcollider> GV: what do you mean by validate it? Check that the script you have corresponds to that address? Check that you can sign a transaction sent to that address? what?
16:22 < meshcollider> GV: And what do you mean by 'older addresses', just normal P2PKH addresses? 
16:22 < meshcollider> GV: This is not the right channel for support, you should ask in #bitcoin
16:22 < GV> To make sure that the address is a valid P2PKH or P2SH address.
16:23 < GV> Oh okay, I'll try there
16:23 -!- YellowSphere [~YellowSph@95-37-194-52.dynamic.mts-nn.ru] has quit [Read error: Connection reset by peer]     
16:34 -!- jb55 [~jb55@216-71-192-56.dyn.novuscom.net] has quit [Ping timeout: 240 seconds]     
16:35 -!- jadee_ [~Jadee@50-248-173-75-static.hfc.comcastbusiness.net] has quit [Quit: This computer has gone to sleep]     
16:36 -!- ula [~ula@b2b-78-94-11-194.unitymedia.biz] has joined #bitcoin-core-dev     
16:37 -!- jadee_ [~Jadee@50-248-173-75-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
16:40 -!- Murch [~murch@mobile-166-170-36-220.mycingular.net] has joined #bitcoin-core-dev     
16:41 -!- jadee_ [~Jadee@50-248-173-75-static.hfc.comcastbusiness.net] has quit [Client Quit]     
16:45 -!- Murch [~murch@mobile-166-170-36-220.mycingular.net] has quit [Quit: Snoozing.]     
16:45 -!- jadee_ [~Jadee@50-248-173-75-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
16:52 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-core-dev     
16:58 -!- wxss [~user@184.75.212.158] has quit [Quit: leaving]     
17:00 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
17:05 -!- ula [~ula@b2b-78-94-11-194.unitymedia.biz] has quit [Read error: Connection reset by peer]     
17:19 -!- Dylan [b2a2d188@gateway/web/freenode/ip.178.162.209.136] has joined #bitcoin-core-dev     
17:20 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
17:21 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
17:22 < Dylan> watcha working on?
17:27 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
17:27 -!- Kozuch [~Kozuch@81.0.198.168] has quit [Ping timeout: 264 seconds]     
17:31 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
17:32 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
17:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
17:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
17:42 -!- Randolf [~randolf@69.166.112.240] has joined #bitcoin-core-dev     
17:44 -!- Dylan [b2a2d188@gateway/web/freenode/ip.178.162.209.136] has quit [Quit: Page closed]     
17:45 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 265 seconds]     
17:47 -!- Randolf [~randolf@69.166.112.240] has quit [Ping timeout: 272 seconds]     
17:48 -!- Randolf [~randolf@69.166.112.240] has joined #bitcoin-core-dev     
17:52 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ffghqbcwirlejdhg] has quit [Quit: Connection closed for inactivity]     
17:58 -!- harrymm [~harrymm@104.207.83.57] has quit []     
18:03 -!- harrymm [~harrymm@104.207.83.40] has joined #bitcoin-core-dev     
18:08 -!- Murch [~murch@208.71.159.194] has joined #bitcoin-core-dev     
18:09 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
18:09 -!- jamesob [~james@199.230.10.198] has quit [Ping timeout: 248 seconds]     
18:10 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
18:21 -!- Murch [~murch@208.71.159.194] has quit [Quit: Snoozing.]     
18:25 -!- Randolf [~randolf@69.166.112.240] has quit [Ping timeout: 240 seconds]     
18:26 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
18:27 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
18:31 -!- imabinarydigit01 [~IRCTestSS@52.179.96.28] has quit [Remote host closed the connection]     
18:36 -!- AegisAttack [~colin@2605:6000:cdc9:3b00:2913:7355:d8f7:e248] has joined #bitcoin-core-dev     
18:40 -!- Jackson8377 [~Jackson@162-204-109-161.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev     
18:44 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has quit [Read error: Connection reset by peer]     
18:56 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
18:57 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Client Quit]     
18:57 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
18:59 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 272 seconds]     
19:18 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
19:19 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
19:35 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has quit [Quit: Page closed]     
19:38 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
19:39 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
19:41 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
19:43 -!- StopAndDecrypt_ [~StopAndDe@c-73-248-248-9.hsd1.nj.comcast.net] has quit [Ping timeout: 248 seconds]     
19:43 -!- reden [becafc53@gateway/web/freenode/ip.190.202.252.83] has joined #bitcoin-core-dev     
19:43 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev     
19:49 -!- reden [becafc53@gateway/web/freenode/ip.190.202.252.83] has quit [Quit: Page closed]     
19:58 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 248 seconds]     
19:59 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
20:09 -!- ABRAH [2a6d804c@gateway/web/freenode/ip.42.109.128.76] has joined #bitcoin-core-dev     
20:11 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
20:12 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
20:15 -!- jamesob [~james@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev     
20:19 -!- ABRAH [2a6d804c@gateway/web/freenode/ip.42.109.128.76] has quit [Ping timeout: 260 seconds]     
20:21 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
20:22 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
20:30 -!- mrfrasha_ [~mrfrasha@66-188-250-34.dhcp.eucl.wi.charter.com] has joined #bitcoin-core-dev     
20:30 -!- Gabe [b00bf122@gateway/web/freenode/ip.176.11.241.34] has joined #bitcoin-core-dev     
20:34 -!- Gabe [b00bf122@gateway/web/freenode/ip.176.11.241.34] has quit [Ping timeout: 260 seconds]     
20:58 -!- Jackson8377 [~Jackson@162-204-109-161.lightspeed.rcsntx.sbcglobal.net] has quit [Quit: Leaving]     
21:05 < meshcollider> is there any way for the functional tests to assert two error messages in a row
21:06 < meshcollider> assert_start_raises_init_error only checks the last error I think, which is a more general failure in the test I am working on, the error directly before it is more specific which is what I want to assert
21:07 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 272 seconds]     
21:20 -!- anditto [~anditto@182.248.158.129] has joined #bitcoin-core-dev     
21:23 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
21:23 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Client Quit]     
21:23 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
21:24 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
21:25 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
21:26 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 272 seconds]     
21:29 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
21:30 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
21:32 -!- jadee_ [~Jadee@50-248-173-75-static.hfc.comcastbusiness.net] has quit [Quit: This computer has gone to sleep]     
21:34 -!- mrfrasha_ [~mrfrasha@66-188-250-34.dhcp.eucl.wi.charter.com] has quit [Quit: mrfrasha_]     
22:04 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
22:05 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
22:06 < jonasschnelli> I'm working on a RPC call "scantxoutset" (scan utxo set for particular scrips or pubkeys[->script]) based on luke-jr sweepprivkey work. Would it make sense to run the command async?
22:07 < jonasschnelli> Like "scantxoutset start [<pubkeys>]",... and "scantxoutset status", where the later would tell about the progess... then maybe a "scantxoutset result <jobid>" for getting the txouts (compatible with listunspents for createrawtransaction usage)
22:08 < jonasschnelli> It would require an additional thread (utxo-scan-thread) and only one scan in time would be allowed
22:11 -!- jamesob [~james@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds]     
22:18 -!- _jadeeUnix [~Mutter@pool-173-63-207-238.nwrknj.fios.verizon.net] has joined #bitcoin-core-dev     
22:23 -!- _jadeeUnix [~Mutter@pool-173-63-207-238.nwrknj.fios.verizon.net] has quit [Quit: Mutter: www.mutterirc.com]     
22:27 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
22:28 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
22:33 < luke-jr> jonasschnelli: this sounds like a "create ram-only wallet; add watch addresses; rescan" tbh
22:34 < jonasschnelli> luke-jr: scantxoutset purpose is to crate a raw sweep transaction (and more)
22:35 < jonasschnelli> it would spit out utxos that can directly been used in createrawtransaction.. like:
22:35 < luke-jr> jonasschnelli: you would then do a fundrawtransaction after the rescan ;)
22:36 < luke-jr> I guess difference is you don't look at history; but maybe that should just be an alternative to rescan
22:36 < jonasschnelli> luke-jr: you don't want to do a rescan..
22:36 < jonasschnelli> the purpose of the utxo scan is to be much faster and works on pruned peers as well
22:36 < luke-jr> right
22:37 < luke-jr> my point is that if we're considering an async UTXO scan, it'd be better to have "createwallet" make a RAM-only one, and add a "scanutxo" or something
22:37 < luke-jr> and the RAM-only wallet is your state
22:39 < jonasschnelli> luke-jr: What would be the benefit of a mem only CWallet instead of a mem only CKeyStore?
22:39 < luke-jr> having only one kind of state instead of multiple
22:42 < jonasschnelli> luke-jr: I can't follow
22:42 -!- danklasson [3131eec6@gateway/web/freenode/ip.49.49.238.198] has quit [Quit: Page closed]     
22:42 < jonasschnelli> luke-jr: or do you mean the possibility to run multiple utxo scans concurrently?
22:45 < luke-jr> jonasschnelli: I would expect that to be supported, yes
22:45 < jonasschnelli> Okay. Yes. That would make sense...
22:46 < luke-jr> although maybe it has little use case, not sure
22:46 < luke-jr> so long as the scan can look for multiple things at the same time, that would seem much more sensible after all
22:47 < jonasschnelli> The major point I'm worried about is an RPC call that requires a couple of minutes to response... 
22:47 -!- maaku [~maaku@173.234.25.100] has joined #bitcoin-core-dev     
22:47 < jonasschnelli> multiple scans during the same time seems nice to have, but not extremely important.
22:49 < luke-jr> I would expect simpler code to use a temporary wallet too
22:50 < jonasschnelli> luke-jr: maybe
22:50 < jonasschnelli> BlueMatt: re https://github.com/bitcoin/bitcoin/pull/11281#pullrequestreview-83551405
22:50 < jonasschnelli> ack on "Caller needs to make sure pindexStop (and the optional pindexStart) are on the main chain after to the addition of any new keys you want to detect transactions for"?
22:54 -!- AegisAttack [~colin@2605:6000:cdc9:3b00:2913:7355:d8f7:e248] has quit [Ping timeout: 265 seconds]     
22:58 -!- mrfrasha_ [~mrfrasha@66-188-250-34.dhcp.eucl.wi.charter.com] has joined #bitcoin-core-dev     
23:00 -!- Guest16 [~textual@249.13.77.188.dynamic.jazztel.es] has joined #bitcoin-core-dev     
23:03 -!- Guest16 [~textual@249.13.77.188.dynamic.jazztel.es] has quit [Client Quit]     
23:04 -!- Guest16 [~textual@249.13.77.188.dynamic.jazztel.es] has joined #bitcoin-core-dev     
23:05 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
23:06 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
23:11 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
23:12 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
23:26 -!- Guest16 [~textual@249.13.77.188.dynamic.jazztel.es] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
23:29 -!- AegisAttack [~colin@2605:6000:cdc9:3b00:2913:7355:d8f7:e248] has joined #bitcoin-core-dev     
23:29 < jonasschnelli> wumpus: I think this should be merged (#11616), maybe do a last review/test?
23:29 < gribble> https://github.com/bitcoin/bitcoin/issues/11616 | Update ban-state in case of dirty-state during periodic sweep by jonasschnelli · Pull Request #11616 · bitcoin/bitcoin · GitHub
23:46 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-tgpwvnvnigftvbwt] has quit [Quit: Connection closed for inactivity]     
23:50 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 240 seconds]     
23:57 -!- AegisAttack [~colin@2605:6000:cdc9:3b00:2913:7355:d8f7:e248] has quit [Ping timeout: 265 seconds]