--- Log opened Thu Jan 24 00:00:29 2019
00:03 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
00:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
00:07 < hebasto> fanquake: thanks
00:09 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection]
00:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 244 seconds]
00:15 -!- _luc_ [~luc@2001:8003:24ae:8900:952a:340a:2ac8:9b7a] has quit [Remote host closed the connection]
00:17 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
00:19 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
00:21 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Ping timeout: 240 seconds]
00:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
00:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
00:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
00:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
00:42 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds]
00:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
00:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
00:47 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
00:48 -!- JackH [~laptop@host86-175-127-233.range86-175.btcentralplus.com] has quit [Ping timeout: 246 seconds]
00:49 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
00:49 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
01:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:03 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
01:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
01:15 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
01:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]
01:29 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
01:32 -!- JackH [~laptop@62.232.170.181] has joined #bitcoin-core-dev
01:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds]
01:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
02:03 -!- kexkey [~kexkey@199.229.249.116] has quit [Read error: Connection reset by peer]
02:18 -!- miknotauro [~miknotaur@187.207.5.246] has quit [Ping timeout: 240 seconds]
02:19 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
02:19 -!- brianhoffman [~brianhoff@pool-72-83-155-130.washdc.fios.verizon.net] has quit [Read error: Connection reset by peer]
02:20 -!- ExtraCrispy [~ExtraCris@gateway/tor-sasl/extracrispy] has joined #bitcoin-core-dev
02:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:43 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has quit [Ping timeout: 252 seconds]
02:44 -!- Apocalyptic [~Apocalypt@unaffiliated/apocalyptic] has joined #bitcoin-core-dev
02:52 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 256 seconds]
02:55 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev
02:59 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
03:08 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
03:19 -!- laurentmt [~Thunderbi@185.94.189.190] has joined #bitcoin-core-dev
03:24 -!- laurentmt [~Thunderbi@185.94.189.190] has quit [Quit: laurentmt]
03:27 -!- laurentmt [~Thunderbi@185.94.189.190] has joined #bitcoin-core-dev
03:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
03:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:52 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
03:52 -!- IZooo [~IzZzoOo@78.192.31.65] has joined #bitcoin-core-dev
03:53 < IZooo> Hello ! 
03:55 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection]
03:56 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev
03:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
03:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
04:25 -!- laurentmt [~Thunderbi@185.94.189.190] has quit [Quit: laurentmt]
04:27 -!- _luc_ [~luc@2001:8003:24ae:8900:10f:f8a1:75c2:f359] has joined #bitcoin-core-dev
04:31 -!- _luc_ [~luc@2001:8003:24ae:8900:10f:f8a1:75c2:f359] has quit [Ping timeout: 240 seconds]
04:42 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]
04:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
05:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
05:15 -!- promag [~promag@145.166.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
05:16 -!- _luc_ [~luc@2001:8003:24ae:8900:70fc:5c02:9936:fb6e] has joined #bitcoin-core-dev
05:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]
05:18 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-khwgychuxykoqkvd] has joined #bitcoin-core-dev
05:18 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/73a6bac9fffa...5eb32d23841b
05:18 < bitcoin-git> bitcoin/master 5a5ea93 David A. Harding: Doc: add information about security to the JSON-RPC doc
05:18 < bitcoin-git> bitcoin/master 5eb32d2 Wladimir J. van der Laan: Merge #15223: Doc: add information about security to the JSON-RPC doc...
05:18 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-khwgychuxykoqkvd] has left #bitcoin-core-dev []
05:19 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-uecumglylwkdxorp] has joined #bitcoin-core-dev
05:19 < bitcoin-git> [bitcoin] laanwj closed pull request #15223: Doc: add information about security to the JSON-RPC doc (master...2019-01-rpc-security) https://github.com/bitcoin/bitcoin/pull/15223
05:19 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-uecumglylwkdxorp] has left #bitcoin-core-dev []
05:21 -!- _luc_ [~luc@2001:8003:24ae:8900:70fc:5c02:9936:fb6e] has quit [Ping timeout: 268 seconds]
05:22 -!- qwert [31c207e0@gateway/web/freenode/ip.49.194.7.224] has joined #bitcoin-core-dev
05:25 < promag> achow101: I'm getting "libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument" in #15225 on startup
05:25 < gribble> https://github.com/bitcoin/bitcoin/issues/15225 | GUI: Change the receive button to respond to keypool state changing by achow101 · Pull Request #15225 · bitcoin/bitcoin · GitHub
05:26 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
05:26 < promag> rebuild does't help
05:26 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev
05:27 < promag> lldb gives "frame #9: 0x000000010033d532 bitcoin-qt`(anonymous namespace)::RNGState::MixExtract(this=0x000000010269af80, out="", num=4335447936, hasher=0x00007ffeefbfc4d8, strong_seed=<unavailable>) at random.cpp:355 [opt]"
05:27 < gribble> https://github.com/bitcoin/bitcoin/issues/9 | Fix for GUI on Macs and latest wxWidgets by gavinandresen · Pull Request #9 · bitcoin/bitcoin · GitHub
05:27 -!- qwert [31c207e0@gateway/web/freenode/ip.49.194.7.224] has quit [Ping timeout: 256 seconds]
05:27 < promag> should clear ccache? :/
05:30 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 245 seconds]
05:34 -!- laurentmt [~Thunderbi@185.94.189.190] has joined #bitcoin-core-dev
05:53 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev
05:55 -!- brianhoffman [~brianhoff@pool-72-83-155-130.washdc.fios.verizon.net] has joined #bitcoin-core-dev
06:24 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
06:25 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-koiklxzxdetosymq] has joined #bitcoin-core-dev
06:25 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5eb32d23841b...72bd4ab867e3
06:25 < bitcoin-git> bitcoin/master a36d97d Suhas Daftuar: Default -whitelistforcerelay to off
06:25 < bitcoin-git> bitcoin/master 72bd4ab Wladimir J. van der Laan: Merge #15193: Default -whitelistforcerelay to off...
06:25 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-koiklxzxdetosymq] has left #bitcoin-core-dev []
06:26 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-kjjotumibjjchcnv] has joined #bitcoin-core-dev
06:26 < bitcoin-git> [bitcoin] laanwj closed pull request #15193: Default -whitelistforcerelay to off (master...2019-01-forcerelayoff) https://github.com/bitcoin/bitcoin/pull/15193
06:26 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-kjjotumibjjchcnv] has left #bitcoin-core-dev []
06:28 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
06:30 -!- DrOlmer [~DrOlmer@unaffiliated/drolmer] has joined #bitcoin-core-dev
06:31 -!- promag [~promag@145.166.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]
06:34 -!- DrOlmer [~DrOlmer@unaffiliated/drolmer] has quit [Ping timeout: 252 seconds]
06:41 -!- fanquake_ [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
06:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
06:44 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Ping timeout: 244 seconds]
06:46 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #bitcoin-core-dev
06:49 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
06:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 244 seconds]
06:52 -!- fanquake_ [~fanquake@unaffiliated/fanquake] has quit []
06:57 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
06:57 < fanquake> wumpus could you block Vant13425, they are spamming at the moment
06:57 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-suraviyjmrxrtcol] has joined #bitcoin-core-dev
06:57 < bitcoin-git> [bitcoin] jnewbery opened pull request #15243: [doc] add notes on release notes (master...release_notes) https://github.com/bitcoin/bitcoin/pull/15243
06:57 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-suraviyjmrxrtcol] has left #bitcoin-core-dev []
07:09 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-mmjnqyiqadqdryrv] has joined #bitcoin-core-dev
07:15 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
07:16 -!- promag [~promag@83.223.251.89] has joined #bitcoin-core-dev
07:19 -!- timothy [tredaelli@redhat/timothy] has quit [Ping timeout: 246 seconds]
07:19 < promag> achow101: sorry, it's not your PR, master fails for me. Looks like the problem was introduced in #14955
07:19 < gribble> https://github.com/bitcoin/bitcoin/issues/14955 | Switch all RNG code to the built-in PRNG by sipa · Pull Request #14955 · bitcoin/bitcoin · GitHub
07:21 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has joined #bitcoin-core-dev
07:22 < sipa> promag: there is already an open PR to fix it
07:22 < sipa> #15223
07:22 < gribble> https://github.com/bitcoin/bitcoin/issues/15223 | Doc: add information about security to the JSON-RPC doc by harding · Pull Request #15223 · bitcoin/bitcoin · GitHub
07:23 < sipa> hmm, no
07:23 < promag> 15233
07:23 < sipa> #15233
07:23 < gribble> https://github.com/bitcoin/bitcoin/issues/15233 | Prevent mutex lock fail even if --enable-debug by AkioNak · Pull Request #15233 · bitcoin/bitcoin · GitHub
07:24 < promag> how come #14955 got merged with this problem?
07:24 < gribble> https://github.com/bitcoin/bitcoin/issues/14955 | Switch all RNG code to the built-in PRNG by sipa · Pull Request #14955 · bitcoin/bitcoin · GitHub
07:25 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit []
07:25 < promag> provoostenator: I think you test on macos?
07:30 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev
07:31 -!- michaels_ [~michaelsd@38.126.31.226] has joined #bitcoin-core-dev
07:34 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Ping timeout: 240 seconds]
07:35 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has quit [Quit: Leaving.]
07:35 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has joined #bitcoin-core-dev
07:40 < sipa> promag: it needs --enable-debug to detect
07:41 < promag> right, I have configure with CPPFLAGS=-DDEBUG_LOCKORDER 
07:42 < provoostenator> promag: yes
07:42 < promag> actually I always have that enabled
07:44 < provoostenator> That's a good one to use next time, yes. Can we make Travis do that as well?
07:44 < promag> it does I think
07:44 < promag> it checks lock order
07:45 < provoostenator> But Travis didn't fail. Is there a test that would catch this?
07:46 < sipa> travis doesn't run osx, does it?
07:47 < promag> not sure, looks like this is macos only?
07:47 < sipa> yes
07:48 < promag> I'll review the fix
07:48 -!- laurentmt [~Thunderbi@185.94.189.190] has quit [Quit: laurentmt]
07:49 < provoostenator> Travis machine 10 cross compiles to bitcoin-x86_64-apple-darwin14, but that only compiles and doesn't run tests (obviously).
07:50 < provoostenator> There's this though: https://docs.travis-ci.com/user/reference/osx/ (never tried it)
07:53 < promag> ok
07:56 < provoostenator> See also #15241
07:56 < gribble> https://github.com/bitcoin/bitcoin/issues/15241 | travis: add --enable-debug macos build by kallewoof · Pull Request #15241 · bitcoin/bitcoin · GitHub
07:57 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
08:07 -!- mistergold [~mistergol@77.243.31.95] has joined #bitcoin-core-dev
08:09 -!- kexkey [~kexkey@199.229.249.116] has joined #bitcoin-core-dev
08:17 -!- promag [~promag@83.223.251.89] has quit [Remote host closed the connection]
08:17 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
08:23 -!- MrPaz [~MrPaz@c-71-57-73-68.hsd1.il.comcast.net] has quit [Ping timeout: 268 seconds]
08:29 -!- promag [~promag@83.223.251.89] has joined #bitcoin-core-dev
08:33 -!- promag [~promag@83.223.251.89] has quit [Ping timeout: 240 seconds]
08:37 -!- miknotauro [~miknotaur@187.207.5.246] has joined #bitcoin-core-dev
08:43 -!- Randolf [~randolf@96.53.47.42] has quit [Quit: Leaving]
09:04 -!- promag [~promag@83.223.251.89] has joined #bitcoin-core-dev
09:05 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has quit [Remote host closed the connection]
09:08 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
09:11 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Client Quit]
09:15 -!- promag [~promag@83.223.251.89] has quit [Remote host closed the connection]
09:17 -!- JackH [~laptop@62.232.170.181] has quit [Ping timeout: 240 seconds]
09:21 -!- sfhi [~sfhi@178.255.154.106] has joined #bitcoin-core-dev
09:21 -!- ThomasLuong [ThomasLuon@gateway/vpn/privateinternetaccess/thomasluong] has joined #bitcoin-core-dev
09:26 -!- promag [~promag@83.223.251.89] has joined #bitcoin-core-dev
09:29 < wumpus> did github stop turning commit ids into links?
09:29 < wumpus> seeing a lot of (ut)ACKs with commit ids that stay plain text, see e.g. https://github.com/bitcoin/bitcoin/pull/15112
09:30 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev
09:32 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has quit [Remote host closed the connection]
09:33 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has joined #bitcoin-core-dev
09:33 -!- trillhc2 [~trillhc@c-71-232-65-53.hsd1.ma.comcast.net] has joined #bitcoin-core-dev
09:34 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 245 seconds]
09:36 -!- trillhc [~trillhc@c-71-232-65-53.hsd1.ma.comcast.net] has quit [Ping timeout: 246 seconds]
09:37 -!- mistergo1d [~mistergol@185.37.26.59] has joined #bitcoin-core-dev
09:38 -!- mistergold [~mistergol@77.243.31.95] has quit [Read error: Connection reset by peer]
09:42 < promag> wumpus: I think that's the case when the commit is garbage
09:43 < promag> and is no longer available
09:43 < promag> there's also the case when 7chars is not enough
09:44 < promag> enough because there's multiple commits with the same 7 initial chars
09:57 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
09:58 -!- miknotauro [~miknotaur@187.207.5.246] has quit [Ping timeout: 240 seconds]
10:00 -!- JackH [~laptop@host86-175-127-233.range86-175.btcentralplus.com] has joined #bitcoin-core-dev
10:00 < wumpus> promag: I'm suddenly seeing it a lot though, did everyone suddenly start mispasting commit ids?
10:01 < wumpus> of course I know that a garbage commit ID won't be turned into a link
10:02 < promag> idk, it must be a gh problem
10:03 -!- sfhi [~sfhi@178.255.154.106] has quit [Read error: Connection reset by peer]
10:05 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
10:10 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-upuarnmvaevucjpu] has joined #bitcoin-core-dev
10:10 < bitcoin-git> [bitcoin] instagibbs opened pull request #15244: gdb attaching to process during tests has non-sudo solution (master...gdb_ptrace) https://github.com/bitcoin/bitcoin/pull/15244
10:10 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-upuarnmvaevucjpu] has left #bitcoin-core-dev []
10:14 -!- promag [~promag@83.223.251.89] has quit [Remote host closed the connection]
10:17 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has joined #bitcoin-core-dev
10:17 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has quit [Changing host]
10:17 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev
10:19 -!- michaels_ [~michaelsd@38.126.31.226] has quit [Ping timeout: 240 seconds]
10:23 -!- harrigan [~harrigan@skynet.skynet.ie] has quit [Ping timeout: 246 seconds]
10:23 -!- harrigan [~harrigan@skynet.skynet.ie] has joined #bitcoin-core-dev
10:31 -!- ThomasLuong [ThomasLuon@gateway/vpn/privateinternetaccess/thomasluong] has quit [Ping timeout: 246 seconds]
10:32 -!- ThomasLuong [~ThomasLuo@170.199.232.138] has joined #bitcoin-core-dev
10:36 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
10:37 -!- mistergold [~mistergol@185.37.26.59] has joined #bitcoin-core-dev
10:40 -!- rex4539 [~rex4539@ppp-2-84-172-204.home.otenet.gr] has quit [Quit: rex4539]
10:40 -!- mistergo1d [~mistergol@185.37.26.59] has quit [Ping timeout: 246 seconds]
10:45 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection]
10:46 -!- rh0nj [~rh0nj@88.99.167.175] has joined #bitcoin-core-dev
10:52 -!- promag [~promag@83.223.251.89] has joined #bitcoin-core-dev
10:53 -!- promag_ [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
10:56 -!- promag [~promag@83.223.251.89] has quit [Ping timeout: 240 seconds]
10:57 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev
10:59 -!- mistergo1d [~mistergol@185.37.26.59] has joined #bitcoin-core-dev
11:00 < achow101> meeting?
11:00 < jnewbery> hi
11:00 < gleb> hi
11:00 < sipa> hi
11:00 < wumpus> #startmeeting
11:00 < lightningbot> Meeting started Thu Jan 24 19:00:54 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:00 < provoostenator> hi
11:01 < moneyball> topic proposed by jnewbery: Chaincode summer residency: looking for (remote) mentors and recommendations for residents
11:01 < sipa> suggested topic: globals and initialization order
11:01 < promag_> hi
11:01 < 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
11:01 < instagibbs> hi
11:01 < meshcollider> hi
11:01 -!- promag_ is now known as promag
11:01 < jamesob> yo
11:02 < gwillen> \o
11:02 < marcinja> hi
11:02 -!- mistergold [~mistergol@185.37.26.59] has quit [Ping timeout: 245 seconds]
11:02 < wumpus> #topic High priority for review
11:03 -!- a__ [43fbc19a@gateway/web/freenode/ip.67.251.193.154] has joined #bitcoin-core-dev
11:03 < wumpus> #11082 #14491 #14711 #14897 #15153 #15226
11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/14491 | Allow descriptor imports with importmulti by MeshCollider · Pull Request #14491 · bitcoin/bitcoin · GitHub
11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/14711 | Remove uses of chainActive and mapBlockIndex in wallet code by ryanofsky · Pull Request #14711 · bitcoin/bitcoin · GitHub
11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/14897 | randomize GETDATA(tx) request order and introduce bias toward outbound by naumenkogs · Pull Request #14897 · bitcoin/bitcoin · GitHub
11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/15153 | gui: Add Open Wallet menu by promag · Pull Request #15153 · bitcoin/bitcoin · GitHub
11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/15226 | Allow creating blank (empty) wallets (alternative) by achow101 · Pull Request #15226 · bitcoin/bitcoin · GitHub
11:03 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
11:03 < wumpus> anything to be added or removed?
11:04 < achow101> can I have #15225 on hi prio?
11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/15225 | GUI: Change the receive button to respond to keypool state changing by achow101 · Pull Request #15225 · bitcoin/bitcoin · GitHub
11:04 < promag> regarding open wallet menu - there are concerns regarding blocking GUI - is this something to avoid or can it be improved in 0.18.1?
11:04 < jamesob> #15118
11:04 < gribble> https://github.com/bitcoin/bitcoin/issues/15118 | Refactor block file logic by jimpo · Pull Request #15118 · bitcoin/bitcoin · GitHub
11:04 < achow101> it's actually a blocker for 15226
11:05 < wumpus> 14711 should be almost mergeable
11:05 < jnewbery> +1 for #15118. It blocks #14121
11:05 < gribble> https://github.com/bitcoin/bitcoin/issues/15118 | Refactor block file logic by jimpo · Pull Request #15118 · bitcoin/bitcoin · GitHub
11:05 < gribble> https://github.com/bitcoin/bitcoin/issues/14121 | Index for BIP 157 block filters by jimpo · Pull Request #14121 · bitcoin/bitcoin · GitHub
11:05 < wumpus> though promag keeps commenting so I'm not sure xD
11:05 < gwillen> I am hoping for movement on #13932 but I think it needs love from achow101 more than review at present
11:05 < gribble> https://github.com/bitcoin/bitcoin/issues/13932 | Additional utility RPCs for PSBT by achow101 · Pull Request #13932 · bitcoin/bitcoin · GitHub
11:05 -!- michaels_ [~michaelsd@38.126.31.226] has joined #bitcoin-core-dev
11:05 < achow101> gwillen: oh yeah, I forgot to update that
11:06 < promag> wumpus: :(
11:06 < gwillen> achow101: lmk if there's any way I can help!
11:07 < wumpus> promag: I don't mean that negatively! if there's issues there's issues no matter *when* you find them, just mean it postpones the merge if there's new review comments
11:07 < wumpus> ok added #15225  #15118
11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/15225 | GUI: Change the receive button to respond to keypool state changing by achow101 · Pull Request #15225 · bitcoin/bitcoin · GitHub
11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/15118 | Refactor block file logic by jimpo · Pull Request #15118 · bitcoin/bitcoin · GitHub
11:08 < jamesob> wumpus: thanks
11:08 < wumpus> let's also try to remove (merge) a few this weke
11:08 < phantomcircuit> hi
11:09 < wumpus> 8 is kind of a lot to have on the list, and closer to the release the focus shifts to the milestone instead of this list
11:09 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Ping timeout: 245 seconds]
11:10 < sdaftuar> #15141 is ready for review again btw
11:10 < wumpus> so 2019-02-01 is string freeze, 2019-02-15 is feature freeze for 0.18
11:10 < gribble> https://github.com/bitcoin/bitcoin/issues/15141 | Rewrite DoS interface between validation and net_processing by sdaftuar · Pull Request #15141 · bitcoin/bitcoin · GitHub
11:10 < sdaftuar> oops
11:10 < sdaftuar> oh, wait i did type that correcly
11:10 < sipa> sdaftuar: cool will review
11:10 < jonasschnelli> hi
11:11 < wumpus> #topic Globals and initialization order (sipa)
11:11 < sipa> hi!
11:11 < sipa> we currently have a bit of a mix in the codebase for dealing with initialization order of globals
11:12 < sipa> some things are explicitly initialized using init functions, called from main/test startup
11:12 < sipa> some things are initialized just using global initializers
11:13 < sipa> and some things are using once/init-on-first-use-block-scoped-statics
11:13 < sipa> and mixing them is pretty fragile
11:14 < wumpus> I prefer explicit initializer functions unless it's simply setting a value, at least it's perfectly clear what the order is in which things get initialized
11:14 < wumpus> which is very important if things depend on each other
11:14 < wumpus> also things running before main() is quite annoying for debugging
11:14 < sipa> the problem is that with explicit initializer functions, things don't work when called from global initializer
11:16 < wumpus> (and things that take significant time to run certainly shouldn't be called from global initializers, as they'll delay showing even, say, the help message, which doesn't need any initialization at all)
11:16 < sipa> and i think we actually had a long-standing problem with the RNG, which was used possibly before being initialized (since #14955 it uses an init-on-first use construction, which should always be fine)
11:16 < gribble> https://github.com/bitcoin/bitcoin/issues/14955 | Switch all RNG code to the built-in PRNG by sipa · Pull Request #14955 · bitcoin/bitcoin · GitHub
11:17 < wumpus> anyhow that's my opinion on it, I'm aware the codebase is quite crazy in that regard, we've had initialation order issues since the first release...
11:17 < promag> sipa: what's your preference?
11:17 < sipa> so i'm getting more and more in favor of using this init-on-first-use construction in more places
11:17 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev
11:17 < wumpus> meh
11:18 < sipa> since it's compatible with everything
11:18 < wumpus> it's hard to reason about
11:18 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
11:18 < jimpo> I also like explicit initialization of non-trivial things
11:18 < wumpus> accidentally using something before something else will suddenly change the initialization order
11:18 < wumpus> instead of just fail
11:18 < wumpus> we've seen that with logging, for example
11:18 < sipa> that's because logging using a global initialized
11:19 < provoostenator> I'm in favor of having fewer globals :-) But otherwise haven't really developed a preference in C++
11:19 < promag> I prefer explicit order initialization
11:19 < wumpus> initializing on first use also doesn't really regard initialization dependencies
11:19 < luke-jr> wumpus: in a bad way? the only time I can think of order mattering is when we're pre-config-files-loaded
11:20 < sipa> wumpus: how so?
11:20 < wumpus> like "we need to have the datadirectory set before writing to it"
11:20 < luke-jr> (thinking RNG specifically)
11:20 < sipa> oh, i'm not really talking about application level things
11:21 < sipa> more things like RNG, logging objects (not actually setting the logfile, which happens later), libsecp, ...
11:21 < sipa> syncronization debugging state
11:21 < wumpus> if it's really only setting a value to a data structure I agree it's different, but if there's extensive work that might depend on other or OS things, it gets hairy fast
11:21 < wumpus> only allocating a data structure on first use is fine...
11:22 < gmaxwell> It's also important to avoid undefined behavior over and above just avoiding doing the wrong thing. 
11:22 < sipa> basically the RNG right now can't use the SHA module, because the RNG is invoked from global constructors (and it works fine with it), and SHA needs explicit initialzation
11:22 < wumpus> but I think we agree that global constructors are bad
11:22 < wumpus> that's one thing :)
11:23 < sipa> so i think there are two solutions to that... avoid global constructors everywhere, or make everything work fine on first use
11:23 < wumpus> (I here mean global constructors as 'runs before main', not the static initializers that run on first use)
11:24 < sipa> wumpus: right
11:24 < sipa> wumpus: so what's your opinion on solving this particular issue?
11:24 < gmaxwell> Or make SHA module's autodetect get resolved by the linker, using the GCC extension that does that. :P
11:25 < gmaxwell> (doesn't address the general question about dependencies between global constructors)
11:25 < wumpus> sipa: so move to initialization on first use or explicit initialization, whatever makes sense in the case, move away from global initializers that do anything more significant than assigning a constant value
11:25 < sipa> we can get rid of all globals whose construction needs randomness, but making the SHA256 code autodetect on first use seems a simpler change
11:25 < wumpus> I really like how you got rid of CInit, for example
11:26 < gmaxwell> The downside of autodetect on first use is that it would make every call to sha256 slightly slower. :(
11:26 < gmaxwell> One way to compensate for that would be make sure that there is a batch sha256 function that does many of them and only does the detection once, and be sure to use it where possible.
11:27 < sipa> gmaxwell: hmm?
11:27 < sipa> i benchmarked it as a 1.8ns slowdown here to use an on-first-use construction
11:27 < gmaxwell> sipa: I assume 'autodetect on first use' means "Check a synchronized variable every time the function is run".
11:27 < sipa> gmaxwell: nope!
11:28 < sipa> it actually compiles to both a synchronized and unsynchronized variable, and in the initialized case, only the latter is checked
11:28 < gmaxwell> Okay, 1.8ns doesn't sound that terrible. What the runtime of the function on that host?
11:28 < wumpus> nice
11:28 < gmaxwell> sipa: how does it know its initialized?
11:29 < wumpus> though this is a compiler implementation specific thing, clang and gcc might not do it the same way?
11:29 < sipa> gmaxwell: it's just a boolean; when the boolean is false, it means it could be initialized or not (to be checked using synchronized primitives), if it is true, it is guaranteed to be initialized
11:30 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
11:30 < sipa> from cppreference.com:If multiple threads attempt to initialize the same static local variable concurrently, the initialization occurs exactly once (similar behavior can be obtained for arbitrary functions with std::call_once).
11:30 < sipa> Note: usual implementations of this feature use variants of the double-checked locking pattern, which reduces runtime overhead for already-initialized local statics to a single non-atomic boolean comparison.
11:30 < wumpus> good to know
11:31 < gmaxwell> in any case, I think that seems an obviously better way to handle it. Residual performance concerns could be handled by my above batching suggestion (which would be a win regardless because of function call overheads).  MOST places where we'd have this concern wouldn't be a big performance bottleneck like sha256 is.
11:31 < wumpus> exactly
11:31 < wumpus> maybe sha256 is just special here
11:31 < wumpus> and we can at least decide for the general case
11:31 < sipa> agree
11:32 < sipa> enough on this topic, i think
11:32 < wumpus> ok!
11:32 < gmaxwell> well I could see the same problem showing up for crc32 and being worse, because 1.8ns would be like a 2x slowdown for it. :P  but otherwise I can't come up with much where a 1.8ns slowdown would matter.
11:32 < wumpus> #topic Chaincode summer residency (jnewbery)
11:32 < luke-jr> could have the calls be pointers that get changed on initialisation (I thought we already did?)
11:32 -!- Krellan [~Krellan@2601:640:4000:a876:c976:2ef:a35b:4458] has quit [Remote host closed the connection]
11:32 < jnewbery> hi
11:33 < wumpus> luke-jr: that means the overhead of an indirect function call every time, that's worse than checking a boolean
11:33 < jnewbery> we're hosting the next iteration of the Chaincode residency this summer
11:33 < jnewbery> it'll be in our new office in Midtown Manhattan
11:33 < jnewbery> details are here: https://residency.chaincode.com/
11:34 < wumpus> great!
11:34 < jnewbery> we'll take care of sourcing residents, paying travel/accommodation/stipend and hosting them in our office
11:34 < sipa> nice!
11:34 < provoostenator> nice!
11:34 < jnewbery> it's 2-3 weeks of seminars followed by 2 months of project work. We're expecting the residents to make really meaningful contributions to Bitcoin Core and other Bitcoin/Lightning projects while they're here
11:35 < jnewbery> I bring this up here because we need help for a couple of things:
11:35 < jnewbery> 1. We (Chaincode) will be doing the heavy lifting for the seminar series and hosting, but we need (remote) mentors for the 2 month project period.
11:36 < kanzure> what are the responsibilities of the mentors
11:36 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev
11:36 < jnewbery> each resident will be paired with a mentor. We're looking for 1 hour per week video calls with the resident to help guide them in their project
11:37 < jnewbery> obviously chaincoders and their peers will be on hand for incidental questions during the week, and the mentor will be providing overall guidance helping with the project
11:37 < meshcollider> Will the peers be chosen based on areas of knowledge
11:37 < instagibbs> jnewbery, what's the action item here? ping you if interested in mentoring?
11:38 < jamesob> oh don't worry instagibbs, we've already signed you up
11:38 < jamesob> ;)
11:38 < jnewbery> We'll try to pair residents with mentors who have overlapping interests obviously
11:38 < jnewbery> instagibbs - I'll be reaching out individually
11:38 < instagibbs> hah
11:38 < instagibbs> ok, so check e-mails DMs 
11:39 < jnewbery> 2. We're looking for recommendations for residents. If you know anyone who wants to immerse themselves in Bitcoin/Lightning over summer and is excited about making a real contribution to the project, please send them our way
11:39 < jnewbery> Adam Jonas is taking the lead on organizing this one
11:39 < jnewbery> So you can ping him or me if you have any questions
11:40 < jnewbery> that's it!
11:40 < wumpus> ok! thanks for organizing this
11:40 < jnewbery> We're really excited about this one. The longer format means we're expecting to have a lot of great contributions from the residents
11:41 < wumpus> hope so!
11:41 < wumpus> any other topics?
11:42 < jnewbery> one reminder: I'd encourage people to use moneyball's #proposedmeetingtopic to propose meeting topics during the week!
11:42 < gmaxwell> Could I nag for review on #14929 ?  it's getting forced to rebase faster than its being reviewed...
11:42 < gribble> https://github.com/bitcoin/bitcoin/issues/14929 | net: Allow connections from misbehavior banned peers by gmaxwell · Pull Request #14929 · bitcoin/bitcoin · GitHub
11:43 < sdaftuar> gmaxwell: yep i'm actually in the middle of re-reviewing so i can re-ack
11:43 < wumpus> #action review #14929
11:43 < sipa> add to high priority?
11:43 < gribble> https://github.com/bitcoin/bitcoin/issues/14929 | net: Allow connections from misbehavior banned peers by gmaxwell · Pull Request #14929 · bitcoin/bitcoin · GitHub
11:43 < wumpus> ok
11:44 < gmaxwell> Thanks.
11:46 < wumpus> that... concludes the meeting, I guess
11:47 < wumpus> #endmeeting
11:47 < lightningbot> Meeting ended Thu Jan 24 19:47:19 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
11:47 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-24-19.00.html
11:47 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-24-19.00.txt
11:47 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-01-24-19.00.log.html
11:48 < achow101> does anyone have an opinion on whether encrypting a blank wallet should generate a seed for it?
11:48 < luke-jr> hmm, it might be nice to have all the security-critical stuff generated at once
11:49 < luke-jr> eg, so people who have a no-RNG system can make the wallet easily on one that has a RNG and then backup/restore it
11:49 < luke-jr> but that may be independent of encryption or not
11:49 < wumpus> is it even sensible
11:50 < wumpus> to encrypt a blank wallet? encryption only protects private data, after all
11:50 < achow101> the only thing I can think of is encrypting a blank wallet and then importing privat ekeys
11:50 < wumpus> ah yes
11:52 < gmaxwell> I like the idea that "if you have a wallet file, you can back that up, and your backup is not likely to be surprise invalidated."
11:52 < gmaxwell> under that thinking: wallets should be born encrypted and also born with their master keys.
11:52 < gmaxwell> If you import things, you invalidate backups, sucks to be you.  At least the import (docs) can warn you of this.
11:53 < gmaxwell> I dunno if "wallet which is blank except for imported keys" is a case we should care much about supporting.
11:54 < gmaxwell> luke-jr: I'd like us to have wallet loading take the high entropy data from a loaded wallet (e.g. encrypted master key, or first key in non-encrypted wallets) and hash that into the RNG state. That would achieve what you want as a side effect.
11:54 < achow101> since I want blank wallets as a stepping stone to born encrypted wallets, I prefer that encrypting would generate the seed
11:55 < gmaxwell> luke-jr: (similarly, we should also be hashing any rpcauth credentials into the RNG state)
11:55 < gmaxwell> I see.
11:55 < achow101> but other people may want blank wallets for other reasons, which is why I ask
11:56 < gmaxwell> achow101: well I don't think it would be terrible to have blank wallets with no keys in them at all. At least they'd be obviously smaller? Long term though we should try to get it so that under normal workflows if there is a file there, thats the file you should be backing up.
11:56 < luke-jr> achow101: consider that some wallets might never have a seed
11:57 < achow101> luke-jr: we don't make non-hd wallets anymore.
11:57 < luke-jr> achow101: I'm thinking watch-JBOK-only
11:58 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving]
12:01 < achow101> luke-jr: right. I think that's the only case to not set a seed when encrypting
12:01 -!- a__ [43fbc19a@gateway/web/freenode/ip.67.251.193.154] has quit [Ping timeout: 256 seconds]
12:01 < luke-jr> well, watch-only means encryption is meaningless
12:01 < luke-jr> so nevermind that case
12:02 < achow101> oh, i thought you meant importing the privkeys
12:02 -!- sc_ [c43410e1@gateway/web/freenode/ip.196.52.16.225] has joined #bitcoin-core-dev
12:02 < luke-jr> I suppose there might be a use case for that
12:02 < achow101> (that's what we were taling about earlier)
12:02 -!- sc_ is now known as Guest55956
12:02 < luke-jr> but that seems roughly equivalent to non-HD wallets which isn't supported
12:05 < gwillen> I mean, it still makes sense to have support for legacy imported non-HD wallets
12:05 < luke-jr> gwillen: sure
12:05 < luke-jr> but the topic is strictly new wallets AFAIK
12:06 < gwillen> in fact, I think in the multiwallet world, it would make sense to split wallets into like (*) normal HD wallets, (*) watchonly wallets, (*) legacy importonly wallet
12:06 < gwillen> *nods*
12:06 < gwillen> but if you're going to import privkeys then you do want a blank empty wallet with no seed and encryption
12:07 < gmaxwell> I don't think we generally want to support that case so much as to special case it.
12:07 < gmaxwell> Having an extra seed and keys you don't use is harmless.
12:07 < gwillen> well, I'm afraid of it leading to "oopses"
12:07 < gmaxwell> (other than making the wallet bigger, but it's already going to be fairly big if you're importing a bunch of keys)
12:08 < luke-jr> gmaxwell: well, you don't want to accidentally use one of the keys
12:08 < gmaxwell> any manual private key handling already leads to oopses, which is why we already strongly discourage it.
12:08 < gwillen> like, when I was testing my new offline signing stuff, it autogenerated a change address using the wallet seed that I didn't want
12:08 < gwillen> and sent my change to it, oops
12:08 < gmaxwell> And exactly what would an imported keys only wallet do?
12:08 < gwillen> which I realized about 10 minutes before doing a live demo and frantically sent it back ;-)
12:08 < gwillen> I mean, it would let you spend from your legacy keys from your old wallet
12:09 < gwillen> although I guess that's messy if you don't spend all at once
12:09 < luke-jr> gmaxwell: if it has no solution, throw an error
12:09 < gwillen> because you still have to handle change _somehow_
12:09 < achow101> gwillen: that implies address reuse, no?
12:09 < gmaxwell> gwillen: right.
12:09 < gmaxwell> It implies: this is just not a supported case.
12:09 < luke-jr> you might have imported a keypool too
12:10 < luke-jr> not sure if it's possible to mark them as such, but we do allow manually specifying change addresses
12:10 < gmaxwell> If you're going to manually specify change addresses, you don't have gwillen's problem.
12:10 < luke-jr> gmaxwell: if you forget to, it's better to get an exception than potentially lose funds
12:12 < achow101> I think the question is really whether this is a case that happens frequently enough that it is something we should support
12:12 < gmaxwell> There are 1001 other wallet features that deserve love, attention, writing, and review...  going through and breaking the design assumption that you can always get a key from a signable wallet just to support a currently unsupported and known risky usage, seems like a really bad idea. Esp when the subject of doing it came up as an excercise in thinking about how some other case is handled, 
12:12 < gmaxwell> rather than someone showing up and saying "it should support this and heres why"
12:12 < achow101> to support it requires adding more parameters to encryptwallet and getting a born encrypted wallet needs another step
12:12 < luke-jr> achow101: I can't think of a good reason to support it
12:13 < luke-jr> any case where it *might* make sense can also do a watch-only wallet and provide private keys to signraw as needed I think
12:15 < achow101> agreed
12:17 < gmaxwell> unrelated, it would be kinda neat if there were a backupwallet rpc that made a watching wallet by playing the keypools arbritarily far forward and then writing out a wallet without private keys.
12:19 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
12:21 < provoostenator> gmaxwell: or just use a descriptor to import whatever you want in a watch-only wallet, requires: #14075
12:21 < gribble> https://github.com/bitcoin/bitcoin/issues/14075 | Import watch only pubkeys to the keypool if private keys are disabled by achow101 · Pull Request #14075 · bitcoin/bitcoin · GitHub
12:23 < gmaxwell> Using a single descriptor forces you to use security toxic non-hardened keys. Plus doing that (using the descriptor at all) violates the principle that directly handling keys is risky and fault prone.
12:23 < gmaxwell> Note that descriptors don't have checksums, a simple typo or copy-paste error can result in your funds blasting off into space. 
12:24 < provoostenator> achow: as for encrypting an empty wallet, easiest might be to just a bool param where user can decide if a seed is added
12:24 < sipa> gmaxwell: the idea is for descriptor wallets to contained cached pre-expanded public keys
12:25 < provoostenator> gmaxwell: you could use hardened derivation too if you include a private key in the descriptor (which is not saved)
12:25 < provoostenator> (and that currently doesn't work probably)
12:25 < sipa> so you can use hardened bip32 keys as descriptor; they need access to the private key to derive, but not to otherwise use
12:26 < gmaxwell> provoostenator: fair on that point, doesn't address my second point... and that also means you're likely leaving private keys in your shell history.
12:26 < gwillen> hrm, why do descriptors _not_ have checksums?
12:26 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection]
12:27 < gwillen> given their intended uses it seems like maybe they should
12:27 < gmaxwell> because they weren't intended to be some general construct for transporting keys around?
12:27 < sipa> gwillen: they're human editable
12:27 < provoostenator> gmaxwell: assuming the private keys are on a different device,  that device could return an array of descriptors, one for each pubkey, in import format.
12:27 < provoostenator> As for checksums: that sounds solveable.
12:27 < gmaxwell> provoostenator: sweet, then you get a multiplicative blowup in possibilities to corrupt the data and cause funds to go off into space.
12:28 < sipa> gwillen: inside the wallet we could store them with a checksum, or even have a more efficient binary encoding
12:28 < gwillen> *nods*
12:28 < sipa> which would still be human accessible for transport, if they're intended to be treated as a black box
12:28 < gmaxwell> sipa: but its when humans touch them that they're most likely to get corrupted.
12:29 < gmaxwell> (as the now hundreds of millions lost in eth land due to corrupted addresses attest to...)
12:29 < gmaxwell> (humans and application boundaries)
12:30 < gmaxwell> The original descriptor work was largely wallet internal... it's mostly later efforts that have been turning them into a general key import/export thing.  This seems ill-advised to me.
12:30 < provoostenator> So we need something to replace xpub that has a better checksum? Or does that still data corruption risk? Because something goes wrong inside of Bitcoin Core during the import?
12:31 < gmaxwell> xpub actually has a checksum, it's sufficient, as it was intended for use as an address.
12:32 < provoostenator> In #14912 I'm using xpubs all the way. The HWI tool (achow101) gets xpub(s) from the device.
12:32 < gribble> https://github.com/bitcoin/bitcoin/issues/14912 | [WIP] External signer support (e.g. hardware wallet) by Sjors · Pull Request #14912 · bitcoin/bitcoin · GitHub
12:32 < provoostenator> (though I'm not sure _how_ they are obtained from the device, that's probably worth double checking)
12:33 < gmaxwell> Corruption inside bitcoin is also a concern, but a strictly less serious one than corruption by humans or across application boundaries. 
12:33 < provoostenator> If the device spits out a normal public key and the script converts it to an xpub then there's no point.
12:33 < achow101> provoostenator: it depends on the device. some give xpubs, other give pubkeys + chaincode which then become xpubs
12:33 < gmaxwell> For HWI you might want to consider an enrolling process that gets a signed message with one of the imported watch keys, to prove that the device can sign for the keys you're importing.
12:33 < provoostenator> Also there's a feature to show an address on the device display. We could make that mandatory for the receive address functionality to be on the safe side.
12:34 < gmaxwell> Which is analogous to the process bitcoin uses internally when generating keys: it signs a message and verifies, to make sure that the generated address/key actually work.
12:34 < achow101> gmaxwell: currently we have a displayaddress command where the address for a given derivation path is shown on the device's screen (if it has one). you can then compare that to the address the wallet gives you for that path
12:35 < provoostenator> Though perhaps betetr is to 1) import using xpubs and then 2) checking all imported keys with a call to the device
12:35 < gmaxwell> achow101: thats good, but I think thats more effective at checking for correct pairing than checking for corruption.
12:36 < gmaxwell> getting the device to sign something that you can verify is probably the gold standard for corruption checking. I'm not sure about how the devices work, but is it currently possible to import a device that you don't know the pin for, thus cannot actually sign with?
12:37 < provoostenator> You can always forget the pin and lose your backup. But the normal flow is that you unlock the device with the pin before it's willing to give your computer any pubkeys.
12:37 -!- mistergold [~mistergol@185.37.26.59] has joined #bitcoin-core-dev
12:37 < achow101> i think for all devices you need the pin/passphrase to do anything with it
12:38 < provoostenator> Capabilities vary per deivce, see this table: https://github.com/achow101/HWI#device-support
12:39 < gmaxwell> Okay, thats useful. I'm not sure if there are other ways that you could export keys but turn out not to be able to sign, except a device fault.
12:39 < provoostenator> Ideally we'd ask the device to sign something to prove it really has the keys. I don't know if devices can do that though, especially without user interaction.
12:39 < gmaxwell> ISTM that it wouldn't be too hard for the enrollment process though to ask the device to sign a message.. you're user interacting on the import to enter the pin in any case, no?
12:39 < achow101> signing anything requires user interaction
12:40 < achow101> otherwise it would be a huge security hole
12:40 < gmaxwell> But so does the import?
12:40 -!- Randolf [~randolf@96.53.47.42] has quit [Quit: Leaving]
12:40 < provoostenator> gmaxwell: the problem is that the device probably only signs 1 thing at a time, so checking 1000 addresses would be tedious.
12:40 < gmaxwell> I don't think it's necessary to check all the addresses.
12:40 < provoostenator> So then the next best thing is essentially just importing again and double checking.
12:40 < gmaxwell> But it's a big gain to check at least one.
12:41 < gmaxwell> provoostenator: importing again doesn't tell you that the device actually can sign, however.
12:41 -!- mistergo1d [~mistergol@185.37.26.59] has quit [Ping timeout: 250 seconds]
12:41 < achow101> for implementation with core, you could definitely make it import then sign a message
12:42 < achow101> right now where using HWI is manual, you do that manually
12:42 < gmaxwell> So for example, imagine a device doing public derrivation, botches the generation of the public key, and it caches that value (since its slow I bet all implementations store it).  Any number of imports would give keys, they'd all look fine, but the device would fail to be able to sign for any of its keys.
12:43 < provoostenator> I suspect most devices don't cache public keys, and only store the seed. So if they can derive a valid address they can sign it.
12:43 < gmaxwell> With public derrivation in use, I can't think of any likely issue where it could sign for one key but not another.
12:43 < provoostenator> (until they can't, which is where backups become important)
12:44 < gmaxwell> If they don't cache the master pubkey, then indeed multiple imports would be different under that proposed failure mode.
12:44 < achow101> I don't think they cache the pubkeys, but that could change at any time and be different between devices
12:44 < gmaxwell> Though a 'also try to get a signed message on import' would catch faults in both implementations.
12:45 < achow101> deriving multiple keys with just different indexes is slow as fuck on all devices
12:45 < gmaxwell> Basically getting a signature is a fully general test to make sure signing works.
12:45 < gmaxwell> achow101: I was thinking they'd cache the master, not the child keys. but who knows, as you note it could change at any time.
12:45 < provoostenator> To the degree cache exists, it might also be ephemeral, so in that case asking the user to unplug and replug, might help.
12:45 < provoostenator> But this all varies per device. I agree signing would be better.
12:46 < achow101> gmaxwell: they all require hardened derivation at some point IIRC, so caching the master wouldn't be particularly helpful
12:46 < provoostenator> But devices don't like having code that can sign arbitrary stuff, for risk of an attacking abusing that.
12:46 < gmaxwell> right. Well we can only go so far too. :)  But the standard we've set internally to bitcoin core is sign-after-generate.
12:46 < provoostenator> (sign arbitrary stuff without user approving, and checking all the details)
12:47 < gmaxwell> At enrollment time, a user approving one signature seems reasonsable.
12:47 < provoostenator> "internally to bitcoin core is sign-after-generate" - I didn't know we did that, that seems smart.
12:47 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has quit [Quit: Leaving]
12:48 < gmaxwell> It's a response to a real failure-- in other wallet software a few years back-- that resulted in an extreme amount funds loss (that unfortunately is non-public).
12:48 < provoostenator> Even devices that don't have an official sign message feature, Bitcoin Core could just have it sign a fake transaction.
12:48 < gmaxwell> Indeed.
12:48 < provoostenator> (provably fake ideally)
12:48 < gmaxwell> 0 value, locktimed almost-forever far in the future would be nice.
12:49 < provoostenator> Or with a relative lock time after the heath death of the universe.
12:49 < gmaxwell> I think it would be nice to even do more than what Bitcoin Core currently does.. but priorities,  the sign/verify after generate is a pretty general protection at least.
12:49 < achow101> provoostenator: that's actually largely not possible for most devices since they verify inputs
12:49 < achow101> oh, actually if you claim it's segwit that's fine
12:49 < provoostenator> Ah that pesky Segwit thing, but they still sign legacy transactions...
12:50 < provoostenator> Or you mean the other way around?
12:50 < achow101> sign a segwit input. they don't verify those inputs
12:51 < provoostenator> Ah ok, so for legacy they insist on seeing an entire transaction with inputs? That does get tedious. 
12:51 < achow101> yeah
12:51 < provoostenator> But that could also be fake right?
12:51 < provoostenator> Spending non-existing coins.
12:51 < achow101> sure, but that's more work
12:51 < provoostenator> Indeed
12:56 < provoostenator> So I'll probably add something to my PR in the signerfetchkeys  RPC method, which imports the keys, to call sign message on the device with one of the keys, and then check the result.
12:57 < provoostenator> Although there's no way to undo an import, at the RPC method would fail with a giant error telling the user to delete their new wallet and retry the import. 
12:57 < provoostenator> *, at least the RPC...
12:59 -!- Guest55956 [c43410e1@gateway/web/freenode/ip.196.52.16.225] has quit [Quit: Page closed]
13:07 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Ping timeout: 246 seconds]
13:12 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
13:13 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
13:29 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 252 seconds]
13:29 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-udmjlzfqdxokktiy] has joined #bitcoin-core-dev
13:29 < bitcoin-git> [bitcoin] instagibbs opened pull request #15245: remove deprecated mentions of signrawtransaction from fundraw help (master...fundraw_signraw) https://github.com/bitcoin/bitcoin/pull/15245
13:29 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-udmjlzfqdxokktiy] has left #bitcoin-core-dev []
13:32 -!- mistergo1d [~mistergol@185.37.26.59] has joined #bitcoin-core-dev
13:36 -!- mistergold [~mistergol@185.37.26.59] has quit [Ping timeout: 250 seconds]
13:38 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
13:41 -!- IZooo [~IzZzoOo@78.192.31.65] has quit [Ping timeout: 250 seconds]
13:41 -!- IzoooO [~IzZzoOo@78.192.31.65] has joined #bitcoin-core-dev
13:42 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 245 seconds]
13:45 -!- mistergold [~mistergol@185.37.26.59] has joined #bitcoin-core-dev
13:49 -!- mistergo1d [~mistergol@185.37.26.59] has quit [Ping timeout: 250 seconds]
13:57 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-mmjnqyiqadqdryrv] has quit [Quit: Connection closed for inactivity]
14:07 -!- zivl [~zivl@unaffiliated/zivl] has joined #bitcoin-core-dev
14:09 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ehhwzoytoomrwspf] has joined #bitcoin-core-dev
14:09 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #15246: qa: Add tests for invalid message headers (master...Mf1901-qaMsgHeader) https://github.com/bitcoin/bitcoin/pull/15246
14:09 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ehhwzoytoomrwspf] has left #bitcoin-core-dev []
14:09 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
14:10 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev
14:14 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 240 seconds]
14:29 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
14:39 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
14:46 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
14:54 -!- harrigan [~harrigan@skynet.skynet.ie] has quit [Read error: Connection timed out]
14:54 -!- harrigan [~harrigan@skynet.skynet.ie] has joined #bitcoin-core-dev
15:00 -!- mistergo1d [~mistergol@185.37.26.59] has joined #bitcoin-core-dev
15:03 -!- mistergold [~mistergol@185.37.26.59] has quit [Ping timeout: 246 seconds]
15:25 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
15:26 < meshcollider> sipa: I've been thinking about your comment here: https://github.com/bitcoin/bitcoin/pull/14491#discussion_r247192015
15:26 < meshcollider> current behaviour is that all pubkeys are added as watchonly if theyre provided in the pubkeys field of importmulti, even if they appear only in subscripts
15:27 < meshcollider> do we want to keep that behaviuor?
15:29 < sipa> meshcollider: you can only specify pubkeys for importmulti when they're actually used as pubkey hashes
15:29 < sipa> right?
15:29 < sipa> and not for example a pubkey in a multisig
15:29 < meshcollider> yeah but if you use pubkey hashes in a P2SH script is it intentionally that the pubkey itself becomes watched
15:29 < sipa> sure
15:29 < sipa> that's ok
15:29 < meshcollider> ok
15:30 < sipa> (and inevitable for now)
15:30 < sipa> well, it's not ok - but it isn't changing policy
15:30 < sipa> if you want to watch a P2WPKH you shouldn't need to also watch the corresponding P2PK and P2PKH, but for now that's inevitable
15:30 < meshcollider> right
15:30 < sipa> however, if you're able to spend the P2WPKH, you're also able to spend the P2PK/P2PKH
15:31 < sipa> this is not the case for multisig; if you want to watch the multisig, you shouldn't also watch P2PKH for the keys in it
15:34 < sipa> does that make sense?
15:34 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Quit: WeeChat 2.3]
15:36 < meshcollider> yes
15:36 < meshcollider> I just wanted to check the current behaviour was correct
15:37 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 240 seconds]
15:44 -!- miknotauro [~miknotaur@187.207.5.246] has joined #bitcoin-core-dev
15:45 -!- mn9495 [~nodebot@172.96.165.50] has joined #bitcoin-core-dev
15:45 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-janrvlionpxjmews] has joined #bitcoin-core-dev
15:45 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #15247: qa: Use wallet to retrieve raw transactions (master...Mf1901-qaWalletRaw) https://github.com/bitcoin/bitcoin/pull/15247
15:45 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-janrvlionpxjmews] has left #bitcoin-core-dev []
15:46 -!- mn9495 [~nodebot@172.96.165.50] has quit [Remote host closed the connection]
15:47 -!- mn949588 [~nodebot@172.96.165.50] has joined #bitcoin-core-dev
15:56 -!- mn949588 [~nodebot@172.96.165.50] has quit [Remote host closed the connection]
15:56 -!- mn949588 [~nodebot@172.96.165.50] has joined #bitcoin-core-dev
15:57 -!- mistergold [~mistergol@185.37.26.59] has joined #bitcoin-core-dev
16:01 -!- mistergo1d [~mistergol@185.37.26.59] has quit [Ping timeout: 250 seconds]
16:11 -!- mn9495881 [~nodebot@172.96.165.50] has joined #bitcoin-core-dev
16:12 -!- miknotauro [~miknotaur@187.207.5.246] has quit [Ping timeout: 240 seconds]
16:15 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
16:24 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds]
16:27 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
16:29 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection]
16:31 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has joined #bitcoin-core-dev
16:38 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
16:43 -!- mistergold [~mistergol@185.37.26.59] has quit [Quit: leaving]
16:43 -!- mistergold [~mistergol@185.37.26.59] has joined #bitcoin-core-dev
16:50 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
16:54 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ofxxgjxleyieqptq] has joined #bitcoin-core-dev
16:54 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #15248: rpc: Compile on GCC4.8 (master...Mf1901-rpcCompileGCC48) https://github.com/bitcoin/bitcoin/pull/15248
16:54 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ofxxgjxleyieqptq] has left #bitcoin-core-dev []
16:54 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
17:00 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-qnnuysdwuvthzaeh] has joined #bitcoin-core-dev
17:00 < bitcoin-git> [bitcoin] Empact opened pull request #15249: Docs: Update python docs to reflect that wildcard imports are disallowed (master...wildcard-imports-doc) https://github.com/bitcoin/bitcoin/pull/15249
17:00 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-qnnuysdwuvthzaeh] has left #bitcoin-core-dev []
17:00 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
17:05 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Ping timeout: 244 seconds]
17:05 -!- IzoooO [~IzZzoOo@78.192.31.65] has quit [Quit: Leaving]
17:07 -!- cyber55 [~cyber55@unaffiliated/cyber55] has joined #bitcoin-core-dev
17:16 -!- michaels_ [~michaelsd@38.126.31.226] has quit [Remote host closed the connection]
17:18 -!- mistergo1d [~mistergol@185.37.26.59] has joined #bitcoin-core-dev
17:18 -!- ThomasLuong [~ThomasLuo@170.199.232.138] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
17:21 -!- mistergold [~mistergol@185.37.26.59] has quit [Ping timeout: 240 seconds]
17:26 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
17:28 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 245 seconds]
17:28 -!- justan0theruser is now known as justanotheruser
17:32 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 268 seconds]
17:33 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
17:36 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev
17:37 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Ping timeout: 246 seconds]
17:40 -!- jgb [4672c5e2@gateway/web/freenode/ip.70.114.197.226] has joined #bitcoin-core-dev
17:40 -!- jgb is now known as Guest29703
17:41 -!- Guest29703 [4672c5e2@gateway/web/freenode/ip.70.114.197.226] has quit [Client Quit]
17:53 -!- mistergold [~mistergol@185.37.26.59] has joined #bitcoin-core-dev
17:56 -!- mistergo1d [~mistergol@185.37.26.59] has quit [Ping timeout: 240 seconds]
18:00 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 256 seconds]
18:06 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
18:11 -!- ThomasLuong [~ThomasLuo@c-71-193-183-116.hsd1.or.comcast.net] has joined #bitcoin-core-dev
18:13 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev
18:16 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
18:34 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
18:38 -!- mistergo1d [~mistergol@185.37.26.59] has joined #bitcoin-core-dev
18:41 -!- mistergold [~mistergol@185.37.26.59] has quit [Ping timeout: 245 seconds]
18:44 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-kteduyqbapuidaqi] has joined #bitcoin-core-dev
18:44 < bitcoin-git> [bitcoin] sipa opened pull request #15250: Use RdSeed when available, and reduce RdRand load (master...201901_rdseed) https://github.com/bitcoin/bitcoin/pull/15250
18:44 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-kteduyqbapuidaqi] has left #bitcoin-core-dev []
19:09 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
19:14 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has quit [Ping timeout: 240 seconds]
19:44 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-hnqcgutxltddilhk] has joined #bitcoin-core-dev
19:44 < bitcoin-git> [bitcoin] fanquake opened pull request #15251: [0.17] doc: Remove errant paste from walletcreatefundedpsbt for nLocktime replaceable (0.17...017-backport-15213) https://github.com/bitcoin/bitcoin/pull/15251
19:44 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-hnqcgutxltddilhk] has left #bitcoin-core-dev []
19:56 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-qdfbqdhnherktlmp] has joined #bitcoin-core-dev
19:56 < bitcoin-git> [bitcoin] fanquake opened pull request #15252: [0.17] Backport: Update zmq to 4.3.1 (0.17...017-backport-15188) https://github.com/bitcoin/bitcoin/pull/15252
19:56 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-qdfbqdhnherktlmp] has left #bitcoin-core-dev []
20:05 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-dqdpjdnkiscnplke] has joined #bitcoin-core-dev
20:05 < bitcoin-git> [bitcoin] Empact opened pull request #15253: Net: Consistently log outgoing INV messages (master...inv-log) https://github.com/bitcoin/bitcoin/pull/15253
20:05 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-dqdpjdnkiscnplke] has left #bitcoin-core-dev []
20:08 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-hzxojcsdmlrmwxvf] has joined #bitcoin-core-dev
20:08 < bitcoin-git> [bitcoin] Empact opened pull request #15254: Trivial: fixup a few doxygen comments (master...doxygen-comments) https://github.com/bitcoin/bitcoin/pull/15254
20:08 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-hzxojcsdmlrmwxvf] has left #bitcoin-core-dev []
20:26 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-qdycoqogvhjfnmmd] has joined #bitcoin-core-dev
20:26 < bitcoin-git> [bitcoin] Empact closed pull request #15231: Drop defunct Windows compat fixes (master...ai-addrconfig) https://github.com/bitcoin/bitcoin/pull/15231
20:26 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-qdycoqogvhjfnmmd] has left #bitcoin-core-dev []
20:31 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-lnzyzhecknhcyoyg] has joined #bitcoin-core-dev
20:31 < bitcoin-git> [bitcoin] gkrizek opened pull request #15255: [tests] Remove travis_wait from lint script (master...remove-travis_wait) https://github.com/bitcoin/bitcoin/pull/15255
20:31 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-lnzyzhecknhcyoyg] has left #bitcoin-core-dev []
21:07 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection]
21:08 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev
21:35 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
21:37 -!- mistergold [~mistergol@185.37.27.234] has joined #bitcoin-core-dev
21:37 < jonasschnelli> Is there another reason then complexity that the script descriptors do not have a range specifier? Like wpkh(xpub6DJ2dNUysrn5Vt36jH2KLBT2i1auw1tTSSomg8PhqNiUtx8QX2SvC9nrHu81fT41fvDUnhMjEzQgXnQjKEu3oaqMSzhSrHMxyyoEAmUHQbY/0/*[100-200])?
21:38 -!- mistergo1d [~mistergol@185.37.26.59] has quit [Read error: Connection reset by peer]
21:39 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Ping timeout: 245 seconds]
21:41 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]
21:41 < sipa> jonasschnelli: yes, not all places where descriptors are useful require a range
21:42 < sipa> specifically, a wallet doesn't, as it can automatically extend the ranges
21:42 < jonasschnelli> sipa: but it could be an optional element that may be ignored by the application logic
21:42 < jonasschnelli> sipa: say I want to import p2wpkh script from an xpub from 100 to 200
21:42 < sipa> then you need a record with that descriptor, and that range
21:43 < sipa> there is other metadata you need that has no place in a desceiptor
21:43 < sipa> like whether or not to treat it as change
21:43 < sipa> or what hw device is associated with it
21:43 < jonasschnelli> Yes. That is a point.
21:58 -!- mistergo1d [~mistergol@185.37.27.234] has joined #bitcoin-core-dev
22:00 -!- _luc_ [~luc@2001:8003:24ae:8900:500e:a3a3:82f2:c063] has joined #bitcoin-core-dev
22:01 -!- mistergold [~mistergol@185.37.27.234] has quit [Ping timeout: 240 seconds]
22:01 -!- _luc_ [~luc@2001:8003:24ae:8900:500e:a3a3:82f2:c063] has quit [Client Quit]
22:01 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
22:12 -!- mistergo1d [~mistergol@185.37.27.234] has quit [Read error: Connection reset by peer]
22:14 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-noggypxclcbaddam] has joined #bitcoin-core-dev
22:14 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/72bd4ab867e3...d14ef5721ffc
22:14 < bitcoin-git> bitcoin/master b09dab0 Akio Nakamura: Prevent mutex lock fail even if --enable-debug...
22:14 < bitcoin-git> bitcoin/master d14ef57 MarcoFalke: Merge #15233: Prevent mutex lock fail even if --enable-debug...
22:14 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-noggypxclcbaddam] has left #bitcoin-core-dev []
22:14 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
22:15 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-pzygjshxploqqtkq] has joined #bitcoin-core-dev
22:15 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #15233: Prevent mutex lock fail even if --enable-debug (master...fix_mutex_lock_fail) https://github.com/bitcoin/bitcoin/pull/15233
22:15 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-pzygjshxploqqtkq] has left #bitcoin-core-dev []
22:26 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-izrizoxosgqeebse] has joined #bitcoin-core-dev
22:26 < bitcoin-git> [bitcoin] kallewoof closed pull request #15241: travis: add --enable-debug macos build (master...travis-enable-debug-macos) https://github.com/bitcoin/bitcoin/pull/15241
22:26 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-izrizoxosgqeebse] has left #bitcoin-core-dev []
22:26 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #bitcoin-core-dev
22:28 -!- cyber55 [~cyber55@unaffiliated/cyber55] has quit [Read error: Connection reset by peer]
22:29 -!- cyber55 [~cyber55@unaffiliated/cyber55] has joined #bitcoin-core-dev
22:33 < kallewoof> looks like adding 'osx' as an os is possible in travis (but would result in 2* the number of builds, if I understand... and there is a bunch of docker stuff in there now that wasn't there when I fiddled last..)
22:37 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
22:42 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
22:48 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
22:52 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
22:52 < sipa> kallewoof: ideally we'd be able to test the linux cross-compiled macos binaries... but that's tricky as it means tranferrings builds from one run to another
22:55 < jonasschnelli> Maybe as a starter just run one build (wallet + QT) on nativ travis osx and run the tests?
22:55 -!- miknotauro [~miknotaur@187.207.5.246] has joined #bitcoin-core-dev
22:56 < jonasschnelli> Running the cross compiled macos binaries would indeed be great... 
22:57 < jonasschnelli> But since macOS is very likely non apple nativ and even if – its a form of a BSD, we could eventually use the same cross compile toolchain used under linux to somehow emulate the cross compile process and run the test
22:58 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
23:01 < sipa> what does "since macos is very likely non apple native" mean?
23:01 < jonasschnelli> the travis macOS is probably an emulated macOS... not a Apple native... probably some sort of Hackintosh
23:02 < jonasschnelli> the test results are eventually not directly identical... but I may be wrong.
23:02 < kallewoof> i think they are running on an actual macOS actually.. "Travis CI uses macOS 10.13 and Xcode 9.4.1 by default" (https://docs.travis-ci.com/user/reference/osx/)
23:02 < jonasschnelli> AFAIK Apple (by the TOC) does not allow virtualization of its macOS on non mac hardware ... and I don't expect that travis has a bunch of iMac laying around
23:03 < jonasschnelli> kallewoof: Yeah. I have read this... but I wonder how they do it
23:03 < jonasschnelli> macOS runs only on mac
23:04 < jonasschnelli> expect you modify it in a pretty nasty way
23:04 < jonasschnelli> (which I what makes me say the test results may not be completely representative)
23:04 < sipa> they may well have negotiated a license agreement with apple
23:05 < jonasschnelli> could be... but unlikely
23:05 < jonasschnelli> But they maybe have a couple of mac pros or so running those jobs
23:05 < echeveria> jonasschnelli: it’s not modified much actually.
23:05 < jonasschnelli> AFAIK there are no drivers for non mac hardware, etc.
23:06 < jonasschnelli> echeveria: what means "not much"? :)
23:06 < echeveria> jonasschnelli: there’s a kernel module, DONTSTEALMACOS.kext, and other than that it’s just driver support mostly.
23:07 < echeveria> most services just virtualize OS X on a farm of Mac Minis anyway, which doesn’t violate the license and sort of fits into a data center.
23:07 < jonasschnelli> Yeah. I heard about this. But I guess not very efficient...
23:07 < jonasschnelli> Mac Mini is probably the nightmare of a server data center admin...
23:08 < sipa> it looks like they run on actual mac hardware
23:08 < echeveria> they run mostly alright for this sort of target. I know a developer that has a dedicated Mac Mini build server for their binary distribution in a similar way to bitcoin core.
23:09 < echeveria> similar to Travis, building Bitcoin Core, I men’s.
23:09 < jonasschnelli> Good to know...
23:09 < echeveria> mean.
23:09 < jonasschnelli> however, a travis macOS job would probably be a good thing...
23:10 < sipa> agree.
23:10 < jonasschnelli> Curious to know if you can run the GUI process and take a screenshot...
23:18 -!- ThomasLuong [~ThomasLuo@c-71-193-183-116.hsd1.or.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
23:23 -!- trillhc3 [~trillhc@c-71-232-65-53.hsd1.ma.comcast.net] has joined #bitcoin-core-dev
23:23 -!- trillhc2 [~trillhc@c-71-232-65-53.hsd1.ma.comcast.net] has quit [Read error: Connection reset by peer]
23:31 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-bolzsvcovofgyglc] has joined #bitcoin-core-dev
23:31 < bitcoin-git> [bitcoin] Empact opened pull request #15257: Scripts and tools: Bump flake8 to 3.6.0 (master...flake-36) https://github.com/bitcoin/bitcoin/pull/15257
23:31 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-bolzsvcovofgyglc] has left #bitcoin-core-dev []
23:47 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-mwiaurdrgsvbukao] has joined #bitcoin-core-dev
23:47 < bitcoin-git> [bitcoin] Empact opened pull request #15258: Scripts and tools: Fix devtools/copyright_header.py to always honor exclusions (master...copyright-header-abs) https://github.com/bitcoin/bitcoin/pull/15258
23:47 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-mwiaurdrgsvbukao] has left #bitcoin-core-dev []
--- Log closed Fri Jan 25 00:00:30 2019