--- Log opened Thu Jul 19 00:00:15 2018
00:02 -!- nmnkgl [uid306870@gateway/web/irccloud.com/x-qtontbebeybvvyng] has joined #bitcoin-core-dev
00:03 < harding> sipa: Hmm.  (Looks it up myself.)  Ok, yeah.  This quote seems like a good way to remember it: "way to remember: '~' is "fuzzy" or "approximate" (i.e., you only get the first parent) while '^' is precise (so goes through every single commit)."
00:06 -!- shesek [~shesek@bzq-84-110-60-161.red.bezeqint.net] has joined #bitcoin-core-dev
00:06 -!- shesek [~shesek@bzq-84-110-60-161.red.bezeqint.net] has quit [Changing host]
00:06 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
00:23 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
00:26 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
00:32 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 276 seconds]
00:42 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]
00:43 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
00:59 -!- Krellan [~Krellan@2601:640:4000:9258:e863:a2a8:8e:4f75] has quit [Ping timeout: 276 seconds]
01:09 < bitcoin-git> [bitcoin] AkioNak opened pull request #13711: [bench] Add benchmark for unserialize prevector (master...add_bench_unserialize) https://github.com/bitcoin/bitcoin/pull/13711
01:13 -!- unixb0y [~unixb0y@p2E555F29.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
01:18 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
01:20 -!- farmerwampum [~farmerwam@88.202.178.98] has quit [Ping timeout: 240 seconds]
01:22 -!- meshcollider_ [uid246294@gateway/web/irccloud.com/x-nyqiggosftdeoevt] has quit [Quit: Connection closed for inactivity]
01:25 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
01:33 < bitcoin-git> [bitcoin] practicalswift opened pull request #13712: wallet: Add error handling. Check return value of ParseUInt32(...) in… (master...check-ParseUInt32-return-value) https://github.com/bitcoin/bitcoin/pull/13712
01:38 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
01:47 -!- booyah [~bb@193.25.1.157] has joined #bitcoin-core-dev
01:49 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has joined #bitcoin-core-dev
01:49 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]
01:53 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
01:53 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has quit [Ping timeout: 240 seconds]
01:54 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]
02:02 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
02:06 < provoostenator> I just had a node (on crappy hardware) complain "ERROR: ConnectBlock: CheckQueue failed" and "InvalidChainFound: invalid block=" on a block that's valid. It then just sat there complaining that its peers were giving it invalid tips. 
02:06 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #13713: Ignore new blocks when -stopatheight target has been reached (master...2018/07/stopatheight) https://github.com/bitcoin/bitcoin/pull/13713
02:06 < provoostenator> reconsiderblock did the trick and now it's happy again
02:21 < provoostenator> For about 30 blocks, rinse and repeat. This probably falls under "there's no generic way to deal with crappy hardware". Maybe just recommend a virtual RAID for indexes and chainstate dirs :-)
02:21 -!- narodnik [~kk@92.59.59.28] has joined #bitcoin-core-dev
02:21 -!- narodnik [~kk@92.59.59.28] has quit [Remote host closed the connection]
02:26 < provoostenator> Maybe worth noting that this only started happening after the assumevalid block and the CPU's are only 50C. I think a while ago we discussed the idea of retrying signature validation a few times to handle "cosmic rays".
02:27 < kallewoof> Sure the hardware isn't broken?
02:27 < provoostenator> I'm sure the hardware _is_ broken.
02:27 < kallewoof> ok
02:28 < provoostenator> Assume valid block is 506067, this starts happening at 506364. I'm just wondering what's reasonable in trying to compensate for bad hardware.
02:31 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]
02:31 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
02:36 -!- SopaXT [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
02:37 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Disconnected by services]
02:37 -!- SopaXT is now known as SopaXorzTaker
02:38 -!- SopaXT [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
02:43 -!- face [~face@80.72.82.160.coresnet.bg] has joined #bitcoin-core-dev
02:48 -!- SopaXT [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Ping timeout: 244 seconds]
02:49 < bitcoin-git> [bitcoin] ken2812221 opened pull request #13714: [gitian-build] Add automatical lxc network setup for Bionic (master...gitian-build-auto-install) https://github.com/bitcoin/bitcoin/pull/13714
02:53 < jonasschnelli> wumpus: what do you think about #9662. IMO it's ready for merge (has >5 utACKs). Since it's my PR, I'd prefer if someone else merges it
02:53 < gribble> https://github.com/bitcoin/bitcoin/issues/9662 | Add createwallet "disableprivatekeys" option: a sane mode for watchonly-wallets by jonasschnelli · Pull Request #9662 · bitcoin/bitcoin · GitHub
02:58 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
03:08 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]
03:09 < bitcoin-git> [bitcoin] ken2812221 closed pull request #13660: [depends] Don't build Qt dependencies if it doesn't support Qt (master...qt-packages-fix) https://github.com/bitcoin/bitcoin/pull/13660
03:10 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has quit [Excess Flood]
03:10 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev
03:10 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
03:20 -!- ttlloo [dabd1c78@gateway/web/freenode/ip.218.189.28.120] has joined #bitcoin-core-dev
03:20 < ttlloo> s
03:20 < ttlloo> getblonkNumber
03:21 -!- ttlloo [dabd1c78@gateway/web/freenode/ip.218.189.28.120] has left #bitcoin-core-dev []
03:32 -!- ExtraCrispy [~ExtraCris@185.9.18.150] has joined #bitcoin-core-dev
03:34 -!- goatpig [56eece80@gateway/web/freenode/ip.86.238.206.128] has joined #bitcoin-core-dev
03:49 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]
03:50 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
03:52 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]
04:06 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
04:06 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
04:13 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev
04:16 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
04:17 -!- rafalcpp_ is now known as rafalcpp
04:31 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
04:37 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]
04:39 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 276 seconds]
04:41 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
04:42 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
04:48 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 245 seconds]
04:51 -!- face [~face@80.72.82.160.coresnet.bg] has quit [Quit: leaving]
04:55 -!- face [~face@80.72.82.160.coresnet.bg] has joined #bitcoin-core-dev
05:00 -!- face [~face@80.72.82.160.coresnet.bg] has quit [Quit: leaving]
05:00 -!- face [~face@80.72.82.160.coresnet.bg] has joined #bitcoin-core-dev
05:01 -!- face [~face@80.72.82.160.coresnet.bg] has quit [Client Quit]
05:01 -!- face [~face@80.72.82.160.coresnet.bg] has joined #bitcoin-core-dev
05:06 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 240 seconds]
05:09 -!- face [~face@80.72.82.160.coresnet.bg] has quit [Quit: leaving]
05:10 -!- face [~face@80.72.82.160.coresnet.bg] has joined #bitcoin-core-dev
05:10 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds]
05:10 -!- face [~face@80.72.82.160.coresnet.bg] has quit [Client Quit]
05:10 -!- face [~face@80.72.82.160.coresnet.bg] has joined #bitcoin-core-dev
05:11 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:17 < bitcoin-git> [bitcoin] marcoagner opened pull request #13715: tests: fixes mininode's P2PConnection sending messages on closing transport (master...fix_mininode_p2pconnection_send_message) https://github.com/bitcoin/bitcoin/pull/13715
05:17 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]
05:19 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]
05:20 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
05:20 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
05:25 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has joined #bitcoin-core-dev
05:25 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]
05:29 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has quit [Ping timeout: 264 seconds]
05:32 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
05:35 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev
05:40 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 245 seconds]
05:42 -!- un1c0d3r [~nico@190.18.155.139] has joined #bitcoin-core-dev
05:45 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
05:46 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 255 seconds]
05:54 -!- un1c0d3r [~nico@190.18.155.139] has quit [Ping timeout: 240 seconds]
05:59 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]
06:08 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4a3e8c5aa6a5...e1260a798d10
06:08 < bitcoin-git> bitcoin/master ea5340c marcoagner: tests: fixes mininode's P2PConnection sending messages on closing transport...
06:08 < bitcoin-git> bitcoin/master e1260a7 MarcoFalke: Merge #13715: tests: fixes mininode's P2PConnection sending messages on closing transport...
06:09 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #13715: tests: fixes mininode's P2PConnection sending messages on closing transport (master...fix_mininode_p2pconnection_send_message) https://github.com/bitcoin/bitcoin/pull/13715
06:19 -!- texan136 [~tex@2a02:587:821c:d000:2132:3d11:eac7:e4c7] has joined #bitcoin-core-dev
06:20 -!- texan136 [~tex@2a02:587:821c:d000:2132:3d11:eac7:e4c7] has left #bitcoin-core-dev ["Leaving"]
06:21 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
06:22 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
06:26 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
06:30 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:36 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev
06:36 -!- harrymm [~harrymm@69.161.195.103] has quit [Ping timeout: 260 seconds]
06:39 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has joined #bitcoin-core-dev
06:40 -!- harrymm [~harrymm@69.161.195.103] has joined #bitcoin-core-dev
06:41 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 268 seconds]
06:49 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has quit [Ping timeout: 245 seconds]
06:51 -!- farmerwampum [~farmerwam@88.202.178.98] has joined #bitcoin-core-dev
06:52 -!- un1c0d3r [~nico@190.18.158.170] has joined #bitcoin-core-dev
06:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
07:04 -!- grafcaps [~haroldbr@107.147.175.194] has joined #bitcoin-core-dev
07:05 < wumpus> rc2 executables up https://bitcoincore.org/bin/bitcoin-core-0.16.2/test.rc2/
07:10 -!- grafcaps [~haroldbr@107.147.175.194] has quit [Ping timeout: 256 seconds]
07:11 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 240 seconds]
07:16 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
07:24 -!- grafcaps [~haroldbr@104.137.194.255] has joined #bitcoin-core-dev
07:25 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Read error: Connection timed out]
07:25 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
07:28 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
07:31 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 245 seconds]
07:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
07:42 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
07:48 -!- texan136 [~tex@2a02:587:8206:db00:2132:3d11:eac7:e4c7] has joined #bitcoin-core-dev
07:50 -!- texan136 [~tex@2a02:587:8206:db00:2132:3d11:eac7:e4c7] has left #bitcoin-core-dev ["Leaving"]
07:52 < bitcoin-git> [bitcoin] kallewoof opened pull request #13716: bitcoin-cli: -stdinwalletpassphrase and non-echo stdin passwords (master...stdinwalletpassphrase) https://github.com/bitcoin/bitcoin/pull/13716
07:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
07:53 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev
07:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
07:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
07:58 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 260 seconds]
07:59 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
08:00 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
08:03 < promag> sipa: instead of old(pk), could just be pk(...) and add a "backward compability" option to scantxoutset?
08:04 < promag> that option could be per descriptor
08:06 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
08:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
08:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
08:17 -!- harrymm [~harrymm@69.161.195.103] has quit [Ping timeout: 255 seconds]
08:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
08:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
08:23 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 240 seconds]
08:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds]
08:26 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
08:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
08:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
08:35 -!- harrymm [~harrymm@69.161.195.102] has joined #bitcoin-core-dev
08:36 < promag> sipa: I mean, instead of providing a descriptor for the old behaviour, add an option to support that behaviour
08:38 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 244 seconds]
08:39 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds]
08:40 -!- harrymm [~harrymm@69.161.195.102] has quit [Ping timeout: 276 seconds]
08:42 < provoostenator> Coolest error message ever: *** stack smashing detected ***: <unknown> terminated
08:46 -!- wumpus_ [~wumpus@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev
08:46 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
08:47 -!- ken2812221 [~ken281222@110.50.131.77] has joined #bitcoin-core-dev
08:48 -!- wumpus [~wumpus@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 248 seconds]
08:48 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
08:49 -!- wumpus_ is now known as wumpus
08:49 -!- pierre_rochard [sid299882@gateway/web/irccloud.com/x-qgqctqvpqwkncxfe] has joined #bitcoin-core-dev
08:50 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev
08:56 -!- Guest26115 [uid299882@gateway/web/irccloud.com/x-dheywjnxekbeicej] has quit []
08:56 -!- ken2812221_ [~androirc@110.50.131.77] has joined #bitcoin-core-dev
08:57 -!- harrymm [~harrymm@69.161.195.103] has joined #bitcoin-core-dev
09:04 -!- ken2812221_ [~androirc@110.50.131.77] has quit [Remote host closed the connection]
09:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
09:28 -!- str4d [~str4d@rrcs-24-136-119-35.nyc.biz.rr.com] has joined #bitcoin-core-dev
09:33 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]
09:34 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev
09:36 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Quit: Leaving]
09:38 -!- bitconne1 [~conner@136.24.175.89] has joined #bitcoin-core-dev
09:41 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 264 seconds]
09:49 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 240 seconds]
09:50 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
09:55 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 276 seconds]
09:57 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
10:07 -!- ken2812221_ [~ken281222@110.50.131.77] has joined #bitcoin-core-dev
10:07 -!- ken2812221 [~ken281222@110.50.131.77] has quit [Ping timeout: 240 seconds]
10:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
10:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
10:13 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
10:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds]
10:26 -!- ken2812221_ is now known as ken2812221
10:33 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]
10:34 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
10:37 -!- str4d [~str4d@rrcs-24-136-119-35.nyc.biz.rr.com] has quit [Ping timeout: 260 seconds]
10:40 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]
10:41 -!- Krellan [~Krellan@2601:640:4000:9258:e863:a2a8:8e:4f75] has joined #bitcoin-core-dev
10:46 -!- str4d [~str4d@rrcs-24-136-119-35.nyc.biz.rr.com] has joined #bitcoin-core-dev
10:55 -!- Krellan [~Krellan@2601:640:4000:9258:e863:a2a8:8e:4f75] has quit [Remote host closed the connection]
10:56 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev
10:56 -!- yadev [9a48ab25@gateway/web/freenode/ip.154.72.171.37] has joined #bitcoin-core-dev
10:59 < arubi> sipa, wrt earlier script{sig,pubkey} fork, do you mean that a script like " [script lhs] codesep <pubkey> checksig | [script rhs] " could be signed in a way that's invalid pre fork and valid after?  here "script lhs" and "script rhs" are just any script and '|' is the point where scriptsig and scriptpubkey are concatenated, so a second codesep pre-fork.
10:59 < arubi> at first I thought it was about codesep being "missing" to the right side of the sig post-fork, but afaict the signature would not sign the second codesep op pre-fork anyway because findanddelete removes it, so that's probably not it..  also sighash_single effectively just signs "1" so I don't see how anything in script might change what a sig must sign.
10:59 < arubi> anyway, if you could expand on what such an invalid pre-fork and valid after script would look like, I'd be very interested :)
11:00 < arubi> s/sighash_single/sighash_single bug/
11:05 < arubi> I do like the malformed serialization thing..  it feels like you could massage the bytes pushdata takes to glob the codesep pre-fork..  that's really interesting
11:05 < MarcoFalke> jonasschnelli: Looks like the nightly builds are down? https://bitcoin.jonasschnelli.ch/build/698
11:10 < jonasschnelli> MarcoFalke: looks like. thanks for reporting... I'll investigate
11:14 < MarcoFalke> Thx!
11:17 < sipa> jonasschnelli: please have a look at #13697
11:17 < gribble> https://github.com/bitcoin/bitcoin/issues/13697 | Support output descriptors in scantxoutset by sipa · Pull Request #13697 · bitcoin/bitcoin · GitHubAsset 1Asset 1
11:20 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e1260a798d10...8c3643279165
11:20 < bitcoin-git> bitcoin/master a4ba238 Lawrence Nahum: depends: disable Werror for zmqlib release, causes ndk build to break
11:20 < bitcoin-git> bitcoin/master 8c36432 MarcoFalke: Merge #13689: depends: disable Werror when building zmq...
11:20 < sipa> arubi: yeah, i think you can exploit sighash_single on an input position above the number of outputs, which signs the message 0x0000...0001
11:20 < gmaxwell> I didn't understand your sighash single claim myself.
11:21 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #13689: depends: disable Werror when building zmq (master...zmq_clang_depends) https://github.com/bitcoin/bitcoin/pull/13689
11:21 < gmaxwell> since it's signing a constant, why would the data going into the sighash matter?
11:21 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 248 seconds]
11:22 < sipa> gmaxwell: uh, yes
11:22 < sipa> of course :)
11:22 < arubi> phew :)
11:24 < arubi> so that leaves something like pushdata behaving differently by either globbing the 0xAB of the codesep as data size or not..  it really seems possible
11:25 < gmaxwell> arubi: or not
11:25 < gmaxwell> I think it's silly to speculate on, without testing no one really knows
11:25 < jonasschnelli> sipa: Oh. Nice... will have a look soon!
11:25 < sipa> oh, of course
11:25 -!- yadev [9a48ab25@gateway/web/freenode/ip.154.72.171.37] has quit [Ping timeout: 252 seconds]
11:25 < sipa> arubi: i don't think that works
11:26 < gmaxwell> arubi: e.g. perhaps any case you could construct to do that fails because earlier deserialization will fail.
11:27 < sipa> arubi: for it to be valid post-fork, pushes/opcodes need to align with the scriptSig end
11:27 < arubi> hm, yea..  pushdata in scriptsig without enough bytes to glob fails..  right
11:27 < sipa> so we're perhaps back to it being a HF only under the assumption you can create a self-signing signature
11:27 < arubi> you could with op_swap 
11:27 < arubi> or well, just op checksig right?
11:28 < arubi> ah again, findanddelete removes it..
11:28 < sipa> ah yes
11:28 < sipa> doesn't findanddelete save us?
11:30 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
11:32 < arubi> it almost seems like any signing shenanigans are out of the question.  definitely gonna be busy thinking about this :)
11:32 -!- str4d [~str4d@rrcs-24-136-119-35.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
11:32 -!- riemann_ [~riemann@217.96.149.217.ipv4.supernova.orange.pl] has joined #bitcoin-core-dev
11:32 -!- str4d [~str4d@rrcs-24-136-119-35.nyc.biz.rr.com] has joined #bitcoin-core-dev
11:36 -!- ExtraCrispy [~ExtraCris@185.9.18.150] has quit [Remote host closed the connection]
11:36 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 245 seconds]
11:36 < sipa> i think just a scriptSig of "<sig> <pubkey> OP_CHECKSIG" and a scriptPubKey of "OP_TRUE" is enough to HF
11:37 < sipa> is it not possible to create such a scriptSig now, due to FindAndDelete?
11:39 < arubi> with FaD you'd be signing everything except the signature both pre and post fork afaict, why is this hard forking?
11:40 < arubi> codesep is also removed, so just "<pubkey checksig 1" on both cases (codesep is to the right of checksig and removed)
11:41 < sipa> arubi: pre-fork you'd be signing "<pubkey> OP_CHECKSIG OP_TRUE", post-fork you're signing "<pubkey> OP_CHECKSIG"
11:41 < arubi> why?  1 is scriptpubkey, isn't it in sighash?
11:41 < arubi> err, 1 == op_true
11:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
11:42 < sipa> pre-fork the executed script was "<sig> <pubkey> CHECKSIG CODESEP TRUE"
11:42 < arubi> yes, no codeseps to the left of checksig, the one on the right is removed
11:43 < sipa> i don't understand what you're disagreeing with
11:43 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
11:43 < arubi> I don't understand why you'd not be signing op_true post fork
11:44 -!- reallll [~belcher@unaffiliated/belcher] has quit [Remote host closed the connection]
11:44 < arubi> ohhh
11:44 < sipa> because it's in a different script?
11:44 < arubi> yes!
11:47 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 264 seconds]
11:47 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
11:51 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev
12:00 < sipa> DING
12:01 < jonasschnelli> DONG
12:01  * cfields hits snooze
12:02 < wumpus> #startmeeting
12:02 < lightningbot> Meeting started Thu Jul 19 19:02:03 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:02 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:02 < provoostenator> hi
12:02 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
12:02 < kanzure> hi.
12:02 < jonasschnelli> hu
12:02 < achow101> hi
12:02 < cfields> hi
12:02 < sipa> ho
12:02 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
12:03 < wumpus> PSA: 0.16.2rc2 executables have been uploaded today and announcement sent
12:03 < jonasschnelli> thanks wumpus 
12:03 < wumpus> any topics? I think main priority is to review feature PRs that need to go in before the feature freeze - which was postponed to the 23th
12:04 < sipa> 4 days and ticking...
12:04 < wumpus> although we maerged a view
12:04 < wumpus> few*
12:04 < cfields> <topic> last chance to vote on scheduling if you haven't already. Poll closes at the end of the meeting </topic>
12:04 < wumpus> cfields: I voted
12:04 < jonasschnelli> I'd like to see #9662 merged...
12:04 < gribble> https://github.com/bitcoin/bitcoin/issues/9662 | Add createwallet "disableprivatekeys" option: a sane mode for watchonly-wallets by jonasschnelli · Pull Request #9662 · bitcoin/bitcoin · GitHub
12:04 < jonasschnelli> (has >5 acks)
12:04 < cfields> wumpus: thanks :)
12:04 < wumpus> jonasschnelli: let's do it then
12:04 -!- Guest26115 [sid299882@gateway/web/irccloud.com/x-dfrukunqjmlhidem] has joined #bitcoin-core-dev
12:05 < achow101> topic suggestion: exposing coin selection (or other possibly more internal things) as rpcs
12:05 < jonasschnelli> #9502 has also a couple of acks and waits for a final review from cfields
12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/9502 | [Qt] Add option to pause/resume block downloads by jonasschnelli · Pull Request #9502 · bitcoin/bitcoin · GitHub
12:05 < jonasschnelli> (was originally tagged for 0.17)
12:05 < sipa> i also want to bring up #13697 which changes the API for scantxoutset 
12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/13697 | Support output descriptors in scantxoutset by sipa · Pull Request #13697 · bitcoin/bitcoin · GitHub
12:05 < lclc> Topic Suggestion: Hi everyone, I propose moving the bitcoin-seeder from sipa's private GitHub (https://github.com/sipa/bitcoin-seeder) to the bitcoin-core GitHub organisation (https://github.com/bitcoin-core). (if this is on-topic)
12:05 < cfields> jonasschnelli: oh! sorry, will take a look right after the meeting
12:06 < jonasschnelli> thanks cfields
12:06 < jonasschnelli> I think sipas 13697 should be added to the high prio list
12:06 < provoostenator> Nice, though it would be nice if a followup PR made disable_private_keys positional, then we'll see if that part makes it into 0.17
12:06 < provoostenator> non-positional
12:06 < jonasschnelli> (since it's an API thing)
12:06 -!- laurentmt [~Thunderbi@37.58.58.232] has joined #bitcoin-core-dev
12:06 < sipa> if it doesn't go into 0.17, it'll either need to be an addition rather than a replacement, or we need to mark the API experimental (which may be a good idea regardless)
12:06 -!- ken2812221_ [~ken281222@110.50.131.77] has joined #bitcoin-core-dev
12:06 < wumpus> I think it's more relevant right now to tag things for 0.17 instead of adding them to the high-priority list
12:06 < jonasschnelli> Or that, yes.
12:07 < wumpus> everything that needs to go into 0.17 is high-priority by definition
12:07 -!- ken2812221 [~ken281222@110.50.131.77] has quit [Read error: Connection reset by peer]
12:07 < jnewbery> in general I think it's a sensible default policy to mark new APIs as experimental
12:07 < wumpus> (although some things are taggd 0.17 that shouldn't be,I tihnk)
12:07 < sipa> what about #13666 ?
12:07 < gribble> https://github.com/bitcoin/bitcoin/issues/13666 | Always create signatures with Low R values by achow101 · Pull Request #13666 · bitcoin/bitcoin · GitHub
12:07 < provoostenator> What's in a number?
12:08 < sipa> 13 and 666, can't beat those odds
12:08 < wumpus> niice
12:08 < achow101> it was completely planned, obviously
12:08 < ken2812221_> Could #13426 be tagged for 0.17?
12:08 < gribble> https://github.com/bitcoin/bitcoin/issues/13426 | [bugfix] Add u8path and u8string to fix encoding issue for Windows by ken2812221 · Pull Request #13426 · bitcoin/bitcoin · GitHub
12:08 < sipa> in some timezones it was also opened on friday the 13th
12:09 < sipa> oh, no
12:09 < jonasschnelli> I hope no black cat was sitting on the keyboard during coding
12:09 < wumpus> ken2812221_: done
12:09 < ken2812221_> thanks
12:09 < sipa> if it is a bugfix it can also go in after the feature freeze
12:10 < wumpus> tagged 13666 13426 and 13697 with 0.17
12:10 < wumpus> absolutely
12:10 -!- laurentmt [~Thunderbi@37.58.58.232] has quit [Client Quit]
12:10 < sipa> 12 PRs tagged 0.17 :o
12:10  * sipa fires up the review engine
12:10 < achow101> #13712 is a bug fix for 0.17 too
12:10 < gribble> https://github.com/bitcoin/bitcoin/issues/13712 | wallet: Fix non-determinism in ParseHDKeypath(...). Avoid using an uninitialized variable in path calculation. by practicalswift · Pull Request #13712 · bitcoin/bitcoin · GitHub
12:10 < jonasschnelli> Looks like #8469 won't make it for 0.17. I guess untag would make sense
12:10 < gribble> https://github.com/bitcoin/bitcoin/issues/8469 | [POC] Introducing property based testing to Core by Christewart · Pull Request #8469 · bitcoin/bitcoin · GitHub
12:11 < wumpus> jonasschnelli: yes will remove that one
12:11 < jonasschnelli> Also #13617 (I like, but to wip-ish for the timing of 0.17)
12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/13617 | [WIP] release: require macOS 10.10+ by fanquake · Pull Request #13617 · bitcoin/bitcoin · GitHub
12:11 < wumpus> and added 13712
12:12 < wumpus> jonasschnelli: ok
12:13 < cfields> jonasschnelli: if 13617 isn't ready in time (I don't see why it wouldn't, though), we can always bump the requirement and leave the stale code for later removal
12:13 < sipa> #13617
12:13 < gribble> https://github.com/bitcoin/bitcoin/issues/13617 | [WIP] release: require macOS 10.10+ by fanquake · Pull Request #13617 · bitcoin/bitcoin · GitHub
12:13 < jonasschnelli> Oh. Right... it's not a feature... agree with cfields
12:14 -!- booyah [~bb@193.25.1.157] has quit [Ping timeout: 276 seconds]
12:14 < wumpus> re-add it then?
12:14 < jonasschnelli> Yes. I'll do it. Sry for the confusion
12:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
12:15 < wumpus> no problem
12:15 < wumpus> #topic exposing coin selection on RPC (achow101)
12:15 < gmaxwell> What does that mean precisely?
12:15 < achow101> this came up in a discussion with some companies about coin selection. basically, some are interested in using core's coin selection (or someone elses) instead of having to implement/roll their own
12:15 < wumpus> I'd say listunspent+raw transactions API
12:16 < achow101> currently if they wanted to use core's coin selection, the utxos need to be in the wallet, i.e. the addresses and possibly keys need to be in the wallet
12:16 < wumpus> fundrawtransaction?
12:16 < achow101> that is not ideal for them
12:16 < jonasschnelli> achow101: hmm,... is RPC the right interface for that?`
12:16 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 244 seconds]
12:16 < sipa> i suggested to achow101 that a library might be a better way of doing so
12:16 < gmaxwell> but again what does that mean.  like isn't fun-draw-transaction that?
12:16 < jonasschnelli> Right.. what wumpus said
12:16 < achow101> the idea was then to have an rpc call where the utxos are provided and coin selection is operated on those utxos
12:16 < sipa> gmaxwell: they don't want to use the wallet; they just want to be able to run coin selection
12:16 < wumpus> you can import utxos into the wallet with importprunedfunds
12:16 < achow101> wumpus: fundrawtransaction requires the wallet
12:17 < jonasschnelli> achow101: using private key disabled dynamic wallet in conjunction with fundraw seems very efficient
12:17 < gmaxwell> I am doubtful that it is worth our effort in maintaining a stable interface for such a thing.
12:17 < achow101> wumpus: that's probably slow with hundreds of thousands of utxos
12:17 < wumpus> meh, RPC is not a good place for pure utility functions
12:17 < wumpus> if it doesn't need the wallet nor core state, why have it on *remote* procedure call?
12:17 < gmaxwell> E.g. kallewoof's recent grouping PR would have obliterated the interface for coin selection.
12:17 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev
12:17 < wumpus> it just creates a central point of faliure for no good reason
12:18 < wumpus> a library indeed sounds like a better idea
12:18 < jonasschnelli> Agree with wumpus.
12:18 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
12:18 < jonasschnelli> I know a library would be cumbersome to implement (compared to RPC),... but that is a weak argument IMO
12:18 < wumpus> RPC is not a good way to do code sharing
12:18 < sipa> it sounded like people really like RPC interfaces over libraries though, for reason i have difficulty comprehending
12:18 < achow101> a library is probably better, but the issue with libraries is that they all use different languages. so a different library for each language would need to be created
12:18 < sipa> but one possibility would be to have a separate binary with utility functions, that exposes an RPC
12:19 < gmaxwell> its just the webby world.
12:19 < wumpus> I don't get it
12:19 < achow101> and they seemed to like rpcs where things are easily dropped in
12:19 < wumpus> I don't want to debate this madness
12:19 < gmaxwell> achow101: C(++) is callable from every language.... :P
12:19 < jonasschnelli> Wild though: provide a cli tool?
12:19 < bitcoin-git> [bitcoin] masonicboom opened pull request #13717: docs: Link to python style guidelines from developer notes (master...link-to-python-style-guidelines-from-dev-notes) https://github.com/bitcoin/bitcoin/pull/13717
12:19 < gmaxwell> (well C is, C++ via making a C interface. :) )
12:19 < jonasschnelli> *thought
12:19 < sipa> jonasschnelli: slow
12:19 < gmaxwell> but in any case, if you have a library you can also wrap that to present an RPC.
12:19 < jonasschnelli> (a library & a CLI tool for the lazy people)
12:19 < wumpus> cli also a 'remote' call, though it invokes a new process for every call!
12:19 < wumpus> but it has the same issues with (de)serialization
12:20 < gmaxwell> But the argument I was making above is also an argument against a library: pressure to maintain a stable interface to this would be harmful to the project.
12:20 < wumpus> right
12:20 < jonasschnelli> indeed... if performance is the goal, a library is probably the right choice.
12:20 < sipa> i think coin selection is relatively well encapsulated
12:20 < sipa> i also don't see how kallewoof's groupings would break the API
12:20 < gmaxwell> sipa: I just gave an example where recent changes changed the API substantailly.
12:21 < gmaxwell> Both BNB and kallewoof changed arguments to every entry point.
12:21 < wumpus> to be honest I think this is not a concern for our project
12:21 < achow101> gmaxwell: but the interface exposed to the callers did not
12:21 < sipa> so? overall it takes a list of UTXOs and gives a subset back
12:21 < wumpus> some other people want a coin selection algorithm for their own purposes
12:21 < achow101> gmaxwell: only things within selectcoins changed, and an rpc would effectively only expose selectcoins
12:22 < wumpus> it's fine, they can make a library out of it themselves
12:22 < gmaxwell> it's more tightly coupled than "list of UTXOs" ... e.g. it needs fees, signature sizes. 
12:22 < wumpus> the code is open source
12:22 < gmaxwell> I mean if someone can jigger things around to make it seperable and they find that useful, fantastic.
12:22 < achow101> wumpus: sure the code is open source, but it is not something that can easily be taken out and dropped into something else.
12:23 < gmaxwell> But I don't want to hear "we can't implement privacy feature X because it'll break an interface"
12:23 < wumpus> for the consensus code I see a strong reason to provide it as a library: it is *important* that everyone uses the same consensus code
12:23 < jonasschnelli> wumpus: I think what they want is something maintained by the same people
12:23 < wumpus> jonasschnelli: the same people might not agree with that, who asks them?!
12:23 < gmaxwell> perhaps they should contribute to making the wallet code better so they don't have to write their own. :P
12:23 < wumpus> they might want the whole world to be maintained by the same people
12:23 < jonasschnelli> heh... 
12:24 -!- booyah [~bb@193.25.1.157] has joined #bitcoin-core-dev
12:24 < wumpus> gmaxwell: right, exactly
12:24 -!- laurentmt [~Thunderbi@37.58.58.232] has joined #bitcoin-core-dev
12:25 < achow101> the general feeling was that they wanted core to be more modular so that they can pick and choose specific internal components to use in their software
12:25 -!- riemann_ [~riemann@217.96.149.217.ipv4.supernova.orange.pl] has quit [Ping timeout: 240 seconds]
12:25 < achow101> also more generally that there was some sort of "canonical" libraries for things instead of everyone implementing their own thing
12:26 < wumpus> but making internal interfaces stable does restrict future flexibilty, as gmaxwell says
12:26 < wumpus> it's already hard enough to change the RPC interface
12:26 < wumpus> I understand the desire for that, bt puttingn that all on our plate is unreasonable
12:27 < wumpus> as well as centralization
12:27 -!- laurentmt [~Thunderbi@37.58.58.232] has quit [Client Quit]
12:27 < wumpus> it's not how things can work in a project like this, the same group providing canonical implementations for everything
12:28 < achow101> right
12:28 < moneyball> suggested topic: next Core dev tech meetup
12:28 < jnewbery> wumpus: there is some benefit to making the Core coin selection algorithm more generally usable though
12:29 < wumpus> jnewbery: people that want that, can work on that, the code is open source, they can make a library out of it
12:29 < jnewbery> eg if we think it's good and reduces UTXO bloat, having more people using it is a benefit
12:29 < wumpus> if it turns out to be feasible enough then core can start using that library too
12:29 < wumpus> that's a two-step process, though
12:29 < sipa> i think the first step for this is something we're doing anyway; making the code itself more encapsulated
12:29 < jonasschnelli> Agree with wumpus: I guess its a one-day job to extract the coin selection code and create a library out of it...
12:30 < sipa> no it's not
12:30 < jonasschnelli> The burden is the maintenance...
12:30 < sipa> it's currently split between wallet code and coinselection
12:30 < wumpus> jonasschnelli: I doubt it's that easy
12:30 < sipa> and that's improving
12:30 < bitcoin-git> [bitcoin] masonicboom opened pull request #13718: docs: Specify preferred Python string formatting technique (master...python-string-format-guideline) https://github.com/bitcoin/bitcoin/pull/13718
12:30 < jnewbery> yes, agree that anyone can work on it. I think it's a legitimate thing to bring up in a core meeting though
12:31 < sipa> i think it's great to hear there is interest in code we're writing
12:31 < jnewbery> sipa: +1
12:31 < wumpus> sipa: so in as far as that helps our own maintainability of the walletcode, that's a good thing
12:31 < sipa> wumpus: perhaps once the code is sufficiently encapsulated, someone else can librarify that and maintain it
12:32 -!- LukeJr [~quassel@75.113.216.147] has joined #bitcoin-core-dev
12:32 < wumpus> right
12:33 < wumpus> #topic #13697 which changes the API for scantxoutset
12:33 < gribble> https://github.com/bitcoin/bitcoin/issues/13697 | Support output descriptors in scantxoutset by sipa · Pull Request #13697 · bitcoin/bitcoin · GitHub
12:33 < wumpus> (sipa)
12:33 < sipa> first of all, this is part of a bigger effort to combine keys and scripts and chains into one concept
12:34 < sipa> there's a mini language to specify (sets of) scriptPubKeys, so i'd very much first want to hear comments on that language
12:34 < wumpus> yes that is very neat
12:34 < sipa> https://github.com/sipa/bitcoin/blob/895a46d83550838a8170ccba075367232eabbd8c/src/script/descriptor.h#L9L68
12:35 < jonasschnelli> I really like it. Will review and test it asap!
12:36 < sipa> the other question is scantxoutset experimental or not, and with descriptor support in 0.17 or not
12:36 < jonasschnelli> What is the difference between the FlatSigningProvider and the dummysigner?
12:36 < sipa> dummysignatureprovider doesn't provide anything
12:36 < sipa> flatisigningprovider takes its information from flat maps
12:36 < jonasschnelli> I see
12:37 < wumpus> I think scantxout should be marked experimental
12:37 < jonasschnelli> Agree
12:37 < jonasschnelli> Also with 13697...
12:37 < sipa> agree
12:37 < jonasschnelli> Helps us to do unplaned API changed
12:37 < jonasschnelli> *changes
12:37 < wumpus> right
12:37 < sipa> i plan to write a longer explanation in doc/descriptors.md or so
12:38 < wumpus> cool
12:38 < jonasschnelli> thanks for working on this sipa
12:38 < sipa> one of the future ideas is a PSBT standalone binary that can sign/update using descriptors
12:38 < luke-jr> should these be a BIP? seems potentially useful outside Core
12:38 < sipa> luke-jr: potentially yes, but not in first instance
12:38 < sipa> i expect that this will evolve rather quickly
12:39 < luke-jr> BIP drafts can evolve :p
12:39 < wumpus> maybe at some point, but as this doesn't touch consensus or P2P it'd be an advisory BIP at most, and it's not required to do it first
12:39 < wumpus> luke-jr: let's just leave it up to sipa
12:39 < sipa> also, the part that actually needs interoperability is PSBT; descripors are just how we (or at least i hope) represent our knowledge 
12:40 < sipa> compability would certainly be useful too, but i'd rather take some time to see how things evolve
12:40 < sipa> otherwise i fear we'll have something with a dozen optional parts all implemented by different subsets of software
12:40 < wumpus> yes
12:41 < wumpus> #topic bitcoin-seeder under bitcoin-core GitHub organisation (lclc)
12:41 < sipa> lclc: no problem as far as I'm concerned, but i'm not sure it's the right message
12:41 < luke-jr> Seems unnecessary.
12:42 < lclc> I though because there are a few open issues and simple PRs for bitcoin-seeder and it might would make sense that several Bitcoin maintainers have merge rights.
12:42 < sipa> there are other pieces of seeder software out there too, and having variety is a good thing here
12:42 < luke-jr> should we put bfgminer, knots, kallewoof's script debugger stuff, etc under bitcoin-core too? :p
12:42 < lclc> I know there are several seeder implementations but it appears to be the most used one. And since getting new node IPs by DNS is the default way to bootstrap a node in Core I think it makes sense to have one implementation in the bitcoin-core org.
12:42 < wumpus> luke-jr: if they want
12:42 < luke-jr> wumpus: what sipa said - it sends the wrong msg IMO
12:43 < wumpus> yes, to be clear I don't think it's necessary
12:43 < provoostenator> Another approach could be for sipa to give more people access to that repo?
12:43 < jonasschnelli> No strong opinion... but slighly prefere to have it under the bitcoin-core repository
12:43 < luke-jr> although maybe it would make sense for knots, but that would probably just be a mess on github
12:43 < luke-jr> provoostenator: +1
12:43 < luke-jr> to sipa giving access as desired
12:43 < sipa> provoostenator: i'm fine with that!
12:43 < wumpus> as I said before with the library stuff, I think it's more robust to spread projects around instead of create the illusion that they're all maintained by the same 'team'
12:43 < provoostenator> Or create an ad hoc organization "Sipa's DNS Seed maintainer club"
12:43 -!- bitconne1 [~conner@136.24.175.89] has quit [Ping timeout: 268 seconds]
12:43 < wumpus> so agree with you on that luke-jr 
12:44 < luke-jr> there's no reason to turn access to tht eCore github repo ainto an actual position
12:44 < luke-jr> forgive the typos
12:45 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev
12:45 < lclc> That's also fine with me
12:45 < achow101> topic suggestion: moving away from bitcoin.org more
12:46 < lclc> I (and others) just have a few simple PRs open (and open PRs feels like potential outstanding work in the future :D), so a few more maintainers (maybe jonasschnelli ?) would be good
12:46 < wumpus> #topic moving away from bitcoin.org more (achow101)
12:46 < luke-jr> not sure there's anything further we can do in terms of oving away..?
12:46 < achow101> we still link to bitcoin.org for things like downloads
12:46 < wumpus> achow101: moving what, excatly? executables have been moved
12:46 < achow101> should probably change those
12:46 < jonasschnelli> I'm pretty familiar with the seeder code and happy to co-maintain it
12:46 < wumpus> achow101: where?
12:46 < luke-jr> achow101: where?
12:46 < achow101> in the readme
12:46 < jnewbery> I don't think we link to bitcoin.org for downloads any more
12:46 < wumpus> at least in the release mail I link to bitcoincore.org nowadays
12:47 < moneyball> suggested topic: next Core dev tech meetup :)
12:47 < sipa> For more information, as well as an immediately useable, binary version of
12:47 < provoostenator> And there's guiconstants.h: QAPP_ORG_DOMAIN "bitcoin.org"
12:47 < sipa> the Bitcoin Core software, see https://bitcoin.org/en/download
12:47 < jnewbery> Open a PR to remove that link from the readme. I will happily ACK
12:47 < luke-jr> bitcoin.org could increase distance further, but someone needs to do that work, and people whined when they tried, so I think it's stuck
12:47 < wumpus> I think the link to bitcoin.org is only for the *general* descriptoin of bitcoin
12:47 < wumpus> that certainly would be confusing to make bitcoincore.or
12:47 < wumpus> moneyball: yep
12:47 < sipa> wumpus: see quote above
12:47 < luke-jr> provoostenator: oh yeah, that was an issue for distro stuff somewhere IIRC
12:47 < wumpus> sipa: oh yes that should go
12:48 < sipa> ack on that in any case
12:48 < wumpus> provoostenator: don't change that! it determines the settings path
12:48 < luke-jr> provoostenator: might want to make it something generic though, not Core-specific
12:48 < achow101> I was thinking that it may not be appropriate to make release posts on bitcoin.org, at least not before they go up on bitcoincore.or
12:48 < luke-jr> wumpus: I think it's used outside settings too, but maybe best to just leave it alone
12:48 < achow101> as in we should simply take the bitcoin.org steps out of our release process and if someone wants to do them later, then that's fine
12:49 < luke-jr> perhaps a comment explaining it's for compatibility, nothing more
12:49 < wumpus> luke-jr: possibly, but at the least it loses the qsettings, that's also why it's not "Bitcoin core" named there yet
12:49 < wumpus> achow101: would that really make anything better?
12:49 < wumpus> achow101: are you seriously suggesting I should no longer update bitcoin.org and upload binaries there?
12:49 < achow101> yes
12:50 < achow101> wumpus: are you aware of the recent events on bitcoin.org?
12:50 < provoostenator> Well, I think technically he's suggesting not having that be part of the documented process, but you can do whatever you want.
12:50 < wumpus> acvaguely
12:50 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 268 seconds]
12:51 < luke-jr> Cobra wanted to make Knots the "default" on bitcoin.org a while back; we could encourage that, or (probably better) encourage not having a "default"
12:51 < wumpus> so I think this will effectively reduce the number of downloads
12:51 < wumpus> I don't care though, I don't want to be involved in political stuff at all, I' kind of burned out on that
12:51 < luke-jr> wumpus: Core doesn't have a problem wth getting users atm
12:51 < jonasschnelli> I think we should only publish binaries via bitcoincore.org and should not actively push it to other websites... 
12:51 < luke-jr> >99% of the network runs Core
12:51 < jonasschnelli> It's gives a wrong sense of project coupling 
12:51 < achow101> there's ongoing work to move all of the bitcoin core stuff from bitcoin.org to bitcoincore.org
12:52 < wumpus> maybe the developer documentation too
12:52 < luke-jr> if people are running/updating Core simply because it's on bitcoin.org, that is kind of a systemic risk we should address if possible
12:52 < luke-jr> (and making it harder to "just run bitcoin.org" seems a step in that direction)
12:53 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
12:53 < wumpus> #topic next coredev tech meeting (moneyball)
12:54 < moneyball> Hi, I wanted to let people know I've volunteered to organize the next Core Dev Tech meetup
12:54 < moneyball> The current thinking is to have it in Tokyo in October after Scaling Bitcoin
12:54 < luke-jr> thanks
12:54 < moneyball> Oct 8-10
12:54 < jonasschnelli> thanks moneyball
12:54 < wumpus> yes, awesome!
12:54 < jonasschnelli> moneyball: please update https://github.com/coredev-tech
12:54 < provoostenator> Awesome indeed
12:54 < cfields> thanks moneyball :)
12:54 < moneyball> And to organize it in a similar fashion as the last one in NYC
12:55 < moneyball> Cory put me in touch with the Digital Garage guys and they will be able to help quite a bit, similar to last year's Tokyo meetup
12:55 < sipa> nice
12:55 < moneyball> I plan to send out a survey to collect some feedback
12:56 < moneyball> If anyone has specific ideas or suggestions please feel free to contact me
12:56 < moneyball> Nothing more from me about the topic now
12:57 < luke-jr> side note: anime meetup after on Oct 11 if anyone's interested https://docs.google.com/document/d/1CWLhg8u9pfNWSVjgiPYt0V5ZIOQFSCIYYdSvzHaqOpQ/edit?usp=sharing
12:57 < jonasschnelli> thanks moneyball for organising!
12:57 < moneyball> You're welcome happy to help!
12:58 < jnewbery> yes, thanks moneyball! Looking forward to it :)
12:59 < wumpus> #endmeeting
12:59 < lightningbot> Meeting ended Thu Jul 19 19:59:27 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:59 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-19-19.02.html
12:59 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-19-19.02.txt
12:59 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-19-19.02.log.html
12:59 < wumpus> thanks everyone
12:59 < achow101> topic suggetion: lunch
12:59 < sipa> #lunch
12:59 < luke-jr> not breakfast?
13:00 < sipa> it will in fact be my first meal of the day
13:00 < ken2812221_> for me, it's almost breakfast.4 AM here
13:01 < cfields> ken2812221_: you got a link to vote on the meeting time, right?
13:01 < ken2812221_> No, I didn't receive the email.
13:02 < provoostenator> Any tips for debugging the auto hidden service feature when it doesn't seem reachable? Its log looks happy, but trying to addnode it results in "general failure" (as opposed to "host unreachable")
13:02 < cfields> ken2812221_: hmm. I'll resend. Can you stick around for another minute to vote?
13:02 -!- lclc [~lclc@unaffiliated/lclc] has quit [Quit: www.bitcoinassociation.ch]
13:03 < ken2812221_> ok, thanks
13:04 < wumpus> provoostenator: fwiw this is what I use to manually check hidden service connections: https://twitter.com/orionwl/status/1000995421739802624
13:04 < cfields> ken2812221_: got that one?
13:04 < ken2812221_> cfields: yes. thank you
13:04 < wumpus> provoostenator: also run with debug=torcontrol on the server
13:04 < provoostenator> Using the wrong port will get me a "connection refused", so something is out there :-)
13:05 < wumpus> ok
13:05 < wumpus> 'general failure' is a generic enough error message to be completely useless :)
13:06 -!- LukeJr [~quassel@75.113.216.147] has quit [Remote host closed the connection]
13:06 < cfields> ken2812221_: please let me know when you're finished so that I can end the poll.
13:06 < wumpus> provoostenator: so it might be something with the forwarding then, is the bind port open?
13:07 < jonasschnelli> Is there a quick cure for my gitian builder? Trying to create a bionic base vm....but getting E: No such script: /usr/share/debootstrap/scripts/bionic
13:07 < cfields> jonasschnelli: try using lxc
13:07 < luke-jr> jonasschnelli: AFAIK we don't have a way to make gitian base VMs for bionic yet (at least KVM?)
13:08 < jonasschnelli> cfields: I though I'm using lxc
13:08 < wumpus> tor, from the server side, reports a different thing if the port is not open on the hidden service at all - versus when the connection to the local target port fails
13:08 < jonasschnelli> Getting the error after executing bin/make-base-vm --suite bionic --arch amd64 --lxc
13:09 < cfields> jonasschnelli: ah, I think it might still look at the bionic debootstrap script. You might need to update a package. sec.
13:09 < ken2812221_> cfields: finished
13:09 < cfields> ken2812221_: thanks!
13:09 < provoostenator> -debug=tor says "ADD_ONION successful ...  advertising service [....].onion ... AddLocal([....].onion:8333,4)"
13:10 < cfields> jonasschnelli: oh, just apt-get update and apt-get install debootstrap
13:10 < cfields> jonasschnelli: in my case, anyway, mine was old and missing the script for Bionic. Upgrading that package fixed it.
13:11 < wumpus> so in any case: does everyone think I should stop uploading bitcoin core to bitcoin.org? this would be a complete break with them, maybe that's better than waiting for cobra to decide to no longer support core as he's already threatened at least once, but I'm ambivalent abouti t
13:12 < wumpus> provoostenator: looks 100% good
13:12 < wumpus> provoostenator: so can you connect locally to the 127.0.0.1:port that tor connects on to reach bitcoin?
13:12 < provoostenator> Indeed. Might be nice for it to try and ping itself via Tor.
13:12 -!- un1c0d3r [~nico@190.18.158.170] has quit [Ping timeout: 260 seconds]
13:13 < luke-jr> wumpus: I think we should leave that up to bitcoin.org, and encourage them to be multi-fullnode
13:13 < wumpus> luke-jr: leave it up to them = keep doing what I do now?
13:14 < luke-jr> wumpus: basically
13:14 < cfields> wumpus: I think that makes sense. They're Bitcoin Core downloads, not Bitcoin downloads. If bitcoin.org wants to mirror them, that's their prerogative.
13:14 < wumpus> ok
13:14 < jonasschnelli> cfields: debootstrap is already the newest version (1.0.89).
13:14 < provoostenator> bind=127.0.0.1:8333 did the trick, bid surprised that was needed.
13:14 < luke-jr> wumpus: if they say "we'll point people to bitcoincore.org for that", then stop (and encourage this outcome)
13:16 < provoostenator> Coming soon: I'm thinking of making my Armbian build script use the Tor hidden service stuff by default, as well as connect via Tor proxy outbound.
13:16 < ken2812221_> The minimum debootstrap version to support bionic is 1.0.92
13:16 < cfields> jonasschnelli: ah, you're on Debian
13:16 < wumpus> provoostenator: yes, that's surprising, the ideal solution for that would be #8973 - make the tor forwarding code create its own private P2P listening port
13:16 < gribble> https://github.com/bitcoin/bitcoin/issues/8973 | Incoming tor connections should use alternative port · Issue #8973 · bitcoin/bitcoin · GitHub
13:16 -!- hex17or [~hex17or@2a02:8071:ba7:d300:17:944:481c:f8af] has joined #bitcoin-core-dev
13:17 < jonasschnelli> cfields: Right...I'm looing for a Bionic script now
13:17 < wumpus> (or even a UNIX socket, if we ever get that code into mergable shape)
13:17 < luke-jr> jonasschnelli: check backports?
13:17 < luke-jr> bbiab
13:17 < cfields> jonasschnelli: if it helps, it's just a symlink to gutsy. Do you have that?
13:18 < jonasschnelli> cfields:okay.Let me try that
13:18 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 250 seconds]
13:19 < jonasschnelli> cfields: that should still create bionic-deterministic builds?
13:19 < jonasschnelli> (seems to work)
13:19 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
13:20 < cfields> jonasschnelli: I guess we'll see :)
13:20 < jonasschnelli> heh..okay. :)
13:20 -!- yadev [9a48a89f@gateway/web/freenode/ip.154.72.168.159] has joined #bitcoin-core-dev
13:20 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has joined #bitcoin-core-dev
13:21 < yadev> Hello !
13:22 < yadev> Please I need to run a full node for a cryptocurrency trading site what are requirements, what do you suggest me to do ? thanks.
13:22 < jonasschnelli> yadev: #bitcoin
13:22 < yadev> Thanks
13:24 < cfields> poll results: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_a80f9a69d20aab2a
13:26 < wumpus> yadev: see https://bitcoin.org/en/full-node  (but yes, discussion of user issues belongs in #bitcoin)
13:27 -!- yadev [9a48a89f@gateway/web/freenode/ip.154.72.168.159] has quit [Ping timeout: 252 seconds]
13:27 < wumpus> cfields: so should we pick the most popular and least popular times? ;)
13:28 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 245 seconds]
13:28 < cfields> heh
13:30 < wumpus> in any case this confirms that a lot of people do in fact like the current time
13:32 < cfields> I had some hope that there's a 25th hour that is amenable to everyone. Guess not :(
13:32 < jonasschnelli> cfields: using bionic, I get "lxc-init: missing container name, use --name option"? Any idea how to get rid of this?
13:33 < jonasschnelli> (don't complain when I use trusty)
13:33 < ken2812221_> update lxc to 2.1.1 or upper
13:33 < cfields> jonasschnelli: ok, that's the lxc2 vs lcx3 incompatibility
13:33 < cfields> right
13:34 < jonasschnelli> I'm on debian stretch
13:34 < jonasschnelli> :(
13:34 < cfields> jonasschnelli: https://github.com/bitcoin/bitcoin/pull/13171#issuecomment-405711147
13:37 < gmaxwell> wumpus: re unix sockets, did the upstream things we need for that happen?
13:39 -!- hex17or [~hex17or@2a02:8071:ba7:d300:17:944:481c:f8af] has quit [Ping timeout: 276 seconds]
13:39 < wumpus> gmaxwell: not sure; though there was only one small part that needed upstream support, the client-side RPC support
13:39 < wumpus> P2P unix sockets support didn't need anything special, neither did server-side RPC 
13:40 < gmaxwell> only reason I ask I guess is because our side can be done whenever, upstream has leadtimes. :)
13:41 < wumpus> I kind of lost track, I think upstream wanted another solution which was much more work and I didn't really understand how it would help us
13:43 -!- nickler [~nickler@185.12.46.130] has quit [Ping timeout: 264 seconds]
13:43 < wumpus> (I think something that would allow automatic reconnection)
13:44 < wumpus> it's still open: https://github.com/libevent/libevent/pull/479
13:44 -!- hex17or [~hex17or@2a02:8071:ba7:d300:17:944:481c:f8af] has joined #bitcoin-core-dev
13:45 < wumpus> "I added EVHTTP_CON_OUTGOING. Making the retry work with a callback (at either http or bufferevent level) as suggested by @azat sounds like a good idea to me, but that exceeds my expertise with the libevent code."
13:45 < wumpus> if anyone knows more about libevent than me, please help
13:46 < jonasschnelli> cfields: so Bionic requires LXC 2.1.1 which is not available on the newest Debian version (stretch)... that seems to be unfortunate
13:46 < jonasschnelli> Looks like I don't have an upgrade path for my build host
13:47 < wumpus> otherwise I'm not sure this is ever going to happen, though I still think it's useful even without bitcoin-cli support
13:47 < cfields> jonasschnelli: yea. I don't see any way around it :(
13:48 < gmaxwell> wumpus: Do we have a way to test it without bitcoin-cli support?
13:48 -!- hex17or [~hex17or@2a02:8071:ba7:d300:17:944:481c:f8af] has quit [Ping timeout: 256 seconds]
13:49 < wumpus> gmaxwell: my original PR already updated the test framework to use it (from python)
13:49 < gmaxwell> Oh.
13:49 < gmaxwell> Well then, I agree its useful without -cli.
13:49 < wumpus> gmaxwell: whihch was one of the primary motivations because it allows doing the tests without claiming port ranges
13:49 -!- frenchy [5a7feba0@gateway/web/freenode/ip.90.127.235.160] has joined #bitcoin-core-dev
13:50 < frenchy> Hello everyone
13:50 < wumpus> using UNIX sockets guarantees that there are no port collisions
13:53 < gmaxwell> wumpus: yep makes perfect sense there.
13:53 < wumpus> and reduces other risk that external things interfere ODODODwith the tests, though making the P2P port in the tests listen on localhost only was a good move in that direction
13:53 < wumpus> frenchy: hello.
13:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
13:58 < gmaxwell> wumpus: right, I think the reason I found the socket most interesting was better security, e.g. making it easy to give a group access to the bitcoin daemon rather than all of localhost.
14:01 < bitcoin-git> [bitcoin] sipa opened pull request #13719: Avoid creating a temporary vector for size-prefixed elements (master...201807_psbt_no_vec_serialize) https://github.com/bitcoin/bitcoin/pull/13719
14:01 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
14:02 < bitcoin-git> [bitcoin] practicalswift opened pull request #13720: build: Make lint-locale-dependence.sh work with BSD grep (avoid empty subexpressions) (master...bsd-grep-compatibility) https://github.com/bitcoin/bitcoin/pull/13720
14:03 -!- booyah [~bb@193.25.1.157] has quit [Ping timeout: 245 seconds]
14:08 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev
14:12 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 240 seconds]
14:13 -!- str4d [~str4d@rrcs-24-136-119-35.nyc.biz.rr.com] has quit [Ping timeout: 248 seconds]
14:14 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
14:16 < jonasschnelli> cfields: self compiled lxc 2.1.1 seems to work.
14:17 -!- un1c0d3r [~nico@190.18.158.170] has joined #bitcoin-core-dev
14:17 < jonasschnelli> https://bitcoin.jonasschnelli.ch/build/707
14:18 -!- un1c0d3r [~nico@190.18.158.170] has quit [Remote host closed the connection]
14:18 -!- frenchy [5a7feba0@gateway/web/freenode/ip.90.127.235.160] has quit [Quit: Page closed]
14:23 < cfields> jonasschnelli: nice!
14:29 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 240 seconds]
14:34 -!- goatpig [56eece80@gateway/web/freenode/ip.86.238.206.128] has quit [Ping timeout: 252 seconds]
14:35 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8c3643279165...f281f8f75522
14:35 < bitcoin-git> bitcoin/master 2c71edc John Newbery: [wallet] [rpc] Fix importaddress help text
14:35 < bitcoin-git> bitcoin/master f281f8f MarcoFalke: Merge #13074: [trivial] Correct help text for `importaddress` RPC...
14:35 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #13074: [trivial] Correct help text for `importaddress` RPC (master...importaddress_help_text) https://github.com/bitcoin/bitcoin/pull/13074
14:36 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
14:37 < jonasschnelli> sipa: is it possible to define a range rather then all keys in a chain? https://github.com/bitcoin/bitcoin/pull/13697/commits/83cc8dcaa5dfe22d4ba657edf35727d09da09dd1#diff-8c0b1c3cb0e19eaad495b468bc5813aaR56
14:37 < jonasschnelli> Haven't looked at the code,... but maybe  pkh(xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw/1'/2/[0-1000]) should be possible
14:37 < sipa> jonasschnelli: i would rather not do that
14:37 < jonasschnelli> why?
14:38 < sipa> jonasschnelli: the reason is that in some contexts where descriptors are useful, the chain size is determined by the environment (in particular, in a wallet it follows from gap limit and blockchain)
14:38 < sipa> so unless you're going to add more "variants" of the descriptor language, it doesn't feel like a core feature
14:39 < jonasschnelli> Thinking practical: assume I haven a xpub and I'd like to find funds via scantxoutset (gap limit not possible)... would it make sense to scan for all non hardened keys (assume BIP44 has been used)?
14:40 < sipa> jonasschnelli: no, you specify a range
14:40 < jonasschnelli> I'm not sure about the performance implications... maybe it's okay
14:40 < sipa> jonasschnelli: the scantxoutset RPC in my PR lets you do that
14:40 < sipa> it's just not part of the descriptor itself
14:40 < jonasschnelli> aha.. okay. I'm still at the third commit. :)
14:40 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has quit []
14:40 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/f281f8f75522...aba2e666d7fd
14:40 < bitcoin-git> bitcoin/master 7223263 practicalswift: wallet: Add tests for ParseHDKeypath(...)
14:40 < bitcoin-git> bitcoin/master 27ee53c practicalswift: wallet: Add error handling. Check return value of ParseUInt32(...) in ParseHDKeypath(...).
14:40 < bitcoin-git> bitcoin/master aba2e66 MarcoFalke: Merge #13712: wallet: Fix non-determinism in ParseHDKeypath(...). Avoid using an uninitialized variable in path calculation....
14:41 < jonasschnelli> (sipa: IMO the third commit "Support output descriptors in scantxoutset" sould be renamed to somthing without "scantxoutset")
14:41 < sipa> why?
14:41 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #13712: wallet: Fix non-determinism in ParseHDKeypath(...). Avoid using an uninitialized variable in path calculation. (master...check-ParseUInt32-return-value) https://github.com/bitcoin/bitcoin/pull/13712
14:41 < jonasschnelli> sipa: it's unrelated to scantxoutset
14:42 < sipa> the third commit is called "Output descriptors module"
14:42 < sipa> you're looking at the PR title
14:42 < jonasschnelli> Damit! Got fooled by github. NM
14:42 < sipa> haha
14:47 -!- brianhoffman [~brianhoff@pool-108-31-201-103.washdc.fios.verizon.net] has joined #bitcoin-core-dev
14:47 < jonasschnelli> sipa: right now, each child key requires to derive the complete chain, right?
14:47 < sipa> jonasschnelli: there's a TODO to cache the bottom non-hardened key
14:48 < sipa> i can add that in the same PR if you want
14:48 < jonasschnelli> I guess that can be added later
14:48 < jonasschnelli> Performance should not mater in the context of scanning the whole utxo set
14:48 < jonasschnelli> (for other descriptor usages it may matter)
14:49 < jonasschnelli> so later should be fine
14:49 < sipa> right, agree
14:51 < achow101> it would be nice if we could also get #12493 in for 0.17
14:52 < gribble> https://github.com/bitcoin/bitcoin/issues/12493 | [wallet] Reopen CDBEnv after encryption instead of shutting down by achow101 · Pull Request #12493 · bitcoin/bitcoin · GitHub
14:53 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 276 seconds]
14:54 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
15:04 -!- meshcollider_ [uid246294@gateway/web/irccloud.com/x-twakpwozmfojhgfp] has joined #bitcoin-core-dev
15:05 -!- meshcollider_ [uid246294@gateway/web/irccloud.com/x-twakpwozmfojhgfp] has quit [Client Quit]
15:05 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
15:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
15:14 < meshcollider> So is the meeting time likely to stay as-is
15:15 < meshcollider> Sorry I missed this morning's
15:28 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
15:29 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 255 seconds]
15:30 -!- lari [~quassel@195.148.220.32] has quit [Remote host closed the connection]
15:31 -!- lari [~quassel@195.148.220.32] has joined #bitcoin-core-dev
15:37 -!- jamesob_ [~james@64-71-8-130.static.wiline.com] has joined #bitcoin-core-dev
15:37 -!- jamesob__ [~james@64-71-8-130.static.wiline.com] has joined #bitcoin-core-dev
15:39 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds]
15:40 -!- jtimon [~quassel@213.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
15:42 < jtimon> review beg https://github.com/bitcoin/bitcoin/pull/13311 , I'm waiting on that to rebase https://github.com/bitcoin/bitcoin/pull/8994
15:51 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
15:51 < aj> #13311 #8994
15:51 < gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
15:51 < gribble> https://github.com/bitcoin/bitcoin/issues/13311 | Dont edit Chainparams after initialization by jtimon · Pull Request #13311 · bitcoin/bitcoin · GitHub
15:54 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
15:56 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Ping timeout: 256 seconds]
16:01 -!- Squidicuz [~squid@pool-173-48-82-37.bstnma.fios.verizon.net] has quit [Read error: Connection reset by peer]
16:02 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 276 seconds]
16:06 -!- polydin [~delphi@2602:306:b8b6:b970:642b:403:836c:b702] has quit [Ping timeout: 240 seconds]
16:19 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Quit: drexl]
16:34 < aj> jtimon: you could tick the todo box for 12128 in 8994's description fwiw
16:37 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
16:39 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev
16:43 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 244 seconds]
16:45 < jtimon> aj: done, thanks
17:00 -!- adam3us [~adam3us@unaffiliated/adam3us] has quit [Ping timeout: 268 seconds]
17:02 -!- revstrangehope [~revstrang@ec2-13-115-230-7.ap-northeast-1.compute.amazonaws.com] has quit [Ping timeout: 268 seconds]
17:02 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 268 seconds]
17:03 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
17:06 -!- Netsplit *.net <-> *.split quits: joshb[m], Magma
17:07 -!- Netsplit *.net <-> *.split quits: keymone, michagogo, cornfeedhobo, treyzania, wumpus, brianhoffman, DougieBot5000, dongcarl, tylevine, justanotheruser,  (+4 more, use /NETSPLIT to show all of them)
17:07 -!- rev_strangehope [~revstrang@ec2-13-115-230-7.ap-northeast-1.compute.amazonaws.com] has joined #bitcoin-core-dev
17:07 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev
17:08 -!- adam3us [~adam3us@unaffiliated/adam3us] has joined #bitcoin-core-dev
17:10 -!- stepa[m] [stepamatri@gateway/shell/matrix.org/x-bkqxgzhoszjoyjip] has quit [Ping timeout: 256 seconds]
17:10 -!- squarfed[m] [squarfedma@gateway/shell/matrix.org/x-xrhjlcdhobsotdit] has quit [Ping timeout: 260 seconds]
17:10 -!- herzmeister[m] [herzmeiste@gateway/shell/matrix.org/x-yhyezbmbnimyzhzu] has quit [Ping timeout: 245 seconds]
17:10 -!- warren [~warren@fedora/wombat/warren] has quit [Ping timeout: 268 seconds]
17:11 -!- ajtowns[m] [ajtownsmat@gateway/shell/matrix.org/x-aoatcavyfmwdoyfz] has quit [Ping timeout: 276 seconds]
17:11 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-nqkhthnbgdprnbuv] has quit [Ping timeout: 276 seconds]
17:12 -!- adam3us [~adam3us@unaffiliated/adam3us] has quit [Ping timeout: 268 seconds]
17:15 -!- Netsplit over, joins: Magma
17:15 -!- Netsplit over, joins: brianhoffman, tylevine, keymone, DougieBot5000, davec, treyzania, Cory, dongcarl, justanotheruser, wumpus (+4 more)
17:15 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Max SendQ exceeded]
17:16 -!- warren [~warren@fedora/wombat/warren] has joined #bitcoin-core-dev
17:17 -!- adam3us [~adam3us@unaffiliated/adam3us] has joined #bitcoin-core-dev
17:18 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
17:46 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
17:47 -!- joshb[m] [joshbmatri@gateway/shell/matrix.org/x-zyzvnsyaqorlnibw] has joined #bitcoin-core-dev
18:08 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
18:09 -!- grafcaps [~haroldbr@104.137.194.255] has quit [Ping timeout: 276 seconds]
18:10 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
18:12 -!- jamesob__ [~james@64-71-8-130.static.wiline.com] has quit [Ping timeout: 240 seconds]
18:13 -!- jamesob_ [~james@64-71-8-130.static.wiline.com] has quit [Ping timeout: 240 seconds]
18:14 -!- Guest26115 [sid299882@gateway/web/irccloud.com/x-dfrukunqjmlhidem] has quit []
18:14 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]
18:26 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has joined #bitcoin-core-dev
18:34 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has quit [Ping timeout: 245 seconds]
18:39 -!- unixb0y [~unixb0y@p2E555F29.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds]
18:44 -!- unixb0y [~unixb0y@p2E555096.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
18:49 -!- stepa[m] [stepamatri@gateway/shell/matrix.org/x-zhvroknhocoitkgb] has joined #bitcoin-core-dev
18:49 -!- squarfed[m] [squarfedma@gateway/shell/matrix.org/x-oeijggkgoaswxxee] has joined #bitcoin-core-dev
18:49 -!- ajtowns[m] [ajtownsmat@gateway/shell/matrix.org/x-gelnqywvlwbenagi] has joined #bitcoin-core-dev
18:49 -!- herzmeister[m] [herzmeiste@gateway/shell/matrix.org/x-mlumhisqkqkdygci] has joined #bitcoin-core-dev
18:49 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-gnvekgigejlodqiv] has joined #bitcoin-core-dev
18:56 -!- jpe_ [~jpe@200116b842bfd600462d4a35161e02b7.dip.versatel-1u1.de] has joined #bitcoin-core-dev
18:58 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has joined #bitcoin-core-dev
19:00 -!- jpe__ [~jpe@i59F74C66.versanet.de] has quit [Ping timeout: 268 seconds]
19:06 < bitcoin-git> [bitcoin] achow101 opened pull request #13721: Bugfixes for BIP 174 combining and deserialization (master...psbt-fixes) https://github.com/bitcoin/bitcoin/pull/13721
19:12 -!- Squidicuz [~squid@pool-173-48-82-37.bstnma.fios.verizon.net] has joined #bitcoin-core-dev
19:20 -!- ken2812221__ [~ken281222@180.217.153.220] has joined #bitcoin-core-dev
19:23 -!- ken2812221_ [~ken281222@110.50.131.77] has quit [Ping timeout: 240 seconds]
19:34 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 276 seconds]
19:39 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds]
19:46 -!- ken2812221__ is now known as ken2812221
19:51 -!- ken2812221 [~ken281222@180.217.153.220] has quit [Ping timeout: 256 seconds]
19:57 -!- hendrik__ [~hendrik@84-46-57-93.lsn7.wtnet.de] has joined #bitcoin-core-dev
20:00 -!- hendrik_ [~hendrik@46-59-160-113.lsn7.wtnet.de] has quit [Ping timeout: 245 seconds]
20:06 -!- ken2812221 [~ken281222@180.217.95.66] has joined #bitcoin-core-dev
20:12 -!- polydin [~delphi@2602:306:b8b6:b970:4157:64ab:75d7:3f2b] has joined #bitcoin-core-dev
20:25 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has quit [Ping timeout: 276 seconds]
20:52 < kallewoof> I'm torn on https://github.com/bitcoin/bitcoin/pull/12257#discussion_r203741762 -- on the one hand, we want to give correct values for ancestor count; on the other hand, the reason ancestor count is taken into account is because we want to avoid too-long chains of unconfirmed transactions, which is separate. on the third (?) hand, the accurate ancestor count will give a hint at the number of ancestors the resulting transaction 
20:52 < kallewoof> will end up having, but on the fifth (!) hand, we want to give a rebate to eliminating multi-utxo-same-dest, and being too strict/accurate here might mean a lot of address reuse remains unspent indefinitely because it creates too many ancestors. in fact, the worse it gets (3,4,5 txs in same output group), the lower the chances the wallet will "fix" the issue.
20:53 < kallewoof> I missed the forth hand. Alas.
21:19 -!- ken2812221 [~ken281222@180.217.95.66] has quit [Ping timeout: 276 seconds]
21:20 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
21:24 -!- booyah [~bb@193.25.1.157] has joined #bitcoin-core-dev
21:34 -!- ken2812221 [~ken281222@180.217.95.66] has joined #bitcoin-core-dev
21:41 -!- jtimon [~quassel@213.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]
21:58 -!- farmerwampum [~farmerwam@88.202.178.98] has quit [Quit: farmerwampum]
22:00 -!- jtimon [~quassel@213.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
22:03 < jcorgan> kallewoof: "on the third (?) hand" <== "on the gripping hand" :-)
22:04 < kallewoof> jcorgan: ohh..
22:08 -!- jtimon [~quassel@213.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]
22:11 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has quit [Ping timeout: 255 seconds]
22:12 -!- ken2812221 [~ken281222@180.217.95.66] has quit [Ping timeout: 264 seconds]
22:36 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has joined #bitcoin-core-dev
22:40 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has quit [Ping timeout: 240 seconds]
22:51 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev
23:09 -!- RoBz [~RoBz@unaffiliated/robz] has quit [Ping timeout: 248 seconds]
23:20 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has joined #bitcoin-core-dev
23:21 -!- riemann_ [~riemann@217.96.163.212.ipv4.supernova.orange.pl] has joined #bitcoin-core-dev
23:25 -!- grafcaps [~haroldbr@050-090-083-229.res.spectrum.com] has quit [Ping timeout: 276 seconds]
23:26 -!- AHemlocksLie [~mikey@2605:6000:151e:c9e8:0:65ba:39ad:a11c] has quit [Quit: Leaving]
23:28 -!- riemann_ [~riemann@217.96.163.212.ipv4.supernova.orange.pl] has quit [Quit: Leaving]
23:37 -!- ken2812221 [~ken281222@110.50.145.134] has joined #bitcoin-core-dev
23:44 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
23:52 < bitcoin-git> [bitcoin] hmel opened pull request #13722: [Trivial] Use variable name instead of relying on class layout (master...use_varname_not_this) https://github.com/bitcoin/bitcoin/pull/13722
23:56 < gmaxwell> kallewoof: keep in mind, usually most inputs in a wallet are confirmed and have an ancestor count of zero.
23:57 < gmaxwell> in general the count handling in selection is really just there to get slightly less bad behavior in pathalogical cases.
23:57 < gmaxwell> Probably if your wallet is running out of confirmed outputs, you'd prefer to no longer group them.
23:58 < gmaxwell> (or at least unless you've decided you'd rather not transact at all than reduce your privacy.)
23:58 < gmaxwell> but in that case you should probably be completely avoiding spending unconfirmed coins.
23:58 < kallewoof> gmaxwell: Yeah, that's a good point.
23:58 < gmaxwell> Since any spend of an unconfirmed output is bad for your privacy.
23:58 < gmaxwell> (since it means that coin was change)
--- Log closed Fri Jul 20 00:00:16 2018