12019-02-19T00:02:30  *** jarthur has quit IRC
  22019-02-19T00:03:27  *** jarthur_ has quit IRC
  32019-02-19T00:11:48  *** schmidty has joined #bitcoin-core-dev
  42019-02-19T00:16:49  *** schmidty has quit IRC
  52019-02-19T00:24:10  *** shesek has joined #bitcoin-core-dev
  62019-02-19T00:24:10  *** shesek has joined #bitcoin-core-dev
  72019-02-19T00:33:44  *** schmidty has joined #bitcoin-core-dev
  82019-02-19T00:33:58  *** kexkey has quit IRC
  92019-02-19T00:37:07  *** audvonslack has joined #bitcoin-core-dev
 102019-02-19T00:38:33  *** schmidty has quit IRC
 112019-02-19T01:20:19  *** zhangzf has joined #bitcoin-core-dev
 122019-02-19T01:23:52  *** audvonslack has quit IRC
 132019-02-19T01:24:49  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 142019-02-19T01:31:26  *** IGHOR has quit IRC
 152019-02-19T01:34:35  *** IGHOR has joined #bitcoin-core-dev
 162019-02-19T01:36:21  *** Chris_Stewart_5 has quit IRC
 172019-02-19T01:46:25  *** schmidty has joined #bitcoin-core-dev
 182019-02-19T01:51:18  *** schmidty has quit IRC
 192019-02-19T02:06:02  *** schmidty has joined #bitcoin-core-dev
 202019-02-19T02:07:20  *** Aaronvan_ has quit IRC
 212019-02-19T02:11:03  *** schmidty has quit IRC
 222019-02-19T02:14:32  *** schmidty has joined #bitcoin-core-dev
 232019-02-19T02:19:04  *** schmidty has quit IRC
 242019-02-19T02:22:47  *** m8tion has quit IRC
 252019-02-19T02:25:17  <midnightmagic> ˆ/w 3
 262019-02-19T02:41:57  <sipa> agree.
 272019-02-19T02:43:38  <midnightmagic> :-)
 282019-02-19T02:49:47  *** Madars has quit IRC
 292019-02-19T03:10:48  *** Madars has joined #bitcoin-core-dev
 302019-02-19T03:40:09  *** drexl has quit IRC
 312019-02-19T04:03:58  *** dviola has quit IRC
 322019-02-19T04:12:46  *** spinza has quit IRC
 332019-02-19T04:15:20  *** schmidty has joined #bitcoin-core-dev
 342019-02-19T04:17:15  *** kexkey has joined #bitcoin-core-dev
 352019-02-19T04:24:04  *** kexkey has quit IRC
 362019-02-19T04:41:36  *** skyikot has joined #bitcoin-core-dev
 372019-02-19T04:44:55  *** spinza has joined #bitcoin-core-dev
 382019-02-19T05:08:48  *** schmidty has quit IRC
 392019-02-19T05:15:35  *** ap4lmtree has quit IRC
 402019-02-19T06:11:28  *** pinheadmz has quit IRC
 412019-02-19T06:13:33  *** pinheadmz has joined #bitcoin-core-dev
 422019-02-19T06:26:18  *** Skirmant has quit IRC
 432019-02-19T07:05:54  *** schmidty has joined #bitcoin-core-dev
 442019-02-19T07:06:22  *** ap4lmtree has joined #bitcoin-core-dev
 452019-02-19T07:15:50  *** Skirmant has joined #bitcoin-core-dev
 462019-02-19T07:24:19  *** Skirmant has quit IRC
 472019-02-19T07:30:01  *** fanquake has joined #bitcoin-core-dev
 482019-02-19T07:32:24  *** promag has joined #bitcoin-core-dev
 492019-02-19T07:35:55  *** promag has quit IRC
 502019-02-19T07:43:29  <provoostenator> promag: regarding create wallet UI, I created a really professional mockup :-) See slide 7-10: https://github.com/Sjors/presentations/blob/master/2019-02-08%20London%20-%20Advancing%20Bitcoin/2019-02%20London%20Advancing%20Bitcoin.pdf
 512019-02-19T07:45:22  <provoostenator> Tl&dr it would be nice to have a dialog for wallet creation which check boxes for what we have now, i.e. "watch-only" and "blank", so that we can later expand that.
 522019-02-19T07:47:05  <provoostenator> In addition I think the same or a similar dialog can be used to recover wallets. Could be loading a wallet dump file, entering some descriptors or even bip39 phrases.
 532019-02-19T07:48:11  <provoostenator> Such a recovery also needs some room, e.g. we would could ask the earliest usage day for rescan purposes. We could even ask if the user knows a few random addresses, so we can guess the derivation paths, but that might be a bit too fancy.
 542019-02-19T07:50:14  <provoostenator> For using existing hardware wallets I imagine the HWI scripts will give hints of what derivation paths to use, so the UI doesn't have to. Maybe some devices even know what date they were initialized.
 552019-02-19T07:52:13  *** MyNickName6390 has joined #bitcoin-core-dev
 562019-02-19T07:53:19  *** MyNickName6390 has quit IRC
 572019-02-19T07:53:26  *** schmidty has quit IRC
 582019-02-19T07:56:14  *** Guyver2 has joined #bitcoin-core-dev
 592019-02-19T08:03:25  *** pinheadmz has quit IRC
 602019-02-19T08:50:00  *** bitcoin-git has joined #bitcoin-core-dev
 612019-02-19T08:50:00  <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
 622019-02-19T08:50:01  *** bitcoin-git has left #bitcoin-core-dev
 632019-02-19T09:11:55  *** siom has joined #bitcoin-core-dev
 642019-02-19T09:21:50  *** jungly has joined #bitcoin-core-dev
 652019-02-19T09:22:50  <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
 662019-02-19T09:24:28  <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.
 672019-02-19T09:25:47  <wumpus> I mean, it would be for people that do know the functionality and want to choose themselves
 682019-02-19T09:27:28  <gmaxwell> absolutely. sorry.
 692019-02-19T09:28:00  <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.
 702019-02-19T09:29:48  *** promag has joined #bitcoin-core-dev
 712019-02-19T09:30:24  <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
 722019-02-19T09:31:02  <wumpus> the "all GUI users are idiots" philosophy
 732019-02-19T09:31:33  <gmaxwell> oy. "you can edit the code if you are a power user" is not a great UI design principle. :P
 742019-02-19T09:31:45  <wumpus> yesss that's what I mean
 752019-02-19T09:31:51  <wumpus> even worse :P
 762019-02-19T09:31:58  <gmaxwell> (gconf is pretty much that... gconf settings aren't stable across versions... almost as bad as carrying patches)
 772019-02-19T09:32:21  <gmaxwell> The user uses the software specifically to avoid writing it and maintaining it themselves. :P
 782019-02-19T09:34:03  *** promag has quit IRC
 792019-02-19T09:34:04  *** setpill has joined #bitcoin-core-dev
 802019-02-19T09:35:12  <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
 812019-02-19T09:37:35  <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
 822019-02-19T09:38:07  *** timothy has joined #bitcoin-core-dev
 832019-02-19T09:43:01  *** rh0nj has quit IRC
 842019-02-19T09:44:05  *** promag has joined #bitcoin-core-dev
 852019-02-19T09:45:08  *** promag has quit IRC
 862019-02-19T09:50:24  *** schmidty has joined #bitcoin-core-dev
 872019-02-19T09:50:24  *** promag has joined #bitcoin-core-dev
 882019-02-19T10:22:07  *** skyikot has quit IRC
 892019-02-19T10:34:53  *** zhangzf has quit IRC
 902019-02-19T10:36:27  *** spinza has quit IRC
 912019-02-19T10:38:48  *** schmidty has quit IRC
 922019-02-19T11:07:13  *** darosior has joined #bitcoin-core-dev
 932019-02-19T11:07:41  *** fanquake has quit IRC
 942019-02-19T11:08:09  <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.
 952019-02-19T11:08:27  *** fanquake has joined #bitcoin-core-dev
 962019-02-19T11:09:36  *** shesek has quit IRC
 972019-02-19T11:10:37  *** spinza has joined #bitcoin-core-dev
 982019-02-19T11:16:35  *** schmidty has joined #bitcoin-core-dev
 992019-02-19T11:21:18  *** schmidty has quit IRC
1002019-02-19T11:37:30  *** drexl has joined #bitcoin-core-dev
1012019-02-19T11:39:05  *** promag has quit IRC
1022019-02-19T11:41:01  *** AaronvanW has joined #bitcoin-core-dev
1032019-02-19T11:48:08  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1042019-02-19T11:55:40  *** DougieBot5000_ has joined #bitcoin-core-dev
1052019-02-19T11:58:23  *** DougieBot5000 has quit IRC
1062019-02-19T12:04:02  *** Aaronvan_ has joined #bitcoin-core-dev
1072019-02-19T12:05:23  *** mmgen has joined #bitcoin-core-dev
1082019-02-19T12:07:14  *** AaronvanW has quit IRC
1092019-02-19T12:26:21  *** m8tion has joined #bitcoin-core-dev
1102019-02-19T12:30:24  *** zhangzf has joined #bitcoin-core-dev
1112019-02-19T12:33:04  *** fanquake has quit IRC
1122019-02-19T12:45:45  *** mmgen has quit IRC
1132019-02-19T12:45:56  *** mmgen has joined #bitcoin-core-dev
1142019-02-19T12:47:35  *** Karyon has joined #bitcoin-core-dev
1152019-02-19T12:51:36  *** Chris_Stewart_5 has quit IRC
1162019-02-19T13:02:18  *** justanotheruser has quit IRC
1172019-02-19T13:05:03  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1182019-02-19T13:13:56  *** promag has joined #bitcoin-core-dev
1192019-02-19T13:17:33  *** schmidty has joined #bitcoin-core-dev
1202019-02-19T13:27:34  *** bitcoin-git has joined #bitcoin-core-dev
1212019-02-19T13:27:35  <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
1222019-02-19T13:27:47  *** bitcoin-git has left #bitcoin-core-dev
1232019-02-19T13:43:51  *** zhangzf has quit IRC
1242019-02-19T13:47:38  *** Karyon has quit IRC
1252019-02-19T13:49:09  *** zhangzf has joined #bitcoin-core-dev
1262019-02-19T13:53:16  *** Chris_Stewart_5 has quit IRC
1272019-02-19T13:55:16  *** AaronvanW has joined #bitcoin-core-dev
1282019-02-19T13:58:04  *** Aaronvan_ has quit IRC
1292019-02-19T14:02:33  *** sipa has quit IRC
1302019-02-19T14:09:27  <wumpus> eek, kinda unbelievable that spaces in directory names is still a problem in 2019 :/
1312019-02-19T14:10:10  <wumpus> this means there's some very unygyenic code somewhere
1322019-02-19T14:10:26  <wumpus> unhygienic*
1332019-02-19T14:10:32  *** schmidty has quit IRC
1342019-02-19T14:12:07  <luke-jr> maybe we need to use it in test dirs in addition to unicode
1352019-02-19T14:12:32  <wumpus> I'd much prefer that solution to "put a warning in all docs", this really doesn't look good on us
1362019-02-19T14:14:19  *** sipa has joined #bitcoin-core-dev
1372019-02-19T14:15:19  *** Karyon has joined #bitcoin-core-dev
1382019-02-19T14:15:58  *** kexkey has joined #bitcoin-core-dev
1392019-02-19T14:38:49  *** Guyver2 has quit IRC
1402019-02-19T14:39:01  *** Guyver2 has joined #bitcoin-core-dev
1412019-02-19T14:46:11  *** dermoth has quit IRC
1422019-02-19T14:46:55  *** schmidty has joined #bitcoin-core-dev
1432019-02-19T14:49:22  *** schmidty has quit IRC
1442019-02-19T14:49:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1452019-02-19T14:49:58  *** schmidty has joined #bitcoin-core-dev
1462019-02-19T14:50:59  *** dermoth has joined #bitcoin-core-dev
1472019-02-19T14:51:43  *** spaced0ut has joined #bitcoin-core-dev
1482019-02-19T14:54:56  *** schmidty has quit IRC
1492019-02-19T14:56:47  <promag> why this fails? getdescriptorinfo('pk(xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8)')
1502019-02-19T14:58:13  <wumpus> what error do you get ?
1512019-02-19T14:58:19  <promag> Invalid descriptor
1522019-02-19T14:58:53  <promag> thats straight from doc/descriptors.md
1532019-02-19T14:59:05  *** jarthur has joined #bitcoin-core-dev
1542019-02-19T15:01:48  <wumpus> might be it's for the wrong network (regtest/testnet or mainnet)
1552019-02-19T15:03:18  *** achow101 has quit IRC
1562019-02-19T15:03:56  <harding> promag: works for me via bitcoin-cli on mainnet using commit 4064d048d6 (master from Sunday).  Rebuilding now to try on latest.
1572019-02-19T15:04:22  <promag> ok then it's what wumpus said
1582019-02-19T15:04:53  *** dermoth has quit IRC
1592019-02-19T15:05:32  <wumpus> might be useful to mention the network that was used for the example, in descriptors.md
1602019-02-19T15:07:43  *** mildly_risky has joined #bitcoin-core-dev
1612019-02-19T15:08:27  *** Evel-Knievel has quit IRC
1622019-02-19T15:09:19  *** Evel-Knievel has joined #bitcoin-core-dev
1632019-02-19T15:09:40  *** dermoth has joined #bitcoin-core-dev
1642019-02-19T15:11:53  <instagibbs> GAit, I'd be willing to champion 10823 if you don't have the time
1652019-02-19T15:15:24  *** achow101 has joined #bitcoin-core-dev
1662019-02-19T15:16:09  *** ap4lmtree has quit IRC
1672019-02-19T15:16:50  <sipa> promag: xpub is for mainnet
1682019-02-19T15:17:37  <provoostenator> Ideally we would have a way for RPC help to spit out correct examples for mainnet, testnet and regtest.
1692019-02-19T15:17:44  <provoostenator> I've made this mistake a few times too.
1702019-02-19T15:18:28  *** bitcoin-git has joined #bitcoin-core-dev
1712019-02-19T15:18:28  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/904308dca3ff...3e4fd4075381
1722019-02-19T15:18:29  <bitcoin-git> bitcoin/master e3e1a56 Sjors Provoost: [test] functional: set cwd of nodes to tmpdir
1732019-02-19T15:18:29  <bitcoin-git> bitcoin/master 3e4fd40 MarcoFalke: Merge #15415: [test] functional: allow custom cwd, use tmpdir as default
1742019-02-19T15:18:34  *** bitcoin-git has left #bitcoin-core-dev
1752019-02-19T15:19:11  *** bitcoin-git has joined #bitcoin-core-dev
1762019-02-19T15:19:11  <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
1772019-02-19T15:19:13  *** ap4lmtree has joined #bitcoin-core-dev
1782019-02-19T15:19:23  *** bitcoin-git has left #bitcoin-core-dev
1792019-02-19T15:19:36  <wumpus> a more specific error might be nice too
1802019-02-19T15:20:11  *** dermoth has quit IRC
1812019-02-19T15:20:49  *** darosior has quit IRC
1822019-02-19T15:20:57  *** dermoth has joined #bitcoin-core-dev
1832019-02-19T15:23:39  *** dermoth has quit IRC
1842019-02-19T15:24:07  *** dermoth has joined #bitcoin-core-dev
1852019-02-19T15:25:24  *** bitcoin-git has joined #bitcoin-core-dev
1862019-02-19T15:25: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
1872019-02-19T15:25:38  *** bitcoin-git has left #bitcoin-core-dev
1882019-02-19T15:28:02  *** dermoth has quit IRC
1892019-02-19T15:28:27  *** dermoth has joined #bitcoin-core-dev
1902019-02-19T15:32:54  *** bitcoin-git has joined #bitcoin-core-dev
1912019-02-19T15:32:55  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3e4fd4075381...38429c4b6228
1922019-02-19T15:32:55  <bitcoin-git> bitcoin/master 8e4b4f6 Amiti Uttarwar: Address test todos by removing -txindex to nodes.
1932019-02-19T15:32:56  <bitcoin-git> bitcoin/master 38429c4 Wladimir J. van der Laan: Merge #15404: [test] Remove -txindex to start nodes
1942019-02-19T15:32:59  *** bitcoin-git has left #bitcoin-core-dev
1952019-02-19T15:33:24  *** bitcoin-git has joined #bitcoin-core-dev
1962019-02-19T15:33:25  <bitcoin-git> [bitcoin] laanwj merged pull request #15404: [test] Remove -txindex to start nodes (master...remove_txindex) https://github.com/bitcoin/bitcoin/pull/15404
1972019-02-19T15:33:31  *** bitcoin-git has left #bitcoin-core-dev
1982019-02-19T15:36:04  *** skyikot has joined #bitcoin-core-dev
1992019-02-19T15:41:44  *** riordant has joined #bitcoin-core-dev
2002019-02-19T15:42:52  *** riordant has left #bitcoin-core-dev
2012019-02-19T15:42:54  *** riordant has joined #bitcoin-core-dev
2022019-02-19T15:43:27  <riordant> Hello, I have a question about this commit: https://github.com/bitcoin/bitcoin/commit/d6712db
2032019-02-19T15:43:48  <riordant> Why was the pid file creation explicitly removed for Windows?
2042019-02-19T15:44:05  <wumpus> there was never PID file creation for windows
2052019-02-19T15:44:29  *** ap4lmtree has quit IRC
2062019-02-19T15:44:35  <wumpus> it requires pid_t type which doesn't exist there
2072019-02-19T15:44:42  <wumpus> and getpid()
2082019-02-19T15:45:54  *** kexkey has quit IRC
2092019-02-19T15:46:12  *** ap4lmtree has joined #bitcoin-core-dev
2102019-02-19T15:47:25  <wumpus> (if you look at the state before that commit, the CreatePidFile was already in #ifndef WIN32 before that)
2112019-02-19T15:48:31  <riordant> Ok sure, thanks. How is process identification handled on Windows in that case?
2122019-02-19T15:49:00  <wumpus> tbh I have no idea, but if you figure that out you could add PID file functionality for windows
2132019-02-19T15:50:42  *** schmidty has joined #bitcoin-core-dev
2142019-02-19T15:51:18  <wumpus> fairly sure that windows does have process ids, but the API to figure them out is different
2152019-02-19T15:55:36  *** setpill has quit IRC
2162019-02-19T15:58:12  *** shesek has joined #bitcoin-core-dev
2172019-02-19T15:58:12  *** shesek has joined #bitcoin-core-dev
2182019-02-19T15:59:28  *** rex4539 has joined #bitcoin-core-dev
2192019-02-19T16:02:13  *** zhangzf has quit IRC
2202019-02-19T16:02:33  *** rex4539 has quit IRC
2212019-02-19T16:04:49  <instagibbs> provoostenator, I don't think it'd be crazy to dynamically generate key-related material for help
2222019-02-19T16:05:25  <instagibbs> then you just call EncodeDestination() etc
2232019-02-19T16:05:32  <wumpus> I do think the help should be deterministic, as it's used to generate webpages and such
2242019-02-19T16:05:40  <instagibbs> It can be
2252019-02-19T16:05:43  <wumpus> so please no random examples that change every time
2262019-02-19T16:06:31  <wumpus> yes, I'm not trying to say that you were intending that, but just thought it needed saying just in case :)
2272019-02-19T16:06:33  <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
2282019-02-19T16:06:52  <instagibbs> :) only returns a result if vanitygen returns something starting with `1Example`
2292019-02-19T16:07:11  <luke-jr> otoh, maybe a key/value editor that changes bitcoin_rw.conf would be sufficient? dunno
2302019-02-19T16:07:25  <wumpus> well bitcoin_rw.conf overrides bitcoin.conf so...
2312019-02-19T16:07:37  <wumpus> could be used for exactly the same
2322019-02-19T16:08:52  <luke-jr> yeah, I guess it would work
2332019-02-19T16:09:27  <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
2342019-02-19T16:09:47  <wumpus> that would be nice
2352019-02-19T16:09:55  <luke-jr> (and destroying post-hoc seems trivial)
2362019-02-19T16:10:01  <wumpus> yes
2372019-02-19T16:10:35  <wumpus> there's no conceptual reason why making an index requires wiping all indices, this is just how it happens to be right now
2382019-02-19T16:11:06  *** siom_ has joined #bitcoin-core-dev
2392019-02-19T16:13:27  *** siom has quit IRC
2402019-02-19T16:13:36  <luke-jr> I guess -txindex=0 shouldn't destroy an existing index, maybe -txindex=delete
2412019-02-19T16:14:40  <wumpus> I'm not sure it's worth changing that at this point
2422019-02-19T16:17:12  <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
2432019-02-19T16:17:28  <wumpus> s/an transction/an index/
2442019-02-19T16:17:39  <luke-jr> oh, someone already did this
2452019-02-19T16:17:49  <wumpus> oh
2462019-02-19T16:18:04  *** bitcoin-git has joined #bitcoin-core-dev
2472019-02-19T16:18:04  <bitcoin-git> [bitcoin] Sjors opened pull request #15444: [docs] Additional productivity tips (master...2019/02/typo-productivity) https://github.com/bitcoin/bitcoin/pull/15444
2482019-02-19T16:18:05  *** bitcoin-git has left #bitcoin-core-dev
2492019-02-19T16:19:02  *** kexkey has joined #bitcoin-core-dev
2502019-02-19T16:29:15  *** mildly_risky has quit IRC
2512019-02-19T16:33:49  *** promag has quit IRC
2522019-02-19T16:35:08  *** dviola has joined #bitcoin-core-dev
2532019-02-19T16:37:55  *** justanotheruser has joined #bitcoin-core-dev
2542019-02-19T16:39:46  *** schmidty has quit IRC
2552019-02-19T16:45:04  *** schmidty has joined #bitcoin-core-dev
2562019-02-19T16:47:27  *** dqx has joined #bitcoin-core-dev
2572019-02-19T16:50:04  *** schmidty has quit IRC
2582019-02-19T16:54:35  *** pinheadmz has joined #bitcoin-core-dev
2592019-02-19T16:57:02  *** justanotheruser has quit IRC
2602019-02-19T16:57:08  *** rh0nj has joined #bitcoin-core-dev
2612019-02-19T17:14:24  *** siom_ has quit IRC
2622019-02-19T17:15:37  *** elichai2 has joined #bitcoin-core-dev
2632019-02-19T17:16:46  *** schmidty has joined #bitcoin-core-dev
2642019-02-19T17:21:42  *** schmidty has quit IRC
2652019-02-19T17:21:47  *** kexkey has quit IRC
2662019-02-19T17:26:01  *** Lauda has quit IRC
2672019-02-19T17:28:27  <cjd> What was the reason for aa21a9ed ?   Just some bytes which are unlikely to collide with anything ?
2682019-02-19T17:28:32  *** owowo has quit IRC
2692019-02-19T17:29:06  *** Lauda has joined #bitcoin-core-dev
2702019-02-19T17:33:21  *** skyikot has quit IRC
2712019-02-19T17:33:55  *** riordant has quit IRC
2722019-02-19T17:34:44  <provoostenator> cjd: which aa21a9ed?
2732019-02-19T17:35:02  <cjd> segwit root hash magic
2742019-02-19T17:35:04  *** copumpkin has quit IRC
2752019-02-19T17:35:23  <provoostenator> Oh ok, I thought it was a commit that accidentally collided with that :-)
2762019-02-19T17:38:18  *** Karyon has quit IRC
2772019-02-19T17:40:16  *** Murch has joined #bitcoin-core-dev
2782019-02-19T17:40:53  <cjd> oh yeah, without context it can definitely look like a git short hash
2792019-02-19T17:41:26  *** Chris_Stewart_5 has quit IRC
2802019-02-19T17:41:48  <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
2812019-02-19T17:42:36  <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.
2822019-02-19T17:43:01  *** schmidty has joined #bitcoin-core-dev
2832019-02-19T17:44:55  *** jtimon has joined #bitcoin-core-dev
2842019-02-19T17:47:58  *** schmidty has quit IRC
2852019-02-19T17:48:09  <cjd> ahh cool
2862019-02-19T17:48:20  *** hebasto has joined #bitcoin-core-dev
2872019-02-19T17:51:26  *** Karyon has joined #bitcoin-core-dev
2882019-02-19T17:56:19  <luke-jr> eh, outputs aren't random. a collision is avoided by just not colliding.
2892019-02-19T17:56:46  <luke-jr> so long as there's *some* 32 bits there, other proposals just avoid using the same 32-bit value
2902019-02-19T17:56:47  <provoostenator> luke-jr the 0xaa21a9ed prefix is random
2912019-02-19T17:56:55  <luke-jr> provoostenator: it doesn't need to be, is my point
2922019-02-19T17:58:52  <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?
2932019-02-19T17:59:23  <sipa> jarthur: just don't use it for anything and you're fine
2942019-02-19T17:59:44  <jarthur> sipa: but if I'm a miner, what should I set it to in my new blocks?
2952019-02-19T17:59:48  <sipa> whatever.
2962019-02-19T18:00:14  <sipa> that comment means that it shouldn't be used to convey any meaning, because that meaning may be constrained in the future
2972019-02-19T18:00:25  <sipa> just set it to zeroes
2982019-02-19T18:00:32  <sipa> or to "blahblahblahblah"
2992019-02-19T18:01:05  <luke-jr> well, if it's constrained in the future, setting it non-zero may make blocks invalid, no?
3002019-02-19T18:01:06  <provoostenator> Oh, the way I read BIP-141 is that it must be exactly 0xaa21a9ed.
3012019-02-19T18:01:19  <sipa> provoostenator: jarthur is asking about something unrelated
3022019-02-19T18:01:20  <luke-jr> provoostenator: the topic changed
3032019-02-19T18:01:36  <sipa> (witness reserved value vs witness coinbase commitment)
3042019-02-19T18:03:19  <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?
3052019-02-19T18:03:29  <sipa> jarthur: no?
3062019-02-19T18:03:56  <provoostenator> jarthur: I assume a future soft fork won't care about historical values before it was activated
3072019-02-19T18:03:57  <sipa> the softfork will obviously only affect future values, not ones in the past
3082019-02-19T18:04:11  <jarthur> OK, great, thanks :)
3092019-02-19T18:06:12  <luke-jr> well, it'd potentially make the code cleaner after the softfork activates, if we can just have it unconditional
3102019-02-19T18:06:44  <luke-jr> so it'd be *nice* of miners didn't make blocks with potentially-conflicting values :p
3112019-02-19T18:07:10  <sipa> sure
3122019-02-19T18:07:16  <sipa> but if they do, so be it
3132019-02-19T18:07:25  * luke-jr nods
3142019-02-19T18:13:46  *** DougieBot5000_ is now known as DougieBot5000
3152019-02-19T18:36:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3162019-02-19T18:39:21  *** jcorgan has joined #bitcoin-core-dev
3172019-02-19T18:39:34  *** schmidty has joined #bitcoin-core-dev
3182019-02-19T18:41:46  *** fabianfabian has joined #bitcoin-core-dev
3192019-02-19T18:44:07  *** schmidty has quit IRC
3202019-02-19T19:20:11  *** promag has joined #bitcoin-core-dev
3212019-02-19T19:24:46  *** promag has quit IRC
3222019-02-19T19:30:16  *** AaronvanW has quit IRC
3232019-02-19T19:30:32  *** schmidty has joined #bitcoin-core-dev
3242019-02-19T19:35:10  *** schmidty has quit IRC
3252019-02-19T19:37:06  *** bigcookie101 has joined #bitcoin-core-dev
3262019-02-19T19:38:48  *** owowo has joined #bitcoin-core-dev
3272019-02-19T19:41:33  *** schmidty has joined #bitcoin-core-dev
3282019-02-19T19:41:55  *** bigcookie101 has quit IRC
3292019-02-19T19:42:15  *** bigcookie101 has joined #bitcoin-core-dev
3302019-02-19T19:43:06  *** bigcookie101 has joined #bitcoin-core-dev
3312019-02-19T19:43:23  *** mmgen has quit IRC
3322019-02-19T19:45:49  *** bigcookie101 has quit IRC
3332019-02-19T19:46:12  *** bigcookie101 has joined #bitcoin-core-dev
3342019-02-19T19:46:26  *** schmidty has quit IRC
3352019-02-19T19:56:42  *** bigcookie101 has quit IRC
3362019-02-19T19:57:04  *** bigcookie101 has joined #bitcoin-core-dev
3372019-02-19T19:58:13  *** jarthur_ has joined #bitcoin-core-dev
3382019-02-19T20:01:36  *** jarthur has quit IRC
3392019-02-19T20:07:40  *** owowo has quit IRC
3402019-02-19T20:12:54  *** owowo has joined #bitcoin-core-dev
3412019-02-19T20:15:55  *** jarthur_ is now known as jarthur
3422019-02-19T20:16:05  *** riordant has joined #bitcoin-core-dev
3432019-02-19T20:16:48  *** bigcookie101 has quit IRC
3442019-02-19T20:17:15  *** bigcookie101 has joined #bitcoin-core-dev
3452019-02-19T20:20:48  *** bigcookie101 has quit IRC
3462019-02-19T20:23:24  *** bigcookie101 has joined #bitcoin-core-dev
3472019-02-19T20:30:01  *** jarthur has quit IRC
3482019-02-19T20:30:49  *** Karyon has quit IRC
3492019-02-19T20:32:08  *** promag has joined #bitcoin-core-dev
3502019-02-19T20:34:35  *** EagleTM has joined #bitcoin-core-dev
3512019-02-19T20:37:39  *** bitcoin-git has joined #bitcoin-core-dev
3522019-02-19T20:37:39  <bitcoin-git> [bitcoin] hebasto opened pull request #15445: [0.17] backport #14409 (0.17...20190219-backport-pr14409) https://github.com/bitcoin/bitcoin/pull/15445
3532019-02-19T20:37:52  *** bitcoin-git has left #bitcoin-core-dev
3542019-02-19T20:39:06  *** promag has quit IRC
3552019-02-19T20:42:25  *** schmidty has joined #bitcoin-core-dev
3562019-02-19T20:43:21  *** shesek has quit IRC
3572019-02-19T20:46:41  *** sdaftuar has quit IRC
3582019-02-19T20:46:41  *** sdaftuar has joined #bitcoin-core-dev
3592019-02-19T20:55:39  *** DeanWeen has quit IRC
3602019-02-19T20:58:44  *** AaronvanW has joined #bitcoin-core-dev
3612019-02-19T21:02:23  *** bitcoin-git has joined #bitcoin-core-dev
3622019-02-19T21:02:24  <bitcoin-git> [bitcoin] dongcarl opened pull request #15446: Improve depends debuggability (master...2019-02-improve-depends-debuggability) https://github.com/bitcoin/bitcoin/pull/15446
3632019-02-19T21:02:26  *** bitcoin-git has left #bitcoin-core-dev
3642019-02-19T21:02:39  *** dviola has quit IRC
3652019-02-19T21:04:03  <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..
3662019-02-19T21:05:22  *** hebasto has quit IRC
3672019-02-19T21:09:32  *** Guyver2 has quit IRC
3682019-02-19T21:09:48  <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
3692019-02-19T21:09:48  <gmaxwell> overwhos fault it was.   That kind of footgun isn't what you expect from bitcoin engineering, it sounds like something ethereum would do.
3702019-02-19T21:10:44  <gmaxwell> (also are you responding to messages that aren't on the list? -- I don't see any really recent message from jl2012)
3712019-02-19T21:12:05  <luke-jr> gmaxwell: I guess the list copies are waiting for moderation
3722019-02-19T21:12:40  <luke-jr> sending twice to the same address is always the sender's fault and should be considered undefined behaviour
3732019-02-19T21:13:00  <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.
3742019-02-19T21:14:04  <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.
3752019-02-19T21:14:16  <gmaxwell> Good engineering isn't just building something that works if you use it perfectly.
3762019-02-19T21:14:24  <luke-jr> gmaxwell: it's already reckless. there's no guarantee it works today.
3772019-02-19T21:14:29  <gmaxwell> It's also about building something that fails gracefully.
3782019-02-19T21:15:58  <luke-jr> IMO it's not much different from accidentally sending with the wrong fee
3792019-02-19T21:16:22  <luke-jr> these are things user applications can try to protect, but not things the protocol should be trying to second-guess
3802019-02-19T21:16:35  <gmaxwell> and we worked hard to make that less possible, e.g. segwit inputs sign the input amounts now.
3812019-02-19T21:17:09  <gmaxwell> luke-jr: and reuse is fundimentally hard to guarentee never happens, you essentially need a consensus system to do so.
3822019-02-19T21:17:22  *** morcos has quit IRC
3832019-02-19T21:17:52  <luke-jr> you could avoid wrong fee without signing input amounts - the benefit there was to avoid the extra data needed for it
3842019-02-19T21:18:20  <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
3852019-02-19T21:18:24  *** skyikot has joined #bitcoin-core-dev
3862019-02-19T21:18:37  <luke-jr> you don't need a consensus system to coordinate a single sender's actions
3872019-02-19T21:19:09  <luke-jr> (and if someone sees the address on the network and sends to it too - there are obvious ways to deal with that)
3882019-02-19T21:19:27  <gmaxwell> People do accidentally double pay, today. It happens, it's not conjecture.  People also do intentionally split one payment into two txouts.
3892019-02-19T21:19:45  <gmaxwell> "obvious ways to deal with that" is handwaving.
3902019-02-19T21:20:29  <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
3912019-02-19T21:20:48  <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
3922019-02-19T21:20:48  <harding> stolen even though Alice herself didn't engage in address reuse.
3932019-02-19T21:21:29  <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)
3942019-02-19T21:21:29  <luke-jr> harding: you're assuming Bob is offline at the time and doesn't see Alice's until after spending Griefer's?
3952019-02-19T21:21:56  <harding> luke-jr: we can't guarantee Bob has a complete view of all possible mempools in any case.
3962019-02-19T21:22:12  <luke-jr> gmaxwell: I don't see why you say ignoring unconfirmed; just not showing them as confirmed, since they aren't
3972019-02-19T21:22:43  <gmaxwell> because if you spend the wrong one you'll burn money. not showing them as confirmed isn't enough.
3982019-02-19T21:22:45  <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
3992019-02-19T21:23:00  *** booyah_ is now known as booyah
4002019-02-19T21:23:12  <luke-jr> arguably if you do so anyway, it's the same as picking the wrong fee would be
4012019-02-19T21:23:14  <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)
4022019-02-19T21:23:53  <gmaxwell> (which was exactly the reason that graftroot and aggregation were left out)
4032019-02-19T21:24:33  <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)
4042019-02-19T21:25:09  <luke-jr> is signed*
4052019-02-19T21:25:41  <gmaxwell> value being signed is just one of the first protections that were added to make this not a complete disaster proposal...
4062019-02-19T21:25:43  <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)
4072019-02-19T21:26:34  <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.
4082019-02-19T21:26:43  *** schmidty has quit IRC
4092019-02-19T21:27:19  <luke-jr> gmaxwell: but my point is that for a protocol level feature, just saying "don't do that" is a reasonable mitigation
4102019-02-19T21:27:39  <luke-jr> these things can/should be addressed by the wallet software
4112019-02-19T21:31:23  *** lucky8277 has joined #bitcoin-core-dev
4122019-02-19T21:31:40  *** elichai2 has quit IRC
4132019-02-19T21:33:02  *** AaronvanW has quit IRC
4142019-02-19T21:34:55  *** lucky8277 has quit IRC
4152019-02-19T21:50:10  *** Murch has quit IRC
4162019-02-19T21:51:12  *** Murch has joined #bitcoin-core-dev
4172019-02-19T21:52:03  *** TheRec has quit IRC
4182019-02-19T22:01:56  *** cornfeedhobo has quit IRC
4192019-02-19T22:02:26  *** AaronvanW has joined #bitcoin-core-dev
4202019-02-19T22:07:32  *** AaronvanW has quit IRC
4212019-02-19T22:09:30  *** TheRec has joined #bitcoin-core-dev
4222019-02-19T22:09:30  *** TheRec has joined #bitcoin-core-dev
4232019-02-19T22:12:17  *** cornfeedhobo has joined #bitcoin-core-dev
4242019-02-19T22:16:01  *** ap4lmtree has quit IRC
4252019-02-19T22:17:56  *** fabianfabian has quit IRC
4262019-02-19T22:18:06  *** Chris_Stewart_5 has quit IRC
4272019-02-19T22:21:49  *** spinza has quit IRC
4282019-02-19T22:26:03  *** Murch has quit IRC
4292019-02-19T22:27:43  *** spinza has joined #bitcoin-core-dev
4302019-02-19T22:28:12  *** bigcookie101 has quit IRC
4312019-02-19T22:29:07  <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.
4322019-02-19T22:29:19  *** Murch has joined #bitcoin-core-dev
4332019-02-19T22:29:20  <gmaxwell> In reality that approach causes failure after failure after failure.
4342019-02-19T22:29:56  <gmaxwell> At some point the designer of a system cannot credibly fob off fault onto the users.
4352019-02-19T22:30:24  <gmaxwell> We build systems to be used by real people, not platonic errorless perfectly knowledgable people.
4362019-02-19T22:31:14  <gmaxwell> We do know how to make noinput safer but it has been slowing down the work on this functionality.
4372019-02-19T22:31:54  <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.
4382019-02-19T22:33:37  <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)
4392019-02-19T22:34:41  <luke-jr> gmaxwell: yet we don't try to enforce random number strength in the consensus protocol
4402019-02-19T22:34:56  *** spinza has quit IRC
4412019-02-19T22:35:57  <sipa> luke-jr: can we?
4422019-02-19T22:36:06  <gmaxwell> luke-jr: we would if we could but we can't so we don't.
4432019-02-19T22:36:11  <luke-jr> sipa: you would know better than me, but not that I'm aware of
4442019-02-19T22:36:37  <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!"
4452019-02-19T22:36:53  <luke-jr> gmaxwell: why don't we enforce the absurd fee policy as a consensus rule?
4462019-02-19T22:37:03  <booyah> uhm is this not typical for crypto protocols to start with "we assume you can provide good, unique, randomness"?
4472019-02-19T22:37:12  <gmaxwell> luke-jr: because it has to change over time, otherwise I would say we probably should.
4482019-02-19T22:37:52  <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.
4492019-02-19T22:37:55  <booyah> and as separate consideration we could provide algorithms to try to improve on OS-provided random
4502019-02-19T22:38:28  <gmaxwell> you won't find any crypto apps that just prompts there user to proide randomness or some such stupid thing. :)
4512019-02-19T22:38:33  <booyah> is bitcoin somehow improving strength of normal random as provided by OS specific api?
4522019-02-19T22:38:42  <gmaxwell> (or to the extent that they do, like brainwallets tools, they cause continual failure)
4532019-02-19T22:38:51  <gmaxwell> booyah: yes, though you're offtopic.
4542019-02-19T22:38:52  <booyah> gmaxwell: well not user, I mean the OS random source
4552019-02-19T22:39:45  <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)
4562019-02-19T22:40:02  <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.
4572019-02-19T22:40:50  <gmaxwell> Whats being limited? there is no way to noinput today. The system was designed otherwise, and having it really throughly breaks assumptions.
4582019-02-19T22:40:51  <luke-jr> in this case, going out of the way to prevent me from using NOINPUT the way I intend to
4592019-02-19T22:41:05  <gmaxwell> oh so sad poor luke
4602019-02-19T22:41:49  * booyah quietly pulls out a violin
4612019-02-19T22:43:27  <sipa> luke-jr: what do you hope to gain from using noinput as you intend to?
4622019-02-19T22:44:08  *** spinza has joined #bitcoin-core-dev
4632019-02-19T22:44:46  <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
4642019-02-19T22:46:22  <gmaxwell> that only works right if all subsiquent transactions are themselves no-input.
4652019-02-19T22:46:41  <gmaxwell> so a katamari of replay attack vulnerablity. :)
4662019-02-19T22:46:43  <luke-jr> which they would be in such a wallet where everything is noinput
4672019-02-19T22:46:55  <gmaxwell> luke-jr: not the recipents spends.
4682019-02-19T22:47:53  <luke-jr> the recipient of the fee-bumped one would be affected, but nothing else?
4692019-02-19T22:48:32  <luke-jr> or, what do you mean?
4702019-02-19T22:48:32  <gmaxwell> the whole chain is invalidated unless all txn in it use noinput for all of their inputs.
4712019-02-19T22:48:49  <luke-jr> but the recipients aren't in the chain of change
4722019-02-19T22:50:44  <gmaxwell> they get the payments, not the change itself. (obviously thats why you have change: you made payments)
4732019-02-19T22:51:03  <luke-jr> but that doesn't break the chain of change
4742019-02-19T22:51:20  <luke-jr> the next transaction would have an unchanged txid
4752019-02-19T22:52:18  <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?)
4762019-02-19T22:52:38  *** AaronvanW has joined #bitcoin-core-dev
4772019-02-19T22:53:04  <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.
4782019-02-19T22:53:10  *** jarthur has joined #bitcoin-core-dev
4792019-02-19T22:53:36  <luke-jr> hmm, right
4802019-02-19T22:55:07  <luke-jr> that only messes up the recipients not using noinput wallets, though
4812019-02-19T22:55:39  <gmaxwell> 14:46:41 < gmaxwell> so a katamari of replay attack vulnerablity. :)
4822019-02-19T22:56:12  <luke-jr> another use case: if the person paying me does some fee bumping, using noinput avoids resigning
4832019-02-19T22:56:26  <gmaxwell> Ethereum has better replay prevention than no input, and still replay there has caused massive funds loss, annoying DOS, etc.
4842019-02-19T22:56:48  <luke-jr> but in this case, replay isn't a problem since addresses aren't reused
4852019-02-19T22:57:00  <gmaxwell> basically noinput = accounts model, instead of utxo model; with the tradeoffs that implies.
4862019-02-19T22:57:12  <luke-jr> or unique-script UTXO model
4872019-02-19T22:58:48  <gmaxwell> one coulde use ethereum accounts exactly once. but because the system doesn't guarentee it, you can't count on it.
4882019-02-19T22:59:31  <luke-jr> since NOINPUT still commits to the amount, it's basically harmless to count on it
4892019-02-19T23:01:01  <gmaxwell> that kind of thinking is why it is so unsafe.
4902019-02-19T23:01:05  <gmaxwell> So thanks for making the point.
4912019-02-19T23:02:13  <luke-jr> am I wrong?
4922019-02-19T23:02:30  *** unknown-os has joined #bitcoin-core-dev
4932019-02-19T23:03:06  *** timothy has quit IRC
4942019-02-19T23:03:26  *** DeanGuss has joined #bitcoin-core-dev
4952019-02-19T23:03:34  *** unknown-os has left #bitcoin-core-dev
4962019-02-19T23:04:23  <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.
4972019-02-19T23:04:56  <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.
4982019-02-19T23:05:48  <luke-jr> that's reuse and undefined behaviour..
4992019-02-19T23:06:01  <gmaxwell> according to _you_.
5002019-02-19T23:06:09  <gmaxwell> Not according to how bitcoin has always worked.
5012019-02-19T23:06:21  <gmaxwell> And certantly not according to what people already do.
5022019-02-19T23:06:40  <gmaxwell> Advisable or not, reuse is ubiquitous. The majority of circulating bitcoins are stored in reused addresses.
5032019-02-19T23:06:52  *** justanotheruser has joined #bitcoin-core-dev
5042019-02-19T23:07:13  <gmaxwell> You are saying that it's just fine to turn something that people ubiquitously do today into a massive footgun.
5052019-02-19T23:07:20  <gmaxwell> I can't abide by that.
5062019-02-19T23:07:42  <luke-jr> it's already a footgun.
5072019-02-19T23:07:58  <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".
5082019-02-19T23:08:04  <luke-jr> nothing obliges the recipient to acknowledge the second payment to the same address
5092019-02-19T23:08:46  <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)
5102019-02-19T23:09:22  <luke-jr> that's like when people say light wallets are okay because nobody's ever lost funds due to their lack of security
5112019-02-19T23:09:25  <booyah> are you talking about two people sending e.g. 1 btc, on same day, to same one e.g. donation address of someone?
5122019-02-19T23:10:11  *** schmidty has joined #bitcoin-core-dev
5132019-02-19T23:10:23  <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.
5142019-02-19T23:11:14  <luke-jr> gmaxwell: I've seen it very nearly explode at least once personally.
5152019-02-19T23:11:19  <luke-jr> without NOINPUT
5162019-02-19T23:12:09  <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.
5172019-02-19T23:12:55  <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.
5182019-02-19T23:13:18  *** schmidty has quit IRC
5192019-02-19T23:13:32  <gmaxwell> (or likewise, inbound payments that reused your addresses could get frowny red recycle icons)
5202019-02-19T23:15:13  <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(?)
5212019-02-19T23:15:26  <gmaxwell> indeed.
5222019-02-19T23:15:47  <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
5232019-02-19T23:15:54  <luke-jr> booyah: that's not a new problem with noinput
5242019-02-19T23:16:09  <gmaxwell> luke-jr: but it does invalidate the case you gave for it.
5252019-02-19T23:16:44  <gmaxwell> booyah: it's difficult to guarentee that a double payment _never_ happen even if you're trying.
5262019-02-19T23:17:09  <gmaxwell> booyah: and in bitcoin today users generally assume addresses can be reused. It's not a great assumption.
5272019-02-19T23:17:19  <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
5282019-02-19T23:17:27  <gmaxwell> They also assume you can go pull an address out of a block explorer and pay to it.
5292019-02-19T23:17:51  <gmaxwell> booyah: right, with enough protection and complexity you can make it arbritarily rare.
5302019-02-19T23:17:52  <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?
5312019-02-19T23:18:36  <gmaxwell> It's not clear to me that it would, at least the lightning stuff proposed can't work that way.
5322019-02-19T23:18:55  <gmaxwell> But even if it is useful, that utility has to be weighed against the risk increase for all other usage.
5332019-02-19T23:19:08  <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?
5342019-02-19T23:19:30  <gmaxwell> luke-jr: no, because they have to be able to resign if the transaction fails (even with no-input)
5352019-02-19T23:20:15  <gmaxwell> (also, if it became justified to do that, it could be done later... along with whatever was needed to make it safer)
5362019-02-19T23:20:30  <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
5372019-02-19T23:21:04  <sipa> that's ok
5382019-02-19T23:21:11  <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)
5392019-02-19T23:21:11  <sipa> we can learn from experience
5402019-02-19T23:21:49  <gmaxwell> luke-jr: as I was pointing out before, we already know the initial v1 segwit script will be not a forever thing.
5412019-02-19T23:21:57  <gmaxwell> We've already dropped headline features from it.
5422019-02-19T23:22:11  <gmaxwell> including the major source of public hype for it (aggregation).
5432019-02-19T23:22:42  <luke-jr> yes, admittedly those are bigger unfortunate-delays
5442019-02-19T23:23:08  <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.
5452019-02-19T23:23:34  <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.
5462019-02-19T23:23:51  <gmaxwell> e.g. if its added, it can never be removed without risk of confsciating funds.
5472019-02-19T23:24:05  <luke-jr> that's a good point
5482019-02-19T23:25:09  <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)
5492019-02-19T23:25:36  <gmaxwell> and the main usecase for it is lightning stuff that ... has a lot of other development work to do anyways.
5502019-02-19T23:25:41  <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
5512019-02-19T23:26:43  <luke-jr> although that runs the risk of getting current addresses labelled "reusable"
5522019-02-19T23:26:49  <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.
5532019-02-19T23:27:44  <luke-jr> well, another script ver number wouldn't be obviously distinguishable in Bech32, would it?
5542019-02-19T23:28:02  <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.
5552019-02-19T23:28:13  <gmaxwell> luke-jr: it would be a different third character.
5562019-02-19T23:28:22  <gmaxwell> er forth.
5572019-02-19T23:28:30  <sipa> fourth.
5582019-02-19T23:28:32  <luke-jr> I suspect most users wouldn't notice that, and it might not accomplish the intended goal
5592019-02-19T23:28:36  <gmaxwell> the fourth character is the version number.
5602019-02-19T23:28:45  <gmaxwell> luke-jr: no but their software could.
5612019-02-19T23:30:04  <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 ;)
5622019-02-19T23:31:43  *** schmidty has joined #bitcoin-core-dev
5632019-02-19T23:33:34  *** tripleslash has quit IRC
5642019-02-19T23:35:53  *** schmidty has quit IRC
5652019-02-19T23:45:09  *** palfun has quit IRC
5662019-02-19T23:49:38  *** captjakk has joined #bitcoin-core-dev
5672019-02-19T23:55:38  *** riordant has quit IRC