--- Log opened Tue Aug 14 00:00:39 2018
00:01 -!- hashrate [~root@li1803-11.members.linode.com] has quit [Quit: leaving]
00:20 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
00:23 -!- Krellan [~Krellan@50-203-21-10-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
00:24 < fanquake> wumpus 13963, 13962 and 13948 are a few trivial merges.
00:24 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev
00:33 < wumpus> fanquake: thanks, agree
00:34 < wumpus> we really need a replacement for the IRC merges bot
00:35 < wumpus> ken2812221_: problems with bitcoincore.org you can file at https://github.com/bitcoin-core/bitcoincore.org
00:36 -!- Rootsudo [~textual@112.205.33.21] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
00:38 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
00:49 < ken2812221_> wumpus: Thanks, I'll check that out.
00:57 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev
00:57 -!- Rootsudo [~textual@112.205.33.21] has quit [Client Quit]
00:58 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev
00:58 -!- Rootsudo [~textual@112.205.33.21] has quit [Client Quit]
00:58 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
01:12 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev
01:16 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds]
01:25 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev
01:34 -!- ken2812221_ is now known as ken2812221
01:34 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
01:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:39 -!- D00M [~D00M@49.146.41.106] has joined #bitcoin-core-dev
01:59 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
02:03 -!- Rootsudo [~textual@112.205.33.21] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
02:20 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev
02:27 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit []
02:32 < wumpus> time to update my build infrastructure so I can finally build the 0.17 branch in gitian
02:34 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev
02:37 < wumpus> starting with building the most recent lxc, 3.0.1 apparently
02:37 -!- Rootsudo [~textual@112.205.33.21] has quit [Client Quit]
02:37 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev
02:38 -!- Rootsudo [~textual@112.205.33.21] has quit [Client Quit]
02:38 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev
02:38 -!- Rootsudo [~textual@112.205.33.21] has quit [Client Quit]
02:39 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev
02:39 -!- Rootsudo [~textual@112.205.33.21] has quit [Client Quit]
02:40 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev
02:40 -!- Rootsudo [~textual@112.205.33.21] has quit [Client Quit]
02:41 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev
02:41 -!- Rootsudo [~textual@112.205.33.21] has quit [Client Quit]
02:45 -!- Jmabsd [~jmabsd@pcd247152.netvigator.com] has joined #bitcoin-core-dev
02:55 -!- Gnappuraz [5f5bf576@gateway/web/freenode/ip.95.91.245.118] has joined #bitcoin-core-dev
02:57 < Gnappuraz> Hi, I was going through the bitcoin documentation but I can't find the rationale behind the fact of using the prevTx.scriptPubKey in the place of curTx.scriptSig when creating the signature
03:01 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
03:05 -!- vexbuy [~vexbuy@89.39.107.195] has joined #bitcoin-core-dev
03:08 -!- vexbuy_ [~vexbuy@89.39.107.195] has joined #bitcoin-core-dev
03:12 -!- vexbuy [~vexbuy@89.39.107.195] has quit [Ping timeout: 248 seconds]
03:13 -!- vexbuy [~vexbuy@89.39.107.195] has joined #bitcoin-core-dev
03:17 -!- vexbuy_ [~vexbuy@89.39.107.195] has quit [Ping timeout: 248 seconds]
03:19 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 250 seconds]
03:21 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev
03:22 -!- vexbuy_ [~vexbuy@89.39.107.195] has joined #bitcoin-core-dev
03:26 -!- vexbuy [~vexbuy@89.39.107.195] has quit [Ping timeout: 272 seconds]
03:26 -!- vexbuy [~vexbuy@89.39.107.195] has joined #bitcoin-core-dev
03:29 -!- vexbuy_ [~vexbuy@89.39.107.195] has quit [Ping timeout: 240 seconds]
03:31 -!- vexbuy_ [~vexbuy@89.39.107.195] has joined #bitcoin-core-dev
03:34 -!- vexbuy [~vexbuy@89.39.107.195] has quit [Ping timeout: 240 seconds]
03:35 -!- vexbuy [~vexbuy@89.39.107.195] has joined #bitcoin-core-dev
03:39 -!- vexbuy_ [~vexbuy@89.39.107.195] has quit [Ping timeout: 268 seconds]
03:40 -!- vexbuy_ [~vexbuy@89.39.107.195] has joined #bitcoin-core-dev
03:43 -!- vexbuy [~vexbuy@89.39.107.195] has quit [Ping timeout: 256 seconds]
03:49 -!- vexbuy [~vexbuy@89.39.107.195] has joined #bitcoin-core-dev
03:50 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving]
03:52 -!- vexbuy_ [~vexbuy@89.39.107.195] has quit [Ping timeout: 260 seconds]
03:54 -!- vexbuy_ [~vexbuy@89.39.107.195] has joined #bitcoin-core-dev
03:54 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
03:57 -!- vexbuy [~vexbuy@89.39.107.195] has quit [Ping timeout: 248 seconds]
04:03 -!- vexbuy [~vexbuy@89.39.107.195] has joined #bitcoin-core-dev
04:06 -!- vexbuy_ [~vexbuy@89.39.107.195] has quit [Ping timeout: 240 seconds]
04:07 -!- vexbuy_ [~vexbuy@89.39.107.195] has joined #bitcoin-core-dev
04:10 -!- vexbuy [~vexbuy@89.39.107.195] has quit [Ping timeout: 240 seconds]
04:12 -!- vexbuy [~vexbuy@89.39.107.195] has joined #bitcoin-core-dev
04:16 -!- vexbuy_ [~vexbuy@89.39.107.195] has quit [Ping timeout: 248 seconds]
04:16 -!- goatpig [56eece80@gateway/web/freenode/ip.86.238.206.128] has joined #bitcoin-core-dev
04:16 -!- vexbuy_ [~vexbuy@89.39.107.195] has joined #bitcoin-core-dev
04:19 -!- vexbuy [~vexbuy@89.39.107.195] has quit [Ping timeout: 256 seconds]
04:21 -!- vexbuy [~vexbuy@89.39.107.195] has joined #bitcoin-core-dev
04:24 -!- vexbuy_ [~vexbuy@89.39.107.195] has quit [Ping timeout: 248 seconds]
04:26 -!- vexbuy_ [~vexbuy@89.39.107.195] has joined #bitcoin-core-dev
04:27 -!- Gnappuraz [5f5bf576@gateway/web/freenode/ip.95.91.245.118] has quit [Ping timeout: 252 seconds]
04:29 -!- vexbuy [~vexbuy@89.39.107.195] has quit [Ping timeout: 260 seconds]
04:30 -!- vexbuy [~vexbuy@89.39.107.195] has joined #bitcoin-core-dev
04:33 -!- vexbuy_ [~vexbuy@89.39.107.195] has quit [Ping timeout: 240 seconds]
04:33 -!- JackH [~laptop@host86-174-212-180.range86-174.btcentralplus.com] has quit [Ping timeout: 272 seconds]
04:35 -!- vexbuy_ [~vexbuy@89.39.107.195] has joined #bitcoin-core-dev
04:35 -!- vexbuy_ [~vexbuy@89.39.107.195] has quit [Remote host closed the connection]
04:38 -!- vexbuy [~vexbuy@89.39.107.195] has quit [Ping timeout: 240 seconds]
04:42 -!- JackH [~laptop@host86-173-175-116.range86-173.btcentralplus.com] has joined #bitcoin-core-dev
04:53 -!- miknotauro_ [~miknotaur@187.207.33.20] has quit [Ping timeout: 268 seconds]
04:54 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
05:09 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
05:09 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
05:12 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Read error: No route to host]
05:13 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
05:19 < wumpus> $ bin/make-base-vm --lxc --suite bionic --arch amd64                                                                                              
05:19 < wumpus> E: No such script: /usr/share/debootstrap/scripts/bionic
05:19  * wumpus wonders where to get this file
05:23 < wumpus> seemingly the ubuntu package of debootstrap has it, but I don't think I can just install that on debian
05:26 < wumpus> found the source download @ http://archive.ubuntu.com/ubuntu/pool/main/d/debootstrap/debootstrap_1.0.95.tar.gz
05:29 < wumpus> nice, removing the debootstrap debian package and simply installing that seems to have worked
05:32 < wumpus> luckily it's only a VM so I don't care about the mess
05:47 < wumpus> Failed run an application inside container
05:47 < wumpus> bin/gbuild:21:in `system!': failed to run make-clean-vm --suite bionic --arch amd64 (RuntimeError)
05:47 < wumpus> ouch--can't build 0.16.x nor 0.17.x anymore
06:07 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
06:07 < wumpus> apparently I'm missing init.lxc.static
06:07 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
06:09 < BlueMatt> can someone close #13826 and #13901 as dup's (sorry, wasnt able to fix it last week, will fix it soon)
06:09 < gribble> https://github.com/bitcoin/bitcoin/issues/13826 | packaging: Auto-change datadir in ubuntu ppa · Issue #13826 · bitcoin/bitcoin · GitHub
06:09 < gribble> https://github.com/bitcoin/bitcoin/issues/13901 | adduser: The user `bitcoin already exists. Exiting. · Issue #13901 · bitcoin/bitcoin · GitHubAsset 1Asset 1
06:11 < BlueMatt> wait, no I misread the first one, I have no idea what they're even saying
06:12 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Ping timeout: 268 seconds]
06:13 < wumpus> apparently I needed "apt-get libcap-dev",  please work now
06:13 < wumpus> BlueMatt: sure
06:14 < wumpus> closed the second one
06:26 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has joined #bitcoin-core-dev
06:32 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
06:33 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
06:35 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
06:37 -!- unholymachine [~quassel@2601:8c:c003:9f16:6c76:f163:bba:9166] has quit [Remote host closed the connection]
06:41 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
06:44 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
06:47 -!- jamesob [~james@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
07:02 -!- marcinja_ [~marcin@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev
07:05 < wumpus> phew, 0.16.2 build succesfully, let's see about 0.17
07:05 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has quit [Read error: Connection reset by peer]
07:09 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
07:25 -!- harding [quassel@2600:3c03::f03c:91ff:fe7b:78d1] has joined #bitcoin-core-dev
07:34 < MarcoFalke> did the irc spam stop?
07:34 < MarcoFalke> If so could we set the irc flags to what they were a few weeks ago?
07:35 -!- mode/#bitcoin-core-dev [+o sipa] by ChanServ
07:35 -!- mode/#bitcoin-core-dev [-n] by sipa
07:35 -!- mode/#bitcoin-core-dev [-o sipa] by sipa
07:35 < sipa> done
07:35 < MarcoFalke> thx
07:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
07:39 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
07:42 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
07:42 -!- vexbuy [~vexbuy@109.201.133.30] has joined #bitcoin-core-dev
07:47 -!- vexbuy [~vexbuy@109.201.133.30] has quit [Client Quit]
07:52 < wumpus> does this mean...
07:53 -!- unholymachine [~quassel@2601:8c:c003:9f16:80e7:5db4:8539:2ee3] has joined #bitcoin-core-dev
07:53 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/dabfcb03071e...3e5424faf6ff
07:53 < bitcoin-git> bitcoin/master 43811e6 Andrew Chow: Fix PSBT deserialization of 0-input transactions...
07:53 < bitcoin-git> bitcoin/master bd19cc7 Andrew Chow: Serialize non-witness utxo as a non-witness tx but always deserialize as witness...
07:53 < bitcoin-git> bitcoin/master 3e5424f Wladimir J. van der Laan: Merge #13960: Fix PSBT deserialization of 0-input transactions...
07:53 < wumpus> YESSSSS
07:54 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
07:54 < bitcoin-git> [bitcoin] laanwj closed pull request #13960: Fix PSBT deserialization of 0-input transactions (master...fix-decodepsbt-no-in) https://github.com/bitcoin/bitcoin/pull/13960
07:58 < sipa> haha
07:59 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Quit: Leaving.]
08:00 -!- davex__ [~user@97-119-117-177.omah.qwest.net] has joined #bitcoin-core-dev
08:00 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
08:02 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
08:02 -!- D00M [~D00M@49.146.41.106] has quit [Ping timeout: 260 seconds]
08:10 < ben_zen1>  ­ ­ ­ ­ ­  http://magaimg.net/img/wqz.jpg  ­  ­ ­ ­ ­ ­ ­ ­ ­ ­ http://magaimg.net/img/wqz.jpg  ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­
08:10 < ben_zen1>  ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­  ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­  ­ https://i.redd.it/8w0r915sm1ty.jpg  ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­
08:10 < ben_zen1>  ­ ­  https://i.imgur.com/FZ5iI6Y.jpg ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­
08:10 < ben_zen1>  ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­  ­ https://i.redd.it/el0p0os7u7fz.jpg  ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­
08:10 < ben_zen1>  ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ https://i.redd.it/r2n8a788qs211.jpg  ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ 
08:10 < ben_zen1> http://i.imgur.com/DfZdPTy.jpg  ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ 
08:10 < ben_zen1> http://magaimg.net/img/5xpf.jpg  ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­
08:11 < ben_zen1>  ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ https://i.imgur.com/AaQg3Pp.jpg  ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­ ­
08:12 -!- mode/#bitcoin-core-dev [+o sipa] by ChanServ
08:12 -!- mode/#bitcoin-core-dev [+n] by sipa
08:12 < sipa> sorry :(
08:12 -!- mode/#bitcoin-core-dev [-o sipa] by sipa
08:13 -!- mode/#bitcoin-core-dev [+o sipa] by ChanServ
08:15 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
08:29 <@sipa> wumpus: i'm going to clear the 'needs release notes' for all PRs merged before 0.17
08:29 <@sipa> or are there things in the 0.16 branch that haven't been in a release yet?
08:43 <@sipa> are we going to include qt arm builds in 0.17 releases?
08:55 -!- marcinja_ [~marcin@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
09:01 -!- nodweber [~nodweber@unaffiliated/nodweber] has joined #bitcoin-core-dev
09:08 <@sipa> i went through the list of merged PRs, and added "Needs Release Notes" here and there where i felt it was useful
09:09 <@sipa> some of these already have release notes, but i think it's useful to have such a list to compare with the notes when they are finished
09:11 -!- photonclock_ [~photonclo@47.37.153.193] has joined #bitcoin-core-dev
09:12 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
09:18 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
09:19 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
09:46 -!- marcinja [~marcin@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
09:49 -!- vexbuy [~vexbuy@109.201.133.30] has joined #bitcoin-core-dev
09:55 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev
09:59 < wumpus> sipa: make ssense
09:59 < wumpus> +s
10:00 < wumpus> nothing has been merged after 0.16.2 that needs release notes
10:07 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
10:10 -!- vexbuy [~vexbuy@109.201.133.30] has quit [Ping timeout: 240 seconds]
10:11 -!- Rootsudo [~textual@112.205.33.21] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
10:34 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
10:35 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
10:40 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev
10:40 -!- grubles [~grubles@unaffiliated/grubles] has quit [Remote host closed the connection]
10:41 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev
10:44 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
10:45 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
10:46 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Quit: Leaving.]
10:47 < wumpus> gitian build--at least for linux--of 0.17 branch worked, phew
10:48 < wumpus> going to test at least the ARM executables
10:49 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Ping timeout: 240 seconds]
10:52 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev
10:57 < instagibbs> anyone else getting github.com domain name res failure for git
10:58 < instagibbs> oh sike, i just have no internet on the device
10:58 <@sipa> i confirm your IRC client is on the internet
10:58 -!- mode/#bitcoin-core-dev [-o sipa] by sipa
10:59 < instagibbs> the burdens of running multiple computing devices...
10:59 -!- Rootsudo [~textual@112.205.33.21] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
10:59 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev
11:00 -!- Rootsudo [~textual@112.205.33.21] has quit [Client Quit]
11:00 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev
11:00 -!- Rootsudo [~textual@112.205.33.21] has quit [Client Quit]
11:01 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev
11:01 -!- Rootsudo [~textual@112.205.33.21] has quit [Client Quit]
11:02 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev
11:02 -!- Rootsudo [~textual@112.205.33.21] has quit [Client Quit]
11:03 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev
11:03 -!- Rootsudo [~textual@112.205.33.21] has quit [Client Quit]
11:03 -!- math_ [~mario@p4FCB3FA3.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
11:12 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev
11:13 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
11:28 -!- itaseski [~itaseski@213.135.176.245] has joined #bitcoin-core-dev
11:30 -!- Jmabsd [~jmabsd@pcd247152.netvigator.com] has quit [Ping timeout: 244 seconds]
11:38 -!- timothy [~tredaelli@redhat/timothy] has quit [Ping timeout: 256 seconds]
12:13 < BlueMatt> hmmm, MarcoFalke points out that it looks like we may be undercounting mempool memory usage by sizeof(CTransaction)*txcount
12:14 < gmaxwell> BlueMatt: so fix it?
12:14 < BlueMatt> oh, wait, nvm, I'm misreading it
12:15 < BlueMatt> gmaxwell: I was hoping for someone to double-check me, but I found myself to be wrong faster :p
12:15 < gmaxwell> fixing it also has the property of showing you that you're wrong fast. :P
12:16 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Quit: Leaving]
12:16 < BlueMatt> lol true
12:21 < jonasschnelli_> hmm... manually added nodes with -connect have no service flags?!
12:22 -!- jonasschnelli_ is now known as jonasschnelli
12:23 < jonasschnelli> If its unknown if the peer supports NODE_ENCRYPTION, I guess just trying and ^NODE_ENCRYPTION if failed seems accptable 
12:25 < gmaxwell> probably just try. maybe in a couple years we mandate encryption for connect and addnode (and add something for a connect that doesn't support it)
12:27 < jonasschnelli> gmaxwell: you mean also trying on peers not signalling NODE_ENCRYPTION via the service flags (and eventually update addrman's service flags if failed to encrypt)?
12:28 < sipa> i would only try it for things that signal encryption
12:28 < sipa> if it doesn't work, drop the flag in your addrman and disconnect
12:28 < gmaxwell> I was specifically talking about connect and addnode, where there are no 'flags' before we connect.
12:28 < sipa> ah, makes sense
12:28 < sipa> uh, that means trying twice :(
12:29 < gmaxwell> if they don't support it.
12:29 < gmaxwell> Do you see an alternative?
12:29 < gmaxwell> We could immediately introduce flags to connect and addnode to say that crypto isn't in use.
12:29 < sipa> -encaddnode -encconnect :)
12:29 < gmaxwell> encryption should be the default.
12:30 < gmaxwell> Ignoring the initial deployment catch22,  I dont think there is much reason to even support connect/addnode to non-encryption supporting things...
12:30 < jonasschnelli> indeed...
12:30 < sipa> yeah
12:30 < sipa> but you don't want existing addnode=IP lines in bitcoin.conf files suddenly fail 
12:31 < jonasschnelli> I think if -netconnection is enabled (which could be the default), addnode (and friends) should enforce encrypted peers
12:31 < gmaxwell> sipa: Major versions can break things, thats what release notes are for.
12:31 -!- michaels_ [~michaelsd@208.59.170.5] has joined #bitcoin-core-dev
12:32 < sipa> or we could add encryption support, and a way to add flags to addnode/connect in one version
12:32 < jonasschnelli> I think failing on addnodes that are non encrypted is probably a good thing
12:32 < sipa> and then change the default to encryption in a later version
12:32 < jonasschnelli> or that,.. yes
12:32 < gmaxwell> we could make connect and addnode able to take an parameter e.g. connect=1.2.3.4$nocrypto 
12:32 < gmaxwell> yes, that would be okay.
12:32 < sipa> that may be necessary regardless, yes
12:33 < sipa> i wonder if we should call it encryption
12:33 < jonasschnelli> enciphering? *duck*?
12:33 < gmaxwell> connect=1.2.3.4$crypto  connect=1.2.3.4$nocrypto   ... and the default if no specified starts out no and gets switched later.
12:33 < sipa> maybe it should just be "v2 protocol" (which happens to encrypt, but it's really a new non-backward compatible protocol encoding
12:34 < jonasschnelli> Yes. That sounds good... I just fear scope creeping if we label it like that
12:34 < sipa> okay
12:34 < sipa> just an idea
12:34 < jonasschnelli> "Ah. v2 protocol, why don't use change the inv that way",. etc.
12:35 < sipa> but encryption isn't something that should be advertized really
12:35 < jonasschnelli> But since it's a new protocol (kind-of a one time chance), those ideas are maybe welcome
12:35 < sipa> or "v2 transport"
12:36 < sipa> it's not really the protocol that changes, just the encoding
12:36 < jonasschnelli> sipa: what do you mean with "advertised"?
12:36 < jonasschnelli> sipa: Yes. "v2 transport" is more accurate
12:36 < sipa> if you use the term 'encryption' to describe the feature there may be a false sense of security risk
12:37 -!- photonclock___ [~photonclo@47.37.153.193] has joined #bitcoin-core-dev
12:37 < jonasschnelli> Hm... you mean by not protecting from an active MITM?
12:38 < jonasschnelli> I guess using the word encryption when it comes to the v2 transport would not be entirely wrong though
12:38 -!- photonclock_ [~photonclo@47.37.153.193] has quit [Ping timeout: 244 seconds]
12:38 -!- photonclock___ is now known as photonclock_
12:38 < sipa> well encryption certainly protects against certain attacks, but not nearly all the ones that people think of when you say encryption :)
12:39 -!- michaels_ [~michaelsd@208.59.170.5] has quit [Quit: Textual IRC Client: www.textualapp.com]
12:39 < gmaxwell> Yea, it's more than encrypion, also encryption implies properties that it doesn't provide.
12:39 < gmaxwell> e.g. the oppturnistic encryption does not prevent MITM.
12:40 < jonasschnelli> It eventually does prevent from MITM because an MITM would be easy to detect, but it does not protect from MITM
12:40 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
12:41 < sipa> not without somewhat deployed authentication
12:41 < jonasschnelli> Yes
12:41 < gmaxwell> in any case, we'll want to be able to provide arguments to addnode and connect later for auth keys.
12:42 < jonasschnelli> With the "stealth handshake" (the very first 32byte message/key exchange), is there anything we should plan for in case we want to add something like RLWE to the handshake
12:42 < jonasschnelli> +?
12:42 < gmaxwell> If we did something like add rwle we could establish the secp256k1 handshake first and then inside that stream upgrade.
12:43 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has joined #bitcoin-core-dev
12:44 < jonasschnelli> gmaxwell: wouldn't that partially break the "stealth" component (if we assume ecdh in secp256k1 is broken) since the inner 2nd handshake would probably require standard p2p message encryption?
12:45 < sipa> jonasschnelli: not more than the current secp stealth component is broken by being sent in cleartest
12:45 -!- Randolf [~randolf@96.53.47.42] has quit [Quit: Leaving]
12:45 < gmaxwell> ^ plus the 'stealth's is pretty weak, it's mostly just making harder to use dumb pattern matching to block.
12:47 < jonasschnelli> We could allow additional dummy data in the encryption handshake as we do in the v2 message encoding protocol to make DPI harder
12:47 < gmaxwell> hm. it really would be much easier if the initial handshake had a flag. e.g. [ecdh key][byte]  it could still block dumb pattern matching by making the byte xored with the last byte of the pubkey.
12:48 < gmaxwell> kinda irritating to add RLWE after the fact, sadly.
12:48 < jonasschnelli> I think the change is already pretty huge,... I think adding more should be avoided
12:49 < jonasschnelli> The tor argument "collect now, decrypt later" may not be applicable 1:1 to bitcoin
12:49 < jonasschnelli> Especially as long as there are no private p2p extensions and an internal auth mechanism
12:49 < jonasschnelli> IMO deploying RLWE together with auth could make sense
12:50 < sipa> how much code is it?
12:51 < jonasschnelli> Right now +1,563/-178 (incomplete, missing tests)
12:51 < gmaxwell> RWLE is small, one sec.
12:52 < jonasschnelli> I guess the new code is very critical. Must be review profound
12:56 -!- rls [~rls@ip98-171-84-127.ph.ph.cox.net] has joined #bitcoin-core-dev
12:56 < gmaxwell> sipa: the ref implementation of newhope appears to be Total Physical Source Lines of Code (SLOC)                = 1,347
12:56 < gmaxwell> which includes some tests and stuff.
12:56 < gmaxwell> obviously it's bigger with the AVX versions and whatnot.
12:57 < jonasschnelli> I guess AVX for Chacha, Poly1305 and newhope could follow later?
12:58 < gmaxwell> as far as security goes, the interfaces is really trivial, so it's easy to review that the worst risk it presents is not adding security, leaking something about its randomness, or being slow.
12:58 < gmaxwell> It also has been deployed in _chrome_ as part of an expirement with ssl.
12:58 < gmaxwell> (they made an expiremental handshake for SSL that did the H(ECDH||newhope) thing.
12:58 < gmaxwell> implementation is here: https://github.com/newhopecrypto/newhope-usenix/tree/master/ref
12:59 < gmaxwell> I think the worst outcome from deploying it is that a month after wide deployment, the security is broken completely and we're stuck carrying it around (and wasting cpu cycles on it) even though it does nothing. :P
13:00 < jonasschnelli> I somehow would prefer a two step implementation (and eventually also specification) approach from current v1 non encrypted network protocol to a quantum safe v2 (or v2.1) protocol
13:00 < gmaxwell> ah, the torref/toravx implementations are apparently constant time.
13:01 < jonasschnelli> Is there an anti DPI argument for using 32byte keyhandshakes rather then 64byte?
13:01 < gmaxwell> jonasschnelli: sad thing is that the quantum safe thing is probably not worth doing on its own. 
13:01 < gmaxwell> jonasschnelli: what would the extra 64 bytes be?
13:01 < gmaxwell> er extra 32.
13:02 < jonasschnelli> if we want to add a flag but want to avoid 33bytes (or 34) due to DPI issues, we could pad up to 64? 
13:03 < gmaxwell> I don't think we want to avoid 33. We want to avoid fixed bytes. E.g. "if bytes 32-45 are 0xdeadbeef... reject"
13:04 < jonasschnelli> Oh that. So the xoring with the last pubkey byte for the flag could then be accptable... I think
13:04 < gmaxwell> right.
13:05 < jonasschnelli> gmaxwell: why is upgrading the handshake later to include newhope be "not worth doing on its own"?
13:05 < jonasschnelli> you mean the additional (questionable) security versus the deployment hassle?
13:05 < sipa> i think upgrading the transport can be upgraded later easily enough that we don't need to rush including it right now
13:06 < gmaxwell> because the security benefit is quite conjectural. so taking a network upgrade cycle, with incompatiblities and stuff, to maybe gain nothing.
13:06 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]
13:06 < gmaxwell> So for example I think to do newhope nicely later, just a flag isn't enough.
13:06 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev
13:06 < gmaxwell> because you want the initator to send their DH value in the first message.
13:07 < gmaxwell> well I don't think we need to rush for sure. But if nothing else it's useful to think about how we would take the next step.
13:07 < gmaxwell> So lemme talk though my thought process a bit.
13:07 < jonasschnelli> what if the flag comes first to the message content and length can change later?
13:08 < gmaxwell> earlier today I was thinking "we could deploy newhope by just brining up the secp256k1 encryption, then sending a rekey message that triggers upgrading."  but then I realized that runs into the problem we had before of having to do the keying twice-- once for each direction.
13:09 < gmaxwell> jonasschnelli: how does the recipent even know the length?
13:09 < gmaxwell> (if its not fixed)
13:09 < sipa> wahaha, the low-security version of newhope is called jarjar
13:09 < jonasschnelli> gmaxwell: right now,... is just looks for 32bytes, if it matches a version message, it transforms the bytes into a legacy v1 message container
13:10 < jonasschnelli> (and continues with legacy protocol)
13:10 < jonasschnelli> if not a version message, it tried the handshake
13:10 < jonasschnelli> *tries
13:11 < sipa> that seems overly complicated
13:11 < gmaxwell> okay, so your point is that there could be extra data, but how does a current client know to ignore the extradata? e.g. why won't that just look like an invalid encryption once the handshake completes.
13:11 < jonasschnelli> sipa: idea how to make this simpler?
13:11 < sipa> i think you should just assume a connection is encrypted if the flag is set, and it will fail if it turns out it wasn't encrypted
13:11 < sipa> at which point you just disconnect and try another peer
13:12 < jonasschnelli> sipa: I thought we want a mode where encryption is optional
13:12 < gmaxwell> It is optional.
13:12 < gmaxwell> sipa: how does this avoid an attack where the first peer you connect to gives you the encryption flag set for everyone, causing you to be unable to connect to most of the network?
13:14 < jonasschnelli> I can't follow. That would mean we drop every connection that failes to do a handshake (think of SPV clients, etc.)?
13:14 < sipa> jonasschnelli: ah, for incoming connections!
13:14 < sipa> ugh
13:14 < gmaxwell> I had the same confusion as sipa.
13:14 < jonasschnelli> Outgoind is easy
13:14 < jonasschnelli> Incomming IMHO must be ready to detect a handshake OR a version legacy msg
13:15 < sipa> unless they're separate ports or something like that... but yeah
13:15 < jonasschnelli> But code wise its simple: buffer the first 32bytes, check if it is (very likely) a version message and migrate the message type to a legacy message
13:15 < jonasschnelli> https://github.com/bitcoin/bitcoin/commit/edfbd082af48f3a8f4447083e847e67aa4b2a40b#diff-9a82240fe7dfe86564178691cc57f2f1R791
13:16 < jonasschnelli> (& avoid pubkeys that start with the network magic & 'version')
13:16 < sipa> ah yes, that seems reasonable
13:17 < jonasschnelli> If the handshake flag would be the first byte, and the xor key the second, we could read to bytes and figure out if we need to buffer 64 or 32
13:17 < sipa> i think it could just be "pubkeys cannot start with the network magic"
13:18 < jonasschnelli> Wouldn't that reduce the possible key-space by 2^28?
13:18 < jonasschnelli> I guess I'm wrong though. :)
13:19 < sipa> from 255 bits to 254.999999999664 bits of entropy
13:19 < gmaxwell> and not in a useful way that helps attacks regardless.
13:20 < jonasschnelli> Okay. I see
13:20 < jonasschnelli> Is using the first pubkey bytes as flag xor key reasonable?
13:21 < sipa> can't the flag be inside the encrypted stream?
13:21 < jonasschnelli> It can, but we then would assume that ECDH must always be done
13:21 < sipa> i think that's fine
13:21 < gmaxwell> now we wind back to my prior comment about upgrading and synchronizing both directions.
13:22 < sipa> i don't mean a flag to signal upgrading
13:22 < jonasschnelli> I guess then we don't need a flag, we can handle it with messages then
13:22 < sipa> just a flag that says "this is protocol version X"
13:22 < gmaxwell> I think it's fine if ECDH is always done.
13:22 < sipa> if you don't understand the flag, disconnect
13:22 < jonasschnelli> gmaxwell: why is re-keying in both directions a problem?
13:22 < sipa> and in a new version, the RWLE can be mandatory in both directions, with no synchronization issues
13:22 < gmaxwell> twice the computation and overhead.
13:23 < jonasschnelli> AFAIK the current rekeying can only be initiated by the encryption responder (server) by sending a "rekey" message
13:23 < sipa> both parties should be able to rekey
13:23 < sipa> or it should be automatic after a certain amount of data
13:23 < jonasschnelli> Yes. 1GB is currently the specs and not below 10s
13:23 < gmaxwell> sipa: I pointed out before that we ought to support time based so that we get forward compromise resistance on low traffic links.
13:24 < sipa> also, is rekeying just hashing the existing encryption key, or is it a new ECDH negotiation?
13:24 < jonasschnelli> just hashing
13:24 < gmaxwell> it should be the former.
13:24 < gmaxwell> right.
13:24 < sipa> okay
13:24 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #bitcoin-core-dev
13:24 < gmaxwell> I don't see any value in repeating ECDH for incremental rekeying.
13:24 < sipa> yeah
13:25 -!- rls [~rls@ip98-171-84-127.ph.ph.cox.net] has quit [Ping timeout: 272 seconds]
13:25 < gmaxwell> in any case, if your intention is to encrypt the protocol version that means the initator cannot send a version without an extra roundtrip.
13:25 < sipa> i don't think that matters
13:25 < gmaxwell> I guess we don't really care too much about roundtrips, but it's the consequence.
13:25 < sipa> the responder picks the version of the protocl
13:25 < sipa> of the initiator doesn't like it, disconnect
13:25 < gmaxwell> but the initator has to offer.
13:26 < gmaxwell> or the responder will pick something the initator doesn't support, gratitiously.
13:26 < sipa> that's no different than now
13:26 < gmaxwell> So say, for example, you deploy newhope on your node... now you lose crypto to all existing peers? because you pick newhope and then they drop you?
13:27 < sipa> ah yes, i see; there is an assymetry in knowledge
13:27 < sipa> the initiator can be expected to know what the responder supports beforehand, but not the other way around
13:28 < jonasschnelli> Would that be an argument for the flag at the very beginning of the handshake?
13:29 < gmaxwell> or, it's just something that we'd have to handle with an additional round trip.
13:29 < sipa> i think that's fine
13:30 < gmaxwell> e.g. ecdh->   <-ecdh,enc(<flags>, extradata like a new hope handshake)  ->enc(flags, payload)...
13:30 < jonasschnelli> But I currently don't know how to handle the re-key sync problem,.. I guess dropping all messages after peer has sent the "rekey" message until it gots the "rekey-ack" response is a no go
13:31 < gmaxwell> the rekey is determinstic.  it should just be you send a rekey message and then the very next byte is encrypted with the next key.
13:31 < sipa> and do it separately for both directions
13:31 < gmaxwell> And have the rekey operate independantly for each direction.
13:31 < gmaxwell> rekeys are cheap, they're fine to do independantly.  
13:31 < jonasschnelli> Ah yes. That would work.
13:31 < gmaxwell> I want to avoid doing DH protocols independantly even for a newhope upgrade though.
13:32 < sipa> there could also be a reqrekey message message, which requests that the other party do a rekey, but it has no effect on the protocol until they respond with a rekey
13:32 < gmaxwell> sipa: I think instead you can just say that you have to do at least one rekey between two rekeys by the other side.
13:33 < jonasschnelli> or could an initiated rekey from peer A requires an rekeying from peer B within a timeout of X?
13:33 < gmaxwell> jonasschnelli: then you get into a rekey looop for a link with latency higher than X. :P :P
13:33 < gmaxwell> But just saying that you must rekey if you have seen two rekeys in the other direction since the last time you rekeyed, I think doesn't have that problem.
13:33 < jonasschnelli> heh... on dump implementations, yes. But point taken.
13:34 < gmaxwell> or don't even worry about it and just specify that you must rekey after 1hr or 1GB (whichever comes first). And anyone who doesn't is non-conforming and if anyone cares, they could start banning based on the behavior.
13:35 < jonasschnelli> Yes. Seems the be required anyways.
13:36 < jonasschnelli> Okay. Thanks. Going back to the "drawing board" (specs and impl.).
13:37 < sipa> i guess a rekey request is pointless; the other party could obey the request, but still keep the old encryption key in memory
13:39 < gmaxwell> yep.
13:51 -!- unholymachine [~quassel@2601:8c:c003:9f16:80e7:5db4:8539:2ee3] has quit [Remote host closed the connection]
13:56 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving]
14:07 -!- unholymachine [~quassel@89.34.98.194] has joined #bitcoin-core-dev
14:21 -!- promag [~promag@83.223.251.125] has joined #bitcoin-core-dev
14:38 -!- michaelsdunn1 [~michaelsd@208.59.170.5] has joined #bitcoin-core-dev
14:55 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
14:56 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
14:57 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
14:58 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 240 seconds]
14:59 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Ping timeout: 240 seconds]
15:00 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Ping timeout: 272 seconds]
15:05 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 244 seconds]
15:06 -!- aggieben [~aggieben@cpeb7-162.geusnet.com] has quit [Remote host closed the connection]
15:11 -!- itaseski [~itaseski@213.135.176.245] has quit [Ping timeout: 256 seconds]
15:21 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has quit [Remote host closed the connection]
15:21 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev
15:31 -!- michaelsdunn1 [~michaelsd@208.59.170.5] has quit [Remote host closed the connection]
15:31 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
15:39 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds]
15:40 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
15:46 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev
15:51 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
15:56 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has quit []
15:58 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
16:05 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
16:06 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
16:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 244 seconds]
16:43 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
16:44 -!- Rootsudo [~textual@112.205.33.21] has quit [Quit: Textual IRC Client: www.textualapp.com]
16:54 -!- polydin [~delphi@2602:306:b8b6:b970:3da2:8778:ad8c:877a] has joined #bitcoin-core-dev
16:57 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has joined #bitcoin-core-dev
16:59 -!- profmac [~ProfMac@2001:470:1f0f:226:4170:c2a5:7820:3124] has quit [Quit: Leaving]
17:00 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
17:06 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]
17:17 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
17:32 -!- polydin [~delphi@2602:306:b8b6:b970:3da2:8778:ad8c:877a] has quit [Quit: Leaving]
17:58 -!- promag [~promag@83.223.251.125] has quit [Remote host closed the connection]
18:07 -!- photonclock___ [~photonclo@47.37.153.193] has joined #bitcoin-core-dev
18:08 -!- photonclock_ [~photonclo@47.37.153.193] has quit [Ping timeout: 248 seconds]
18:08 -!- photonclock___ is now known as photonclock_
18:16 -!- murrayn [~dafuq@unaffiliated/murrayn] has quit [Quit: Adios mofos]
18:17 -!- goatpig [56eece80@gateway/web/freenode/ip.86.238.206.128] has quit [Ping timeout: 252 seconds]
18:20 -!- murrayn [~dafuq@unaffiliated/murrayn] has joined #bitcoin-core-dev
18:21 -!- justan0theruser is now known as justanotheruser
18:24 -!- photonclock_ [~photonclo@47.37.153.193] has quit [Quit: photonclock_]
18:49 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]
18:49 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
18:50 -!- justan0theruser is now known as justanotheruser
19:08 -!- D00M [~D00M@49.146.41.106] has joined #bitcoin-core-dev
19:12 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit []
19:19 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has quit [Read error: Connection reset by peer]
19:23 -!- Jmabsd [~jmabsd@pcd247152.netvigator.com] has joined #bitcoin-core-dev
19:25 -!- nanotube [~nanotube@unaffiliated/nanotube] has quit [Ping timeout: 276 seconds]
19:25 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
19:29 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 244 seconds]
19:32 -!- Rootsudo [~textual@112.205.33.21] has joined #bitcoin-core-dev
19:34 -!- nanotube [~nanotube@unaffiliated/nanotube] has joined #bitcoin-core-dev
20:06 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 244 seconds]
20:08 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
20:10 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
20:17 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
20:19 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
20:20 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
20:21 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
20:22 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
20:23 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
20:24 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
20:40 -!- Rootsudo [~textual@112.205.33.21] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
20:42 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]
20:45 < Jmabsd> there's a weird claim at https://en.bitcoin.it/wiki/Script#Constants that null outputs must have amount == 0 to be relayed. is it so? 
20:48 < luke-jr> Jmabsd: I don't see what you're referring to
20:53 < Jmabsd> luke-jr: wrong url sorry, here! https://bitcoin.org/en/developer-guide#standard-transactions
20:53 < Jmabsd> "Bitcoin Core 0.12.0 defaults to relaying and mining null data outputs with up to 83 bytes with any number of data pushes, provided the total byte limit is not exceeded. There must still only be a single null data output and it must still pay exactly 0 satoshis."
20:54 -!- waiting2compile [43aef314@gateway/web/freenode/ip.67.174.243.20] has joined #bitcoin-core-dev
20:54 < sipa> that's correct
20:54 < Jmabsd> luke-jr: see there, this doc says a NULL data output (scriptpubkey = "OP_RETURN  and a constant") must have amount == 0
20:54 < Jmabsd> where did the amount == 0 requirement come from, what if I like to *BURN*? 
20:54 < Jmabsd> where in the core code is this?
20:54 < sipa> there are plenty of other ways to burn
20:54 < Jmabsd> i don't want to TXFEE it
20:55 < Jmabsd> so i have a transaction with one null output. what's the easiest way to add a solid burn logic here?
20:55 < sipa> this has nothing to do with fees
20:55 < sipa> you still pay fees for null data outputs
20:55 < Jmabsd> sipa: an alternative way to burn would be to just mismatch the input txo's amount and the sum of the null data output and the change output:s amounts right
20:56 < Jmabsd> right i know
20:56 < sipa> Jmabsd: that would be creating fee
20:56 < Jmabsd> however this burn scheme is not a miner funding scheme.
20:56 < sipa> you can burn in other ways
20:56 < sipa> just send to an invalid pubkey
20:56 < Jmabsd> would you make a P2SH output that either can't be redeemed, or that contained OP_RETURN?
20:56 < Jmabsd> what's a mathemathically proven ever-invalid pubkey :)
20:56 < sipa> this discussion is more appropriate for #bitcoin or https://bitcoin.stackexchange.com
20:56 < luke-jr> sipa: that spams up the UTXO set forever though :<
20:56 < Jmabsd> arr, i'll sign up later.
20:57 < Jmabsd> what has the rationale been for enforcing amount == 0 on null data outputs? 
20:57 < Jmabsd> may it be lifted in the future?
20:57 < luke-jr> Jmabsd: make a PR and see if it gets merged?
20:57 < sipa> you can change the code and run it yourself
20:57 < sipa> and convince others to run it
20:57 < sipa> or that
20:57 < Jmabsd> luke-jr: yes good point.
20:58 < Jmabsd> where is the amount == 0 check in the code?
20:59 < Jmabsd> sipa: thank you for emphasising that i should post this kind of Q online, that indeed is way better for knowledge conservation, i'll intend to do it in a while.
20:59 < Jmabsd> do you have an example of a provably-unspendable pubkey? :-}
21:00 < sipa> Jmabsd: if you ask on stackexchange, i promise i'll personally answer it
21:01 < sipa> i can't actually find the 0-value requirement in the code
21:01 -!- waiting2compile [43aef314@gateway/web/freenode/ip.67.174.243.20] has quit [Quit: Page closed]
21:02 < Jmabsd> sipa: exactly, i'm rading the relay code and can't find it too. so i was thinking maybe that bitcoin.org article is bss*ahem*incorrect*ahem*obsolete.
21:03 < sipa> i would expect it to be here: https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp
21:03 < sipa> but it isn't
21:03 < Jmabsd> "grep -r "amount == 0" *" gives nothing.
21:04 < sipa> the amount of a CTxOut object is called nValue, so you'd at least need to look for that
21:04 < Jmabsd> nothing.
21:05 < Jmabsd> i would think that Bitcoin accomodated burn already, that's why i was so surprised to see that comment in that bitcoin.org article.
21:05 < Jmabsd> very well. thanks for confirming. i'll presume the article was all incorrect.
21:05 < Jmabsd> in this particular question.
21:08 < sipa> i believe that's the case
21:33 -!- harrymm [~harrymm@69.161.195.103] has joined #bitcoin-core-dev
21:35 -!- Jmabsd [~jmabsd@pcd247152.netvigator.com] has quit [Quit: Leaving]
21:42 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
21:50 -!- Jmabsd [~jmabsd@pcd247152.netvigator.com] has joined #bitcoin-core-dev
23:08 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
23:09 < fanquake> wumpus How'd you go with lxc 3 and getting your new gitian build setup sorted? I've been meaning to switch for the 0.17 builds.
23:28 -!- [\\\] [~triplesla@unaffiliated/imsaguy] has quit [Read error: Connection reset by peer]
23:28 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
23:48 < jonasschnelli> fanquake: I compiled LXC 2.1 (or similar) on debian stretch and it worked flawless
23:49 < jonasschnelli> haven't tried 3 (since the 2.something version should also work)
--- Log closed Wed Aug 15 00:00:41 2018