--- Log opened Thu Oct 17 00:00:36 2019
00:03 -!- Francisco_ [uid397221@gateway/web/irccloud.com/x-ynipioirujyrguku] has left #bitcoin-core-dev []
00:05 -!- _Francisco_ [uid397221@gateway/web/irccloud.com/x-ynipioirujyrguku] has joined #bitcoin-core-dev
00:06 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 264 seconds]
00:11 -!- rex4539 [~rex4539@balticom-197-78.balticom.lv] has joined #bitcoin-core-dev
00:19 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
00:22 -!- marcoagner [~user@2001:8a0:6a53:2e00:1967:22be:ad77:2d5] has joined #bitcoin-core-dev
00:24 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds]
00:32 -!- jonatack [~jon@p57B4C1A5.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
00:36 < jeremyrubin> There aren't RPCs which support raw scripts are there?
00:36 < sipa> what does that mean?
00:37 < jeremyrubin> e.g., in sendmany you pass a associative list of addresses and values
00:37 < sipa> decodescript certainly does, in a way
00:39 < jeremyrubin> but I guess there's not a decent way to make a transaction to a raw piece of ASM
00:39 < sipa> no, asm is ambiguous even
00:39 < sipa> you can't convert it back to script
00:39 < jeremyrubin> err hexstr
00:41 < sipa> with a lot of imagination, sendrawtransaction/fundrawtransacrion/... support that
00:41 < sipa> but that's it
00:41 < jeremyrubin> hence 'decent'
00:47 -!- kljasdfvv [~flack@p200300D46F014C00489E25F5842E29F4.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!]
00:49 -!- kljasdfvv [~flack@p200300D46F014C00CC0BB59D2E047F44.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
01:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:28 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
01:30 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
01:34 -!- EagleTM [EagleTM@gateway/vpn/nordvpn/eagletm] has joined #bitcoin-core-dev
01:35 -!- promag_ [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 252 seconds]
01:38 -!- jarthur [~jarthur@2605:6000:1019:4971:7df1:e332:57a8:5471] has quit []
01:44 -!- jonatack [~jon@37.173.137.123] has joined #bitcoin-core-dev
01:44 -!- designwish [~designwis@51.ip-51-68-136.eu] has quit [Quit: ZNC - http://znc.in]
01:48 -!- Highway61 [~Thunderbi@199.229.250.86] has joined #bitcoin-core-dev
01:49 -!- tsujp [~tsujp@27-33-228-156.tpgi.com.au] has quit [Ping timeout: 268 seconds]
01:49 -!- tsujp_ [~tsujp@209.58.139.9] has joined #bitcoin-core-dev
02:00 -!- WhereIsMySpoon [~WhereIsMy@195.206.169.238] has quit []
02:06 -!- designwish [~designwis@51.ip-51-68-136.eu] has joined #bitcoin-core-dev
02:09 -!- gwillen [~gwillen@unaffiliated/gwillen] has quit [Remote host closed the connection]
02:09 -!- EagleTM [EagleTM@gateway/vpn/nordvpn/eagletm] has quit [Ping timeout: 240 seconds]
02:11 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]
02:15 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
02:17 -!- votesmith [~votesmith@237.ip-217-182-75.eu] has quit [Quit: bye]
02:17 -!- mota [~mota@185.103.96.143] has joined #bitcoin-core-dev
02:18 -!- profmac [~ProfMac@2001:470:1f0f:226:2157:601c:f39a:1e3c] has quit [Ping timeout: 245 seconds]
02:20 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
02:22 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev
02:23 -!- votesmith [~votesmith@237.ip-217-182-75.eu] has joined #bitcoin-core-dev
02:24 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]
02:30 -!- profmac [~ProfMac@2001:470:1f0f:226:dd41:c98d:1972:1095] has joined #bitcoin-core-dev
02:30 -!- jonatack [~jon@37.173.137.123] has quit [Quit: jonatack]
02:31 -!- jonatack [~jon@37.173.137.123] has joined #bitcoin-core-dev
02:44 -!- oyvkva [~hi@static.190.91.251.148.clients.your-server.de] has quit [Quit: quit]
02:44 -!- oyvkva_ [~hi@2a01:4f8:202:718b::2] has joined #bitcoin-core-dev
02:45 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
02:50 < promag> meshcollider: yes, I'm reviewing that one.
02:53 < meshcollider> ?
02:56 -!- rex4539 [~rex4539@balticom-197-78.balticom.lv] has quit [Quit: rex4539]
03:08 -!- spinza [~spin@102.132.245.16] has quit [Ping timeout: 240 seconds]
03:18 -!- rex4539 [~rex4539@balticom-197-78.balticom.lv] has joined #bitcoin-core-dev
03:29 -!- Mael-Rolland [6d0f0cd4@212.12.15.109.rev.sfr.net] has joined #bitcoin-core-dev
04:12 -!- waxwing_ [~waxwing@193.29.57.116] has left #bitcoin-core-dev []
04:13 -!- waxwing [~waxwing@unaffiliated/waxwing] has joined #bitcoin-core-dev
04:18 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Ping timeout: 260 seconds]
04:19 -!- jb551 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 260 seconds]
04:19 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 260 seconds]
04:19 -!- SiAnDoG [~514nDoG@gateway/tor-sasl/siandog] has quit [Ping timeout: 260 seconds]
04:19 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 260 seconds]
04:19 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Ping timeout: 260 seconds]
04:19 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 260 seconds]
04:19 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 260 seconds]
04:19 -!- lowentropy [~lowentrop@gateway/tor-sasl/lowentropy] has quit [Ping timeout: 260 seconds]
04:19 -!- astro [~astro@gateway/tor-sasl/astro] has quit [Ping timeout: 260 seconds]
04:19 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 260 seconds]
04:19 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 260 seconds]
04:19 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 260 seconds]
04:21 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
04:26 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds]
04:28 -!- m1rror8955363887 [~m1rror@109.134.206.46] has joined #bitcoin-core-dev
04:32 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
04:32 -!- lowentropy [~lowentrop@gateway/tor-sasl/lowentropy] has joined #bitcoin-core-dev
04:33 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined #bitcoin-core-dev
04:33 -!- jb551 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-dev
04:33 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev
04:36 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-dev
04:38 -!- astro [~astro@gateway/tor-sasl/astro] has joined #bitcoin-core-dev
04:39 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
04:40 -!- Mael-Rolland [6d0f0cd4@212.12.15.109.rev.sfr.net] has quit [Remote host closed the connection]
04:44 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev
05:00 -!- mota [~mota@185.103.96.143] has quit []
05:17 -!- pdurbin1 [~pdurbin@84.39.117.57] has joined #bitcoin-core-dev
05:23 -!- spinza [~spin@102.132.245.16] has joined #bitcoin-core-dev
05:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:24 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/46d6930f8c7b...4f42284fc0c5
05:24 < bitcoin-git> bitcoin/master f59bbb6 Jim Posen: test: Fix bug in blockfilter_index_tests.
05:24 < bitcoin-git> bitcoin/master 4f42284 MarcoFalke: Merge #17140: test: Fix bug in blockfilter_index_tests.
05:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:25 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #17140: test: Fix bug in blockfilter_index_tests. (master...fix-index-test) https://github.com/bitcoin/bitcoin/pull/17140
05:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:26 -!- Mael-Rolland [6d0f0cd4@212.12.15.109.rev.sfr.net] has joined #bitcoin-core-dev
05:26 -!- EagleTM [EagleTM@gateway/vpn/nordvpn/eagletm] has joined #bitcoin-core-dev
05:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:28 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/4f42284fc0c5...fcf1ebde3db9
05:28 < bitcoin-git> bitcoin/master 5013171 fanquake: doc: correct function name in ReportHardwareRand()
05:28 < bitcoin-git> bitcoin/master fcf1ebd MarcoFalke: Merge #17169: doc: correct function name in ReportHardwareRand()
05:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:29 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #17169: doc: correct function name in ReportHardwareRand() (master...random_doc_inithardwarerand) https://github.com/bitcoin/bitcoin/pull/17169
05:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:38 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection]
05:38 -!- davterra [~none@195.242.213.120] has joined #bitcoin-core-dev
05:40 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 240 seconds]
05:40 -!- Mael-Rolland [6d0f0cd4@212.12.15.109.rev.sfr.net] has quit [Remote host closed the connection]
05:42 -!- tsujp_ [~tsujp@209.58.139.9] has quit [Quit: My MacBook has gone to sleep. ZZZzzz...]
05:48 -!- tsujp [~tsujp@209.58.139.9] has joined #bitcoin-core-dev
05:49 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
05:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:52 < bitcoin-git> [bitcoin] ch4ot1c opened pull request #17172: doc: Update list of valid PR areas (master...doc/pr-areas) https://github.com/bitcoin/bitcoin/pull/17172
05:52 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:57 -!- Sentineo [~Undefined@unaffiliated/sentineo] has quit [Ping timeout: 268 seconds]
06:01 -!- Sentineo [~Undefined@unaffiliated/sentineo] has joined #bitcoin-core-dev
06:16 -!- jonatack [~jon@37.173.137.123] has quit [Read error: Connection reset by peer]
06:16 -!- jonatack_ [~jon@37.173.137.123] has joined #bitcoin-core-dev
06:22 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
06:26 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 245 seconds]
06:27 -!- EagleTM [EagleTM@gateway/vpn/nordvpn/eagletm] has quit [Ping timeout: 276 seconds]
06:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:41 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fcf1ebde3db9...048e456fc408
06:41 < bitcoin-git> bitcoin/master 85016e5 Andrew Toth: [rpc] Fix broken bitcoin-cli examples
06:41 < bitcoin-git> bitcoin/master 048e456 Wladimir J. van der Laan: Merge #17119: doc: Fix broken bitcoin-cli examples
06:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:41 -!- jonatack_ [~jon@37.173.137.123] has quit [Read error: Connection reset by peer]
06:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:41 < bitcoin-git> [bitcoin] laanwj merged pull request #17119: doc: Fix broken bitcoin-cli examples (master...example-fixes) https://github.com/bitcoin/bitcoin/pull/17119
06:41 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:42 -!- jonatack_ [~jon@37.173.137.123] has joined #bitcoin-core-dev
06:45 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev
06:50 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 264 seconds]
06:52 -!- rex4539 [~rex4539@balticom-197-78.balticom.lv] has quit [Quit: rex4539]
06:53 -!- rex4539 [~rex4539@balticom-197-78.balticom.lv] has joined #bitcoin-core-dev
06:53 -!- rex4539 [~rex4539@balticom-197-78.balticom.lv] has quit [Client Quit]
06:53 -!- rex4539 [~rex4539@balticom-197-78.balticom.lv] has joined #bitcoin-core-dev
06:54 -!- rex4539 [~rex4539@balticom-197-78.balticom.lv] has quit [Client Quit]
06:54 -!- rex4539 [~rex4539@balticom-197-78.balticom.lv] has joined #bitcoin-core-dev
06:55 -!- rex4539 [~rex4539@balticom-197-78.balticom.lv] has quit [Client Quit]
07:17 -!- rex4539 [~rex4539@balticom-197-78.balticom.lv] has joined #bitcoin-core-dev
07:26 -!- lightlike [~lightlike@2001:16b8:5710:fb00:4126:5a97:dbec:38cb] has joined #bitcoin-core-dev
07:28 -!- ensign [~ensign@2001:41d0:8:d711::1] has joined #bitcoin-core-dev
07:37 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
07:38 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
07:39 -!- tsujp [~tsujp@209.58.139.9] has quit [Quit: My MacBook has gone to sleep. ZZZzzz...]
07:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:39 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/048e456fc408...ec3ed5a44878
07:39 < bitcoin-git> bitcoin/master 1f6c650 Sjors Provoost: travis: run tests on macOS native
07:39 < bitcoin-git> bitcoin/master ec3ed5a MarcoFalke: Merge #16597: Travis: run full test suite on native macOS
07:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:40 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #16597: Travis: run full test suite on native macOS  (master...2019/08/travis-macos) https://github.com/bitcoin/bitcoin/pull/16597
07:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:41 -!- EagleTM [EagleTM@gateway/vpn/nordvpn/eagletm] has joined #bitcoin-core-dev
07:42 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
07:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:53 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #17176: ci: Cleanup macOS runs (master...1910-ciMac) https://github.com/bitcoin/bitcoin/pull/17176
07:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:55 < bitcoin-git> [bitcoin] fjahr opened pull request #17177: doc: Describe log files + consistent paths in test READMEs (master...pr15830) https://github.com/bitcoin/bitcoin/pull/17177
07:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:58 -!- davterra [~none@195.242.213.120] has quit [Remote host closed the connection]
08:00 -!- pdurbin1 [~pdurbin@84.39.117.57] has quit []
08:02 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
08:03 -!- jonatack_ [~jon@37.173.137.123] has quit [Read error: Connection reset by peer]
08:09 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
08:16 -!- gwillen [~gwillen@unaffiliated/gwillen] has joined #bitcoin-core-dev
08:16 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
08:17 -!- Darki1 [~Darki@141.98.102.235] has joined #bitcoin-core-dev
08:21 -!- captjakk [~captjakk@178.128.232.240] has joined #bitcoin-core-dev
08:23 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
08:27 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
08:27 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds]
08:33 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]
08:33 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev
08:35 -!- davterra [~none@195.242.213.120] has joined #bitcoin-core-dev
08:58 -!- captjakk [~captjakk@178.128.232.240] has quit [Ping timeout: 276 seconds]
08:59 -!- captjakk [~captjakk@c-24-72-155-6.ni.gigamonster.net] has joined #bitcoin-core-dev
09:00 -!- kljasdfvv [~flack@p200300D46F014C00CC0BB59D2E047F44.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!]
09:16 -!- astro [~astro@gateway/tor-sasl/astro] has quit [Ping timeout: 260 seconds]
09:19 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
09:22 -!- astro [~astro@gateway/tor-sasl/astro] has joined #bitcoin-core-dev
09:23 -!- jungly [~quassel@79.8.200.97] has quit [Remote host closed the connection]
09:25 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
09:26 -!- rabidus [~rabidus@85-23-137-40.bb.dnainternet.fi] has quit [Ping timeout: 240 seconds]
09:28 -!- rabidus [~rabidus@85-23-137-40.bb.dnainternet.fi] has joined #bitcoin-core-dev
09:29 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
09:31 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Read error: Connection reset by peer]
09:35 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-dev
09:35 -!- afk11` [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev
09:37 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 260 seconds]
09:40 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
09:42 -!- angins [b6017f9b@182.1.127.155] has joined #bitcoin-core-dev
09:42 -!- angins [b6017f9b@182.1.127.155] has quit [Remote host closed the connection]
09:44 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Ping timeout: 265 seconds]
09:46 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 245 seconds]
09:48 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-dev
09:48 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev
09:49 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer]
09:49 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev
09:50 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
09:54 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Ping timeout: 268 seconds]
09:58 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev
10:00 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
10:05 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Ping timeout: 250 seconds]
10:10 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
10:14 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Ping timeout: 245 seconds]
10:16 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
10:18 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 268 seconds]
10:19 -!- jonatack_ [~jon@37.167.163.202] has joined #bitcoin-core-dev
10:20 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection]
10:20 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has joined #bitcoin-core-dev
10:36 < sipa> jonasschnelli: where is your latest v2 p2p protocol draft?
10:37 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
10:39 < sipa> gleb: re #17163... are you sure that no lightweight clients do their own IP address management? maybe they don't currently, but that sounds like a bug
10:39 < gribble> https://github.com/bitcoin/bitcoin/issues/17163 | p2p: Avoid relaying ADDR messages to SPV clients by naumenkogs . Pull Request #17163 . bitcoin/bitcoin . GitHub
10:43 < jonasschnelli> sipa: https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52
10:44 -!- arik_ [~arik@c-24-5-126-13.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
10:47 < wumpus> sipa: I also wasn't sure the tight coupling between lightweight validation and no IP address management, but apparently it's an accepted thing 
10:48 < wumpus> tbh, I think everyone that cares about decent address management gave up on SPV nodes long ago
10:48 < wumpus> so it's not wrong, but it wouldn't have to be a necessary correlation
10:49 < gleb> sipa: This was my intuition. Maybe, we should allow them to ask (we can discuss that), but we certainly don't want to rely on them when we choose 1/2 peers to forward a <10 addr message.
10:50 < sipa> gleb: agree there; i commented on your PR
10:54 < gleb> Let's ask others at the meeting in an hour :) Should be pretty quick.
10:58 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 240 seconds]
11:00 -!- Darki1 [~Darki@141.98.102.235] has quit []
11:01 < gleb> Another idea would be to add a service flag? Sounds reasonable to me protocol-wise, but I'm not sure I have the right intuition.
11:03 < wumpus> you want a way to be able to signify that nodes don't want to receive addr messages at all?
11:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:03 < bitcoin-git> [bitcoin] fanquake closed pull request #17172: doc: Update list of valid PR areas (master...doc/pr-areas) https://github.com/bitcoin/bitcoin/pull/17172
11:04 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:06 < wumpus> might be able to smuggle that into addrv2 somehow; it has a proposed message for a peer to signify support for v2 addrsses, maybe it could signify 'no addr support' as well
11:06 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-dev
11:06 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
11:08 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
11:08 < luke-jr> maybe there should be a node mode that *only* relays addr messages, and sipa could only return those with his DNS seed :P
11:08 < fanquake> rex4539 This might be the error message you were talking about the other day #17179
11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/17179 | macos: shutdown on first run due to -psn_ parameter . Issue #17179 . bitcoin/bitcoin . GitHub
11:09 < rex4539> Yes, this was it :)
11:10 < fanquake> Good to know at least 1 other person has been (clean) testing rc1 on macOS
11:10 < wumpus> why does this happen with rc1 though?
11:11 < wumpus> and not with other versions
11:11 < luke-jr> another Qt thing?
11:12 < luke-jr> like the duplicate URIs
11:12 < fanquake> It might be because we are doing more strict argument passing now? It's also only happens when you run Bitcoin Core for the very first time
11:12 < wumpus> oh, maybe Qt filtered it out before
11:12 < wumpus> right
11:12 < luke-jr> https://stackoverflow.com/questions/10242115/os-x-strange-psn-command-line-parameter-when-launched-from-finder
11:12 < wumpus> Qt's argument handling probebly kind of shielded us from platform specific craziness like this
11:12 < fanquake> heh, so qt does filter it out yes
11:13 < fanquake> from qtbase: "// eat "-psn_xxxx" on Mac, which is passed when starting an app from Finder."
11:13 < wumpus> like the files handling
11:13 < luke-jr> fanquake: is it near the duplicate URI filtering code? maybe someone should go through all that
11:14 < fanquake> Will link to the tree in a sec
11:14 < wumpus> everyone on every OS now has to suffer basically because of a buggy browser issue on windows :-)
11:14 < fanquake> https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qguiapplication.cpp?h=5.9.8#n1377
11:17 -!- chrissie1 [~chrissie@141.98.102.235] has joined #bitcoin-core-dev
11:17 < luke-jr> so we should chdir too..?
11:18 < luke-jr> or do we even care
11:20 -!- watchtower [~watchtowe@pool-96-239-24-37.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
11:20 -!- jonatack_ [~jon@37.167.163.202] has quit [Ping timeout: 240 seconds]
11:23 -!- watchtower [~watchtowe@pool-96-239-24-37.nycmny.fios.verizon.net] has quit [Client Quit]
11:24 < fanquake> I don't think we care. I'm not sure why they are changing directory code was added. The commit is from 7 years ago, and doesn't have much detail. However they were doing the psn filtering before that was added.
11:26 < gleb> luke-jr: jokes aside, I was considering separating addr-relay from tx-relay and block-relay. Because I think topology leakage is cumulative, haha. But that requires a lot of analysis.
11:30 -!- arik_ [~arik@c-24-5-126-13.hsd1.ca.comcast.net] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz...]
11:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:30 < bitcoin-git> [bitcoin] JeremyCrookshank opened pull request #17180: gui: Improved wording/explanation of Bitcoin sends amount box (master...sendamounttooltip) https://github.com/bitcoin/bitcoin/pull/17180
11:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:32 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has quit [Ping timeout: 240 seconds]
11:35 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has joined #bitcoin-core-dev
11:37 -!- drbrule [uid395654@gateway/web/irccloud.com/x-dinjtmwqtxxrodld] has joined #bitcoin-core-dev
11:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:37 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ec3ed5a44878...88eff969c201
11:37 < bitcoin-git> bitcoin/master 9576614 Martin Erlandsson: doc: Describe log files + consistent paths in test READMEs
11:37 < bitcoin-git> bitcoin/master 88eff96 MarcoFalke: Merge #17177: doc: Describe log files + consistent paths in test READMEs
11:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:38 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #17177: doc: Describe log files + consistent paths in test READMEs (master...pr15830) https://github.com/bitcoin/bitcoin/pull/17177
11:38 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:39 < warren> I'm here for the weekly meeting, that's in 20 minutes?
11:40 < wumpus> yes
11:49 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
11:49 < dongcarl> gleb: Not 100% sure what you mean in your latest comment on #17163
11:49 < gribble> https://github.com/bitcoin/bitcoin/issues/17163 | p2p: Avoid relaying ADDR messages to SPV clients by naumenkogs . Pull Request #17163 . bitcoin/bitcoin . GitHub
11:49 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
11:50 < dongcarl> "Older nodes are very likely to forward their <10 addr messages in the blackhole" because they might forward to newer nodes that will ignore addr messages from incoming connections like sipa described?
11:52 < gleb> Yes
11:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:53 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/88eff969c201...4daadce36cfe
11:53 < bitcoin-git> bitcoin/master fa04673 MarcoFalke: chain: Set all CBlockIndex members to null, remove SetNull helper
11:53 < bitcoin-git> bitcoin/master 4daadce fanquake: Merge #17162: chain: Remove CBlockIndex::SetNull helper
11:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:54 < bitcoin-git> [bitcoin] fanquake merged pull request #17162: chain: Remove CBlockIndex::SetNull helper (master...1910-docChainLocks) https://github.com/bitcoin/bitcoin/pull/17162
11:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:57 < dongcarl> gleb: "it's very likely that this "stem" will end up at a private node very fast (just graph-wise), and it will drop it on the floor" private node being a node with only outgoing connections?
11:58 < gleb> dongcarl: also yes.
11:59 < dongcarl> gleb: if this private node only has outgoing connections, why would it drop anything on the floor?
12:00 -!- jb551 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
12:00 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Remote host closed the connection]
12:00 < gleb> Because I assume that if we enforce a rule "don't accept addr from inbounds", then this private node won't even try to relay it further (as the receiver will discard it)
12:00 < gleb> .
12:00 < dongcarl> gleb: oh I see...
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Oct 17 19:00:31 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 < jnewbery> hi
12:00 -!- jb551 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-dev
12:00 < warren> hi
12:00 < kanzure> hi
12:00 < gleb> hi
12:00 < moneyball> hi
12:00 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral
12:00 < jonasschnelli> hi
12:00 < fanquake> hi
12:01 < dongcarl> hi
12:01 < jeremyrubin> hi
12:01 < wumpus> one proposed topic for today: taproot proposal next steps; possible review sessions (moneyball)
12:01 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined #bitcoin-core-dev
12:01 < sipa> hi
12:01 < moneyball> wumpus: i assume we'll do high priority list first?
12:01 < aj> hola
12:02 < promag> hi
12:02 < wumpus> moneyball: yes, let's start with that (I wait a bit in case people have additional last minute topics to propose)
12:02 < wumpus> #topic High priority for review
12:03 < achow101> hi
12:03 < wumpus> https://github.com/bitcoin/bitcoin/projects/8
12:03 < promag> please add 17135
12:03 < wumpus> #17135
12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/17135 | gui: Make polling in ClientModel asynchronous by promag . Pull Request #17135 . bitcoin/bitcoin . GitHub
12:04 < fanquake> promag: can you fill out the description in that PR? Why is it high-prio?
12:04 < wumpus> promag: ok done
12:04 < promag> fanquake: IMO they are necessary for 0.19, also #16963 #17120
12:05 < promag> ty
12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/16963 | wallet: Fix unique_ptr usage in boost::signals2 by promag . Pull Request #16963 . bitcoin/bitcoin . GitHub
12:05 < wumpus> yes, would be nice if you also say what it is blocking
12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/17120 | gui: Fix start timer from non QThread by promag . Pull Request #17120 . bitcoin/bitcoin . GitHub
12:05 < wumpus> seems to big a change for 0.19.0 at least
12:05 < wumpus> 0.19.1 maybe
12:06 < promag> I'll update description sure
12:06 < fanquake> I'll re-review 16963
12:07 < fanquake> I'm not sure there's too much else to discuss high-prio wise other than hopefully people are doing some rc1 testing
12:07 < promag> but it's meant to fix #17112
12:07 < gribble> https://github.com/bitcoin/bitcoin/issues/17112 | v0.19.0rc1 GUI repeatedly not responding . Issue #17112 . bitcoin/bitcoin . GitHub
12:07 < fanquake> Maybe jump into the taproot discussion?
12:07 < wumpus> promag: that's just too deep a rabbit hole to fix before the release, is it really a reversion in 0.19?
12:08 < promag> yes
12:08 < wumpus> where did it happen then?
12:08 < promag> see https://github.com/bitcoin/bitcoin/issues/17112#issuecomment-541659632
12:09 < wumpus> ok
12:09 < wumpus> I still think adding the GUI async stuff last minute is risky
12:09 < sipa> is there a simpler way to fix the issue itself?
12:10 < promag> well it's still a HP decision
12:10 < sipa> harry potter? health points? hewlett-packard?
12:10 < wumpus> I mean it's the obvious thing to do long term but between rcs?
12:10 < promag> heh, high prio
12:10 < sipa> oh lol, sorry, that should have been obvious :)
12:11 < promag> wumpus: it's fine if we postpone the that change, but let's decide that then :p
12:11 < aj> gui hangs would cause a lot of user complaints though?
12:11 < wumpus> yes, but we've always have lots of GUI hangs during initial sync
12:12 < jonasschnelli> Yes. This has been there for a long time
12:12 < wumpus> this lock just makes it slightly worse I guess
12:12 < jonasschnelli> No need for risky fixes in rc-timeframe
12:12 < sipa> if it's a visible regression it seems reasonable to fix it, but is it possible to just say undo the change that caused it rather than fixing the root issue?
12:12 < jonasschnelli> Better do proper fixes in 0.20
12:12 < wumpus> but this is always been a problem and I don't think we're going to solve it for 0.19.0
12:12 < wumpus> can we fix it by reverting something instead?
12:12 < promag> Jackielove4u: tested that PR in win/linux/macos and compared to 0.18
12:12 < wumpus> (on the 0.19 branch I mean)
12:12 < promag> 0.19rc is really bad in that regards
12:12 < wumpus> instead of adding more code
12:12 < jonasschnelli> Its not an easy fix
12:13 < jonasschnelli> It requires conceptual changes
12:13 < wumpus> no, it's not an easy fix, it's changing things in a very differnt place than where the problem was introduced
12:13 < sipa> jonasschnelli: well there was a specific PR that caused it, or at least worsened it
12:13 -!- captjakk [~captjakk@c-24-72-155-6.ni.gigamonster.net] has quit [Remote host closed the connection]
12:13 < promag> yeah revert is another option I guess, MarcoFalke_?
12:13 < sipa> i'd like to know if we can revert that PR instead
12:13 < wumpus> so this basically means we're delaying 0.19.0 indefnintely
12:13 < jonasschnelli> sipa: maybe a part of it. But GUI unresponsivenes was always an issue
12:13 < wumpus> until the GUI is async
12:13 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev
12:13 < jonasschnelli> The GUI was not created to be async
12:13 < sipa> jonasschnelli: i'm very much aware; but i'm not talking about fixing the root issue, only the regression
12:13 < wumpus> which is not soemthing I can get behind, sorry
12:14 < promag> BTW, the same approach is already used in WalletController
12:14 < jonasschnelli> sipa: sure. If we can fix the regression in a sane way we may want it in 0.19. But unclear of 17120 fixes that 
12:15 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
12:15 < jonasschnelli> s/of/if
12:15 < sipa> jonasschnelli: i'm literally suggesting reverting the PR that caused it, nothing more
12:16 < fanquake> so revert #14193 ?
12:16 < wumpus> that would be ok with me
12:16 < gribble> https://github.com/bitcoin/bitcoin/issues/14193 | validation: Add missing mempool locks by MarcoFalke . Pull Request #14193 . bitcoin/bitcoin . GitHub
12:16 -!- rockhouse [~rockhouse@unaffiliated/rockhouse] has quit [Remote host closed the connection]
12:16 -!- victorSN [~victorSN@unaffiliated/victorsn] has quit [Read error: Connection reset by peer]
12:16 < valwal> hi
12:16 < promag> ok, I'll revert it in 0.19 and see how it goes
12:16 -!- rockhouse [~rockhouse@unaffiliated/rockhouse] has joined #bitcoin-core-dev
12:16 < fanquake> Does that not mean we are back with whatever problems that was meant to fix?
12:16 < wumpus> what we're arguing against is making changes to GUI asynchronicity before the 0.19.0 release, I think if it's possible to revert the locking change that caused it in the first place that's a more direct and safer option
12:17 < jonasschnelli> Yes
12:17 -!- victorSN [~victorSN@unaffiliated/victorsn] has joined #bitcoin-core-dev
12:17 < wumpus> but  #17135 adds an extra thread, that's not a trivial fix
12:17 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
12:17 < gribble> https://github.com/bitcoin/bitcoin/issues/17135 | gui: Make polling in ClientModel asynchronous by promag . Pull Request #17135 . bitcoin/bitcoin . GitHub
12:17 < wumpus> all we know it might make locking issues worse somewhere
12:17 < jonasschnelli> Reverting #14193 (merged in july, invasive) may be not super easy
12:17 < gribble> https://github.com/bitcoin/bitcoin/issues/14193 | validation: Add missing mempool locks by MarcoFalke . Pull Request #14193 . bitcoin/bitcoin . GitHub
12:17 < fanquake> MarcoFalke: Had you seen inconsistent mempool reads prior to 14193?
12:18 -!- ajonas [uid385278@gateway/web/irccloud.com/x-rtsxrcjsnlndomgd] has joined #bitcoin-core-dev
12:18 < wumpus> which is okay for a release schedule for 0.20.0 where there's a long time to go before the actual release, but not something to do last minute
12:19 < promag> I'll just submit the revert commit to 0.19, ask for gitian build and let's see how testing goes
12:19 < wumpus> promag: thanks!
12:19 < jonasschnelli> promag: nice!
12:19 < achow101> could just add a known issue to the release notes and tell people to not mess around in the gui during IBD?
12:20 < wumpus> achow101: that would be the fallback then, yes
12:20 < promag> achow101: I think it's not just ibd - not sure 
12:20 < achow101> i would be somewhat surprised if people were actually doing things in the gui during ibd
12:21 < jonasschnelli> achow101: I guess the UX stopper is, if someone wants to get an address or so while he is syncing the last 2-3 days
12:21 < wumpus> not only IBD but also when you catch up after having not run it for a while
12:21 < jonasschnelli> (laptop users, etc.)
12:21 < wumpus> that's usually the most annoying time for it to happen
12:21 < jonasschnelli> indeed
12:21 < wumpus> espeiclaly when you want to send a transaction quickly
12:21 < promag> the problem is more evident in windows because windows show that app is not responding that can cause some frustration 
12:21 < sipa> #17135 does not look crazy, and may be worth considered... but my preference is reverting
12:21 < gribble> https://github.com/bitcoin/bitcoin/issues/17135 | gui: Make polling in ClientModel asynchronous by promag . Pull Request #17135 . bitcoin/bitcoin . GitHub
12:21 < wumpus> but anyhow this is not new, and can't be solved before 0.19.0
12:22 < wumpus> sipa: it's not crazy but it does add a new thread
12:22 < jonasschnelli> I tested 17135 a bit and I still had freezes. It's better but not solved.
12:22 < wumpus> I think that's a big change between rcs
12:22 < sipa> wumpus: agree it's a big change to do at this stage
12:22 < jonasschnelli> Lets aim for the mempool locks revert and add more fixes in 0.20
12:22 < promag> jonasschnelli: I'd love to know more about that :D
12:22 < wumpus> and... it's annoying but not a crash issue
12:23 < achow101> would reverting the locks cause other problems?
12:23 < promag> wumpus: yeah but people can force kill upon these hangs
12:23 < jonasschnelli> promag: yeah. Currently setting up a test env to better reproduce those locks
12:23 < achow101> I guess it wouldn't really be a regression..
12:23  * jonasschnelli wishes the GUI would just work via RPC
12:24 < warren> deadlock can happen in headless bitcoind?
12:24 -!- real_or_random [~real_or_r@2a02:c207:3002:7468::1] has quit [Ping timeout: 276 seconds]
12:24 < sipa> warren: this discussion is about Qt GUI only
12:24 < warren> ok thx
12:24 < promag> next topic?
12:24 < fanquake> cc moneyball
12:24 < moneyball> Hi
12:24 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Ping timeout: 260 seconds]
12:24 -!- mryandao_ [~mryandao@gateway/tor-sasl/mryandao] has joined #bitcoin-core-dev
12:25 < jnewbery> MarcoFalke has been responding but his messages aren't getting through
12:25 < wumpus> #topic Taproot proposal (moneyball)
12:25 < moneyball> aj, harding, and i have been discussing organizing a review of the schnorr/taproot/tapscript proposals
12:25 < wumpus> jnewbery: oh no :( is he logged in to nickserv
12:25 < moneyball> our thinking is here https://docs.google.com/document/d/1G48-yhZMLLMZW68Bq59h_FBi__pwFKoWKF1D385I38Y/edit#
12:26 < moneyball> it would be a 7 week series ending by end of year
12:26 < promag> jnewbery: MarcoFalke_ been there too :(
12:26 < wumpus> it looks like he isn't logged in-- you can't post here in that case, and worse, you don't really get feedback--I had the same problem some meetings ago
12:26 < moneyball> i raise it here because (a) create awareness (b) solicit feedback on the idea (c) solicit ideas for how to invite high quality broad reviewers
12:27 < moneyball> i'm thinking we will communicate this on bitcoin-dev, lightning-dev, optech newsletters + slack to member companies
12:27 -!- davterra [~none@195.242.213.120] has quit [Remote host closed the connection]
12:28 < sipa> sounds like a great idea to get feedback
12:28 < moneyball> the goal of this is to generate high quality feedback, give us further confidence in the proposal, give the Core project confidence to proceed with code review and QA of the existing PR, and to improve the decentralization / broader participation of review of the proposal
12:28 < sipa> there is no PR
12:28 -!- MarcoFalke_ [~none@198.12.116.246] has quit [Quit: ZNC 1.7.1 - https://znc.in]
12:28 -!- davterra [~none@195.242.213.120] has joined #bitcoin-core-dev
12:28 < moneyball> sorry, branch
12:29 < aj> to proceed with getting an implementation that we can PR :)
12:29 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-core-dev
12:29 < sipa> yeah
12:29 < MarcoFalke> test
12:29 < jnewbery> (b) I think it's a good idea
12:29 < sipa> MarcoFalke: reading you loud and clear
12:29 < aj> MarcoFalke: success
12:29 < MarcoFalke> I was wondering why no one responeded to me for days
12:29 < jonasschnelli> heh
12:29 < sipa> oww
12:30 < fanquake> moneyball sounds good. I see some australian friendly time slots as well 
12:30 < jnewbery> welcome back, MarcoFalke
12:30 < wumpus> oh crap
12:30 < promag> lol
12:30 < achow101> moneyball: is the idea to kind of do it in the style of the pr review club?
12:31 < wumpus> kafkaIRC
12:31 < sipa> wumpus: IRC where only some people see what certain others are saying... sounds like twitter to me
12:31 < moneyball> achow101: aj has proposed a small group study structure then come together as a larger group once a week via IRC for Q&A (see the doc for details)
12:31 < MarcoFalke> I think the issue was the znc put an underscore behind my name and bitcoin-core-dev only allows logged in users to post?
12:31 < MarcoFalke> (sorry ot)
12:31 < moneyball> it will definitely require diligence and commitment, but i think it is necessary for a high quality review of the proposal
12:31 < wumpus> sipa: yes it seems the same kind of shadowban idea
12:33 < wumpus> MarcoFalke: yes, it allows only logged in users to post, though you can log in while having an alternative nick (by using /msg nickserv login <registered_user> <pass> AFAIK instead of just /... login <PASS>)
12:33 < moneyball> "once a week" = twice a week at different times to provide good global coverage
12:33 < wumpus> MarcoFalke: the crazy thing is that freenode doesn't seem to send an error message anymore in that case
12:33 < sipa> 7 weeks seems like a lot, but i also agree it's not something that can be done in 1-2 hours
12:33 < jeremyrubin> i think it would make sense to talk about deployment/acceptance criteria
12:34 < wumpus> MarcoFalke: the reason for "only registered users can post" is for some spam avoidance, it used to be really bad at some point, maybe it's no longer necessary I don't know
12:34 < sipa> jeremyrubin: imho that's an entirely different discussion; we first need to know if the ecosystem is on board including all the details it entails (to the extent they care), then we can talk about activation
12:35 < warren> MarcoFalke: strongly recommend figuring out the nickserv SASL or TLS cert authentication, then you'll never connect without login
12:35 < wumpus> warren: somehow it did happen to me once
12:35 < achow101> moneyball: who are the participants? open to public?
12:35 < warren> wumpus: yeah server splits or other weird conditions
12:35 < jeremyrubin> sipa: thats what i said kinda
12:36 < jeremyrubin> "we first need to know if the ecosystem is on board" == acceptance criteria 
12:37 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
12:37 < jeremyrubin> knowing what that means, i agree, is a separate discussion 
12:37 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
12:37 < moneyball> achow101: open to public. some level of moderation may be needed just to keep folks on track and avoid trolls. i mention above the proposed method of outreach. if others have ideas let me know.
12:37 -!- real_or_random [~real_or_r@2a02:c207:3002:7468::1] has joined #bitcoin-core-dev
12:38 < jeremyrubin> but an impt one for taproot and other stuff too, separate from the actual instance
12:38 < aj> sipa: i don't think shrinking it below 5 "sessions" works, and multiple sessions a week seems a bit intense, 7 weeks seems the max before hitting xmas/new year, and 5 + 2 weeks padding seems okayish
12:38 < sipa> jeremyrubin: i have no idea what you're trying to say
12:38 < sipa> aj: ok
12:39 < jeremyrubin> ok
12:39 < jeremyrubin> can chat out of band later
12:39 < sipa> ok
12:40 < moneyball> also feel free to comment directly in the doc if you have ideas or concerns
12:40 < moneyball> thanks everyone! hope to see many of you participate. it is a fairly large commitment but as aj points out in the doc:
12:40 < moneyball> https://www.irccloud.com/pastebin/igNUbnnf/
12:41 < wumpus> thanks!
12:41 < sipa> sgtm
12:43 < MarcoFalke> #proposedmeetingtopic address relay and spv clients
12:43 < gleb> I wanted to mention that in #17163 we're discussion whether we should stop relaying addresses to light clients or just limit relay to the cases where it does not hurt addr propagation.
12:43 < gleb> It's not clear for us whether SPV should sync their addr database with random peers from the network. Input welcome!
12:43 < gribble> https://github.com/bitcoin/bitcoin/issues/17163 | p2p: Avoid relaying ADDR messages to SPV clients by naumenkogs . Pull Request #17163 . bitcoin/bitcoin . GitHub
12:44 < gleb> I guess we tend to "allowing SPV to ask for addresses does not hurt", so the latter, but I'd like to hear more opinions.
12:45 < MarcoFalke> I guess we switched topics?
12:45 < MarcoFalke> #topic address relay and spv clients
12:46 < gleb> To be clear: currently when we get a short ADDR message (less than 10), we choose 1 or 2 peers to relay forward. That's the primary way to announce new nodes in the network. Currently it's possible that we choose SPV which will throw it on the floor, which is unfortunate.
12:47 < aj> how about just biassing against picking peers for the 1 or 2 to relay for if those peers haven't sent us ADDR messages already, if that makes sense?
12:47 < achow101> I think it would hurt SPV clients to not receive addr messages
12:47 < achow101> *for them to not receive addr messages
12:48 < gleb> I also mentioned above that an explicit service flag is maybe a good idea, to decouple addr-relay from SPV/non-SPV reasoning.
12:49 < gleb> Or whatever other explicit way you can imagine. aj: Biasing is sort of that, but implicit.
12:50 < gleb> Anyway, just wanted to mention that this discussion is taking place in #17163. Let's continue there. Thanks.
12:50 < gribble> https://github.com/bitcoin/bitcoin/issues/17163 | p2p: Avoid relaying ADDR messages to SPV clients by naumenkogs . Pull Request #17163 . bitcoin/bitcoin . GitHub
12:50 < achow101> gleb: are you certain that spv clients discard addr messages?
12:51 < MarcoFalke> as mentioned on the pull request, SPV clients should not deal with addr messages. I can only see ways in which they shoot themselves in the foot
12:51 < wumpus> maybe most current ones do, but it's not a necessary coupling
12:51 < sipa> MarcoFalke: i don't understand that comment
12:51 < sipa> and i don't understand what SPV has to do with it
12:52 < MarcoFalke> Though, there might be a node without NODE_NETWORK set that wants addr messages
12:52 < wumpus> I don't get why SPV clients couldn't implement full address management instead of blindly trusting DNS seeders
12:52 < MarcoFalke> So that coupling doesn't make sense
12:52 < achow101> i don't understand what about spv makes it such that they don't need addrs
12:52 < wumpus> right
12:52 < MarcoFalke> wumpus: I doubt implementing address management is trivial
12:53 < MarcoFalke> See for example feeler connections
12:53 < wumpus> no one is talking about 'trivial'
12:53 < sipa> MarcoFalke: i'm sure it's nontrivial, but it's nontrivial for everyone
12:53 < wumpus> but why couldn't they if they wanted?
12:54 < wumpus> so the reasoning is 'SPV implementations tend to be trivial, so they won't implement something as complex as addr handling'
12:54 < sipa> i agree partially with luke-jr that it's reasonable for lightweight clients to instead rely on a trusted server... but not all light clients do that; and within those that do, i think doing actual ip address management is far more reasonable that blindly using dns seeds
12:54 < wumpus> which more or less makes sense but it's very indirect
12:54 < warren> The "throwing to the floor" part is concerning but I'm thinking address relay is best effort. It is reasonable to need to connect to multiple/many peers before you get any quality addresses. There is no guaratee that a peer you try first is honest.
12:55 < BlueMatt> what does wasting a service bit cost? we've got a bunch of 'em :p
12:55 -!- rex4539 [~rex4539@balticom-197-78.balticom.lv] has quit [Quit: rex4539]
12:55 < achow101> wumpus: but at the same time, they are probably using some library like bitcoinj that already handles it for them (at least I think bitcoinj uses addrs)
12:55 < MarcoFalke> would the service bit be for "i want addr messages" or "i send addr messages"
12:56 < wumpus> achow101: that's another assumption though, based on current software
12:56 < wumpus> achow101: I"m not sure that should determine the protocol
12:56 < sipa> i think a service bit makes sense (e.g. explicitly opting out of address relay), but i think that's an independent question of whether we want to bias our own relay away from nodes we assume won't participate in relaying further
12:56 < gleb> MarcoFalke: Your peer shouldn't care whether you promise to send them something or not
12:56 < MarcoFalke> I also think it makes sense to make this more explicit with service bits or a new message type
12:57 < MarcoFalke> Would addrv2 help with that?
12:57 < wumpus> it could be added to that
12:57 < dongcarl> addrv2 has a message to indicate that I want addrv2 messages
12:57 < dongcarl> I'm hearing we want some kind of more complex negotiation?
12:58 < wumpus> the same mechanism (say, a new message) for requesting addrv2 messages could be used to request *NO* addr messages
12:58 < MarcoFalke> gleb: It is useful to know whether a peer might not relay addr messages, but still wants them
12:58 < wumpus> dongcarl: I don't think it would be more complex
12:58 < wumpus> just a third option (besides addr and addrv2)
12:58 < gleb> MarcoFalke: yeah, if they want, they should signalize. But whether they send us or not -- we don't care.
12:58 < gleb> Okay, it seems like I change a PR to avoid forwarding ADDR to SPV, but still allow SPV to ask for addresses.
12:59 < warren> +1
12:59 < gleb> And then we should expand addrv2 spec for this further change separately.
12:59 < sipa> that sounds reasonable
12:59 < achow101> how are you determining a node is spv? no node_network?
12:59 < gleb> and no node_network_limited.
12:59 < aj> (we also drop ADDRs on the floor if they're from a node we've set as block-relay-only per #15759)
13:00 < gribble> https://github.com/bitcoin/bitcoin/issues/15759 | p2p: Add 2 outbound block-relay-only connections by sdaftuar . Pull Request #15759 . bitcoin/bitcoin . GitHub
13:00 < achow101> that'd affect old pruned nodes tho
13:00 < wumpus> aj: oh? block relay only also means no addr relay?
13:00 < gleb> Yeah, but we already don't forward short addr to "block_relay_only" :)
13:00 < wumpus> aj: I kind of wondered that
13:00 < BlueMatt> time
13:00 < aj> wumpus: only for the 2 of 10 outbounds when we do tx's but have a couple of block-relay-only nodes
13:01 < wumpus> #endmeeting
13:01 < lightningbot> Meeting ended Thu Oct 17 20:01:13 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:01 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-10-17-19.00.html
13:01 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-10-17-19.00.txt
13:01 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-10-17-19.00.log.html
13:01 < aj> gleb: but we might pick a node who's chosen us as block_relay_only to forward addresses to
13:01 < MarcoFalke> gleb: this ^ for example
13:01 < achow101> filter by fRelay
13:02 < gleb> aj: In current implementation we won't pick a node which is set to be block_relay_only.
13:02 < MarcoFalke> I think we should guess whether a node relays (sends) addr messages based on other (unrelated) service bits or version flags
13:02 < aj> gleb: block_relay_only reflects our choice, not our peer's choice
13:03 < aj> or fRelay reflects that, i think; bit long since i've looked at it now
13:03 < MarcoFalke> gleb: That doesn't mean that in the future there might be a blocks-only-relay-and-addr-relay node
13:03 < gleb> It should be per-link, non per-direction, otherwise doesn't make sense.
13:03 < MarcoFalke> s/might/won't/
13:03 < gleb> Because then transactions will flow through that link, just in one direction :)
13:04 < aj> gleb: right, but for -blocksonly you want ADDR but not txs to flow, and you don't know if the other guy's selected you as block_relay_only or is doing -blocksonly in general
13:05 < aj> (i think)
13:06 < achow101> imo we should do the service bit thing to explicitly ask for or opt out of addr messages. all of the things mentioned don't necessarily exclude needing addrs
13:09 < gleb> achow101: Before service bit thing happens, I am suggesting to still allow everybody to learn, but just not forward them <10 addr messages.
13:15 < MarcoFalke> Sure, old Bitcoin Core nodes won't set that service bit, so they should be accomodated for and provided with addr messages
13:27 < luke-jr> [19:55:54] <MarcoFalke> would the service bit be for "i want addr messages" or "i send addr messages" <-- it doesn't make sense to use service bits for "i want"
13:28 < luke-jr> that can very easily be done at connection negotiation
13:30 < meshcollider> Oops forgot the meeting
13:35 < meshcollider> The taproot thing sounds good to me too 
13:38 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
13:42 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has quit [Quit: (https://github.com/mmgen) leaving]
13:47 -!- drbrule [uid395654@gateway/web/irccloud.com/x-dinjtmwqtxxrodld] has quit [Quit: Connection closed for inactivity]
13:47 < luke-jr> moneyball: ACK/HOLD isn't clear. If there's minor changes desired, does that need a HOLD?? :/
14:00 -!- chrissie1 [~chrissie@141.98.102.235] has quit []
14:03 -!- captjakk [~captjakk@c-24-72-155-6.ni.gigamonster.net] has joined #bitcoin-core-dev
14:10 < aj> luke-jr: some minor changes shouldn't need a HOLD (like "maybe add a reference to https://..." or "might be clearer if X was described before Y") ; and still want to go through github issues/PRs to actually get changes made. i'm thinking of ACK/HOLD as more like the summaries on the Segwit_support wiki page
14:12 < aj> luke-jr: (also, a double question-mark character? fancy)
14:17 -!- ski1 [~ski@185.103.96.143] has joined #bitcoin-core-dev
14:18 -!- nullptr| [~nullptr|@ip-94-112-129-192.net.upcbroadband.cz] has quit [Quit: ZNC - http://znc.in]
14:18 < luke-jr> I haven't checked if my review comments were addressed yet; I wonder if I should do that in advance, or wait for the meetings
14:20 -!- nullptr| [~nullptr|@ip-94-112-129-192.net.upcbroadband.cz] has joined #bitcoin-core-dev
14:20 < sipa> luke-jr: i never understood your comment about avoiding space savings
14:21 < sipa> do you just mean to clarify whether it's about bandwidth or other kinds of savings?
14:21 < luke-jr> sipa: I mean weight shouldn't be gamed.
14:22 < luke-jr> if a different weight is desirable, the algorithm for weight can be proposed adjusted, but just omitting bytes to manipulate weight isn't a good way
14:22 < aj> s/omitting/adding/ ?
14:23 < luke-jr> aj: IIRC it was omissions in the earlier draft
14:23 < sipa> ?
14:23 < sipa> weight = base_size + 3 * witness_size; nothing in taproot ever did anything else
14:23 < luke-jr> I'll need to go re-read, sec
14:24 < aj> there's "Instead, the taproot annex can be used to add weight to the witness ..." in bip-tapscript; otherwise i've no idea
14:25 < sipa> one idea for the "annex" (but not currently proposed) is that it could be used to add a "extra weight" marker, which would then translate to an additional allowance for example for hypothetical future opcodes that have a much higher cpu cost per byte than existing things
14:25 < sipa> fwiw, it seems that right now, blocks full of sha256, blocks full of stack operations, or blocks full of signature checks remarkably are all very similar in their cpu cost per byte for verifiers
14:26 < luke-jr> sipa: basically, my point is that p2pkh, p2wpkh, and the new taproot equivalent with the same CPU/IO/etc costs should have the same weight, not be tweaked in special-casing ways to reduce it
14:27 < sipa> i don't understand
14:27 < sipa> we're trying to use block space as efficiently as possible
14:27 < sipa> without increasing cpu cost per byte
14:28 < sipa> (i'd argue that if it becomes possible to do the same thing with less bytes, but significantly increase how burdensome it is to validation, that would be a bad thing, but i don't think that's the case)
14:29 < luke-jr> I don't see how that isn't self-contradicting
14:29 < aj> iirc it costs slightly more to send to a taproot address than p2wpkh (because it's a 32B point not a 20B hash) and corresponding less to spend via taproot key path (64B sig, versus 33B key reveal and 72B DER signature), but they average out almost the same in weight
14:29 < luke-jr> what does it mean to "increase efficiency" of block space use, without increasing CPU cost per byte?
14:30 < sipa> luke-jr: if i can perform a payment on chain with fewer bytes, but also reduce the CPU cost needed to verify it, is it justified that the weight also goes down?
14:30 < aj> batch verification decreases the cpu cost per signature, so if that were the only factor more sigs per byte could keep cpu cost stable
14:30 < luke-jr> I seem to recall special-casing where something is omitted if it's a particular value.. but I'm having trouble finding it now
14:31 < luke-jr> sipa: so Taproot in fact uses less CPU time?
14:31 < luke-jr> I would think it uses more
14:31 < sipa> luke-jr: if batch validation is implemented, significantly less
14:31 < luke-jr> isn't that just per transaction, though? so 1 input wouldn't benefit?
14:32 < sipa> you can batch all signatures in a block
14:32 < sipa> or even more
14:32 < luke-jr> hmm
14:33 < sipa> note that batch validation is not the same as aggregation; there is still a signature on chain per logical signature to check; you just have a faster algorithm that can tell you whether all of them are valid or not (which won't tell you which ones are invalid if it fails, but in block validation that's not relevant)
14:33 < aj> luke-jr: SIGHASH_ALL signatures are 64 bytes, versus others being 65 bytes; that's the only case like that that comes to mind
14:33 < luke-jr> can we fix it so segwit/taproot are on the same weight scale as pre-segwit? or would that need to be another BIP? because right now, the weights are too low
14:34 < luke-jr> (this is admittedly a different issue beyond merely not making it worse)
14:34 < luke-jr> aj: that sounds like what I remember; why shouldn't they all be 65?
14:34 < sipa> i don't believe that belongs in the same bip
14:35 < luke-jr> the code would likely be simpler to have 65 bytes for everything
14:36 < luke-jr> and unless I'm mistaken, SIGHASH_ALL vs other SIGHASH don't change actual resource costs
14:36 < aj> sighash_all is slightly easier to calculate (hash is the same for all sighash_all sigs in a tx)
14:36 < aj> err, in an input, except for codesep use
14:36 < sipa> i think it would save maybe 2 lines of code here: https://github.com/sipa/bitcoin/blob/taproot/src/script/interpreter.cpp#L1527L1533
14:37 < sipa> i think there is a fungibility benefit to encouraging a default sighash
14:38 < luke-jr> 4 lines
14:38 < luke-jr>     if (sig.size() != 65) return false;
14:38 < sipa> ok!
14:38 < luke-jr>     uint8_t hashtype = sig.back();
14:38 < luke-jr>     sig.pop_back();
14:40 < luke-jr> I think the fungibility thing is stretching it, but aj may have a point
14:40 -!- arik_ [~arik@c-24-5-126-13.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
14:40 < luke-jr> sipa: did you understand/address my other comments?
14:43 < sipa> the non-overridable branches thing was answered i think in the thread, and is also in the document; you can use a point without known DL as internal key, and the result is something that can provably only be spent using scripts
14:45 < sipa> salting branches shouldn't be needed if you don't reuse pubkeys 
14:46 < luke-jr> what if a branch doesn't have any keys?
14:46 < aj> you can pair it with a branch that's "OP_RETURN <salt>"
14:46 < luke-jr> anyone-can-spend is apparently useful to troll the IRS :P
14:46 < luke-jr> aj: ah, nice idea
14:48 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
14:48 < bitcoin-git> [bitcoin] ch4ot1c closed pull request #16797: scripts: Add convenience script for committing scripted-diffs from a file (master...scripts/commit-script) https://github.com/bitcoin/bitcoin/pull/16797
14:48 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
14:58 -!- marcoagner [~user@2001:8a0:6a53:2e00:1967:22be:ad77:2d5] has quit [Ping timeout: 276 seconds]
15:18 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 264 seconds]
15:22 -!- arik_ [~arik@c-24-5-126-13.hsd1.ca.comcast.net] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz...]
15:24 -!- arik_ [~arik@c-24-5-126-13.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
15:47 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
15:48 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
15:50 -!- shesek` [~shesek@5.22.135.66] has quit [Remote host closed the connection]
15:53 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 268 seconds]
15:55 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
15:57 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
16:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
16:07 < bitcoin-git> [bitcoin] promag opened pull request #17182: 0.19: Revert 14193 to fix 17112 (0.19...2019-10-revert-14193-fix-17112) https://github.com/bitcoin/bitcoin/pull/17182
16:08 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
16:08 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Ping timeout: 240 seconds]
16:13 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-dev
16:14 -!- astro [~astro@gateway/tor-sasl/astro] has quit [Ping timeout: 260 seconds]
16:15 -!- astro [~astro@gateway/tor-sasl/astro] has joined #bitcoin-core-dev
16:24 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 268 seconds]
16:33 < promag> ^ 14963, #16443 and probably others are making the revert hard
16:33 < gribble> https://github.com/bitcoin/bitcoin/issues/16443 | refactor: have CCoins* data managed under CChainState by jamesob . Pull Request #16443 . bitcoin/bitcoin . GitHub
16:34 < promag> lots of annotations were merged
16:34 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
16:35 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
16:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
16:47 -!- ajonas [uid385278@gateway/web/irccloud.com/x-rtsxrcjsnlndomgd] has quit [Quit: Connection closed for inactivity]
16:51 -!- Highway61 [~Thunderbi@199.229.250.86] has quit [Ping timeout: 240 seconds]
17:00 -!- ski1 [~ski@185.103.96.143] has quit []
17:17 -!- romtam [~romtam@195.206.169.238] has joined #bitcoin-core-dev
17:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
17:23 < bitcoin-git> [bitcoin] theStack opened pull request #17183: refactor: test/bench: dedup Build{Crediting,Spending}Transaction() (master...20191018-refactor-deduplicate_build_transaction_functions) https://github.com/bitcoin/bitcoin/pull/17183
17:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
17:28 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 268 seconds]
17:28 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Read error: Connection reset by peer]
17:31 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-dev
17:36 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 240 seconds]
18:00 -!- lightlike [~lightlike@2001:16b8:5710:fb00:4126:5a97:dbec:38cb] has quit [Quit: Leaving]
18:22 -!- emilengler [~emilengle@unaffiliated/emilengler] has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
18:25 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev
18:36 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-dev
18:42 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 250 seconds]
18:43 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev
18:56 < achow101> sipa: was it intended that uncompressed pubkeys in segwit are only non-standard? most documentation say it is consensus mandatory, but looking at the code, and testing it, shows otherwise
18:56 < sipa> achow101: of course it's not intended, but it's the best we could do :)
18:57 < sipa> if there is documentation saying it's consensus invalid it should be fixed
18:57 < sipa> it was an afterthought 
18:58 < achow101> why wasn't it consensus enforced?
18:58 < sipa> because it was too late when we realized it should have been
18:59 < achow101> ah
19:05 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-dev
19:07 -!- felixfoertsch23 [~felixfoer@2001:16b8:50e0:a800:d507:249:7728:4c1] has joined #bitcoin-core-dev
19:07 -!- felixfoertsch [~felixfoer@2001:16b8:5093:fb00:d507:249:7728:4c1] has quit [Ping timeout: 276 seconds]
19:15 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 260 seconds]
19:17 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
19:18 -!- spinza [~spin@102.132.245.16] has quit [Quit: Coyote finally caught up with me...]
19:22 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-dev
19:23 -!- spinza [~spin@102.132.245.16] has joined #bitcoin-core-dev
19:24 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 260 seconds]
19:25 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
19:29 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 276 seconds]
19:47 -!- Highway61 [~Thunderbi@199.229.250.86] has joined #bitcoin-core-dev
19:48 -!- arik_ [~arik@c-24-5-126-13.hsd1.ca.comcast.net] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz...]
19:50 -!- jarthur [~jarthur@2605:6000:1019:4971:817:2890:cafd:8d0e] has joined #bitcoin-core-dev
20:00 -!- romtam [~romtam@195.206.169.238] has quit []
20:08 -!- rabidus [~rabidus@85-23-137-40.bb.dnainternet.fi] has quit [Ping timeout: 265 seconds]
20:15 -!- rabidus [~rabidus@85-23-137-40.bb.dnainternet.fi] has joined #bitcoin-core-dev
20:17 -!- directhex1 [~directhex@141.98.102.235] has joined #bitcoin-core-dev
20:28 < luke-jr> please reopen #12677
20:28 < gribble> https://github.com/bitcoin/bitcoin/issues/12677 | RPC: Add ancestor{count,size,fees} to listunspent output by luke-jr . Pull Request #12677 . bitcoin/bitcoin . GitHub
21:06 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 268 seconds]
21:16 -!- felixfoertsch23 [~felixfoer@2001:16b8:50e0:a800:d507:249:7728:4c1] has quit [Quit: ZNC 1.7.3 - https://znc.in]
21:16 -!- felixfoertsch [~felixfoer@2001:16b8:50e0:a800:216e:5e91:7f9b:ca4d] has joined #bitcoin-core-dev
21:17 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
21:19 -!- Highway61 [~Thunderbi@199.229.250.86] has quit [Remote host closed the connection]
21:19 -!- Highway61 [~Thunderbi@199.229.250.86] has joined #bitcoin-core-dev
21:24 -!- Highway61 [~Thunderbi@199.229.250.86] has quit [Ping timeout: 276 seconds]
21:28 -!- nosss2 [nosss2@gateway/vpn/privateinternetaccess/nosss2] has quit [Remote host closed the connection]
21:29 -!- nosss2 [nosss2@gateway/vpn/privateinternetaccess/nosss2] has joined #bitcoin-core-dev
21:34 -!- nosss2 [nosss2@gateway/vpn/privateinternetaccess/nosss2] has quit [Ping timeout: 265 seconds]
21:43 -!- captjakk [~captjakk@c-24-72-155-6.ni.gigamonster.net] has quit [Remote host closed the connection]
22:10 -!- captjakk [~captjakk@174-16-221-137.hlrn.qwest.net] has joined #bitcoin-core-dev
22:29 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
22:31 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
22:34 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 276 seconds]
22:35 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 276 seconds]
22:53 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
22:55 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 265 seconds]
22:59 -!- Highway61 [~Thunderbi@199.229.250.86] has joined #bitcoin-core-dev
23:00 -!- directhex1 [~directhex@141.98.102.235] has quit []
23:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:14 < bitcoin-git> [bitcoin] hebasto opened pull request #17184: util: Filter out macOS process serial number (master...patch-1) https://github.com/bitcoin/bitcoin/pull/17184
23:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:15 -!- zyga1 [~zyga@184.75.223.195] has joined #bitcoin-core-dev
--- Log closed Fri Oct 18 00:00:37 2019