--- Log opened Thu Jul 25 00:00:20 2019 00:01 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 00:03 -!- liberiga [~liberiga@gateway/tor-sasl/liberiga] has joined #bitcoin-core-dev 00:05 -!- d_t [~dt@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 00:08 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 244 seconds] 00:26 -!- calkob [5202e122@cpc78879-bele10-2-0-cust33.2-1.cable.virginm.net] has joined #bitcoin-core-dev 00:27 -!- Deadhand [~deadhand@kntaon1614w-grc-03-70-51-84-38.dsl.bell.ca] has quit [Ping timeout: 264 seconds] 00:28 -!- d_t [~dt@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 00:29 -!- calkob [5202e122@cpc78879-bele10-2-0-cust33.2-1.cable.virginm.net] has left #bitcoin-core-dev [] 00:33 -!- Deadhand [~deadhand@kntaon1614w-grc-09-74-15-95-144.dsl.bell.ca] has joined #bitcoin-core-dev 00:42 -!- kljasdfvv [~flack@p200300D46F0E7800BCDE5B0A4662DA1D.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 00:52 -!- xuing [225c1596@150.21.92.34.bc.googleusercontent.com] has quit [Ping timeout: 260 seconds] 00:55 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 01:10 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has joined #bitcoin-core-dev 01:15 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection] 01:15 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 01:18 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection] 01:19 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 01:19 -!- dendisuhubdy [~dendisuhu@202.149.83.65] has joined #bitcoin-core-dev 01:20 -!- dgfhdfg [~hgfdfgh@77.243.25.143] has joined #bitcoin-core-dev 01:21 -!- kcalvinalvin [~calvin@118.131.103.244] has quit [Remote host closed the connection] 01:22 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection] 01:22 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 01:27 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection] 01:27 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 01:30 -!- Victor_sueca is now known as Victorsueca 01:34 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev 01:36 -!- dendisuhubdy [~dendisuhu@202.149.83.65] has quit [Ping timeout: 268 seconds] 01:49 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection] 01:50 -!- laptop500 [~laptop@host81-147-158-108.range81-147.btcentralplus.com] has joined #bitcoin-core-dev 01:50 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 01:56 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 258 seconds] 01:57 -!- tnaka_ [~quassel@240d:1a:759:6000:a7b1:451a:8874:e1ac] has joined #bitcoin-core-dev 02:00 -!- inquis [~inquis@178.162.204.238] has quit [] 02:02 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 272 seconds] 02:06 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-core-dev 02:09 -!- akionak [~quassel@240d:1a:759:6000:a7b1:451a:8874:e1ac] has joined #bitcoin-core-dev 02:14 -!- ihower [~ihower@184.75.223.219] has joined #bitcoin-core-dev 02:28 -!- kcalvinalvin [~calvin@118.131.103.244] has joined #bitcoin-core-dev 02:34 -!- spinza [~spin@102.132.245.16] has quit [Ping timeout: 244 seconds] 02:39 -!- Kevin30 [52c2738a@82.194.115.138] has joined #bitcoin-core-dev 02:39 -!- ihower [~ihower@184.75.223.219] has quit [Remote host closed the connection] 02:41 -!- lugosi1 [~lugosi@185.103.96.147] has joined #bitcoin-core-dev 02:41 -!- kcalvina_ [~calvin@175.223.38.220] has joined #bitcoin-core-dev 02:44 -!- kcalvinalvin [~calvin@118.131.103.244] has quit [Ping timeout: 268 seconds] 02:44 -!- ryanofsky [~russ@jumpy.yanofsky.org] has joined #bitcoin-core-dev 02:53 -!- spinza [~spin@102.132.245.16] has joined #bitcoin-core-dev 03:08 -!- kcalvina_ [~calvin@175.223.38.220] has quit [Remote host closed the connection] 03:27 -!- ptiyoyip [~hgfdfgh@77.243.25.143] has joined #bitcoin-core-dev 03:27 -!- Kevin30 [52c2738a@82.194.115.138] has quit [Ping timeout: 260 seconds] 03:28 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 258 seconds] 03:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 03:31 -!- dgfhdfg [~hgfdfgh@77.243.25.143] has quit [Ping timeout: 246 seconds] 03:38 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-core-dev 03:47 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Quit: "Fascism, Nazism, Communism and Socialism are only superficial variations of the same monstrous theme—collectivism." -- Ayn Rand] 03:52 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection] 03:53 -!- rh0nj [~rh0nj@88.99.167.175] has joined #bitcoin-core-dev 03:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 04:35 -!- schnerchi [~schnerchi@p5084A472.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds] 04:37 -!- schnerchi [~schnerchi@p57B83118.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 04:40 < jonasschnelli> MarcoFalke: feature_block.py failed now for the second time in 24h in master (in my CI): https://bitcoinbuilds.org/index.php?ansilog=2ff386f7-798c-4f9a-8233-dc62978cb175.log#l7076 04:40 < jonasschnelli> any ideas? 04:47 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 04:49 -!- zivl [~zivl@unaffiliated/zivl] has joined #bitcoin-core-dev 04:54 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has quit [Remote host closed the connection] 04:59 -!- ossifrage_ [~ossifrage@unaffiliated/ossifrage] has joined #bitcoin-core-dev 04:59 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has quit [Read error: Connection reset by peer] 05:00 -!- lugosi1 [~lugosi@185.103.96.147] has quit [] 05:01 -!- BGL [eighty@75-149-171-58-Washington.hfc.comcastbusiness.net] has quit [Ping timeout: 248 seconds] 05:04 -!- ZeroZiat [~ZeroZiat@139.28.218.198] has joined #bitcoin-core-dev 05:20 -!- liberiga [~liberiga@gateway/tor-sasl/liberiga] has quit [Ping timeout: 260 seconds] 05:24 -!- ryufghj [~hgfdfgh@77.243.19.159] has joined #bitcoin-core-dev 05:24 -!- ptiyoyip [~hgfdfgh@77.243.25.143] has quit [Read error: Connection reset by peer] 05:39 -!- kcalvinalvin [~calvin@14.39.165.3] has joined #bitcoin-core-dev 05:44 -!- shesek [~shesek@141.226.218.3] has joined #bitcoin-core-dev 05:44 -!- shesek [~shesek@141.226.218.3] has quit [Changing host] 05:44 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev 05:44 -!- kcalvinalvin [~calvin@14.39.165.3] has quit [Ping timeout: 272 seconds] 05:46 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 268 seconds] 05:48 -!- ryufghj [~hgfdfgh@77.243.19.159] has quit [Ping timeout: 268 seconds] 05:49 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 05:53 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has quit [Remote host closed the connection] 05:53 -!- promag [~promag@bl16-114-47.dsl.telepac.pt] has joined #bitcoin-core-dev 06:11 -!- shigeya [~shigeya@2001:19f0:7001:3486:5400:1ff:fe90:4da6] has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in] 06:12 -!- shigeya [~shigeya@202.182.116.58] has joined #bitcoin-core-dev 06:13 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 06:19 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev 06:23 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev 06:34 -!- BGL [ninety@75-149-171-58-Washington.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 06:50 -!- d_t [~dt@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 06:55 -!- d_t [~dt@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 258 seconds] 06:56 -!- davterra [~none@195.242.213.120] has joined #bitcoin-core-dev 07:01 -!- laptop500 [~laptop@host81-147-158-108.range81-147.btcentralplus.com] has quit [Quit: Leaving] 07:06 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 07:18 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-szbygdoiahsufyby] has joined #bitcoin-core-dev 07:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 07:19 < bitcoin-git> [bitcoin] Chunbao opened pull request #16457: test (0.18...master) https://github.com/bitcoin/bitcoin/pull/16457 07:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 07:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 07:20 < bitcoin-git> [bitcoin] fanquake closed pull request #16457: test (0.18...master) https://github.com/bitcoin/bitcoin/pull/16457 07:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 07:20 -!- davterra [~none@195.242.213.120] has quit [Ping timeout: 248 seconds] 07:21 -!- davterra [~none@195.242.213.120] has joined #bitcoin-core-dev 07:24 -!- captjakk [~captjakk@75-166-175-210.hlrn.qwest.net] has quit [Remote host closed the connection] 07:32 -!- goatpig [537241de@aaubervilliers-652-1-90-222.w83-114.abo.wanadoo.fr] has joined #bitcoin-core-dev 07:38 -!- as1nc [~as1nc@2a01:e35:2429:dc20:ecda:6113:da8c:cf31] has quit [Remote host closed the connection] 07:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 07:47 < bitcoin-git> [bitcoin] Chunbao opened pull request #16458: Fix msvc compiler error C4146 (unary minus operator applied to unsign… (0.17...fix-C4146-in-util-test) https://github.com/bitcoin/bitcoin/pull/16458 07:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 07:53 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev 07:57 -!- rajarshi [~quassel@103.24.86.32] has joined #bitcoin-core-dev 07:58 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev 08:00 -!- ZeroZiat [~ZeroZiat@139.28.218.198] has quit [] 08:04 -!- NikolaiToryzin [~NikolaiTo@192.145.126.244] has joined #bitcoin-core-dev 08:07 -!- davterra [~none@195.242.213.120] has quit [Ping timeout: 268 seconds] 08:14 -!- davterra [~none@c-73-221-225-225.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 08:16 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Remote host closed the connection] 08:18 -!- davterra [~none@c-73-221-225-225.hsd1.wa.comcast.net] has quit [Ping timeout: 245 seconds] 08:22 -!- lightlike [~lightlike@2001:16b8:579a:5900:582e:afa0:2b7f:83eb] has joined #bitcoin-core-dev 08:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 08:31 < bitcoin-git> [bitcoin] sdaftuar opened pull request #16459: [qa] Fix race condition in example_test.py (master...2019-07-fix-example-test) https://github.com/bitcoin/bitcoin/pull/16459 08:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 08:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 08:31 < bitcoin-git> [bitcoin] Chunbao opened pull request #16460: 0.17my (0.17...master) https://github.com/bitcoin/bitcoin/pull/16460 08:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 08:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 08:33 < bitcoin-git> [bitcoin] fanquake closed pull request #16460: 0.17my (0.17...master) https://github.com/bitcoin/bitcoin/pull/16460 08:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 08:46 -!- kljasdfvv [~flack@p200300D46F0E7800BCDE5B0A4662DA1D.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!] 08:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 08:49 < bitcoin-git> [bitcoin] promag opened pull request #16461: doc: Fix code example in developer notes (master...2019-07-fix-devnotes) https://github.com/bitcoin/bitcoin/pull/16461 08:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 08:49 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 272 seconds] 08:52 < sdaftuar_> jonasschnelli: that is a very strange failure. it looks like the test is trying to construct a 1000000byte block to test p2sh sigop counting, but somehow in your test failure the block was 1000001 bytes, which is why it broke 08:52 < sdaftuar_> jonasschnelli: maybe there is some non-determinism in the test that we need to track down 08:53 -!- rajarshi [~quassel@103.24.86.32] has quit [Ping timeout: 244 seconds] 08:53 -!- davterra [~none@195.242.213.120] has joined #bitcoin-core-dev 08:54 -!- owowo [~ovovo@82.102.24.187] has joined #bitcoin-core-dev 08:54 -!- owowo [~ovovo@82.102.24.187] has quit [Changing host] 08:54 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 08:56 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/] 09:07 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [] 09:14 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has joined #bitcoin-core-dev 09:14 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has quit [Max SendQ exceeded] 09:14 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has joined #bitcoin-core-dev 09:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 09:15 < bitcoin-git> [bitcoin] Chunbao opened pull request #16462: jjjj (0.17...0.18) https://github.com/bitcoin/bitcoin/pull/16462 09:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 09:15 < emilengler> Hi, what was still the name of the channel where pull requests were being discussed every thursday? 09:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 09:16 < bitcoin-git> [bitcoin] laanwj closed pull request #16462: jjjj (0.17...0.18) https://github.com/bitcoin/bitcoin/pull/16462 09:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 09:17 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has quit [Client Quit] 09:18 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has joined #bitcoin-core-dev 09:18 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has quit [Client Quit] 09:19 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has joined #bitcoin-core-dev 09:25 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has joined #bitcoin-core-dev 09:25 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has quit [Changing host] 09:25 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev 09:33 -!- kcalvinalvin [~calvin@110.14.152.121] has joined #bitcoin-core-dev 09:37 -!- rajarshi [~quassel@103.24.86.32] has joined #bitcoin-core-dev 09:47 -!- ezegom [64260e02@pool-100-38-14-2.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 09:53 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 245 seconds] 09:53 -!- d_t [~dt@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 09:54 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection] 09:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 09:55 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fe001925f803...fcc4025c1255 09:55 < bitcoin-git> bitcoin/master d9ab0ff Suhas Daftuar: [qa] Fix race condition in example_test.py 09:55 < bitcoin-git> bitcoin/master fcc4025 MarcoFalke: Merge #16459: [qa] Fix race condition in example_test.py 09:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 09:56 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 09:56 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #16459: [qa] Fix race condition in example_test.py (master...2019-07-fix-example-test) https://github.com/bitcoin/bitcoin/pull/16459 09:56 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 09:57 -!- rajarshi [~quassel@103.24.86.32] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 09:57 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has quit [Quit: Leaving] 09:57 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has joined #bitcoin-core-dev 10:00 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 10:01 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-core-dev 10:02 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 10:03 -!- kcalvinalvin [~calvin@110.14.152.121] has quit [Remote host closed the connection] 10:05 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 272 seconds] 10:05 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has quit [Quit: Leaving] 10:06 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has joined #bitcoin-core-dev 10:06 < moneyball> emilengler: there is a weekly PR review club on wednesdays. IRC channel and other info found here https://bitcoin-core-review-club.github.io/ 10:06 < emilengler> moneyball, Thank you 10:11 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 248 seconds] 10:17 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 10:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 10:45 < bitcoin-git> [bitcoin] achow101 opened pull request #16463: [BIP 174] Implement serialization support for GLOBAL_XPUB field. (master...bip174-xpub) https://github.com/bitcoin/bitcoin/pull/16463 10:46 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 11:00 -!- NikolaiToryzin [~NikolaiTo@192.145.126.244] has quit [] 11:01 < jnewbery_> Does anyone know the probabilities of 70 or 69 byte signatures? Is it always 1/2n of the number of bytes under 73? 11:04 -!- fredcooke1 [~fredcooke@192.145.126.244] has joined #bitcoin-core-dev 11:04 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev 11:08 -!- instagibbs [~instagibb@pool-100-15-121-126.washdc.fios.verizon.net] has quit [Read error: Connection reset by peer] 11:10 < harding> jnewbery_: I think 73 -> 72 is a special case (because an extra byte is added if the value is over 0x80). For anything below 72, there would have to be a 0x00 byte in order for it to be implicit, so the odds are 1/256 per each byte fewer. So 70 bytes or fewer would be (1/2 * 1/256 * 1/256). I'm not confident about this, though. 11:11 -!- Raystonn_ [~Raystonn@c-98-210-96-225.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 11:12 -!- instagibbs [~instagibb@pool-100-15-121-126.washdc.fios.verizon.net] has joined #bitcoin-core-dev 11:14 -!- Raystonn [~Raystonn@c-98-210-96-225.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds] 11:15 -!- Raystonn_ is now known as Raystonn 11:15 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 11:17 < jonasschnelli> sdaftuar_: re block test: looks like. It's happening sometimes... 11:17 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 11:17 < sipa> jnewbery_: with low-r grinding? 11:17 -!- d_t [~dt@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 11:17 < sdaftuar_> jonasschnelli: i think i found the problem 11:18 < jonasschnelli> sdaftuar_: nice! What is it? 11:18 < sdaftuar_> there's non-determinism in the length of the signature in the first transaction of the block (b39) used in the first p2sh sigops test 11:18 < sdaftuar_> combined with a bug in the way the block size is measured in the loop, we can accidentally make too big a block if the first transaction has a too-small signature 11:19 < sdaftuar_> i've got a simple fix, i think, which i'm verifying 11:19 < jonasschnelli> Cool! Thanks for fixing it sdaftuar_. 11:19 < jonasschnelli> So it should have also happend in travis 11:19 < jonasschnelli> (it probably did) 11:19 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 258 seconds] 11:20 < sdaftuar_> yeah that's what motivated john's question, we were trying to figure out what the likelihood of this happening is 11:20 < jonasschnelli> i see 11:20 < sdaftuar_> i suspect the likelihood went up after we switched to using a new secp256k1 implementation for our python test suite? 11:20 < sdaftuar_> sipa: ^^ does that make sense to you? 11:21 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds] 11:23 < sipa> sdaftuar_: the python EC code doesn't do low-r grinding, so it'd be around a 50% chance for 71 byte sigs and 50% for 72 byte sigs (including the sighash byte) 11:23 < sipa> and a tiny probability for 70 bytes and below 11:33 < emilengler> In which file/function the inital blockchain download is being started? 11:35 < sipa> emilengler: PeerValidationLogic::SendMessages(CNode* pto) in src/net_processing.cpp 11:35 < sipa> specifically under the comment "// Start block sync" 11:38 < sipa> it's a function that gets called periodically for each peer 11:39 -!- davterra [~none@195.242.213.120] has quit [Ping timeout: 272 seconds] 11:39 < sipa> that piece of code specifically starts the fetching of headers 11:39 < sipa> once we have enough headers, and know of peers who have blocks corresponding to those headers, we'll automatically start requesting blocks from them 11:40 -!- davterra [~none@195.242.213.120] has joined #bitcoin-core-dev 11:40 -!- rex4539 [~rex4539@2a02:587:3514:c700:d9f4:56dd:269a:f673] has joined #bitcoin-core-dev 11:41 -!- reallll is now known as belcher 11:43 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 248 seconds] 11:44 < emilengler> sipa, Thank you 11:45 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has quit [Quit: Leaving] 11:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 11:45 < bitcoin-git> [bitcoin] sdaftuar opened pull request #16464: [qa] Ensure we don't generate a too-big block in p2sh sigops test (master...2019-07-fix-feature-block) https://github.com/bitcoin/bitcoin/pull/16464 11:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 11:46 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has joined #bitcoin-core-dev 11:47 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has quit [Client Quit] 11:47 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has joined #bitcoin-core-dev 11:48 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 11:50 -!- ryufghj [~hgfdfgh@77.243.19.159] has joined #bitcoin-core-dev 11:59 -!- jonatack [d598a259@213.152.162.89] has quit [Ping timeout: 260 seconds] 11:59 -!- jonatack [6dca67aa@109.202.103.170] has joined #bitcoin-core-dev 12:00 < jnewbery_> meeting time? 12:00 < wumpus> #startmeeting 12:00 < lightningbot> Meeting started Thu Jul 25 19:00:20 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:00 < sipa> ohai 12:00 < kanzure> hi 12:00 < jonasschnelli> hi 12:00 < jnewbery_> hi! 12:00 < achow101> hi 12:00 < amiti> hi 12:00 < andytoshi> hi 12:00 < meshcollider> hi 12:00 < BlueMatt> a wild jnewbery_ imposter apears 12:00 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral 12:01 -!- sdaftuar_ is now known as sdaftuar 12:01 < moneyball> Hi 12:01 < ariard> hi 12:01 < wumpus> one proposed topic today: Transaction Rebroadcasting https://gist.github.com/amitiuttarwar/b592ee410e1f02ac0d44fcbed4621dba 12:01 < jonasschnelli> I have just a little topic/announcement suggestion: bitcoinbuilds.org (can be done at the end when time) 12:01 < promag> hi 12:01 < jamesob> hi 12:02 < jonatack> hi 12:02 < wumpus> hi everyone! 12:02 < wumpus> #topic High priority for review 12:02 < wumpus> https://github.com/bitcoin/bitcoin/projects/8 6 blockers, 6 things waiting for concept ACK 12:02 < BlueMatt> #16421 12:02 < gribble> https://github.com/bitcoin/bitcoin/issues/16421 | Conservatively accept RBF bumps bumping one tx at the package limits by TheBlueMatt · Pull Request #16421 · bitcoin/bitcoin · GitHub 12:03 < sdaftuar> i'd like to review beg #15759, which is already a high priority for review item 12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/15759 | [p2p] Add 2 outbound blocks-only connections by sdaftuar · Pull Request #15759 · bitcoin/bitcoin · GitHub 12:03 < wumpus> BlueMatt: that's one you want to add I suppose? 12:03 < BlueMatt> yesplz 12:03 < wumpus> ok added 12:03 < jamesob> 15759 is a good PR, A+++++ 10/10 would review again 12:04 < sipa> do two jamesob ACKs count as two? i see a win-win situation here 12:06 < MarcoFalke> Can I add #16363 12:06 < jamesob> I'll read it in decreasing line number order this time 12:06 < wumpus> he did ack it twice so... 12:06 < gribble> https://github.com/bitcoin/bitcoin/issues/16363 | test: Add test for BIP30 duplicate tx by MarcoFalke · Pull Request #16363 · bitcoin/bitcoin · GitHub 12:06 < wumpus> MarcoFalke:sure, added 12:07 < wumpus> anything to add/remove from chasing concept ack? 12:08 < ariard> still need reviews for #15713, which is current step to go forward on removing cs_main locks in wallet 12:08 < gribble> https://github.com/bitcoin/bitcoin/issues/15713 | refactor: Replace chain relayTransactions/submitMemoryPool by higher method by ariard · Pull Request #15713 · bitcoin/bitcoin · GitHub 12:09 < ariard> (current tip ACKed by jnewbery and jonatack) 12:09 < MarcoFalke> ariard: Looks like you pushed a new commit today 12:09 < achow101> #16341 for Chasing Concept ACK? 12:09 < gribble> https://github.com/bitcoin/bitcoin/issues/16341 | WIP: Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101 · Pull Request #16341 · bitcoin/bitcoin · GitHub 12:09 < wumpus> good to know, I see it's already on there 12:09 < MarcoFalke> Oh, I see they re-ACKed 12:09 < ariard> I took jnewbery cleanup commit for BroadcastTransaction 12:10 < MarcoFalke> ariard: It conflicts with #16452. So which one should go in first? 12:10 < gribble> https://github.com/bitcoin/bitcoin/issues/16452 | refactor: use RelayTransaction in BroadcastTransaction utility by ariard · Pull Request #16452 · bitcoin/bitcoin · GitHub 12:10 < jnewbery_> I think 15713 goes first 12:11 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection] 12:11 < jnewbery_> 16452 is a nice clean-up, but doesn't hold up the series of PRs 12:11 < wumpus> achow101:added 12:11 < ariard> #15713, so that's way I would be able to addreess nits in 16452 12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/15713 | refactor: Replace chain relayTransactions/submitMemoryPool by higher method by ariard · Pull Request #15713 · bitcoin/bitcoin · GitHub 12:11 < MarcoFalke> Good, I'll take a look at 15713 :eyes: 12:11 < ariard> thanks! 12:12 < wumpus> #topic Transaction broadcasting (amiti) 12:12 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer] 12:12 < promag> +1 on 15713 12:12 < amiti> write up here: https://gist.github.com/amitiuttarwar/b592ee410e1f02ac0d44fcbed4621dba 12:13 < amiti> tldr; want to improve privacy with updates to rebroadcast logic 12:13 < amiti> instead of nodes rebroadcasting only wallet txns, rebroadcast all txns it believes should have been in the last block 12:14 < amiti> looking for critical feedback, concept acks, any high level implementation thoughts 12:14 -!- rh0nj [~rh0nj@88.99.167.175] has joined #bitcoin-core-dev 12:14 < wumpus> how much is this expected to increase bandwidth usage? 12:14 < amiti> choosing the parameters carefully will be important - dramatically impacts the worst case bandwidth usage 12:15 < wumpus> and does this help with privacy? the first node broadcasting something will still be the same one 12:15 < wumpus> as I see it, at least 12:16 < amiti> not necessarily. if a node has a txn in its mempool that should have been picked up in a block already (high fee rate and is old), it will rebroadcast. independent of originating wallet. 12:16 < MarcoFalke> wumpus: Yes, the first node (i.e. the wallet) will be the same one 12:16 < MarcoFalke> But hopefully not for rebroadcasts 12:16 < jnewbery_> wumpus: I think it does. Currently, if you see a peer brodcast a tx more than once, you can be almost certain that it originated the tx, and we rebroadcast our txs that are unconfirmed for more than half an hour 12:17 < sipa> i think it primarily addresses how currently we gratuitously rebroadcast, making it obvious continuously to every peer what our own transactions are 12:17 < sipa> it certainly doesn't address all forms of leaking that information 12:17 < MarcoFalke> small steps :) 12:17 < wumpus> so either every node does this, or it reveals which nodes have a hot wallet 12:18 < sipa> wumpus: the rebroadcast logic will be in the mempool, so even without wallet enabled, it will work 12:18 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev 12:18 < wumpus> and if all nodes do it, that sounds very bad for bandwidth usage 12:19 < achow101> at first glance, this sounds like it will cause bandwidth usage greatly increase 12:19 < sdaftuar> wumpus: i think if we constrain it to old transactions at the top of themempool, it should be a small bandwidth effect? 12:19 < sipa> i suspect it's also filted by the knowninvs logic, so we wouldn't rebroadcast to the same peer twice 12:19 < wumpus> so basically all nodes would create noise for the nodes with a wallet to hide in, hmm 12:19 < MarcoFalke> sipa: The knowninvs will reset every couple of blocks, no? 12:19 < sdaftuar> wumpus: i think it's more than that, it's way to ensure that things that should be mined get relayed, eg to nodes with small mempools or recently started up 12:20 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 258 seconds] 12:20 < sdaftuar> sort of like a mempool-sync might do 12:20 < achow101> would it be picking the oldest high fee rate transactions to rebroadcast, up to some n? Or would it pick some n transactions and choose the oldest and highest fee rate of them? 12:20 < wumpus> sdaftuar: oh good point 12:20 < sipa> right, full nodes have an incentives themselves to see their mempools match what it actually mined 12:20 < sipa> even without wallets 12:20 < amiti> achow: traverse top of mempool by ancestor fee rate, filter out recent transactions, rebroadcast remaining 12:20 < jnewbery_> if we consider the top of the mempool to be "transactions we expect to get mined soon" and they're not getting mined, rebroadcasting them to make sure miners are aware seems like sensible mempool logic 12:21 < jnewbery_> if not, then the mempool might as well expire them - they're doing our node no good 12:21 < sipa> i guess there could be some sort of exponential backoff, that after a tx has been rebroadcast multiple times, it becomes rarer (this may be especially relevant when peers may have other consensus/policy rules) 12:21 < achow101> amiti: so every rebroadcast would have the same number of transactions? 12:21 < sipa> though i guess that's done automatically by our own expiration logic 12:21 < achow101> or rather same amount of data being broadcast 12:22 < wumpus> so if every node broadcasts the transactions at the top of the mempool, this will be more or less the same transactions for every node 12:22 < MarcoFalke> achow101: No. Txs that were added to the mempool or to blocks are excluded 12:22 < sipa> achow101: i guess that depends on how well the mempool matches what is being mined 12:22 < MarcoFalke> wumpus: Yes, mostly 12:22 < wumpus> if someone broadcasts a *different* transaction, or one that would rank lower according to policy, this is suspect 12:22 < sdaftuar> sipa: i think a rebroadcast cap makes sense, also a cap on the number of things rebroadcast in one go (to prevent any kind of edge-case behavior) 12:22 < sipa> gleb: here? 12:22 < sdaftuar> he's away 12:23 < sipa> i'm wondering how to integrate this with erlay 12:23 < sipa> (which shouldn't be a blocker for this discussion of course, but it's nice to have things thought out) 12:23 < wumpus> I'm not entirely sure that this generates noise with enough variance to contribute to privacy 12:23 < sipa> wumpus: hmm? 12:24 < wumpus> it'd just change the logic to 'anyone that broadcasts a transaction that is not on the top of the mempool is broadcasting their own transaction' 12:24 < sipa> is your concern "this isn't enough" or "this doesn't contribute anything" (possible) 12:24 < provoostenator> In particular, this wouldn't benefit lowball fee transactions I assume? 12:24 < MarcoFalke> wumpus: The wallet rebroacast would be removed of course 12:24 < jnewbery_> wumpus: nodes would still relay new transactions they saw 12:24 < wumpus> MarcoFalke: ohhh! 12:24 < MarcoFalke> heh 12:24 < wumpus> MarcoFalke: okay then it makes a lot more sense 12:25 < MarcoFalke> Maybe we should introduce each topic with a three line summary 12:25 < provoostenator> (I mean: I would not add more privacy to wallet transactions with a low fee, but also doesn't make it worse) 12:25 * MarcoFalke meta 12:25 < provoostenator> *it 12:26 < achow101> how would this interact with prioritizetransaction? I assume it would be a privacy leak that you prioritize some particular transaction if that transaction was part of the rebroadcast but not the top for other nodes 12:26 < MarcoFalke> provoostenator: The fee rate should have no effect on privacy after the proposal is merged, no? 12:26 < amiti> provoostenator: my proposed changes would not rebroadcast wallet txns with a low fee until that txn makes it to the top of the mempool 12:26 -!- owowo [~ovovo@s91904425.blix.com] has joined #bitcoin-core-dev 12:26 -!- owowo [~ovovo@s91904425.blix.com] has quit [Changing host] 12:26 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 12:26 < sipa> hmm, so how will low-feerate transactions get broadcast at all? 12:26 < sdaftuar> achow101: i think we'd have to use a sort on actual feerate, and not modified feerate 12:26 < MarcoFalke> sipa: When they are created 12:26 < sdaftuar> sipa: pacakge relay, or wait til they get to the top of the mempool, i think? 12:26 < MarcoFalke> (once) 12:27 < sipa> oh, nvm; the normal "just entered the mempool" relay will do that, not rebroadcast logic 12:27 < amiti> sdaftuar: correct 12:27 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection] 12:28 < provoostenator> So IIUC (I should read the whole thing): we still broadcast the first time as per usual, but we only *rebroadcast* top of mempool? 12:28 < harding> So if I create a low fee transaction that doesn't get relayed initially for some reason, my wallet would never broadcast it unless I just happened to have my node open at the point where fees have dropped? 12:28 < amiti> provoostenator: correct 12:28 < wumpus> harding: it would broadcast it the first time 12:29 < harding> wumpus: right, but what if it wasn't relayed the first time? 12:29 < achow101> harding: I think it's the same situation now. you'd still have to wait for the fees to drop and have your wallet be open so that other nodes will accept it 12:29 < MarcoFalke> harding: Right, but we can improve inital relay as well 12:29 < MarcoFalke> (workin on it)TM 12:31 < wumpus> concept ACK on the idea from me 12:31 < harding> achow101: to overcome the dynamic minimum relay fee, that's true. I'm thinking of the case where I generate a transaction with a (say) 288-block estimatesmartfee target. That's only rarely going to be near the top of the mempool. Right now, my wallet will rebroadcast that every hour or so (random delay); with this change, it'd only rebroadcast it if my wallet was open at the right time. 12:31 < sipa> harding: but on the other hand, your peers will do the rebroadcast for you 12:31 < sipa> those who heard the initial broadcast at least 12:32 < sipa> you can argue that that's relying on their altruistic behaviour, but right now we're already kinda doing that hoping for them to relay it at all 12:32 < sdaftuar> it seems reasonable for the wallet to try to ensure that the transaction was relayed to at least one peer, perhaps 12:32 < harding> An actual usecase of my is that I sendrawtransaction spends from my cold wallet with my network disabled so that I can do a final inspection of the transaction in my local mempool (mainly to check that I didn't forget an output and spend all to fees). That means I always use wallet rebroadcasting in those cases. 12:32 < jnewbery_> harding: s/it'd only rebroadcast it if my wallet was open at the right time/it'd only rebroadcast if your node was online at the right time 12:32 < jnewbery_> but I think your point stil lstands 12:33 < achow101> harding: use testmempoolaccept instead? 12:33 < sipa> harding: that seems like a reasonable use case (though personally i'm using analyzepsbt for that now, before even broadcasting it) 12:34 < amiti> harding: you are right. in the circumstance where a low fee rate txn was not relayed the first time and none of your peers have it, these changes would make it take longer until your txn got rebroadcast, and potentially your node has to be online the right time. 12:34 < sipa> i do think we need a way for this to work when a tx is submitted to your mempool while you're offline 12:34 < provoostenator> One consideration I've seen discussed in a PR recently is that the node doesn't tell the wallet what happened. 12:34 < harding> sipa: I also do that now too. When dealing with thousands of my money, it's belts, suspenders, extra belts, and extra suspenders. :-) 12:34 < provoostenator> And one thing to also consider is that with dynamic loading, a user might unload their wallet after initial broadcast. 12:34 < sipa> wow thousands of moneys 12:35 < sdaftuar> a lot of ico's these days 12:35 < sipa> the mempool could have a per-tx flag "ever broadcast" 12:35 < MarcoFalke> Could the mempool keep track if the txs was pushed to at least one peer? 12:35 < sipa> jinx 12:35 < wumpus> IIRC the wallet used to keep track of number of broadcasts of a transaction, this was removed at some point 12:35 < sipa> in that case, even the initial broadcast of a tx could become pure mempool responsibility 12:36 < sipa> wumpus: correct 12:36 < achow101> sipa: isn't it already? 12:36 < sipa> though it was just used for showing in the UI whether a tx had propagated 12:36 < MarcoFalke> wumpus: That wouldn't work if the wallet is on a different node than the mempool 12:36 < sdaftuar> sipa: if you're the last of your peers to learn of a transaction, was it "ever broadcast"? 12:36 < wumpus> which wasa arguably somewhat useful :) but yes 12:36 < sipa> achow101: well i mean *the mempool* rather than ATMP 12:37 < sipa> sdaftuar: anything you've learned from the network would never get that flag, only rpc/wallet submissions 12:37 -!- ajonas [~ajonas@165.227.48.51] has joined #bitcoin-core-dev 12:37 < MarcoFalke> sdaftuar: If you get the tx from the network it was broadcast 12:37 < wumpus> MarcoFalke: is that even possible? 12:37 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev 12:37 < wumpus> the wallet will always submit the transaction to the local mempool first right? 12:37 < sipa> right 12:37 < MarcoFalke> Sure. Use signrawtransaction on the one with the wallet and sendrawtransaction on the one with the mempool 12:38 < wumpus> oh sure, but in that case you're handling everything manually anyway 12:38 < provoostenator> Well, that makes the sendrawtransaction node's mempool is responsible? 12:38 < wumpus> yes 12:38 < MarcoFalke> You'd still want your node to broadcast at least once (even if at the time of ATMP you were offline) 12:39 < sipa> right now if you use sendrawtransaction, it gets submitted to the mempool/network directly, from which your own wallet may learn it, who will then take over rebroadcasting 12:39 < sipa> because sendrawtransaction is a node RPC not a wallet RPC afaik 12:39 < wumpus> correct 12:39 < wumpus> there's no addrawwallettransaction or something like that 12:40 < wumpus> sendrawtransaction will unconditionally broadcast the transaction as well, so it's sometimes used for manual rebroadcast 12:40 < MarcoFalke> sendrawtransaction should mention that this is privacy leaking, maybe? 12:41 < wumpus> yes, the help could mention that 12:42 < sipa> amiti: what do you think about the "ever broadcast" flag idea? 12:42 < provoostenator> From the gist: "The wallet will attempt to resubmit unconfirmed transactions to the node on a scheduled timer" - does the node remember previously dropped txs? 12:42 < sipa> provoostenator: the wallet always remembers all its own transactions 12:42 < amiti> sipa: sounds great! noted. 12:42 < sipa> the mempool is completely neutral and doesn't treat our own txn different from anyone else's 12:43 < provoostenator> sipa: yes, but wouldn't this behavior just cause the node to do a fresh broadcast of all wallet transactions? 12:43 < amiti> well. if we add the flag, it wont be completely neutral anymore 12:43 < MarcoFalke> sipa: I like it. It sounds even orthogonal to amiti's proposed change 12:43 < sipa> MarcoFalke: indeed 12:43 < sipa> amiti: good point 12:43 < sipa> but at some point we have to treat our own txn different our they wouldn't be broadcast at all :) 12:43 < jnewbery_> sipa: we're wondering if the wallet rebroadcasting txs that it learns from the mempool is also true for txs received over p2p 12:44 < amiti> but, given the circumstances harding pointed out, it seems worth it 12:44 < jnewbery_> ie that your wallet can be dust-attacked and it'll start rebroadcasting the dust txs 12:44 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 12:44 < MarcoFalke> jnewbery_: It should 12:44 < MarcoFalke> s/should/probably does/ 12:44 < sipa> jnewbery_: i think a tx learned through the network (wallet or not) should not be treated differently 12:44 < sipa> only things learned from the wallet or rpc, and never broadcast before 12:45 < MarcoFalke> jnewbery_: I think this has been done in the past 12:45 < amiti> provoostenator: if I understand your question correctly, the node will not remember the txns it previously dropped. it would rely on the wallet to resubmit if needed 12:45 < MarcoFalke> Oh, no. It has been done to get the coinselection include the dust 12:45 < jnewbery_> I guess we want this flag to be saved to mempool.dat so we don't rebroadcast our own txs every time we restart 12:46 < sipa> jnewbery_: yeah 12:46 < sipa> that's scary because mempool saving is only done periodically (or even only at shutdown) 12:46 < sipa> so an unclean shutdown could result in unnecessary rebroadcast 12:46 < MarcoFalke> -nopersistmempool :eyses: 12:47 < provoostenator> Unnecessary rebroadcast as a result of a crash doesn't seem like a huge issue. 12:47 < MarcoFalke> rebroadcast on every start because you don't persist the mempool does sound like an issue 12:47 < harding> You could put the flag on the transaction in the wallet instead? was_relayed_to_at_least_one_peer 12:48 < sipa> harding: a bit of a layer violation but yeah 12:48 < MarcoFalke> harding: That wouldn't work where the wallet is separate from the mempool (two nodes) 12:48 < sipa> it means that the "submit to mempool" function needs to return a bool broadcast or not 12:48 < sipa> oh right, it doesn't work for RPC 12:48 < provoostenator> Maybe the wallet could ask the node "Do you have this in your mempool?" 12:49 < provoostenator> And maybe also "Put in your mempool, but skip initial broadcast" 12:49 < sipa> right but it needs to work even when there is no wallet involved at all 12:49 < provoostenator> That moves responsibility to the wallet, which maybe makes sense because it cares about its own privacy. 12:50 < provoostenator> sipa: true, that's the downside 12:50 < MarcoFalke> We should remove broadcast logic from the wallet and the rpc and tell users to copy-paste the tx into a block explorer over tor 12:51 < wumpus> at least if their node is not connected to tor already 12:51 < sipa> ha 12:51 < provoostenator> Node->WalletTransactionBroadcastDelegate 12:51 < wumpus> but yes, this was kind of my point with -walletbroadcast=0 12:51 < sipa> do we have other topics? :p 12:52 < wumpus> #topic bitcoinbuilds.org (jonasschnelli) 12:52 < hugohn> question: if there are empty blocks (could be consecutive), will every node rebroadcast top of the mempool? 12:52 < jonasschnelli> It's a custom built open source CI that is/can-be-further tailored to our needs. Super slim. 12:52 < MarcoFalke> hugohn: I think so 12:52 < jonasschnelli> bitcoinbuilds.org 12:53 < jonasschnelli> Feature wise its on the same level then travis. Builds fast or even faster then travis on a 50EUR/month machine. 12:53 < jonasschnelli> Additionally, one can download the build results and it logs times per task (install/compile-depends/configure/compile/run-tests/etc.) 12:53 < wumpus> jonasschnelli: nice ! 12:53 < jonasschnelli> Sources are here: https://github.com/jonasschnelli/bitcoin-core-ci 12:53 < jonasschnelli> Intention is not to replace travis. Just to have a backup option for times when we need it. 12:53 < wumpus> so we can trash travis now? :) 12:53 < wumpus> oh 12:53 < jonasschnelli> Maybe at some point.. but not now 12:53 < jonasschnelli> I added a github hook. 12:53 < wumpus> github integration is probably the most difficult part 12:53 < jonasschnelli> So it builds are PRs (master after merges soon) 12:54 < jonasschnelli> Integration with github is easy 12:54 < wumpus> (e.g. reporting the status on github) 12:54 < wumpus> oh! it used to be pretty much impossible for custom tools 12:54 < jonasschnelli> In general... I was surprised how easy it is to "clone travis" 12:54 < MarcoFalke> reply from travis: "Thank you for getting in touch and for raising this issue as well. I apologise for the frustration caused over the last month regarding the problems, and I can assure you we are committed to improving your overall experience while using the platform." 12:54 < jonasschnelli> (though tailored) 12:55 < jonasschnelli> However,.. feel free to check your PR build on bitcoinbuilds.org and contribute to futher extend it to our needs. 12:55 < meshcollider> Currently it just compiles I guess, are you planning on adding test execution? 12:55 < jonasschnelli> cfields more detailed dependency cache would certainly be a build-performance booster (for some types of builds) 12:55 < wumpus> MarcoFalke: hopefully that means anything 12:55 < jonasschnelli> meshcollider; it runs the test on linux64/32 12:56 < MarcoFalke> wumpus: I'd guess its a template response 12:56 < meshcollider> Oh nice :) 12:56 < jonasschnelli> I have also plans to allow running tests on other machines over the internet (like run the ARM tests on a odroid or so) 12:56 < MarcoFalke> Nice 12:56 < jonasschnelli> Contributions welcome... 12:57 < jnewbery_> jonasschnelli: does it use the same travis.yaml format for configuration? 12:57 < jonasschnelli> almost... 12:57 < jonasschnelli> https://github.com/jonasschnelli/bitcoin-core-ci/blob/master/default.yml 12:57 < jonasschnelli> It's static for now to not pollute our git 12:58 < wumpus> oh that's neat! 12:58 < sipa> ideally our travis.yml doesn't really contain any logic apart from "invoke CI step 1", "invoke CI step 2.a", and caching ... which are implemented as a shell script 12:58 < jonasschnelli> yes 12:58 < jnewbery_> sipa: for logic yes, but there's various config in there too 12:58 < MarcoFalke> Some of the variables in the script are travis specific, but it shouldn't be too hard to replace them 12:59 < sipa> right 12:59 < MarcoFalke> Happy to review a pull if someone wants to pull them out 12:59 < jonasschnelli> We could use the .travis folder in the custom CI,.. sure. 12:59 < jnewbery_> jonasschnelli: do you plan to update https://github.com/jonasschnelli/bitcoin-core-ci/blob/master/default.yml if the travis.yml file changes 13:00 * sipa -> lunch 13:00 < jonasschnelli> jnewbery_: I could.. 13:00 * MarcoFalke -> tea 13:00 < jonasschnelli> or we add one in our github 13:00 < jonasschnelli> or we load .travis 13:00 < jonasschnelli> *dong* 13:00 < wumpus> #endmeeting 13:00 < lightningbot> Meeting ended Thu Jul 25 20:00:40 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:00 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-07-25-19.00.html 13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-07-25-19.00.txt 13:00 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-07-25-19.00.log.html 13:00 < jnewbery_> jonasschnelli: thanks for doing this! Definitely useful to have an alternative 13:01 < instagibbs> oh whoops, meeting, I thought you guys were really just havin a productive normal discussion 13:01 < jonasschnelli> heh 13:01 < amiti> thank you everyone for all the feedback :) 13:02 < jonasschnelli> jnewbery_: also, eventually travis builds other stuff then bitcoinbuilds.org does (if both are running fine)... 13:02 < jonasschnelli> so the .travis file doesn't need to be directly synced 13:03 < hugohn> amiti: should there be a check for minimum of empty blocks seen before triggering rebroadcast ? seems bad to have every node rebroadcast top of the mempool as soon as there's one empty block. (Granted, empty blocks would not be a problem post-subsidy, but might still be a problem now.) 13:06 < instagibbs> single empty blocks are still quite common, not due to lack of mempool contents 13:06 < instagibbs> (I haven't read the latest proposal, sorry) 13:06 < sipa> if there is per-tx mempool tracking anyway, there could be a "point sysyem" where every time a tx was expected to have been in a block but wasn't, it gets a point; if the number of points exceeds some threshold, rebroadcast and increment a counter that next time more points are needed 13:15 < lightlike> is it also common that non-empty blocks are mined that include many low-fee txes even if higher ones are available? or is it mostly either empty or fee-efficient? 13:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 13:17 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fcc4025c1255...a54a12046e98 13:17 < bitcoin-git> bitcoin/master 248e22b fanquake: depends: disable unused Qt features 13:17 < bitcoin-git> bitcoin/master a54a120 Wladimir J. van der Laan: Merge #16386: depends: disable unused Qt features 13:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 13:22 -!- ezegom [64260e02@pool-100-38-14-2.nycmny.fios.verizon.net] has quit [Remote host closed the connection] 13:27 < amiti> hugohn: the current thinking is not to trigger rebroadcast based on block timing, but rather an independent timer. the idea is if we choose the param of "is txn recent" to be long enough, we should be able to avoid excessive broadcast of txns even in edge cases. 13:27 < amiti> sipa: thats an interesting idea. I'll add it to considerations. there are a lot of options for strategies to mitigate excessive rebroadcasting (and bandwidth usage) with the main tradeoffs being memory / code complexity. another way of storing per-tx mempool data would be a stamp of the `last_rebroadcast_at` and enforce a minimum there. 13:27 < hugohn> lightlike: high-fee txns could get skipped simply due to timing/relaying issues, so I can see that happening. In fact, it sounds like amiti's proposal is geared towards solving that kind of scenario. Normally you would not expect miners to skip high-fee txns as it does not make economic sense to do so. 13:29 < wumpus> MarcoFalke: looks like it's not picking up the "needs gitian build" on #16441 13:29 < gribble> https://github.com/bitcoin/bitcoin/issues/16441 | build: remove qt libjpeg check from bitcoin_qt.m4 by fanquake · Pull Request #16441 · bitcoin/bitcoin · GitHub 13:34 < MarcoFalke> wumpus: Thx. Looking 13:35 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has quit [Ping timeout: 248 seconds] 13:35 < MarcoFalke> FileNotFoundError: [Errno 2] No such file or directory: 'make': 'make' 13:36 < MarcoFalke> I transferred to a new vm. I guess the host needs make to make the depends 13:36 < jonasschnelli> lol 13:37 < wumpus> hehe 13:38 < MarcoFalke> Fixed. Let's check back in two days. (it is half a cpu) 13:39 < hugohn> > not to trigger rebroadcast based on block timing, but rather an independent timer 13:39 < hugohn> amiti: I see, looks like rebroadcast is triggered once / hour based on the current proposal. Would there be an issue though if there is a sudden drop in hash rate? I suppose an hour should give plenty of room to account for hash rate drop. 13:40 -!- vincenzopalazzo [50689d4d@host77-157-dynamic.104-80-r.retail.telecomitalia.it] has joined #bitcoin-core-dev 13:42 -!- ajonas [~ajonas@165.227.48.51] has quit [Quit: leaving] 13:42 < wumpus> MarcoFalke: thanks! 13:48 -!- vincenzopalazzo [50689d4d@host77-157-dynamic.104-80-r.retail.telecomitalia.it] has quit [Remote host closed the connection] 13:55 < elichai2> jonasschnelli: btw, this might interest you: https://github.com/drone/drone it's also open source and it's dockerized, I used it in the past when I wanted to host my own CI, so you don't have to pay anything except your server(then you can take a powerful one for fast compilation time) 13:56 < amiti> hugohn: I think more relevant than the frequency of the rebroadcast job is the definition of "recent" transaction. the current proposal has that defined as 30 minutes, which may be too low. 13:56 < amiti> right now with the params chosen (enforce max rebroadcast of 1000 txns/hour) my back-of-the-envelope math has the worst case as 36 kb max of inv message / hour. 13:56 < amiti> I'd be curious to hear evaluations of how impactful that seems. 13:56 < amiti> The worst case bandwidth usage would be very tune-able by choosing conservative params. 14:00 -!- fredcooke1 [~fredcooke@192.145.126.244] has quit [] 14:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 14:05 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #16465: test: Test p2sh-witness and bech32 in wallet_import_rescan (master...1907-testAllAddressTypesImport) https://github.com/bitcoin/bitcoin/pull/16465 14:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 14:09 -!- jonatack [6dca67aa@109.202.103.170] has quit [Remote host closed the connection] 14:19 -!- liberiga [~liberiga@gateway/tor-sasl/liberiga] has joined #bitcoin-core-dev 14:20 -!- phyll1s_work [~phyll1s_w@192.145.126.244] has joined #bitcoin-core-dev 14:29 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection] 14:42 -!- captjakk [~captjakk@75-166-175-210.hlrn.qwest.net] has joined #bitcoin-core-dev 14:47 -!- goatpig [537241de@aaubervilliers-652-1-90-222.w83-114.abo.wanadoo.fr] has quit [Remote host closed the connection] 15:30 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 272 seconds] 15:36 -!- ptiyoyip [~hgfdfgh@188.120.117.44] has joined #bitcoin-core-dev 15:39 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 245 seconds] 15:40 -!- ryufghj [~hgfdfgh@77.243.19.159] has quit [Ping timeout: 268 seconds] 16:01 -!- liberiga [~liberiga@gateway/tor-sasl/liberiga] has quit [Ping timeout: 260 seconds] 16:01 -!- itsiku [~itsiku@abelohost-34.207.207.185.dedicated-ip.abelons.com] has quit [Remote host closed the connection] 16:06 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 16:07 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev 16:10 -!- vincenzopalazzo [50689d4d@host77-157-dynamic.104-80-r.retail.telecomitalia.it] has joined #bitcoin-core-dev 16:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer] 16:20 -!- davterra [~none@195.242.213.120] has quit [Ping timeout: 272 seconds] 16:21 -!- liberiga [~liberiga@gateway/tor-sasl/liberiga] has joined #bitcoin-core-dev 16:22 -!- ryufghj [~hgfdfgh@77.243.27.242] has joined #bitcoin-core-dev 16:25 -!- ptiyoyip [~hgfdfgh@188.120.117.44] has quit [Ping timeout: 246 seconds] 16:37 -!- d_t [~dt@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 16:37 -!- vincenzopalazzo [50689d4d@host77-157-dynamic.104-80-r.retail.telecomitalia.it] has quit [Remote host closed the connection] 16:38 -!- vincenzopalzzo [50689d4d@host77-157-dynamic.104-80-r.retail.telecomitalia.it] has joined #bitcoin-core-dev 16:38 -!- vincenzopalzzo [50689d4d@host77-157-dynamic.104-80-r.retail.telecomitalia.it] has quit [Remote host closed the connection] 16:40 -!- vincenzopalazzo [50689d4d@host77-157-dynamic.104-80-r.retail.telecomitalia.it] has joined #bitcoin-core-dev 16:53 -!- vincenzopalazzo [50689d4d@host77-157-dynamic.104-80-r.retail.telecomitalia.it] has quit [Remote host closed the connection] 17:00 -!- phyll1s_work [~phyll1s_w@192.145.126.244] has quit [] 17:03 -!- davterra [c3f2d578@195.242.213.120] has joined #bitcoin-core-dev 17:03 -!- vincenzopalazzo [~Vincent@host77-157-dynamic.104-80-r.retail.telecomitalia.it] has joined #bitcoin-core-dev 17:04 -!- them_ [~them_@89.249.74.218] has joined #bitcoin-core-dev 17:05 -!- lightlike [~lightlike@2001:16b8:579a:5900:582e:afa0:2b7f:83eb] has quit [Quit: Leaving] 17:08 -!- vincenzopalazzo [~Vincent@host77-157-dynamic.104-80-r.retail.telecomitalia.it] has left #bitcoin-core-dev [] 17:10 -!- nijak_ [nijak@gateway/vpn/mullvad/nijak] has joined #bitcoin-core-dev 17:12 -!- nijak [nijak@gateway/vpn/mullvad/nijak] has quit [Ping timeout: 268 seconds] 17:25 < fanquake> MarcoFalke: Is there something wrong with the bot. It keeps tagging and commenting on closed PRs. Some of them more than once. 18:05 -!- davterra [c3f2d578@195.242.213.120] has quit [Remote host closed the connection] 18:33 -!- d_t [~dt@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 18:34 -!- davterra [~none@178.128.106.205] has joined #bitcoin-core-dev 18:36 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev 19:02 -!- ossifrage_ is now known as ossifrage 19:16 -!- ryufghj [~hgfdfgh@77.243.27.242] has quit [Quit: Leaving] 19:17 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 19:22 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev 19:24 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 19:24 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev 19:24 -!- zivl [~zivl@unaffiliated/zivl] has quit [Ping timeout: 276 seconds] 19:25 -!- pinheadmz_ [~matthewzi@cpe-68-173-75-211.nyc.res.rr.com] has joined #bitcoin-core-dev 19:27 -!- pinheadmz [~matthewzi@184.170.246.164] has quit [Ping timeout: 258 seconds] 19:27 -!- pinheadmz_ is now known as pinheadmz 19:27 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev 19:53 -!- davterra [~none@178.128.106.205] has quit [Ping timeout: 248 seconds] 19:55 -!- davterra [~none@178.128.106.205] has joined #bitcoin-core-dev 19:59 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 20:00 -!- them_ [~them_@89.249.74.218] has quit [] 20:03 -!- edunham1 [~edunham@139.28.218.198] has joined #bitcoin-core-dev 20:04 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev 20:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 20:05 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #16386: depends: disable unused Qt features (master...slim_qt_597) https://github.com/bitcoin/bitcoin/pull/16386 20:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 20:15 -!- zivl [~zivl@unaffiliated/zivl] has joined #bitcoin-core-dev 20:16 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 20:26 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev 20:40 -!- farmerwampum [~farmerwam@184.75.209.66] has quit [Ping timeout: 268 seconds] 20:43 -!- michagogo [uid14316@wikia/Michagogo] has quit [Quit: Connection closed for inactivity] 20:48 -!- baldur [~baldur@pool-108-30-43-28.nycmny.fios.verizon.net] has quit [Ping timeout: 244 seconds] 20:50 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 20:52 -!- farmerwampum [~farmerwam@184.75.209.66] has joined #bitcoin-core-dev 20:56 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev 20:56 -!- schnerch_ [~schnerchi@p5084AF19.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 21:00 -!- schnerchi [~schnerchi@p57B83118.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds] 21:00 -!- baldur [~baldur@pool-108-30-43-28.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 21:06 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 21:11 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev 21:26 -!- liberiga [~liberiga@gateway/tor-sasl/liberiga] has quit [Ping timeout: 260 seconds] 21:29 -!- TheV01d_ [thev01d@2001:19c0:1:801:851:ff00:1:6] has quit [Ping timeout: 264 seconds] 21:29 -!- TheV01d_ [thev01d@2001:19c0:1:801:851:ff00:1:6] has joined #bitcoin-core-dev 21:36 -!- rex4539 [~rex4539@2a02:587:3514:c700:d9f4:56dd:269a:f673] has quit [Quit: rex4539] 22:25 -!- d_t [~dt@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 22:36 -!- bralyclow2 [bralyclow@gateway/vpn/protonvpn/bralyclow] has joined #bitcoin-core-dev 22:37 -!- d_t [~dt@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 22:37 -!- bralyclow2 [bralyclow@gateway/vpn/protonvpn/bralyclow] has quit [Client Quit] 22:41 -!- d_t [~dt@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 22:44 -!- kcalvinalvin [~calvin@118.131.103.244] has joined #bitcoin-core-dev 22:45 -!- kcalvina_ [~calvin@104.143.95.21] has joined #bitcoin-core-dev 22:49 -!- kcalvinalvin [~calvin@118.131.103.244] has quit [Ping timeout: 268 seconds] 22:51 -!- d_t [~dt@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 22:57 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-szbygdoiahsufyby] has quit [Quit: Connection closed for inactivity] 23:00 -!- edunham1 [~edunham@139.28.218.198] has quit [] 23:02 -!- davterra [~none@178.128.106.205] has quit [Quit: Leaving] 23:16 -!- slewis [~slewis@141.98.101.133] has joined #bitcoin-core-dev 23:57 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev --- Log closed Fri Jul 26 00:00:21 2019