--- Log opened Tue Feb 19 00:00:54 2019
00:03 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
00:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:50 < bitcoin-git> [bitcoin] AkioNak opened pull request #15439: tests: remove byte.hex() to keep compatibility (master...keep_compatiblity) https://github.com/bitcoin/bitcoin/pull/15439
00:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:11 -!- siom [~siom@165.84.231.26] has joined #bitcoin-core-dev
01:21 -!- jungly [~quassel@79.8.200.97] has joined #bitcoin-core-dev
01:22 < wumpus> provoostenator: yes, such a dialog would be nice to have, though probably shouldn't be thrown in the user's face by default (to overwhelm them with choices), more like an 'advanced' wallet creation dialog
01:24 < gmaxwell> A general UI design principle is that if the developer doesn't know, the user also doesn't know. Also if you force the user user to choices they don't understand, they'll frequently set them randomly.  If they want to accomplish something specific, they'll go looking for it, and try using the first thing that sounds like it.
01:25 < wumpus> I mean, it would be for people that do know the functionality and want to choose themselves
01:27 < gmaxwell> absolutely. sorry.
01:28 < gmaxwell> My point is that if your usecase is something where the user will know they want it, it's fine to bury it... just make sure they won't find something else first while looking for it.
01:29 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
01:30 < wumpus> I'm also a bit skeptical about, say, the GNOME user interface design where the developer always makes the choices and settings and such are buried deeply in some kind of gconf nightmare tree
01:31 < wumpus> the "all GUI users are idiots" philosophy
01:31 < gmaxwell> oy. "you can edit the code if you are a power user" is not a great UI design principle. :P
01:31 < wumpus> yesss that's what I mean
01:31 < wumpus> even worse :P
01:31 < gmaxwell> (gconf is pretty much that... gconf settings aren't stable across versions... almost as bad as carrying patches)
01:32 < gmaxwell> The user uses the software specifically to avoid writing it and maintaining it themselves. :P
01:34 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Ping timeout: 246 seconds]
01:34 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
01:35 < gmaxwell> I am just imagining a create dialog with a text entry box where you can enter a seed, and then confused users not realizing they can ignore it, googling bitcoin seed and entering in some example they found online.. :P
01:37 < wumpus> that'd be a good example of terribly unsafe GUI design, yes, meant as useful functionality but it only serves as a trap for the unknowing
01:38 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
01:43 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection]
01:44 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
01:45 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]
01:50 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
01:50 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
02:22 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has quit [Ping timeout: 256 seconds]
02:34 -!- zhangzf [~zhangzf@106.38.157.147] has quit [Remote host closed the connection]
02:36 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
02:38 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 246 seconds]
03:07 -!- darosior [52ff9820@gateway/web/freenode/ip.82.255.152.32] has joined #bitcoin-core-dev
03:07 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Remote host closed the connection]
03:08 < provoostenator> It helps not to cram too much on a single screen. Instead you can e.g. have a button "Recover an existing wallet" which takes you to another screen which then handles the various options. 
03:08 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
03:09 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 246 seconds]
03:10 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
03:16 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
03:21 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 245 seconds]
03:37 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev
03:39 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]
03:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:48 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
03:55 -!- DougieBot5000_ [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-core-dev
03:58 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Ping timeout: 245 seconds]
04:04 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
04:05 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has joined #bitcoin-core-dev
04:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds]
04:26 -!- m8tion [~user@2a01:e35:8bef:9310:2d12:85d8:eaf8:3005] has joined #bitcoin-core-dev
04:30 -!- zhangzf [~zhangzf@120.244.117.148] has joined #bitcoin-core-dev
04:33 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit []
04:45 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has quit [Remote host closed the connection]
04:45 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has joined #bitcoin-core-dev
04:47 -!- Karyon [~karyon@unaffiliated/karyon] has joined #bitcoin-core-dev
04:51 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]
05:02 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds]
05:05 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:13 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
05:17 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
05:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:27 < bitcoin-git> [bitcoin] Sjors opened pull request #15441: [doc] build: warn against spaces in working directory (master...2019/02/build_discourage_space) https://github.com/bitcoin/bitcoin/pull/15441
05:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:43 -!- zhangzf [~zhangzf@120.244.117.148] has quit [Remote host closed the connection]
05:47 -!- Karyon [~karyon@unaffiliated/karyon] has quit [Ping timeout: 268 seconds]
05:49 -!- zhangzf [~zhangzf@120.244.117.148] has joined #bitcoin-core-dev
05:53 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
05:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
05:58 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 244 seconds]
06:02 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 256 seconds]
06:09 < wumpus> eek, kinda unbelievable that spaces in directory names is still a problem in 2019 :/
06:10 < wumpus> this means there's some very unygyenic code somewhere
06:10 < wumpus> unhygienic*
06:10 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 268 seconds]
06:12 < luke-jr> maybe we need to use it in test dirs in addition to unicode
06:12 < wumpus> I'd much prefer that solution to "put a warning in all docs", this really doesn't look good on us
06:14 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev
06:15 -!- Karyon [~karyon@unaffiliated/karyon] has joined #bitcoin-core-dev
06:15 -!- kexkey [~kexkey@87.101.92.74] has joined #bitcoin-core-dev
06:38 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]
06:39 -!- Guyver2 [~Guyver@2001:985:f3f:1:39c2:c3d2:b6ba:8f46] has joined #bitcoin-core-dev
06:46 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 256 seconds]
06:46 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
06:49 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Read error: Connection reset by peer]
06:49 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:49 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
06:50 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev
06:51 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #bitcoin-core-dev
06:54 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 268 seconds]
06:56 < promag> why this fails? getdescriptorinfo('pk(xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8)')
06:58 < wumpus> what error do you get ?
06:58 < promag> Invalid descriptor
06:58 < promag> thats straight from doc/descriptors.md
06:59 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
07:01 < wumpus> might be it's for the wrong network (regtest/testnet or mainnet)
07:03 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 272 seconds]
07:03 < harding> promag: works for me via bitcoin-cli on mainnet using commit 4064d048d6 (master from Sunday).  Rebuilding now to try on latest.
07:04 < promag> ok then it's what wumpus said
07:04 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 256 seconds]
07:05 < wumpus> might be useful to mention the network that was used for the example, in descriptors.md
07:07 -!- mildly_risky [~~mildly_r@n119236211227.netvigator.com] has joined #bitcoin-core-dev
07:08 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 258 seconds]
07:09 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev
07:09 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev
07:11 < instagibbs> GAit, I'd be willing to champion 10823 if you don't have the time
07:15 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev
07:16 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has quit [Read error: Connection reset by peer]
07:16 < sipa> promag: xpub is for mainnet
07:17 < provoostenator> Ideally we would have a way for RPC help to spit out correct examples for mainnet, testnet and regtest.
07:17 < provoostenator> I've made this mistake a few times too.
07:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:18 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/904308dca3ff...3e4fd4075381
07:18 < bitcoin-git> bitcoin/master e3e1a56 Sjors Provoost: [test] functional: set cwd of nodes to tmpdir
07:18 < bitcoin-git> bitcoin/master 3e4fd40 MarcoFalke: Merge #15415: [test] functional: allow custom cwd, use tmpdir as default
07:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:19 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15415: [test] functional: allow custom cwd, use tmpdir as default (master...2019/02/test_cwd) https://github.com/bitcoin/bitcoin/pull/15415
07:19 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has joined #bitcoin-core-dev
07:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:19 < wumpus> a more specific error might be nice too
07:20 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 256 seconds]
07:20 -!- darosior [52ff9820@gateway/web/freenode/ip.82.255.152.32] has quit [Ping timeout: 256 seconds]
07:20 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev
07:23 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection]
07:24 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev
07:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:25 < bitcoin-git> [bitcoin] promag opened pull request #15443: qa: Add getdescriptorinfo functional test (master...2019-02-qa-feature-descriptor) https://github.com/bitcoin/bitcoin/pull/15443
07:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:28 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection]
07:28 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev
07:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:32 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3e4fd4075381...38429c4b6228
07:32 < bitcoin-git> bitcoin/master 8e4b4f6 Amiti Uttarwar: Address test todos by removing -txindex to nodes.
07:32 < bitcoin-git> bitcoin/master 38429c4 Wladimir J. van der Laan: Merge #15404: [test] Remove -txindex to start nodes
07:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:33 < bitcoin-git> [bitcoin] laanwj merged pull request #15404: [test] Remove -txindex to start nodes (master...remove_txindex) https://github.com/bitcoin/bitcoin/pull/15404
07:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:36 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has joined #bitcoin-core-dev
07:41 -!- riordant [~riordant@101.108.104.66] has joined #bitcoin-core-dev
07:42 -!- riordant [~riordant@101.108.104.66] has left #bitcoin-core-dev []
07:42 -!- riordant [~riordant@101.108.104.66] has joined #bitcoin-core-dev
07:43 < riordant> Hello, I have a question about this commit: https://github.com/bitcoin/bitcoin/commit/d6712db
07:43 < riordant> Why was the pid file creation explicitly removed for Windows? 
07:44 < wumpus> there was never PID file creation for windows
07:44 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has quit [Read error: Connection reset by peer]
07:44 < wumpus> it requires pid_t type which doesn't exist there
07:44 < wumpus> and getpid()
07:45 -!- kexkey [~kexkey@87.101.92.74] has quit [Read error: Connection reset by peer]
07:46 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has joined #bitcoin-core-dev
07:47 < wumpus> (if you look at the state before that commit, the CreatePidFile was already in #ifndef WIN32 before that)
07:48 < riordant> Ok sure, thanks. How is process identification handled on Windows in that case?
07:49 < wumpus> tbh I have no idea, but if you figure that out you could add PID file functionality for windows
07:50 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
07:51 < wumpus> fairly sure that windows does have process ids, but the API to figure them out is different
07:55 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
07:58 -!- shesek [~shesek@141.226.152.217] has joined #bitcoin-core-dev
07:58 -!- shesek [~shesek@141.226.152.217] has quit [Changing host]
07:58 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
07:59 -!- rex4539 [~rex4539@2a02:587:3507:7600:1a2:4d22:62ab:fc55] has joined #bitcoin-core-dev
08:02 -!- zhangzf [~zhangzf@120.244.117.148] has quit [Remote host closed the connection]
08:02 -!- rex4539 [~rex4539@2a02:587:3507:7600:1a2:4d22:62ab:fc55] has quit [Client Quit]
08:04 < instagibbs> provoostenator, I don't think it'd be crazy to dynamically generate key-related material for help
08:05 < instagibbs> then you just call EncodeDestination() etc
08:05 < wumpus> I do think the help should be deterministic, as it's used to generate webpages and such
08:05 < instagibbs> It can be
08:05 < wumpus> so please no random examples that change every time
08:06 < wumpus> yes, I'm not trying to say that you were intending that, but just thought it needed saying just in case :)
08:06 < luke-jr> if only rwconf were allowed to modify bitcoin.conf directly, we could have a nice key/value config editor.. https://twitter.com/kakabakasa/status/1097764863168909313
08:06 < instagibbs> :) only returns a result if vanitygen returns something starting with `1Example`
08:07 < luke-jr> otoh, maybe a key/value editor that changes bitcoin_rw.conf would be sufficient? dunno
08:07 < wumpus> well bitcoin_rw.conf overrides bitcoin.conf so...
08:07 < wumpus> could be used for exactly the same
08:08 < luke-jr> yeah, I guess it would work
08:09 < luke-jr> on another note, I wonder if we actually need txindex to require reindex anymore.. now that it's separate, I guess as long as the user hasn't pruned, it could probably be built post-hoc
08:09 < wumpus> that would be nice
08:09 < luke-jr> (and destroying post-hoc seems trivial)
08:10 < wumpus> yes
08:10 < wumpus> there's no conceptual reason why making an index requires wiping all indices, this is just how it happens to be right now
08:11 -!- siom_ [~siom@cpc107639-dals20-2-0-cust128.20-2.cable.virginm.net] has joined #bitcoin-core-dev
08:13 -!- siom [~siom@165.84.231.26] has quit [Ping timeout: 240 seconds]
08:13 < luke-jr> I guess -txindex=0 shouldn't destroy an existing index, maybe -txindex=delete
08:14 < wumpus> I'm not sure it's worth changing that at this point
08:17 < wumpus> in principle, if it wasn't bound to reindex, the action of creating/destroying an transaction could even be an RPC command instead of a command line option
08:17 < wumpus> s/an transction/an index/
08:17 < luke-jr> oh, someone already did this
08:17 < wumpus> oh
08:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:18 < bitcoin-git> [bitcoin] Sjors opened pull request #15444: [docs] Additional productivity tips (master...2019/02/typo-productivity) https://github.com/bitcoin/bitcoin/pull/15444
08:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:19 -!- kexkey [~kexkey@192.230.35.147] has joined #bitcoin-core-dev
08:29 -!- mildly_risky [~~mildly_r@n119236211227.netvigator.com] has quit [Read error: Connection reset by peer]
08:33 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection]
08:35 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
08:37 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
08:39 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 246 seconds]
08:45 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
08:47 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev
08:50 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 250 seconds]
08:54 -!- pinheadmz [~matthewzi@104-56-112-203.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
08:57 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 268 seconds]
08:57 -!- rh0nj [~rh0nj@88.99.167.175] has joined #bitcoin-core-dev
09:14 -!- siom_ [~siom@cpc107639-dals20-2-0-cust128.20-2.cable.virginm.net] has quit [Ping timeout: 272 seconds]
09:15 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-bqeijebjubihzbrb] has joined #bitcoin-core-dev
09:16 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
09:21 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 268 seconds]
09:21 -!- kexkey [~kexkey@192.230.35.147] has quit [Ping timeout: 255 seconds]
09:26 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Ping timeout: 268 seconds]
09:28 < cjd> What was the reason for aa21a9ed ?   Just some bytes which are unlikely to collide with anything ?
09:28 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 255 seconds]
09:29 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev
09:33 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has quit [Ping timeout: 256 seconds]
09:33 -!- riordant [~riordant@101.108.104.66] has quit [Remote host closed the connection]
09:34 < provoostenator> cjd: which aa21a9ed?
09:35 < cjd> segwit root hash magic
09:35 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Quit: Textual IRC Client: www.textualapp.com]
09:35 < provoostenator> Oh ok, I thought it was a commit that accidentally collided with that :-)
09:38 -!- Karyon [~karyon@unaffiliated/karyon] has quit [Ping timeout: 252 seconds]
09:40 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
09:40 < cjd> oh yeah, without context it can definitely look like a git short hash
09:41 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]
09:41 < provoostenator> sipa says it's random: https://bitcoin.stackexchange.com/questions/59299/why-is-the-bytestring-0xaa21a9ed-used-as-the-witness-commitment-header-in-segwit
09:42 < provoostenator> But not how the random thing was chosen :-) But yes it seems to have been to make collision unlikely enough, but blocks not much bigger.
09:43 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
09:44 -!- jtimon [~quassel@119.24.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
09:47 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 272 seconds]
09:48 < cjd> ahh cool
09:48 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
09:51 -!- Karyon [~karyon@unaffiliated/karyon] has joined #bitcoin-core-dev
09:56 < luke-jr> eh, outputs aren't random. a collision is avoided by just not colliding.
09:56 < luke-jr> so long as there's *some* 32 bits there, other proposals just avoid using the same 32-bit value
09:56 < provoostenator> luke-jr the 0xaa21a9ed prefix is random
09:56 < luke-jr> provoostenator: it doesn't need to be, is my point
09:58 < jarthur> I've been meaning to ask about the witness reserved value. BIP 141 seems to indicate that it can be anything, and yet also that it might have future consensus meaning. Is there any way to pick a witness reserved value that won't collide with future soft forks without knowing how those soft forks will use the field?
09:59 < sipa> jarthur: just don't use it for anything and you're fine
09:59 < jarthur> sipa: but if I'm a miner, what should I set it to in my new blocks?
09:59 < sipa> whatever.
10:00 < sipa> that comment means that it shouldn't be used to convey any meaning, because that meaning may be constrained in the future
10:00 < sipa> just set it to zeroes
10:00 < sipa> or to "blahblahblahblah"
10:01 < luke-jr> well, if it's constrained in the future, setting it non-zero may make blocks invalid, no?
10:01 < provoostenator> Oh, the way I read BIP-141 is that it must be exactly 0xaa21a9ed.
10:01 < sipa> provoostenator: jarthur is asking about something unrelated
10:01 < luke-jr> provoostenator: the topic changed
10:01 < sipa> (witness reserved value vs witness coinbase commitment)
10:03 < jarthur> sipa, if we need to constrain its meaning in the future, will we need to look back what what values have been used by miners to make sure there's no collision? Could a miner troll us by incrementing it like a nonce over years to ensure there are less available reserved values for soft-forking purposes?
10:03 < sipa> jarthur: no?
10:03 < provoostenator> jarthur: I assume a future soft fork won't care about historical values before it was activated
10:03 < sipa> the softfork will obviously only affect future values, not ones in the past
10:04 < jarthur> OK, great, thanks :)
10:06 < luke-jr> well, it'd potentially make the code cleaner after the softfork activates, if we can just have it unconditional
10:06 < luke-jr> so it'd be *nice* of miners didn't make blocks with potentially-conflicting values :p
10:07 < sipa> sure
10:07 < sipa> but if they do, so be it
10:07  * luke-jr nods
10:13 -!- DougieBot5000_ is now known as DougieBot5000
10:36 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
10:39 -!- jcorgan [~jcorgan@64-142-68-61.dsl.static.sonic.net] has joined #bitcoin-core-dev
10:39 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
10:41 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has joined #bitcoin-core-dev
10:44 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 240 seconds]
11:20 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
11:24 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Ping timeout: 250 seconds]
11:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
11:30 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
11:35 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 250 seconds]
11:37 -!- bigcookie101 [~bigcookie@chboston-pool-1-1.tch.harvard.edu] has joined #bitcoin-core-dev
11:38 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
11:41 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
11:41 -!- bigcookie101 [~bigcookie@chboston-pool-1-1.tch.harvard.edu] has quit [Client Quit]
11:42 -!- bigcookie101 [~bigcookie@chboston-pool-1-1.tch.harvard.edu] has joined #bitcoin-core-dev
11:42 -!- bigcookie101 [~bigcookie@chboston-pool-1-1.tch.harvard.edu] has quit [Client Quit]
11:43 -!- bigcookie101 [~bigcookie@chboston-pool-1-1.tch.harvard.edu] has joined #bitcoin-core-dev
11:43 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has quit [Quit: (https://github.com/mmgen) leaving]
11:45 -!- bigcookie101 [~bigcookie@chboston-pool-1-1.tch.harvard.edu] has quit [Client Quit]
11:46 -!- bigcookie101 [~bigcookie@chboston-pool-1-1.tch.harvard.edu] has joined #bitcoin-core-dev
11:46 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 250 seconds]
11:56 -!- bigcookie101 [~bigcookie@chboston-pool-1-1.tch.harvard.edu] has quit [Quit: WeeChat 1.9.1]
11:57 -!- bigcookie101 [~bigcookie@chboston-pool-1-1.tch.harvard.edu] has joined #bitcoin-core-dev
11:58 -!- jarthur_ [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
12:01 -!- jarthur [~jarthur@207.114.244.5] has quit [Ping timeout: 272 seconds]
12:07 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 250 seconds]
12:12 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
12:15 -!- jarthur_ is now known as jarthur
12:16 -!- riordant [~riordant@101.108.105.3] has joined #bitcoin-core-dev
12:16 -!- bigcookie101 [~bigcookie@chboston-pool-1-1.tch.harvard.edu] has quit [Ping timeout: 272 seconds]
12:17 -!- bigcookie101 [bigcookie1@gateway/vpn/privateinternetaccess/bigcookie101] has joined #bitcoin-core-dev
12:20 -!- bigcookie101 [bigcookie1@gateway/vpn/privateinternetaccess/bigcookie101] has quit [Client Quit]
12:23 -!- bigcookie101 [bigcookie1@gateway/vpn/privateinternetaccess/bigcookie101] has joined #bitcoin-core-dev
12:30 -!- jarthur [~jarthur@207.114.244.5] has quit []
12:30 -!- Karyon [~karyon@unaffiliated/karyon] has quit [Quit: Leaving]
12:32 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
12:34 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
12:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:37 < bitcoin-git> [bitcoin] hebasto opened pull request #15445: [0.17] backport #14409 (0.17...20190219-backport-pr14409) https://github.com/bitcoin/bitcoin/pull/15445
12:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:39 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection]
12:42 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
12:43 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 268 seconds]
12:46 -!- sdaftuar [~sdaftuar@238.90.227.35.bc.googleusercontent.com] has quit [Changing host]
12:46 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev
12:55 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
12:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
13:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:02 < bitcoin-git> [bitcoin] dongcarl opened pull request #15446: Improve depends debuggability (master...2019-02-improve-depends-debuggability) https://github.com/bitcoin/bitcoin/pull/15446
13:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:02 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.3]
13:04 < luke-jr> jl2012: I don't understand your last email. My point is, if you don't want NOINPUT, it should be sufficient to just not sign with NOINPUT..
13:05 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
13:09 -!- Guyver2 [~Guyver@2001:985:f3f:1:39c2:c3d2:b6ba:8f46] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
13:09 < gmaxwell> luke-jr: unfortunately no. If noinput can show up anywhere, then if you cannot _guarentee_ that you'll never pay to an address twice (e.g. splitting a payment in two in order to pay from both a hot and cold wallet) then you can only pay to 1xxx addresses.  Otherwise you risk paying, having the payee noinput spend, and then having funds get lost.  Then they get embroiled in some stupid lawsuit 
13:09 < gmaxwell> overwhos fault it was.   That kind of footgun isn't what you expect from bitcoin engineering, it sounds like something ethereum would do.
13:10 < gmaxwell> (also are you responding to messages that aren't on the list? -- I don't see any really recent message from jl2012)
13:12 < luke-jr> gmaxwell: I guess the list copies are waiting for moderation
13:12 < luke-jr> sending twice to the same address is always the sender's fault and should be considered undefined behaviour
13:13 < gmaxwell> personally I prefer noinput be dropped from the proposal for now-- it's basically caused months of delays now at this point. And the initial schnorr support already doesn't support aggregation or graftroot, so we know there needs to be a subsiquent version regardless.
13:14 < gmaxwell> luke-jr: Perhaps, but thats not relevant.  It is bad engineering to make a small (and fundimentally very hard to avoid mistake) into a reckless one.  Look at all the extreme money losing things that we've mocked in eth land, almost all of them also involved mistakes on the user's part.
13:14 < gmaxwell> Good engineering isn't just building something that works if you use it perfectly.
13:14 < luke-jr> gmaxwell: it's already reckless. there's no guarantee it works today.
13:14 < gmaxwell> It's also about building something that fails gracefully.
13:15 < luke-jr> IMO it's not much different from accidentally sending with the wrong fee
13:16 < luke-jr> these are things user applications can try to protect, but not things the protocol should be trying to second-guess
13:16 < gmaxwell> and we worked hard to make that less possible, e.g. segwit inputs sign the input amounts now.
13:17 < gmaxwell> luke-jr: and reuse is fundimentally hard to guarentee never happens, you essentially need a consensus system to do so.
13:17 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Remote host closed the connection]
13:17 < luke-jr> you could avoid wrong fee without signing input amounts - the benefit there was to avoid the extra data needed for it
13:18 < luke-jr> a person can easily avoid sending to the same address twice, and since addresses aren't meant to be reused, no more than one person should ever be on the sender side
13:18 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has joined #bitcoin-core-dev
13:18 < luke-jr> you don't need a consensus system to coordinate a single sender's actions
13:19 < luke-jr> (and if someone sees the address on the network and sends to it too - there are obvious ways to deal with that)
13:19 < gmaxwell> People do accidentally double pay, today. It happens, it's not conjecture.  People also do intentionally split one payment into two txouts.
13:19 < gmaxwell> "obvious ways to deal with that" is handwaving.
13:20 < luke-jr> you just display only the higher value one as confirmed; or spend them all together and ignore future outputs to that key; etc
13:20 < harding> luke-jr: let's say you design a wallet to always sign noinput, as you've proposed.  Alice sends a large payment to Bob with a low fee, accepting that it'll take several days to confirm.  Griefer Mallory sees that tx in the mempool and sends a tiny payment with a high fee to the same address.  Your wallet receives Mallory's payment and happens to respend it with noinput before Alice's payment confirms.  Now Alice's payment can be 
13:20 < harding> stolen even though Alice herself didn't engage in address reuse.
13:21 < gmaxwell> If you've even seen the 'higher one' yet.  (so your 'obvious way' requires as a starting premise that wallets ignore all unconfirmed transactions, and arguable all non-deeply confirmed transactions, since there still could be a reorg)
13:21 < luke-jr> harding: you're assuming Bob is offline at the time and doesn't see Alice's until after spending Griefer's?
13:21 < harding> luke-jr: we can't guarantee Bob has a complete view of all possible mempools in any case.
13:22 < luke-jr> gmaxwell: I don't see why you say ignoring unconfirmed; just not showing them as confirmed, since they aren't
13:22 < gmaxwell> because if you spend the wrong one you'll burn money. not showing them as confirmed isn't enough.
13:22 < luke-jr> harding: okay, I see how that can be a concern; but it's one easily addressed by just not implementing a wallet using NOINPUT that way
13:23 -!- booyah_ is now known as booyah
13:23 < luke-jr> arguably if you do so anyway, it's the same as picking the wrong fee would be
13:23 < gmaxwell> (to be clear, I want to have the functionality eventually, but it clearly has risky implications and has now added months of delay to an otherwise mostly complete proposal)
13:23 < gmaxwell> (which was exactly the reason that graftroot and aggregation were left out)
13:24 < luke-jr> harding: (also, actually, since the value in signed, I think I can argue your threat model is not a real issue, but that's beside the main point: that these limits shouldn't be at the protocol level)
13:25 < luke-jr> is signed*
13:25 < gmaxwell> value being signed is just one of the first protections that were added to make this not a complete disaster proposal...
13:25 < luke-jr> (because even if Griefer's UTXO is the one that gets seen/spent first, it still paid the correct amount to the address given to Alice, so it doesn't actually matter if Alice's UTXO gets lost)
13:26 < gmaxwell> unfortunately there are still a lot of really easy loss vectors even with that mitigation. Months have now been spent trying to cook up better mitigations.
13:26 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 245 seconds]
13:27 < luke-jr> gmaxwell: but my point is that for a protocol level feature, just saying "don't do that" is a reasonable mitigation
13:27 < luke-jr> these things can/should be addressed by the wallet software
13:31 -!- lucky8277 [4b707483@gateway/web/freenode/ip.75.112.116.131] has joined #bitcoin-core-dev
13:31 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-bqeijebjubihzbrb] has quit [Quit: Connection closed for inactivity]
13:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
13:34 -!- lucky8277 [4b707483@gateway/web/freenode/ip.75.112.116.131] has quit [Client Quit]
13:50 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]
13:51 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
13:52 -!- TheRec [~toto@drupal.org/user/146860/view] has quit []
14:01 -!- cornfeedhobo [~cornfeedh@unaffiliated/cornfeed] has quit [Quit: ZNC - https://znc.in]
14:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
14:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds]
14:09 -!- TheRec [~toto@84-72-172-174.dclient.hispeed.ch] has joined #bitcoin-core-dev
14:09 -!- TheRec [~toto@84-72-172-174.dclient.hispeed.ch] has quit [Changing host]
14:09 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-dev
14:12 -!- cornfeedhobo [~cornfeedh@unaffiliated/cornfeed] has joined #bitcoin-core-dev
14:16 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has quit [Read error: Connection reset by peer]
14:17 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has quit [Quit: Textual IRC Client: www.textualapp.com]
14:18 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
14:21 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
14:26 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]
14:27 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
14:28 -!- bigcookie101 [bigcookie1@gateway/vpn/privateinternetaccess/bigcookie101] has quit [Quit: WeeChat 1.9.1]
14:29 < gmaxwell> luke-jr: thats like saying ECDSA as it originally was because "use a strong random number and don't repeat it" is a reasonable mitigation.
14:29 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
14:29 < gmaxwell> In reality that approach causes failure after failure after failure.
14:29 < gmaxwell> At some point the designer of a system cannot credibly fob off fault onto the users.
14:30 < gmaxwell> We build systems to be used by real people, not platonic errorless perfectly knowledgable people.
14:31 < gmaxwell> We do know how to make noinput safer but it has been slowing down the work on this functionality.
14:31 < gmaxwell> We already set aside graftroot and aggregation, both of which are significanly more valuable than no input, in the interest of focus and time.
14:33 < sipa> the argument why it was included in the first place also disappears if we're aimimg for output tagging (because doing it separately would inherently require a "tag" as in a separate witness version)
14:34 < luke-jr> gmaxwell: yet we don't try to enforce random number strength in the consensus protocol
14:34 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
14:35 < sipa> luke-jr: can we?
14:36 < gmaxwell> luke-jr: we would if we could but we can't so we don't.
14:36 < luke-jr> sipa: you would know better than me, but not that I'm aware of
14:36 < gmaxwell> But bip schnorr proscibes a secure procedure-- which can be easily followed, it doesn't just say "this has to be random, good luck!"
14:36 < luke-jr> gmaxwell: why don't we enforce the absurd fee policy as a consensus rule?
14:37 < booyah> uhm is this not typical for crypto protocols to start with "we assume you can provide good, unique, randomness"?
14:37 < gmaxwell> luke-jr: because it has to change over time, otherwise I would say we probably should.
14:37 < gmaxwell> booyah: For an academic analysis, sure. For a pratical engineered system for people to actually use-- only incompetent ones that cause misery to their users.
14:37 < booyah> and as separate consideration we could provide algorithms to try to improve on OS-provided random
14:38 < gmaxwell> you won't find any crypto apps that just prompts there user to proide randomness or some such stupid thing. :)
14:38 < booyah> is bitcoin somehow improving strength of normal random as provided by OS specific api?
14:38 < gmaxwell> (or to the extent that they do, like brainwallets tools, they cause continual failure)
14:38 < gmaxwell> booyah: yes, though you're offtopic.
14:38 < booyah> gmaxwell: well not user, I mean the OS random source
14:39 < gmaxwell> booyah: bip-schnorr doesn't need any randomness for signing at all.  (nor does our ecdsa implementation... but clasical by the book ECDSA does, and as a result is an ocean of failure)
14:40 < luke-jr> there are lots of easy ways to make mistakes that we can't prevent. I don't see why preventing a few unusual cases by limiting functionality is a good idea.
14:40 < gmaxwell> Whats being limited? there is no way to noinput today. The system was designed otherwise, and having it really throughly breaks assumptions.
14:40 < luke-jr> in this case, going out of the way to prevent me from using NOINPUT the way I intend to
14:41 < gmaxwell> oh so sad poor luke
14:41  * booyah quietly pulls out a violin
14:43 < sipa> luke-jr: what do you hope to gain from using noinput as you intend to?
14:44 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
14:44 < luke-jr> sipa: eg, keeping txids for later spends (of unconfirmed change) the same even if the transaction producing the change needs a fee bump; without keeping an exponential number of signed transactions prepared
14:46 < gmaxwell> that only works right if all subsiquent transactions are themselves no-input.
14:46 < gmaxwell> so a katamari of replay attack vulnerablity. :)
14:46 < luke-jr> which they would be in such a wallet where everything is noinput
14:46 < gmaxwell> luke-jr: not the recipents spends.
14:47 < luke-jr> the recipient of the fee-bumped one would be affected, but nothing else?
14:48 < luke-jr> or, what do you mean?
14:48 < gmaxwell> the whole chain is invalidated unless all txn in it use noinput for all of their inputs.
14:48 < luke-jr> but the recipients aren't in the chain of change
14:50 < gmaxwell> they get the payments, not the change itself. (obviously thats why you have change: you made payments)
14:51 < luke-jr> but that doesn't break the chain of change
14:51 < luke-jr> the next transaction would have an unchanged txid
14:52 < luke-jr> (also, unrelated to a mere simple wallet: what if you want someone paying you, to send directly into a smart contract that relies on NOINPUT?)
14:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
14:53 < gmaxwell> luke-jr: no input doesn't keep the inputs out of the txids.  so if you pay1->pay2->pay3->pay4  all with no input and alter pay2 the txids of all the subsiquent txn (pay3/pay4/ and all their children) change too.
14:53 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
14:53 < luke-jr> hmm, right
14:55 < luke-jr> that only messes up the recipients not using noinput wallets, though
14:55 < gmaxwell> 14:46:41 < gmaxwell> so a katamari of replay attack vulnerablity. :)
14:56 < luke-jr> another use case: if the person paying me does some fee bumping, using noinput avoids resigning
14:56 < gmaxwell> Ethereum has better replay prevention than no input, and still replay there has caused massive funds loss, annoying DOS, etc.
14:56 < luke-jr> but in this case, replay isn't a problem since addresses aren't reused
14:57 < gmaxwell> basically noinput = accounts model, instead of utxo model; with the tradeoffs that implies.
14:57 < luke-jr> or unique-script UTXO model
14:58 < gmaxwell> one coulde use ethereum accounts exactly once. but because the system doesn't guarentee it, you can't count on it.
14:59 < luke-jr> since NOINPUT still commits to the amount, it's basically harmless to count on it
15:01 < gmaxwell> that kind of thinking is why it is so unsafe.
15:01 < gmaxwell> So thanks for making the point.
15:02 < luke-jr> am I wrong?
15:02 -!- unknown-os [~root@host-81-190-236-134.dynamic.mm.pl] has joined #bitcoin-core-dev
15:03 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]
15:03 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
15:03 -!- unknown-os [~root@host-81-190-236-134.dynamic.mm.pl] has left #bitcoin-core-dev []
15:04 < gmaxwell> Yes. So for example, the not that uncommon pattern of splitting a payment in half to pay from two different wallets. wham 50% funds loss.
15:04 < gmaxwell> that isn't even 'reuse' thats just two outputs at effectively the same time.  That has never before been a problem in the system, so it's a new footgun behavior that arises out of nowhere.
15:05 < luke-jr> that's reuse and undefined behaviour..
15:06 < gmaxwell> according to _you_.
15:06 < gmaxwell> Not according to how bitcoin has always worked.
15:06 < gmaxwell> And certantly not according to what people already do.
15:06 < gmaxwell> Advisable or not, reuse is ubiquitous. The majority of circulating bitcoins are stored in reused addresses.
15:06 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
15:07 < gmaxwell> You are saying that it's just fine to turn something that people ubiquitously do today into a massive footgun.
15:07 < gmaxwell> I can't abide by that.
15:07 < luke-jr> it's already a footgun.
15:07 < gmaxwell> Worse, instead of saying "yes, I know its dangerous and it will cause funds loss, it's worth it" -- instead you argue that it's "basically harmless".
15:08 < luke-jr> nothing obliges the recipient to acknowledge the second payment to the same address
15:08 < gmaxwell> Although its theoretically possible, I am aware of _no_ instance where funds have been loss due to a near term reuse.  (like sending again on the same day)
15:09 < luke-jr> that's like when people say light wallets are okay because nobody's ever lost funds due to their lack of security
15:09 < booyah> are you talking about two people sending e.g. 1 btc, on same day, to same one e.g. donation address of someone?
15:10 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
15:10 < gmaxwell> luke-jr: I am not saying that reuse is good. It's inadvisable in most cases.  But there is a big difference between something being inadvisable and rigging it to explode. 
15:11 < luke-jr> gmaxwell: I've seen it very nearly explode at least once personally.
15:11 < luke-jr> without NOINPUT
15:12 < gmaxwell> luke-jr: you've had years where you could have also written wallet features in bitcoin core to do stuff like pop up a message saying "You're paying to an address you've paid to before. Is this a mistake? Address reuse can be a symptom of a mistaken double payment and can lead to privacy or funds loss".   but apparently it wasn't important enough to you to bother.
15:12 < gmaxwell> But now it's important enough to you that you think it's no concern to adjust the consensus rules so that behavior will actually lead to funds loss, and not just a fringe risk.
15:13 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Remote host closed the connection]
15:13 < gmaxwell> (or likewise, inbound payments that reused your addresses could get frowny red recycle icons)
15:15 < booyah> I guess, if it is that Alice twice pays to same address of Bob, then it might be impossible to detect in some cases, especially if due to crash and recover from backup she lost local information that she is sending to Bob, and if when she restored then first transaction is in someone's mempool but not yet in block and not visible to it(?)
15:15 < gmaxwell> indeed.
15:15 < aj> luke-jr: noinput sigs sign the amount, so if you feebump the change will be a different value and the noinput sig spending that change will be invalid
15:15 < luke-jr> booyah: that's not a new problem with noinput
15:16 < gmaxwell> luke-jr: but it does invalidate the case you gave for it.
15:16 < gmaxwell> booyah: it's difficult to guarentee that a double payment _never_ happen even if you're trying. 
15:17 < gmaxwell> booyah: and in bitcoin today users generally assume addresses can be reused. It's not a great assumption.
15:17 < booyah> I guess instant backups, kind of like watchtowers in a way, could help, where you commit to them first, and on restart of client it queries them to make sure
15:17 < gmaxwell> They also assume you can go pull an address out of a block explorer and pay to it. 
15:17 < gmaxwell> booyah: right, with enough protection and complexity you can make it arbritarily rare. 
15:17 < luke-jr> gmaxwell: maybe there's too much focus on a specific use case? are you really saying that there is no situation where it would be useful to receive a payment directly into a multi-transaction smart contract that needs noinput?
15:18 < gmaxwell> It's not clear to me that it would, at least the lightning stuff proposed can't work that way.
15:18 < gmaxwell> But even if it is useful, that utility has to be weighed against the risk increase for all other usage.
15:19 < luke-jr> the only reason you can't have someone pay directly into a Lightning channel in such a manner, is because of non-segwit inputs, right?
15:19 < gmaxwell> luke-jr: no, because they have to be able to resign if the transaction fails (even with no-input)
15:20 < gmaxwell> (also, if it became justified to do that, it could be done later... along with whatever was needed to make it safer)
15:20 < luke-jr> gmaxwell: I'm probably not going to object to a neutered noinput being softforked, but I predict in some years we will learn it was a mistake and desire to change it
15:21 < sipa> that's ok
15:21 < luke-jr> (and since we *can* change it in a later softfork, I suppose it isn't worth trying to brainstorm all the possible ideas today; and as you point out, there are things we can do in the meantime to prepare for that being safer by then)
15:21 < sipa> we can learn from experience
15:21 < gmaxwell> luke-jr: as I was pointing out before, we already know the initial v1 segwit script will be not a forever thing.
15:21 < gmaxwell> We've already dropped headline features from it.
15:22 < gmaxwell> including the major source of public hype for it (aggregation).
15:22 < luke-jr> yes, admittedly those are bigger unfortunate-delays
15:23 < gmaxwell> my argument isn't that it's terrible and should never be done, only that there is too much risk that it's terrible and shouldn't be done, and not enough time yet given into how it could best be derisked... and it sould be seperated because it can be seperated.
15:23 < gmaxwell> it's certantly a lot easier to add it later than to deal with the consequence of adding it and wish we could take it back.
15:23 < gmaxwell> e.g. if its added, it can never be removed without risk of confsciating funds.
15:24 < luke-jr> that's a good point
15:25 < gmaxwell> (I mean it could be added with warnings that its provisional and you shouldn't setup things so that you'll lose funds if its turned off... but thats a footgun. which is better avoided)
15:25 < gmaxwell> and the main usecase for it is lightning stuff that ... has a lot of other development work to do anyways.
15:25 < luke-jr> I suppose in theory, a new address format could always also be added later to set the tx version or whatever without another softfork
15:26 < luke-jr> although that runs the risk of getting current addresses labelled "reusable"
15:26 < gmaxwell> luke-jr: Right, at least my preference at the moment is that it just get a different segwit script version so that you know what you're dealing with.
15:27 < luke-jr> well, another script ver number wouldn't be obviously distinguishable in Bech32, would it?
15:28 < gmaxwell> luke-jr: considering that they're already reused by most users (including you, fwiw https://www.blockchain.com/btc/address/134dV6U7gQ6wCFbfHUz2CMh6Dth72oGpgH ) the horse is kind of out of the barn on that. 
15:28 < gmaxwell> luke-jr: it would be a different third character.
15:28 < gmaxwell> er forth.
15:28 < sipa> fourth.
15:28 < luke-jr> I suspect most users wouldn't notice that, and it might not accomplish the intended goal
15:28 < gmaxwell> the fourth character is the version number.
15:28 < gmaxwell> luke-jr: no but their software could.
15:30 < luke-jr> existing software doesn't; but since I don't really agree with the intended goal, I'm not going to argue too hard that the mechanism here is insufficient ;)
15:31 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
15:33 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Remote host closed the connection]
15:35 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 245 seconds]
15:45 -!- palfun [4da54cc2@gateway/web/freenode/ip.77.165.76.194] has quit [Ping timeout: 256 seconds]
15:49 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has joined #bitcoin-core-dev
15:55 -!- riordant [~riordant@101.108.105.3] has quit [Remote host closed the connection]
16:04 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 246 seconds]
16:12 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
16:17 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has quit [Ping timeout: 256 seconds]
16:19 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
16:24 -!- TheRec [~toto@drupal.org/user/146860/view] has quit []
16:25 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-dev
16:25 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [Client Quit]
16:26 -!- TheRec [~toto@84-72-172-174.dclient.hispeed.ch] has joined #bitcoin-core-dev
16:26 -!- TheRec [~toto@84-72-172-174.dclient.hispeed.ch] has quit [Changing host]
16:26 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-dev
16:28 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [Client Quit]
16:30 < gmaxwell> luke-jr: in the meantime, if reuse is really a concern for you lets work on improving the UI flow to politely discourage it.
16:30 < gmaxwell> I think there is a lot we can do to shift the norms.
16:30 -!- captjakk [~captjakk@63-238-229-186.dia.static.qwest.net] has quit [Remote host closed the connection]
16:31 < gmaxwell> and also make things safer even from the perspective of someone that thinks reuse is totally fine.
16:31 < gmaxwell> (in particular, I've seen quite a few users accidentally pay someone twice... e.g. going down a spreadsheet to make payments and just processing the same line twice)
16:32 -!- TheRec [~toto@84-72-172-174.dclient.hispeed.ch] has joined #bitcoin-core-dev
16:32 -!- TheRec [~toto@84-72-172-174.dclient.hispeed.ch] has quit [Changing host]
16:32 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-dev
16:33 < luke-jr> gmaxwell: is there? I would like to hope so, but it really does seem like most people use other wallets now. :/
16:34 < luke-jr> I mean, we can certainly improve it anyway, but I'm not sure how effective it would be in shifting norms
16:34 < gmaxwell> luke-jr: at least by transaction count bitcoin core usage appears to outpace electrum something like 5:1
16:34 < luke-jr> :o
16:34 < luke-jr> that's surprisingly positive
16:34 < gmaxwell> you get a distorted perspective from seeing what people post about.
16:34 < gmaxwell> It's probably the case that more _people_ use electrum, but they're transacting infrequently.
16:35 < gmaxwell> plus half those people just lost all their bitcoins anyways. :-/
16:36 < luke-jr> are you sure you're not mixing up other light wallets for Core?
16:39 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has joined #bitcoin-core-dev
16:40 < echeveria> electrum has some interesting usage stats that came out of the malware attack (trying to see a silver lining). information about the number of users and what sort of money they store there. 
16:41 < echeveria> gmaxwell: one mistake in MultiBit that caused duplicate payments was that it saved the previous address you paid, for some reason. so people would see the form partly filled out and assume that was the address they intended to pay, and then sent money there.
16:42  * luke-jr wonders if running an Electrum server would enable him to get reasonable estimates of total Electrum wallets and their economic influence
16:42 < echeveria> it would, roughly speaking. the RPC interface just has a literal list of addresses pushed to the server. there's a number of these which appear to be set up expressly for the task.
16:42 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
16:43 < luke-jr> echeveria: a few years ago, someone decided to tip me unknownst to me, and googled "luke-jr bitcoin address", then paid a random address on the bc.i page (which luckily happened to be my *change* address in the transaction that came up)
16:43 < luke-jr> echeveria: but do Electrum clients often pick a random server to use? or typically peg to the same one(s)?
16:44 < echeveria> I sort of caution about making assumptions based on this sort of data. Bread Wallet used a privacy leak in their "sell BCH" function to determine that the average user who used the feature had X BTC in their wallet, and then multiplied by the number of installs to come to the conclusion that their users were storing billions of dollars. this is obviously not correct. 
16:44 < luke-jr> heh
16:44 < luke-jr> I wish mobile wallets published their "number of current installs" numbers
16:44 < echeveria> luke-jr: there's logic for pinning servers you've seen, but generally speaking it's random based on a returned list (which currently contains about 800 sybil servers and 150 or so real ones). 
16:48 < luke-jr> O.o
16:54 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-core-dev
16:54 < gmaxwell> luke-jr: in the last several releases core has made varrious changes that make its transactions readily identifyable.
16:55 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 255 seconds]
16:58 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection]
16:58 -!- dviola [~diego@unaffiliated/dviola] has quit [Ping timeout: 245 seconds]
17:05 -!- pinheadmz [~matthewzi@104-56-112-203.lightspeed.sntcca.sbcglobal.net] has quit [Quit: pinheadmz]
17:06 < jarthur> Re Electrum server selection, the server pool collection code: https://github.com/spesmilo/electrum/blob/master/electrum/network.py#L460 <- basically hardcoded servers, recently connected, and learned peers from servers we've connected to are aggregated prior to random selection.
17:06 < jarthur> Good servers are blacklisting known evil peers.
17:09 -!- zhangzf [~zhangzf@106.38.157.147] has joined #bitcoin-core-dev
17:09 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]
17:09 -!- jarthur [~jarthur@207.114.244.5] has quit [Quit: BBL]
17:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
17:14 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 246 seconds]
17:16 -!- mn9495882 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has quit [Remote host closed the connection]
17:16 -!- mn949588 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has quit [Remote host closed the connection]
17:16 -!- mn9495884 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has joined #bitcoin-core-dev
17:16 -!- mn949588 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has joined #bitcoin-core-dev
17:16 -!- floki [~floki@5.146.251.250] has joined #bitcoin-core-dev
17:16 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
17:18 -!- mn9495884 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has quit [Remote host closed the connection]
17:18 -!- mn949588 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has quit [Write error: Broken pipe]
17:19 -!- mn9495885 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has joined #bitcoin-core-dev
17:19 -!- mn949588 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has joined #bitcoin-core-dev
17:20 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Quit: WeeChat 2.3]
17:24 -!- mn9495885 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has quit [Ping timeout: 255 seconds]
17:24 -!- mn949588 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has quit [Ping timeout: 255 seconds]
17:25 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
17:26 -!- floki [~floki@5.146.251.250] has quit [Quit: leaving]
17:40 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
17:47 -!- mn9495883 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has joined #bitcoin-core-dev
17:47 -!- mn949588 [~nodebot@cpe-67-243-201-127.nyc.res.rr.com] has joined #bitcoin-core-dev
17:57 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]
18:11 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
18:15 -!- m8tion [~user@2a01:e35:8bef:9310:2d12:85d8:eaf8:3005] has quit [Remote host closed the connection]
18:20 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
18:35 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Quit: drexl]
18:41 -!- shesek [~shesek@5.22.134.245] has joined #bitcoin-core-dev
18:41 -!- shesek [~shesek@5.22.134.245] has quit [Changing host]
18:41 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
18:51 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
18:52 -!- shesek` [~shesek@141.226.220.238] has joined #bitcoin-core-dev
18:52 -!- shesek`` [~shesek@5.22.134.245] has joined #bitcoin-core-dev
18:55 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 255 seconds]
18:56 -!- shesek` [~shesek@141.226.220.238] has quit [Ping timeout: 246 seconds]
19:06 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
19:08 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 250 seconds]
19:24 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
19:39 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
19:41 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.3]
20:15 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
20:44 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
20:50 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
20:51 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
20:52 -!- profmac [~ProfMac@2001:470:1f0f:226:65f7:305:2721:bd6] has quit [Ping timeout: 268 seconds]
21:05 -!- profmac [~ProfMac@2001:470:1f0f:226:cd9c:c140:342b:7ce5] has joined #bitcoin-core-dev
21:06 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
21:14 -!- jtimon [~quassel@119.24.134.37.dynamic.jazztel.es] has quit [Ping timeout: 250 seconds]
21:40 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
21:44 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
21:59 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 245 seconds]
22:07 -!- nubbg [c61bad08@gateway/web/freenode/ip.198.27.173.8] has joined #bitcoin-core-dev
22:11 -!- nubbg [c61bad08@gateway/web/freenode/ip.198.27.173.8] has left #bitcoin-core-dev []
22:21 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
22:33 -!- jtimon [~quassel@119.24.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
22:39 -!- riordant [~riordant@43.249.115.182] has joined #bitcoin-core-dev
22:42 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
22:46 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Quit: Snoozing.]
22:52 -!- rh0nj [~rh0nj@88.99.167.175] has joined #bitcoin-core-dev
22:55 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
22:58 -!- riordant [~riordant@43.249.115.182] has quit []
23:04 -!- jtimon [~quassel@119.24.134.37.dynamic.jazztel.es] has quit [Ping timeout: 255 seconds]
23:37 -!- emilr [~emilr@unaffiliated/goregrind] has quit [Read error: Connection reset by peer]
23:43 -!- zhangzf_ [~zhangzf@106.38.157.147] has joined #bitcoin-core-dev
23:43 -!- zhangzf [~zhangzf@106.38.157.147] has quit [Read error: Connection reset by peer]
23:49 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
23:56 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
--- Log closed Wed Feb 20 00:00:54 2019