12017-08-31T00:01:59  *** RoyceX has quit IRC
  22017-08-31T00:03:21  *** Evel-Knievel has quit IRC
  32017-08-31T00:12:02  *** jtimon has quit IRC
  42017-08-31T00:12:34  *** jtimon has joined #bitcoin-core-dev
  52017-08-31T00:24:09  *** randy-waterhouse has joined #bitcoin-core-dev
  62017-08-31T00:24:26  *** randy-waterhouse has joined #bitcoin-core-dev
  72017-08-31T00:39:25  *** CubicEar_ has joined #bitcoin-core-dev
  82017-08-31T00:41:13  <bitcoin-git> [bitcoin] achow101 opened pull request #11200: Allow for aborting rescans and canceling showProgress dialogs (master...gui-recan-abort) https://github.com/bitcoin/bitcoin/pull/11200
  92017-08-31T00:42:12  *** CubicEarth has quit IRC
 102017-08-31T00:55:43  *** meshcollider has quit IRC
 112017-08-31T00:57:43  *** JackH has quit IRC
 122017-08-31T00:58:16  *** dabura667 has joined #bitcoin-core-dev
 132017-08-31T01:26:56  *** CubicEar_ has quit IRC
 142017-08-31T01:27:32  *** CubicEarth has joined #bitcoin-core-dev
 152017-08-31T01:37:15  *** Aaronvan_ has quit IRC
 162017-08-31T01:41:24  *** randy-waterhouse has quit IRC
 172017-08-31T01:42:09  *** randy-waterhouse has joined #bitcoin-core-dev
 182017-08-31T01:44:30  *** randy-waterhouse has quit IRC
 192017-08-31T01:48:53  *** Terrance has joined #bitcoin-core-dev
 202017-08-31T01:49:04  *** Terrance has quit IRC
 212017-08-31T01:59:33  *** CubicEarth has quit IRC
 222017-08-31T02:06:57  *** sam_c has quit IRC
 232017-08-31T02:08:01  *** Giszmo has quit IRC
 242017-08-31T02:08:12  *** sam_c has joined #bitcoin-core-dev
 252017-08-31T02:24:29  *** btcdrak has joined #bitcoin-core-dev
 262017-08-31T02:24:39  *** RubenSomsen has joined #bitcoin-core-dev
 272017-08-31T02:30:53  <achow101> I don't suppose it is possible to lock the comments on the first commit?
 282017-08-31T02:39:05  *** Giszmo has joined #bitcoin-core-dev
 292017-08-31T02:44:43  *** chjj has quit IRC
 302017-08-31T02:45:17  <sipa> achow101: i don't see an option to do that
 312017-08-31T02:45:29  <achow101> darn
 322017-08-31T02:55:02  <jl2012> i have a question about this line: https://github.com/bitcoin/bitcoin/blob/master/src/validation.h#L376 . Is is same as std::swap(scriptPubKey, check.scriptPubKey); ?
 332017-08-31T03:01:05  *** goatpig has joined #bitcoin-core-dev
 342017-08-31T03:02:06  <sipa> jl2012: yes
 352017-08-31T03:02:25  <sipa> std::swap also works for primitive types
 362017-08-31T03:04:08  <jl2012> thanks sipa. I have another question about my patch here: https://github.com/bitcoin/bitcoin/pull/10953/files#diff-349fbb003d5ae550a2e8fa658e475880L368 .
 372017-08-31T03:04:08  <jl2012> As I replace amount+scriptPubKey with CTxOut, the default value of amount becomes -1. It should be ok?
 382017-08-31T03:05:19  <sipa> sounds fine
 392017-08-31T03:05:50  <sipa> perhaps add an assert to check that it's not -1 for any actual validation
 402017-08-31T03:05:51  <sipa> or at least not for a witness validation
 412017-08-31T03:10:22  <jl2012> sipa: it sounds already like a serious bug if the validation would use the default value, 0 or -1. Maybe -1 is actually better because it must be invalid
 422017-08-31T03:19:26  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 432017-08-31T03:22:10  *** meshcollider has joined #bitcoin-core-dev
 442017-08-31T03:27:02  *** d9b4bef9 has quit IRC
 452017-08-31T03:28:08  *** d9b4bef9 has joined #bitcoin-core-dev
 462017-08-31T03:35:41  *** Giszmo has quit IRC
 472017-08-31T03:38:13  *** justanotheruser has quit IRC
 482017-08-31T03:47:55  *** chjj has joined #bitcoin-core-dev
 492017-08-31T03:48:35  *** Giszmo has joined #bitcoin-core-dev
 502017-08-31T03:49:00  *** Chris_Stewart_5 has quit IRC
 512017-08-31T03:54:41  *** Giszmo has quit IRC
 522017-08-31T03:56:08  *** justanotheruser has joined #bitcoin-core-dev
 532017-08-31T04:07:44  *** arubi has joined #bitcoin-core-dev
 542017-08-31T04:16:29  *** Giszmo has joined #bitcoin-core-dev
 552017-08-31T04:19:13  <bitcoin-git> [bitcoin] justicz opened pull request #11201: [RPC] Add verifyrawtransaction RPC (master...maxj_add_verify_tx_rpc) https://github.com/bitcoin/bitcoin/pull/11201
 562017-08-31T04:50:41  *** justanotheruser has quit IRC
 572017-08-31T05:02:21  *** chjj has quit IRC
 582017-08-31T05:06:56  *** justanotheruser has joined #bitcoin-core-dev
 592017-08-31T05:44:19  *** Victor_sueca is now known as Victorsueca
 602017-08-31T05:46:50  *** Gunnie has joined #bitcoin-core-dev
 612017-08-31T06:06:22  *** ula has joined #bitcoin-core-dev
 622017-08-31T06:19:35  *** clarkmoody has quit IRC
 632017-08-31T06:49:13  *** BashCo has quit IRC
 642017-08-31T06:55:43  *** meshcollider has quit IRC
 652017-08-31T07:01:28  *** Evel-Knievel has joined #bitcoin-core-dev
 662017-08-31T07:01:57  *** RubenSomsen has quit IRC
 672017-08-31T07:06:08  *** Gunnie has quit IRC
 682017-08-31T07:06:58  *** SopaXorzTaker has joined #bitcoin-core-dev
 692017-08-31T07:14:17  *** BashCo has joined #bitcoin-core-dev
 702017-08-31T07:17:35  *** jtimon has quit IRC
 712017-08-31T07:18:16  *** RubenSomsen has joined #bitcoin-core-dev
 722017-08-31T07:25:46  *** sltrain_ has joined #bitcoin-core-dev
 732017-08-31T07:32:15  *** sltrain_ has quit IRC
 742017-08-31T07:32:21  *** dermoth has joined #bitcoin-core-dev
 752017-08-31T07:42:45  <jl2012> is there any easy way to list all segwit txs in the mempool?
 762017-08-31T07:44:32  *** praxeology has joined #bitcoin-core-dev
 772017-08-31T07:46:39  *** clarkmoody has joined #bitcoin-core-dev
 782017-08-31T07:46:40  *** praxeology1 has quit IRC
 792017-08-31T08:07:23  *** timothy has joined #bitcoin-core-dev
 802017-08-31T08:18:14  *** [b__b] has quit IRC
 812017-08-31T08:20:11  *** [b__b] has joined #bitcoin-core-dev
 822017-08-31T08:22:13  *** praxeology has quit IRC
 832017-08-31T08:22:13  *** praxeology has joined #bitcoin-core-dev
 842017-08-31T08:22:18  *** JackH has joined #bitcoin-core-dev
 852017-08-31T08:28:18  *** laurentmt has joined #bitcoin-core-dev
 862017-08-31T08:31:21  *** Guyver2 has joined #bitcoin-core-dev
 872017-08-31T08:41:17  *** Giszmo has quit IRC
 882017-08-31T08:54:17  *** AaronvanW has joined #bitcoin-core-dev
 892017-08-31T08:55:50  *** Giszmo has joined #bitcoin-core-dev
 902017-08-31T08:56:05  *** JackH has quit IRC
 912017-08-31T09:13:47  *** justanotheruser has quit IRC
 922017-08-31T09:15:30  *** justanotheruser has joined #bitcoin-core-dev
 932017-08-31T09:47:05  *** shesek has quit IRC
 942017-08-31T09:49:35  *** shesek has joined #bitcoin-core-dev
 952017-08-31T09:50:11  *** wvr has joined #bitcoin-core-dev
 962017-08-31T10:07:23  *** JackH has joined #bitcoin-core-dev
 972017-08-31T10:16:40  *** dabura667 has quit IRC
 982017-08-31T10:24:49  *** RubenSomsen has quit IRC
 992017-08-31T10:34:32  *** laurentmt has quit IRC
1002017-08-31T10:35:35  *** shesek has quit IRC
1012017-08-31T10:45:41  *** RubenSomsen has joined #bitcoin-core-dev
1022017-08-31T10:52:23  *** str4d has joined #bitcoin-core-dev
1032017-08-31T10:56:33  *** Aaronvan_ has joined #bitcoin-core-dev
1042017-08-31T10:57:37  *** AaronvanW has quit IRC
1052017-08-31T11:08:35  *** Gunnie has joined #bitcoin-core-dev
1062017-08-31T11:16:21  *** meshcollider_ has joined #bitcoin-core-dev
1072017-08-31T11:18:10  *** SopaXorzTaker has quit IRC
1082017-08-31T11:18:22  *** str4d has quit IRC
1092017-08-31T11:18:53  *** SopaXorzTaker has joined #bitcoin-core-dev
1102017-08-31T11:19:45  *** Aaronvan_ is now known as AaronvanW
1112017-08-31T11:26:05  *** justan0theruser has joined #bitcoin-core-dev
1122017-08-31T11:28:00  *** justanotheruser has quit IRC
1132017-08-31T11:39:41  *** justan0theruser has quit IRC
1142017-08-31T11:40:08  *** justanotheruser has joined #bitcoin-core-dev
1152017-08-31T11:43:12  *** Giszmo has quit IRC
1162017-08-31T11:44:46  *** ChesterVal has joined #bitcoin-core-dev
1172017-08-31T11:57:08  *** laurentmt has joined #bitcoin-core-dev
1182017-08-31T12:00:42  *** AaronvanW has quit IRC
1192017-08-31T12:00:50  *** laurentmt has quit IRC
1202017-08-31T12:00:54  *** Giszmo has joined #bitcoin-core-dev
1212017-08-31T12:01:47  *** AaronvanW has joined #bitcoin-core-dev
1222017-08-31T12:32:55  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1232017-08-31T12:43:41  *** To7 has joined #bitcoin-core-dev
1242017-08-31T13:01:30  <wumpus> I won't be at the dev meeting today - just getting settled in here at SF and have a few days holiday
1252017-08-31T13:02:02  *** bitsegwit has quit IRC
1262017-08-31T13:07:28  <instagibbs> Synced rc3 in 5 hours on my laptop with default dbcache, very tame IO use. Very nice work!
1272017-08-31T13:10:02  *** Dyaheon has quit IRC
1282017-08-31T13:11:26  *** Dyaheon has joined #bitcoin-core-dev
1292017-08-31T13:12:32  *** shesek has joined #bitcoin-core-dev
1302017-08-31T13:33:39  *** Chris_Stewart_5 has quit IRC
1312017-08-31T13:35:05  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1322017-08-31T13:36:05  *** shesek has quit IRC
1332017-08-31T13:43:37  <bitcoin-git> [bitcoin] sdaftuar opened pull request #11203: RPC: add wtxid to mempool entry output (master...2017-08-add-wtxid-to-mempool-entry) https://github.com/bitcoin/bitcoin/pull/11203
1342017-08-31T13:44:49  <sdaftuar> jl2012: i don't see an easy way to list all segwit tx's in the mempool currently, but i just opened #11203 which would make it pretty straightforward (just compare txid to wtxid)
1352017-08-31T13:54:32  *** meshcollider_ has quit IRC
1362017-08-31T14:15:08  *** sstone has joined #bitcoin-core-dev
1372017-08-31T14:18:01  *** Chris_Stewart_5 has quit IRC
1382017-08-31T14:27:52  *** riemann has joined #bitcoin-core-dev
1392017-08-31T14:29:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1402017-08-31T14:39:52  *** esotericnonsense has quit IRC
1412017-08-31T14:40:01  *** sturles has quit IRC
1422017-08-31T14:40:01  *** Chris_Stewart_5 has quit IRC
1432017-08-31T14:40:30  *** esotericnonsense has joined #bitcoin-core-dev
1442017-08-31T14:47:35  *** adiabat has quit IRC
1452017-08-31T14:53:40  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1462017-08-31T14:58:24  *** adiabat has joined #bitcoin-core-dev
1472017-08-31T14:59:44  *** riemann has quit IRC
1482017-08-31T15:03:31  *** sturles has joined #bitcoin-core-dev
1492017-08-31T15:07:43  <gmaxwell> sdaftuar: this should work: ./bitcoin-cli getblocktemplate | jq '.transactions | .[] | select(.hash != .txid) | .txid'
1502017-08-31T15:07:57  <gmaxwell> but that only does it with the blocktemplate.
1512017-08-31T15:09:58  <sdaftuar> gmaxwell: yeah so that only gets segwit tx's in the top of the mempool, rather than the whole mempool
1522017-08-31T15:10:10  <sdaftuar> btw you just improved my life substantially by teaching me about jq
1532017-08-31T15:12:11  <sstone> hi, I have a question about SPV nodes: does bitcoin core include tx witness data in filtered blocks sent to SPV client ?
1542017-08-31T15:13:19  <sdaftuar> sstone: not currently, though there's an open PR on that topic.  see #10350
1552017-08-31T15:13:31  <bitcoin-git> [bitcoin] santyraghavan opened pull request #11204: Merge pull request #1 from bitcoin/master (master...master) https://github.com/bitcoin/bitcoin/pull/11204
1562017-08-31T15:16:30  <sstone> sdaftuar: thanks !
1572017-08-31T15:19:48  *** shesek has joined #bitcoin-core-dev
1582017-08-31T15:22:28  <gmaxwell> sstone: if you have a usecase for that I'd like to learn more. I understand codeshark's and I assume we'll do it for his but his is kind of weird and obscure.
1592017-08-31T15:26:20  *** Gunnie has quit IRC
1602017-08-31T15:26:35  *** shesek has quit IRC
1612017-08-31T15:27:27  <sstone> our use case is light-weight (mobile for example) LN compatible wallets. There are cases when you will want to monitor the blockchain and extract preimages from witness data
1622017-08-31T15:28:56  *** Chris_Stewart_5 has quit IRC
1632017-08-31T15:39:13  *** Giszmo has quit IRC
1642017-08-31T15:41:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1652017-08-31T15:51:38  *** Giszmo has joined #bitcoin-core-dev
1662017-08-31T15:54:45  *** BashCo has quit IRC
1672017-08-31T15:55:23  *** BashCo has joined #bitcoin-core-dev
1682017-08-31T15:55:58  *** praxeology has quit IRC
1692017-08-31T15:59:32  *** BashCo has quit IRC
1702017-08-31T16:07:35  *** RubenSomsen has quit IRC
1712017-08-31T16:08:43  *** Yogaqueef has quit IRC
1722017-08-31T16:10:04  *** chjj has joined #bitcoin-core-dev
1732017-08-31T16:14:48  *** BashCo has joined #bitcoin-core-dev
1742017-08-31T16:24:01  *** laurentmt has joined #bitcoin-core-dev
1752017-08-31T16:25:09  *** sstone has quit IRC
1762017-08-31T16:34:04  *** blznblzn2 has joined #bitcoin-core-dev
1772017-08-31T16:46:26  <bitcoin-git> [bitcoin] jnewbery closed pull request #10591: [tests] make pruning.py faster (master...fastprune) https://github.com/bitcoin/bitcoin/pull/10591
1782017-08-31T16:53:43  *** RubenSomsen has joined #bitcoin-core-dev
1792017-08-31T16:56:09  *** SopaXorzTaker has quit IRC
1802017-08-31T17:01:50  *** Chris_Stewart_5 has quit IRC
1812017-08-31T17:02:45  *** abpa has joined #bitcoin-core-dev
1822017-08-31T17:13:41  *** timothy has quit IRC
1832017-08-31T17:14:04  *** illpadrino has joined #bitcoin-core-dev
1842017-08-31T17:14:19  <illpadrino> hello all
1852017-08-31T17:14:52  <illpadrino> Does anyone have experience with Bitcoin ATM? I am thinking to put one in Paraguay
1862017-08-31T17:16:17  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1872017-08-31T17:23:04  <Lauda> Wrong chat, go to #bitcoin.
1882017-08-31T17:23:27  *** klkk has joined #bitcoin-core-dev
1892017-08-31T17:28:48  <warren> https://github.com/bitcoincore/  is this associated with anyone here?
1902017-08-31T17:29:22  <gmaxwell> warren: IIRC it's controlled by a github employee and they refused to give it up.
1912017-08-31T17:32:44  * sturles thinks you should rename Bitcoin Core back to Bitcoin.
1922017-08-31T17:36:18  * esotericnonsense agrees
1932017-08-31T17:41:35  *** Chris_Stewart_5 has quit IRC
1942017-08-31T17:44:28  *** Guyver2 has quit IRC
1952017-08-31T17:44:31  *** Murch has joined #bitcoin-core-dev
1962017-08-31T17:45:31  *** shesek has joined #bitcoin-core-dev
1972017-08-31T17:47:35  *** JackH has quit IRC
1982017-08-31T17:55:33  * luke-jr disagrees.
1992017-08-31T17:56:25  <luke-jr> it was annoying to have to constantly explain to people that Core is not Bitcoin
2002017-08-31T17:58:33  *** karelb has quit IRC
2012017-08-31T17:59:59  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2022017-08-31T18:00:00  *** rjak2 has joined #bitcoin-core-dev
2032017-08-31T18:00:00  *** rjak has quit IRC
2042017-08-31T18:00:05  <warren> Could rename it to Badger? (only half joking)
2052017-08-31T18:00:15  *** rjak2 is now known as rjak
2062017-08-31T18:00:21  *** JackH has joined #bitcoin-core-dev
2072017-08-31T18:00:36  <warren> jonasschnelli: https://github.com/bitcoin/bitcoin/pull/9483  will you be able to rebase this soon?
2082017-08-31T18:02:14  <instagibbs> luke-jr, NotBitcoin
2092017-08-31T18:02:20  <instagibbs> agreed with luke-jr
2102017-08-31T18:19:11  *** Giszmo has quit IRC
2112017-08-31T18:20:06  *** praxeology has joined #bitcoin-core-dev
2122017-08-31T18:20:29  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #11204: Merge pull request #1 from bitcoin/master (master...master) https://github.com/bitcoin/bitcoin/pull/11204
2132017-08-31T18:25:34  <bitcoin-git> [bitcoin] danra opened pull request #11205: Make fixed CAmounts and related sanity function constexpr (master...refactor/constexpr-amount) https://github.com/bitcoin/bitcoin/pull/11205
2142017-08-31T18:29:46  *** jtimon has joined #bitcoin-core-dev
2152017-08-31T18:31:19  *** asimplecoder has joined #bitcoin-core-dev
2162017-08-31T18:31:24  <asimplecoder> hey
2172017-08-31T18:31:30  <asimplecoder> anyone online?
2182017-08-31T18:34:07  *** Chris_Stewart_5 has quit IRC
2192017-08-31T18:34:45  *** Giszmo has joined #bitcoin-core-dev
2202017-08-31T18:35:51  <sipa> no
2212017-08-31T18:37:56  <bitcoin-git> [bitcoin] polyetilen opened pull request #11206: Update optionsdialog.ui (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11206
2222017-08-31T18:40:18  *** Veseli_Zagorec has joined #bitcoin-core-dev
2232017-08-31T18:47:12  *** belcher has quit IRC
2242017-08-31T18:54:25  *** Aaronvan_ has joined #bitcoin-core-dev
2252017-08-31T18:56:30  *** AaronvanW has quit IRC
2262017-08-31T18:57:18  *** luke-jr has quit IRC
2272017-08-31T18:58:10  *** meshcollider_ has joined #bitcoin-core-dev
2282017-08-31T18:58:45  *** meshcollider_ is now known as meshcollider
2292017-08-31T19:00:52  *** luke-jr has joined #bitcoin-core-dev
2302017-08-31T19:01:45  <achow101> Meeting?
2312017-08-31T19:02:11  <sdaftuar> here
2322017-08-31T19:02:15  <jnewbery> hello
2332017-08-31T19:02:22  <meshcollider> hi
2342017-08-31T19:02:35  <sipa> hi
2352017-08-31T19:02:53  <cfields> hi
2362017-08-31T19:04:09  <sdaftuar> wumpus said above that he'd be skipping today
2372017-08-31T19:04:45  <achow101> Oh
2382017-08-31T19:05:09  <cfields> well we can still discuss :)
2392017-08-31T19:05:10  <luke-jr> hi
2402017-08-31T19:05:14  <cfields> gmaxwell: have your mass ping handy?
2412017-08-31T19:05:34  <achow101> Whatever shall we do without our fearless leader? :P
2422017-08-31T19:05:49  <luke-jr> someone should do the startmeeting command
2432017-08-31T19:05:53  <luke-jr> (and chair)
2442017-08-31T19:05:54  <sipa> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
2452017-08-31T19:05:58  <sipa> #startmeeting
2462017-08-31T19:05:58  <lightningbot> Meeting started Thu Aug 31 19:05:58 2017 UTC.  The chair is sipa. Information about MeetBot at http://wiki.debian.org/MeetBot.
2472017-08-31T19:05:58  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2482017-08-31T19:06:13  <sipa> I'm not sure whether gmaxwell is available right now
2492017-08-31T19:06:26  <sipa> topics?
2502017-08-31T19:06:39  <meshcollider> it still lists wumpus as present lol
2512017-08-31T19:07:12  <achow101> Anything with 0.15.0?
2522017-08-31T19:07:16  <luke-jr> meshcollider: it's not a list of present people, just a mention to wake them up
2532017-08-31T19:07:18  <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101
2542017-08-31T19:07:23  <gmaxwell> I'm not really here.
2552017-08-31T19:07:27  <kanzure> hi.
2562017-08-31T19:07:44  <luke-jr> achow101: there's a string issue, but not sure it matters much
2572017-08-31T19:07:49  <luke-jr> the debug log tooltip IIRC
2582017-08-31T19:07:56  <cfields> any observed 0.15 bugs?
2592017-08-31T19:07:57  <sipa> what is up with #11198?
2602017-08-31T19:08:08  <kanzure> next meeting unlikely to be on irc
2612017-08-31T19:08:23  <achow101> (I'm not really here, hard to irc on a bike)
2622017-08-31T19:09:01  <gmaxwell> cfields: there was someone complaining rc3 is crashing on windows
2632017-08-31T19:09:09  <luke-jr> what is #11198? (I'm stuck at CLI)
2642017-08-31T19:09:13  <morcos> heh, i am here, for a change
2652017-08-31T19:09:14  *** Roger2x has joined #bitcoin-core-dev
2662017-08-31T19:09:17  <sipa> #topic 0.15.0
2672017-08-31T19:09:18  <cfields> sipa: heh, that hardly seems like something worth waiting for
2682017-08-31T19:09:22  <gmaxwell> achow101 was going to try reproducing.
2692017-08-31T19:09:25  <sipa> luke-jr: Fix display of package name on 'open config file' tooltip
2702017-08-31T19:09:32  <cfields> gmaxwell: hmm, link? or discussion?
2712017-08-31T19:09:47  <achow101> The rc3 problem was fixed with iirc
2722017-08-31T19:09:57  *** laurentmt has quit IRC
2732017-08-31T19:09:58  <achow101> (the windows crash thing)
2742017-08-31T19:10:03  <instagibbs> present
2752017-08-31T19:10:11  <gmaxwell> cfields: https://bitcointalk.org/index.php?topic=2132893.0
2762017-08-31T19:10:19  <instagibbs> gmaxwell, running fine here on windows fwiw
2772017-08-31T19:10:21  <gmaxwell> ohcrap this again:
2782017-08-31T19:10:22  <luke-jr> IMO a tooltip doesn't need to block final, but since we're waiting a week anyway, might as well do a RC with it? (maybe merge in the -acceptnonstdtxn fix too)
2792017-08-31T19:10:23  <gmaxwell> Problem solved!  Running bitcoin-qt with the '-resetguisettings' switch fixed it.  Thanks to MeshCollider on github for the fix! Smiley
2802017-08-31T19:10:36  <gmaxwell> ^ that is now the third person I've seen screwed by this.
2812017-08-31T19:10:44  <gmaxwell> did we change something that created this problem
2822017-08-31T19:10:47  <luke-jr> gmaxwell: that's the crash?
2832017-08-31T19:10:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2842017-08-31T19:10:54  <gmaxwell> luke-jr: apparently it wasn't actually a crash
2852017-08-31T19:11:07  <gmaxwell> the symptom is you start bitcoin and it vanishes after the splash
2862017-08-31T19:11:11  <sipa> just the window appearing in an offscreen location?
2872017-08-31T19:11:17  <luke-jr> ah
2882017-08-31T19:11:20  <sipa> can we add a test for that?
2892017-08-31T19:11:32  <luke-jr> sipa: we do already IIRC
2902017-08-31T19:11:35  <sipa> (if window is beyond screen coordinates, reset gui settings automatically)
2912017-08-31T19:11:38  <sipa> jonasschnelli: ^
2922017-08-31T19:11:58  <gmaxwell> 16:19 < gmaxwell> jonasschnelli: I just had someone on IRC that had their GUI not displaying after upgrading to 0.14.2 ... this fixed it https://github.com/bitcoin/bitcoin/issues/7869#issuecomment-209265754  is there some underlying bug we need to fix?
2932017-08-31T19:12:02  <gmaxwell> 11:19 < jonasschnelli> gmaxwell: most possible problem of a not-appearing GUI is probably persisted windows coordinates outside of the screen boundaries.
2942017-08-31T19:12:05  <gmaxwell> 11:20 < jonasschnelli> could be fixed by checking the screen bounds against the QSettings coords
2952017-08-31T19:12:08  <gmaxwell> 11:21 < jonasschnelli> -resetguisettings will just evict all user based Qt overrides (and things like window coordinates)
2962017-08-31T19:12:12  <meshcollider> #11171 for reference
2972017-08-31T19:12:16  <sipa> thnaks
2982017-08-31T19:12:36  *** Veseli_Zagorec has quit IRC
2992017-08-31T19:12:54  <gmaxwell> it worries me that I've never seen this complain before and now three in a few weeks, all with people testing 0.15rc
3002017-08-31T19:13:04  <gmaxwell> complaint*
3012017-08-31T19:13:10  <luke-jr> gmaxwell: could it be the Qt version bump?
3022017-08-31T19:13:22  <gmaxwell> thats beyond my pay grade to speculate.
3032017-08-31T19:14:06  <cfields> gmaxwell: all windows complaints?
3042017-08-31T19:14:11  <gmaxwell> yes
3052017-08-31T19:14:12  <luke-jr> a shame the users have done the workaround..
3062017-08-31T19:14:28  <gmaxwell> it's a pretty bad failure mode, silently gone...
3072017-08-31T19:14:32  <luke-jr> if we can get it reproduced again, it'd be nice to get the registry entries involved
3082017-08-31T19:14:36  <cfields> i wonder if they're all multi-monitor
3092017-08-31T19:14:49  <gmaxwell> luke-jr: well I told one to do it because it was a hail mary... I had no idea it would actually fix it.
3102017-08-31T19:14:53  <luke-jr> cfields: hmm, monitors of different sizes maybe?
3112017-08-31T19:15:15  <gmaxwell> we can ask.
3122017-08-31T19:15:22  <cfields> luke-jr: i was thinking: bitcoin-qt on monitor 2, shutdown, restart with only monitor 1
3132017-08-31T19:15:30  <luke-jr> I could totally see different-sized monitors confusing this
3142017-08-31T19:15:46  <luke-jr> cfields: am I wrong that we don't check for visible coordinates?
3152017-08-31T19:15:51  <luke-jr> err, that we do*
3162017-08-31T19:16:16  <luke-jr> (which would probably fail if the monitors are different sizes, due to blocked-off regions within the total dimensions)
3172017-08-31T19:16:21  <cfields> luke-jr: no clue
3182017-08-31T19:16:38  *** belcher has joined #bitcoin-core-dev
3192017-08-31T19:17:20  <achow101> Gmaxwell: I believe it's a registry problem
3202017-08-31T19:17:40  <achow101> Since qsettings stores things in registry
3212017-08-31T19:18:04  <sipa> achow101: i think the registry is just a storage medium
3222017-08-31T19:18:27  <gmaxwell> did we just start doing this... or
3232017-08-31T19:18:51  <sipa> i think bitcoin-qt has done that since forver, and nothing changed wrt to that now
3242017-08-31T19:18:55  <achow101> Gmaxwell: I don't think so. It's been reported a few times before with older versions
3252017-08-31T19:19:12  <meshcollider> relevant code? https://github.com/bitcoin/bitcoin/blob/master/src/qt/guiutil.cpp#L852
3262017-08-31T19:20:15  <BlueMatt> we always see a flood of reports of old issues upon new rc's
3272017-08-31T19:20:36  <gmaxwell> yea, okay!
3282017-08-31T19:21:27  <MarcoFalke> The "Fix for issues with startup and multiple monitors on windows." is already included https://github.com/bitcoin/bitcoin/commit/e9ff818b69c2f8ce4a151d1a81a3e22a4319c93d
3292017-08-31T19:22:24  <ryanofsky> that doesn't seem like a sufficient fix if x and y are just outside screen geometry
3302017-08-31T19:22:33  <jtimon> anything else regarding 0.15 ?
3312017-08-31T19:22:41  <luke-jr> MarcoFalke: new in 0.15?
3322017-08-31T19:22:46  <MarcoFalke> jup
3332017-08-31T19:22:47  <luke-jr> maybe it's the problem..?
3342017-08-31T19:23:04  <MarcoFalke> Yes, I think the fix is not sufficient
3352017-08-31T19:24:01  <ryanofsky> would need to add || pos.x() > screen.width() || pos.y() > screen.height()
3362017-08-31T19:24:16  <gmaxwell> from that code it looks obvious how to fix this.
3372017-08-31T19:24:19  <gmaxwell> what ryanofsky said
3382017-08-31T19:24:32  <gmaxwell> well almost obvious
3392017-08-31T19:24:46  <luke-jr> that won't work for the different-sizes scenario, but sure
3402017-08-31T19:24:48  <achow101> replicated the problem. will write up how in the issue after this class I am in
3412017-08-31T19:24:49  <gmaxwell> ryanofsky: that one will lets the window be at width(),height(). :P
3422017-08-31T19:24:54  <BlueMatt> yea, no idea what QApplication::desktop()->screenNumber(parent) == -1 does, but guess it doesnt work on win....someone able to test?
3432017-08-31T19:25:05  <achow101> tl;dr look at the registry for qsettings for nWindowPos
3442017-08-31T19:25:20  <ryanofsky> BlueMatt, that is probably the check for no longer connected multimonitor
3452017-08-31T19:25:47  <meshcollider> ^^ if its -1 means the screen doesn't exist
3462017-08-31T19:25:49  <achow101> if the setting is for an off screen point, nothing will show
3472017-08-31T19:25:58  <gmaxwell> yea but it may do nothing on windows, perhaps on windows the window is just off screen.
3482017-08-31T19:26:08  <BlueMatt> ryanofsky: yea, but that should work if you're on no screen? no idea
3492017-08-31T19:26:19  <BlueMatt> anyway, I'll stop speculating above my paygrade
3502017-08-31T19:26:38  <sipa> can someone open a bug?
3512017-08-31T19:26:51  <BlueMatt> ^ that
3522017-08-31T19:27:14  <gmaxwell> just reopen 7869 perhaps
3532017-08-31T19:27:20  <jtimon> perhaps also PR ryanofsky's potential solution ?
3542017-08-31T19:27:23  <sipa> i don't think we need to solve this problem in this meeting (though there seem few other topics)
3552017-08-31T19:27:32  <ryanofsky> i think achow101 said he would write it up?
3562017-08-31T19:27:40  <luke-jr> so that's 3 things for an rc4 I guess?
3572017-08-31T19:27:46  <sipa> luke-jr: 3?
3582017-08-31T19:27:51  <achow101> I'll make a new issue with the thing I just found
3592017-08-31T19:27:51  <gmaxwell> We should talk about progress for full segwit support.
3602017-08-31T19:27:53  <meshcollider> whats the 3rd?
3612017-08-31T19:27:57  <instagibbs> gmaxwell, ack
3622017-08-31T19:28:06  <sipa> achow101: thanks!
3632017-08-31T19:28:06  <luke-jr> sipa: 1) positioning; 2) debug log tooltip; 3) acceptnonstdtxn help
3642017-08-31T19:28:28  <morcos> i know i'm the cause of rc3, but i actually advocate for drawing the line somewhere
3652017-08-31T19:28:31  <luke-jr> maybe 4) Polish translation update
3662017-08-31T19:28:41  <morcos> it wasn't clear to me if we have to wait 2 weeks now until we have a new RC
3672017-08-31T19:28:52  <luke-jr> morcos: IMO the positioning issue is sufficient to warrant rc4
3682017-08-31T19:28:55  <morcos> if so i think none of those are maybe sufficient for RC4
3692017-08-31T19:28:59  <sipa> morcos: let's discuss this when wumpus is available
3702017-08-31T19:29:21  <luke-jr> especially if users are encountering it
3712017-08-31T19:29:26  <morcos> ok. at the very least lets, note that its a question, instead of a conclusion that there will be RC4
3722017-08-31T19:29:27  <meshcollider> yeah and first lets make sure the fix for the positioning issue actually solves the problem lol
3732017-08-31T19:29:32  <morcos> luke-jr: but there is a workaround no?
3742017-08-31T19:29:46  <morcos> how much valuable info do you lose my resetguisettings
3752017-08-31T19:29:46  <sipa> meshcollider: indeed
3762017-08-31T19:29:51  <luke-jr> morcos: not a nice one - you lose all your other GUI settings
3772017-08-31T19:29:58  <achow101> morcos: all gui settings
3782017-08-31T19:30:06  <achow101> it can also be fixed with regedt
3792017-08-31T19:30:11  <sipa> achow101 said he'd open a bug with relevant information - let's discuss there when we have that
3802017-08-31T19:30:22  <luke-jr> k
3812017-08-31T19:30:26  <sipa> #topic full segwit support
3822017-08-31T19:31:37  <sipa> i have a question: should we 1) automatically add witness redeem scripts for newly generated addresses, or 2) bypass the restriction that the redeemscript must be available for P2WPKH when the pubkey itself is available?
3832017-08-31T19:32:07  <morcos> sipa: could you explain that a bit more thoroughly
3842017-08-31T19:32:20  <BlueMatt> sipa: #1
3852017-08-31T19:32:21  <sipa> the downside of 2) is that we'd accept segwit payments to converted-p2pkh-to-p2wpkh addresses (which i think is a bad property), but that it significantly reduced the overhead of adding a key
3862017-08-31T19:32:29  <meshcollider> I'd say 1 is better
3872017-08-31T19:33:06  <BlueMatt> i guess drawback of 1 is you cant receive via segwit to old addresses?
3882017-08-31T19:33:09  <BlueMatt> I'm ok with that
3892017-08-31T19:33:19  <sipa> BlueMatt: i would call that an advantage
3902017-08-31T19:33:23  <BlueMatt> agreed
3912017-08-31T19:33:29  <sipa> ideally we don't accept anything to an address that wasn't given out
3922017-08-31T19:33:41  <sdaftuar> ^ that
3932017-08-31T19:33:41  <gmaxwell> we should really try to avoid accepting an address that we'd never issue if at all possible, it's very dangerous if people think they can do that and have it work.
3942017-08-31T19:33:49  <meshcollider> I guess there'd still be a way to manually do it if you wanted to though right?
3952017-08-31T19:33:51  <luke-jr> indeed, if we accept segwit to non-segwit addresses, people might get a false impression it's supported, and lose money
3962017-08-31T19:33:53  <Chris_Stewart_5> is #1 really that expensive?
3972017-08-31T19:34:01  <sipa> alternatively, we can also have a boolean in the key meta data saying that the "corresponding" address is segwit
3982017-08-31T19:34:20  <sipa> in which case we bypass the need-redeemscript property, but just for keys with that flag set
3992017-08-31T19:34:40  <sipa> but at the cost of extra complexity
4002017-08-31T19:34:44  <morcos> sipa: is hte issue wiht 1) bloat?
4012017-08-31T19:34:48  <luke-jr> but when generating an address, it should only automatically add it if the user wants a witness address; we need to support at least P2SH-wrapper addresses until Bech32 adoption is widespread..
4022017-08-31T19:34:50  <sipa> morcos: yes, just bloat
4032017-08-31T19:34:55  <gmaxwell> manually sure, it's like importing a key.
4042017-08-31T19:35:32  <sipa> luke-jr: that brings us to another question - my view is that we shouldn't support choosing on a per-address basis whether it should be segwit or not; just a wallet-wide flag that you now want segwit
4052017-08-31T19:35:40  <luke-jr> sipa: I like the key metadata approach; that lets us refuse non-segwit payments to segwit keys
4062017-08-31T19:35:43  <sipa> the reason for that is for interaction with hd auto topup
4072017-08-31T19:35:49  <gmaxwell> ^ I think so to, wallet wide because of recovery.
4082017-08-31T19:35:53  <instagibbs> i think wallets make a lot more sense if by default you do one or the other, and support importing otherwise
4092017-08-31T19:35:53  <morcos> sipa: +1 on no per-address choosing
4102017-08-31T19:36:04  <luke-jr> sipa: then nobody can reasonably use p2wpkh until support for bech32 is universal? :/
4112017-08-31T19:36:06  <gmaxwell> importing one shows that violate the wallet wide is fine.
4122017-08-31T19:36:07  <morcos> the whole point of segwit (well one of them) is we think thats the right way to do transactions)
4132017-08-31T19:36:18  <BlueMatt> sipa: we could also do that on-disk, but in-memory keep the bloat-y version?
4142017-08-31T19:36:29  <sdaftuar> how will the migration to bech32 work?
4152017-08-31T19:36:42  <instagibbs> luke-jr, is there any reason we cant return multiple address types? thinking out loud :)
4162017-08-31T19:36:48  <sipa> luke-jr: i think we'll be forced to support bech32 as an optional thing and treat bech32 and its p2sh embdeed version identially
4172017-08-31T19:36:49  <luke-jr> also, doesn't this mean you can't upgrade existing wallets?
4182017-08-31T19:36:49  <gmaxwell> sdaftuar: send to it first, and when ~everyone can send it it, we start generating addresses.
4192017-08-31T19:36:51  <instagibbs> if we're doing a hard switchover, we can break api a bit?
4202017-08-31T19:37:04  <luke-jr> instagibbs: eww :(
4212017-08-31T19:37:06  <gmaxwell> sipa: ugh.
4222017-08-31T19:37:19  <sipa> gmaxwell: there's no way we can switch over an entire wallet to bech32
4232017-08-31T19:37:26  <sipa> at least not the first ... year?
4242017-08-31T19:37:26  <gmaxwell> certantly not today!
4252017-08-31T19:37:33  <gmaxwell> yes sure. and
4262017-08-31T19:37:33  <instagibbs> luke-jr, elaborate the ew
4272017-08-31T19:37:35  <luke-jr> sipa: that's why per-address is useful
4282017-08-31T19:37:49  <sipa> luke-jr: but per-address is inherently incompatible with hd auto topup
4292017-08-31T19:37:52  <gmaxwell> luke-jr: per-address is not backup durable.
4302017-08-31T19:38:07  <luke-jr> hmm
4312017-08-31T19:38:18  <luke-jr> what if we use separate HD chains for each type?
4322017-08-31T19:38:21  <gmaxwell> why are we expanding scope to recieve BIP173 addresses. I think we should not make this scope expansion now.
4332017-08-31T19:38:32  <morcos> gmaxwell: what did you not like, having bech32 and p2sh both supported together?
4342017-08-31T19:38:37  <sipa> i think we have two options (which apply to both segwit/legacy and to p2sh/bech32): treat them as identical and accept payments to both, or switch over the wallet entirely
4352017-08-31T19:38:37  <BlueMatt> <luke-jr> also, doesn't this mean you can't upgrade existing wallets? <-- yea. this. the discussion about hd-upgrade kinda devolved (I've been mia for a week so may be behind), but it seems to me with the current disk structure we need hd-upgrade before we can do segwit-upgrade unless we want to start forking the -upgradewallet stuff
4362017-08-31T19:39:00  <gmaxwell> morcos: because then people can randomly turn your addresses to the other kind which you've never given out and pay you.
4372017-08-31T19:39:47  <BlueMatt> yea, I think its unacceptable to do that cause we have shit like breaking uncompressed keys, so we really, really dont want to support people blindly converting addresses, sets a terrible understanding
4382017-08-31T19:39:48  <sipa> my view is that we should treat bech32 and p2sh as identical - because, by design, they are identical - every segwit version is supposed to work in both
4392017-08-31T19:39:52  <luke-jr> BlueMatt: even the ability to upgrade an existing HD wallet to a segwit+HD wallet would be nice
4402017-08-31T19:39:52  <gmaxwell> the pre-segwit vs segwit version of that question is incredibly dangerous.   p2sh-embed vs not, is perhaps less so.
4412017-08-31T19:39:59  <sipa> but we should not treat segwit and p2pkh as identical
4422017-08-31T19:39:59  <morcos> so we can do this in 2 stages?  switch whole wallet to p2sh embedded segwit, and then in 6-12 mos switch whole wallet to bech32?
4432017-08-31T19:40:00  *** Cheeseo has joined #bitcoin-core-dev
4442017-08-31T19:40:05  *** asimplecoder has quit IRC
4452017-08-31T19:40:16  *** Dyaheon has quit IRC
4462017-08-31T19:40:18  <gmaxwell> sipa: we should have specified this as part of the segwit bips then. :(  but okay, it could be done.
4472017-08-31T19:40:21  <BlueMatt> sipa: I'm ok with that
4482017-08-31T19:40:38  <gmaxwell> morcos: that was my expectation, and we will have to do is regardless at least in terms of what addresses we return.
4492017-08-31T19:40:41  <jtimon> sipa: well, we could , for example switch over enterily for segwit/legacy but treat identical for p2sh/bech32, no?
4502017-08-31T19:40:52  <sipa> jtimon: that's exactly what i'm suggesting
4512017-08-31T19:40:58  <BlueMatt> morcos: i think sipa is advocating for (and I like) - switch wallet over to "segwit" and give users the addresses in p2sh-embedded form, but really thats a ui-level thing
4522017-08-31T19:41:07  * jtimon nods
4532017-08-31T19:41:09  <BlueMatt> and maybe a flag for "i gave this address out as version X"
4542017-08-31T19:41:11  <sipa> however, the bech32 question is not very urgent now
4552017-08-31T19:41:21  <sipa> while switchover the segwit is
4562017-08-31T19:41:43  <sipa> i guess there are a) support both for our own keys b) use separate hd chains for segwit c) switchover wallet as a whole
4572017-08-31T19:41:46  <morcos> BlueMatt: right so we'd be capable of receiving a bech32 payment, but we would not give those out for some time?
4582017-08-31T19:41:52  <sipa> i think (c) is best
4592017-08-31T19:41:59  <BlueMatt> morcos: yes
4602017-08-31T19:42:22  <instagibbs> BlueMatt, and send I hope?
4612017-08-31T19:42:22  <BlueMatt> sipa: wait, I'm  confused...does c include a and b?
4622017-08-31T19:42:24  <luke-jr> (c) will slow adoption
4632017-08-31T19:42:24  *** Dyaheon has joined #bitcoin-core-dev
4642017-08-31T19:42:37  <sipa> BlueMatt: they are 3 distinct possibilities
4652017-08-31T19:43:01  <achow101> (c) works well with multi wallet
4662017-08-31T19:43:10  <sipa> (c) means there is a wallet-wide flag that says "SEGWIT: YES", and if so, all new addresses are generated as segwit, and integrated with hd topup
4672017-08-31T19:43:24  <sipa> but no separate chains for segwit or not
4682017-08-31T19:43:25  <instagibbs> achow101, right, my ledger support will likely simply utilize multiwallet for crossover
4692017-08-31T19:43:31  <gmaxwell> sipa: and if we wanted to convert an old wallet we could just import all the keys.
4702017-08-31T19:43:32  <BlueMatt> sipa: ah, yes, back to my previous question...what form does that flag take
4712017-08-31T19:43:41  <sipa> BlueMatt: i see
4722017-08-31T19:43:45  <BlueMatt> sipa: cause its damn-dirty to add a flag like that and not use our versioning stuff
4732017-08-31T19:43:50  <achow101> If we do that, we can also implement the optional features thing for wallets
4742017-08-31T19:43:54  <BlueMatt> but using our versioning stuff means we need hd-upgrade
4752017-08-31T19:44:01  <sipa> BlueMatt: i want to get rid of the version stuff and have feature flags
4762017-08-31T19:44:02  <BlueMatt> which i think we need, but may delay things
4772017-08-31T19:44:20  <BlueMatt> sipa: but exponential blowup of feature options :(
4782017-08-31T19:44:35  <sipa> BlueMatt: yes...
4792017-08-31T19:45:03  <sipa> so perhaps the question is: is there any reason why wallets shouldn't have that segwit flag (apart from backup reasons)
4802017-08-31T19:45:10  * BlueMatt sees no reason to *not* use existing versioning, but only question is possible delay
4812017-08-31T19:45:32  <instagibbs> BlueMatt, sorry delay how
4822017-08-31T19:45:42  <BlueMatt> sipa: yes, like anything else in the wallet, if user doesnt say -upgradewallet, we'd prefer to not break their backward compat
4832017-08-31T19:45:53  <BlueMatt> instagibbs: because if we use the versioning stuff, hd-upgrade must happen first
4842017-08-31T19:46:00  <morcos> Someone should write up a more comprehensive wallet plan.  The only thing that's clear is we need to support any kind of wallet that has existed in the past
4852017-08-31T19:46:02  <instagibbs> Ah, user delay, noted
4862017-08-31T19:46:19  <meshcollider> well it would only happen when they choose to upgrade to segwit only, so you can just give them a warning then right
4872017-08-31T19:46:19  <jtimon> sipa: what if the payer can't pay to segwit ? I think that's why luke wants to be able to genreate legacy for receiving, no?
4882017-08-31T19:46:21  <instagibbs> morcos, some people will be in person in a few days.... would be a good time to review such a doc
4892017-08-31T19:46:22  <morcos> But we don't need to support any possible combination..  So we shouldn't have segwit non-HD chain split wallets for example
4902017-08-31T19:46:28  <sipa> jtimon: every wallet can send to P2SH
4912017-08-31T19:46:29  <morcos> so lets make sure there is no way to create that
4922017-08-31T19:46:32  <BlueMatt> morcos: we've generally supported opening new wallets with old versions as long as they are un-upgraded, too
4932017-08-31T19:46:40  <jtimon> sipa: , oh, right, never mind
4942017-08-31T19:46:52  <gmaxwell> for upgrading I think we'd set the flag, start exploring the segwit address chain from 0 and import all the old keys as whatever they are.
4952017-08-31T19:47:09  <sipa> BlueMatt: yes, understood, but apart from that, is there any reason why someone would not want their wallet to construct segwit outputs?
4962017-08-31T19:47:09  <sipa> *addresses
4972017-08-31T19:47:09  <BlueMatt> morcos: yes, well then we need a "list of acceptable feature flag combinations" against which we check the wallet on load.... :/
4982017-08-31T19:47:16  <gmaxwell> sipa: no, only wallets that are trying to stay unupgraded.
4992017-08-31T19:47:27  <morcos> or for instance having segwit implies HD-chain split...
5002017-08-31T19:47:29  <BlueMatt> sipa: not to my knowledge, no
5012017-08-31T19:47:30  <sipa> so do we need a flag at all?
5022017-08-31T19:47:40  <sipa> as opposed to just start doing it automatically in a new version
5032017-08-31T19:47:43  <BlueMatt> only upgrade, to me
5042017-08-31T19:47:56  <BlueMatt> well we'd need users to do a -walletupgrade
5052017-08-31T19:48:01  <sipa> i don't think so
5062017-08-31T19:48:11  <BlueMatt> errr, I'm not a fan of that
5072017-08-31T19:48:29  <meshcollider> If you give them the setting somewhere in Qt then it can give them a compat warning when they go to upgrade it
5082017-08-31T19:48:30  <BlueMatt> that'd be the first time we break opening new wallets with an old version by default (and have no way to not break it!)
5092017-08-31T19:48:32  <sipa> maybe i'm missing something, but i see no failure scenario
5102017-08-31T19:48:39  <BlueMatt> i guess if we do that we should switch to bdb 5
5112017-08-31T19:48:47  <gmaxwell> if there is a reason we're unaware of the user can stay on the old version until we add support for whatever we want.
5122017-08-31T19:48:48  <luke-jr> sipa: downgrading
5132017-08-31T19:48:53  <sipa> luke-jr: elaborate
5142017-08-31T19:49:06  <sipa> old versions will produce old addresses, and not add the witness redeem script
5152017-08-31T19:49:08  <luke-jr> sipa: if I take my wallet, use it with 0.16, I should be able to use the same wallet with 0.12 again
5162017-08-31T19:49:10  <jtimon> do we want to support downgrading wallets?
5172017-08-31T19:49:25  <luke-jr> until I use -walletupgrade ofc
5182017-08-31T19:49:25  <BlueMatt> sipa: its always been the case that you can pretty easily run your wallet with an old version as long as it is not upgraded
5192017-08-31T19:49:30  <BlueMatt> with no significant feature loss
5202017-08-31T19:49:34  <sipa> new versions will produce new address, add their redeemscript, and when downgrading, those addresses will keep working
5212017-08-31T19:49:37  <BlueMatt> and definitely not with missing transactions
5222017-08-31T19:49:38  <sipa> BlueMatt: i don't see a problem
5232017-08-31T19:49:45  <achow101> So upgrade it with a version number
5242017-08-31T19:49:48  <luke-jr> sipa: old versions don't know how to sign for segwit UTXOs..
5252017-08-31T19:49:51  <BlueMatt> sipa: missing transactions
5262017-08-31T19:49:58  <sipa> BlueMatt: ?
5272017-08-31T19:50:12  <sipa> segwit address will work fine in older versions, if we use the redeemscript add construction
5282017-08-31T19:50:13  <BlueMatt> if you receive a payment using segwit and then open that wallet with an old version, it will not be there
5292017-08-31T19:50:20  <sipa> yes it will be
5302017-08-31T19:50:24  <sipa> at least down to 0.13.0
5312017-08-31T19:50:30  <luke-jr> sipa: and it will spend?
5322017-08-31T19:50:34  <sipa> luke-jr: yes
5332017-08-31T19:50:41  <sipa> luke-jr: the signing code for segwit works fine
5342017-08-31T19:50:48  <BlueMatt> mm, fair, though will fail for native segwit, I suppose?
5352017-08-31T19:50:51  <sipa> yes
5362017-08-31T19:50:58  <sipa> but ignore bech32 for now
5372017-08-31T19:51:02  <jtimon> dow we want to support wallet downgrade beyond 0.13 ?
5382017-08-31T19:51:08  <luke-jr> sipa: okay, so how does this all work for people who actively do not wish to use segwit transactions?
5392017-08-31T19:51:10  <sipa> jtimon: that's a good question
5402017-08-31T19:51:16  <BlueMatt> ohhhhhhhhhh, wait, errrrrr, wont everythin break anyway cause it wont deserialize segwit-formatted txn in the wallet pre-0.13.0?
5412017-08-31T19:51:22  <sipa> BlueMatt: yes
5422017-08-31T19:51:30  <BlueMatt> lol, ok, well we're not fixing that one
5432017-08-31T19:51:34  <BlueMatt> so I dont care
5442017-08-31T19:51:39  <morcos> we're talking about 2 different things...  are you saying if i open an 0.12 wallet in 0.16, then i can't reopen it in 0.12
5452017-08-31T19:51:41  <sipa> i guess BlueMatt answered jtimon's question
5462017-08-31T19:51:43  <morcos> that sounds like a terrible idea
5472017-08-31T19:51:49  <gmaxwell> I think it's fine if use of segwit makes the wallet 0.15.1+
5482017-08-31T19:51:51  <sipa> morcos: that's already the case...
5492017-08-31T19:51:53  <morcos> if you upgrade it, then yeah of course you don't need to be able to go backwards
5502017-08-31T19:52:01  <BlueMatt> gmaxwell: I'm not ok with that, I think
5512017-08-31T19:52:02  <luke-jr> sipa: why?
5522017-08-31T19:52:02  <morcos> sipa: huh?
5532017-08-31T19:52:10  <gmaxwell> wut
5542017-08-31T19:52:11  <sipa> morcos: because of what BlueMatt says
5552017-08-31T19:52:12  <morcos> i don't think so at all
5562017-08-31T19:52:18  <BlueMatt> gmaxwell: I'm fine with it being 0.13.0, which it already is
5572017-08-31T19:52:22  <morcos> hmm.
5582017-08-31T19:52:25  <sipa> you can receive a segwit transaction that pays you (via legacy output)
5592017-08-31T19:52:29  <morcos> i don't think so
5602017-08-31T19:52:29  <BlueMatt> gmaxwell: do we have any need to make it 0.15.1?
5612017-08-31T19:52:31  <sipa> that will be stored as a segwit txn in your wallet
5622017-08-31T19:52:33  <gmaxwell> I bet it doesn't work for 0.13.0
5632017-08-31T19:52:35  <BlueMatt> do we get any features from that, really?
5642017-08-31T19:52:36  <sipa> which 0.12 won't open
5652017-08-31T19:52:37  <morcos> oh maybe
5662017-08-31T19:52:38  <morcos> durn
5672017-08-31T19:52:44  <luke-jr> ugh
5682017-08-31T19:52:51  <meshcollider> Not if you just open the wallet without generating new addresses though ?
5692017-08-31T19:52:57  <gmaxwell> BlueMatt: how about testing resources if nothing else... but also you'll corrupt your wallet, when it doesn't know how to extend the keypool.
5702017-08-31T19:53:07  <luke-jr> does that mean if 0.12 receives a segwit tx, it will break newer??
5712017-08-31T19:53:19  <sipa> meshcollider: there can be a segwit address that pays you via a plain old p2pkh address
5722017-08-31T19:53:19  <BlueMatt> gmaxwell: if the wallet is un-upgraded it wont break?
5732017-08-31T19:53:30  <BlueMatt> gmaxwell: obviously if its an hd wallet old versions will refuse to open
5742017-08-31T19:53:38  <gmaxwell> BlueMatt: if it's unupgraded it's not giving out segwit addresses.
5752017-08-31T19:53:48  <BlueMatt> gmaxwell: though testing resources are obviously always an issue
5762017-08-31T19:54:02  <BlueMatt> gmaxwell: sipa was proposing that it give out segwit addresses even if it is unupgraded
5772017-08-31T19:54:30  <luke-jr> what happens right now, if we have a segwit tx in the wallet without witness data? :/
5782017-08-31T19:54:31  <gmaxwell> BlueMatt: how the heck does this even work for HD chains.
5792017-08-31T19:54:32  <instagibbs> 6 minutes
5802017-08-31T19:54:49  <meshcollider> sipa
5812017-08-31T19:54:58  <sipa> gmaxwell: it will work fine, unless you downgrade at the same time as you recover
5822017-08-31T19:55:00  <BlueMatt> gmaxwell: hd doesnt matter...wait, sipa was saying no new hd chain, maybe we should reopen that part of the discussion :p
5832017-08-31T19:55:01  <meshcollider> isnt that only the case if you gave out the address
5842017-08-31T19:55:07  <sipa> meshcollider: no
5852017-08-31T19:55:14  <sipa> 19:53:19 < sipa> meshcollider: there can be a segwit address that pays you via a plain old p2pkh address
5862017-08-31T19:55:28  <sipa> ^ in that case you don't ever generated a segwit address
5872017-08-31T19:55:29  <meshcollider> Can anyone generate that themselves?
5882017-08-31T19:55:42  <jtimon> in any case, is the question adding a new wallet version or not?
5892017-08-31T19:55:42  <BlueMatt> lol, sounds like we've got a lot to discuss next week
5902017-08-31T19:55:50  <BlueMatt> homework: everyone go farmiliarize yourself with wallet
5912017-08-31T19:55:53  <BlueMatt> ALL OF WALLET =D
5922017-08-31T19:55:54  <achow101> I'm horribly confused now
5932017-08-31T19:56:09  <sipa> meshcollider: no, but the sender can be segwit enabled while you aren't
5942017-08-31T19:56:13  <luke-jr> BlueMatt: every time I do that, I get the inclination to throw it all away and start from scratch :x
5952017-08-31T19:56:33  <cfields> heh, we desperately need to break this discussion up into chunks
5962017-08-31T19:56:40  <BlueMatt> cfields: yes
5972017-08-31T19:56:51  <instagibbs> can someone whip up a table or something of concerns
5982017-08-31T19:56:56  <instagibbs> action item?
5992017-08-31T19:57:01  <luke-jr> kanzure has one
6002017-08-31T19:57:06  <luke-jr> just needs updating
6012017-08-31T19:57:08  <achow101> Kanzure: add to list?
6022017-08-31T19:57:15  <meshcollider> oh I see yeah, true
6032017-08-31T19:57:21  <instagibbs> oh, for that too, if you're in SF next week
6042017-08-31T19:57:24  <cfields> kanzure: and update it so that it's backwards compatible to the last list, please.
6052017-08-31T19:57:36  <achow101> Lol
6062017-08-31T19:57:54  <sipa> a) how to deal with 0.13.1 through 0.15.0 receiving a segwit transaction and then downgrading to 0.12.x or below
6072017-08-31T19:58:05  <sipa> b) how to switch to generating segwit addresses
6082017-08-31T19:58:11  <sipa> c) how to switch to generating bech32 addresses
6092017-08-31T19:58:39  <jtimon> I won't go this time :( have productive discussions there, and fun too!
6102017-08-31T19:58:44  <BlueMatt> d) how to deal with 0.15.1 downgradingg to 0.13.1 (in both hd and non-hd modes)
6112017-08-31T19:59:05  <BlueMatt> e) whether to use a new hd chain for segwit addresses
6122017-08-31T19:59:13  <sipa> e falls under b
6132017-08-31T19:59:18  <BlueMatt> err, ok
6142017-08-31T19:59:21  <gmaxwell> BlueMatt: please just don't support that. It makes no sense to back and revalidate segwit wallet support in old versions.
6152017-08-31T19:59:43  <gmaxwell> we will not manage to adequately test it and it will sharply constrain our implementation choices.
6162017-08-31T19:59:45  <sipa> any last minute short topic?
6172017-08-31T19:59:46  <BlueMatt> gmaxwell: then we should explicitly break it...but, anyway, lets have this discussion next week
6182017-08-31T19:59:48  <gmaxwell> and lead to weird corner case bugs.
6192017-08-31T20:00:01  <instagibbs> sipa, activate schnorr?
6202017-08-31T20:00:02  <sipa> #endmeeting
6212017-08-31T20:00:02  <lightningbot> Meeting ended Thu Aug 31 20:00:02 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6222017-08-31T20:00:02  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-31-19.05.html
6232017-08-31T20:00:02  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-31-19.05.txt
6242017-08-31T20:00:02  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-31-19.05.log.html
6252017-08-31T20:00:04  <instagibbs> too late, over
6262017-08-31T20:00:05  <jtimon> gmaxwell: besides, is downgrading such an important use case?
6272017-08-31T20:00:12  <BlueMatt> if we dont support downgrading, I very, very strongly support switching to bdb5 for wallet
6282017-08-31T20:00:14  <gmaxwell> instagibbs: schnorr is cancled.
6292017-08-31T20:00:21  <instagibbs> gmaxwell, ah shite.
6302017-08-31T20:00:28  <chainhead> aggregated signatures
6312017-08-31T20:00:38  <gmaxwell> Yea, AggSig.
6322017-08-31T20:00:40  <luke-jr> BlueMatt: what does bdb5 have over 4?
6332017-08-31T20:00:52  <meshcollider> eventually we want to remove bdb entirely right
6342017-08-31T20:00:59  <sipa> nothing we care about, except likely being slightly longer supported in OSes
6352017-08-31T20:01:02  <achow101> luke-jr it's actually in package managers by default
6362017-08-31T20:01:09  <BlueMatt> luke-jr: not having every goddamned distro build with the backward-compat-break option?
6372017-08-31T20:01:09  <esotericnonsense> is there a specific goal in mind with regard to downgrading? a 'support period' as such? it seems to me that defining that would be useful. say, 1 major version back, otherwise all bets are off.
6382017-08-31T20:01:26  <BlueMatt> luke-jr: its purely a make-distros-keep-our-wallets-sane thing
6392017-08-31T20:01:41  <sipa> esotericnonsense: https://bitcoincore.org/en/lifecycle/
6402017-08-31T20:01:54  <luke-jr> sipa: that's never applied to wallets though
6412017-08-31T20:01:56  <sipa> 0.12 is EOL
6422017-08-31T20:02:02  <luke-jr> wallets were supposed to remain compat to 0.3 even :/
6432017-08-31T20:02:31  <sipa> we still stupport wallet files from 0.3.0 (and even lower, i think)
6442017-08-31T20:02:31  <BlueMatt> luke-jr: well the second segwit activated that broke - we can now put transactions in the wallet (today) that have witnesses and those versions will fail to deserialize, I presume
6452017-08-31T20:02:47  <BlueMatt> er, yes, but loading them should still be fine
6462017-08-31T20:02:51  <luke-jr> BlueMatt: sounds like a bug :(
6472017-08-31T20:02:53  <sipa> downgrading that far back is probably broken in multiple other ways too
6482017-08-31T20:03:17  <luke-jr> BlueMatt: why don't we store them stripped?
6492017-08-31T20:03:25  <sipa> luke-jr: iirc, no
6502017-08-31T20:03:42  <luke-jr> sipa: ?
6512017-08-31T20:03:56  <sipa> if i recall correctly, we do not store wallet transactions stripped
6522017-08-31T20:03:58  <luke-jr> "why?" is not a boolean question :p
6532017-08-31T20:04:08  * sipa lunch
6542017-08-31T20:04:24  <esotericnonsense> i would be curious to know how many users actually express a desire to downgrade significantly (i.e. beyond some sort of emergency 'we found out .15.1 is broken, go back to .15' scenario). but I feel that I'm interrupting and so will shuffle off.
6552017-08-31T20:04:39  <jtimon> so our goal is to make 0.15.1 wallets dongradeable to 0.12 ? that's I think too ambitious...
6562017-08-31T20:04:47  <BlueMatt> esotericnonsense: I think its really just an "emergency-need-to-downgrade" support thing
6572017-08-31T20:05:00  <BlueMatt> which, realistically, just means you need to be able to downgrade to the latest stable of the previous version
6582017-08-31T20:05:05  <morcos> we have to stop using confusing technology
6592017-08-31T20:05:11  <morcos> we don't support any downgrading now do we
6602017-08-31T20:05:17  <morcos> we just support not-upgrading
6612017-08-31T20:05:18  <BlueMatt> jtimon: I dont think thats possible, 0.13.1 may be possible, but, indeed, is also ambitious
6622017-08-31T20:05:25  <morcos> or at least we used to
6632017-08-31T20:05:29  <BlueMatt> morcos: i think you can create an old-version wallet
6642017-08-31T20:05:33  <luke-jr> morcos: we've always supported downgrading 0.X wallets back to 0.X
6652017-08-31T20:05:45  <morcos> why are you calling downgrading it
6662017-08-31T20:05:49  <BlueMatt> morcos: we theoretically try to avoid breaking downgrading if you did not explicitly upgrade your wallet
6672017-08-31T20:05:53  <BlueMatt> (with -walletupgrade)
6682017-08-31T20:06:02  *** Roger2x has quit IRC
6692017-08-31T20:06:07  <morcos> if you take 0.10 wallet and run it in 0.14, it doesn't get upgraded automatically does it, its still a 0.10 wallet
6702017-08-31T20:06:14  <luke-jr> morcos: that's the goal, yes
6712017-08-31T20:06:16  <BlueMatt> correct
6722017-08-31T20:06:17  <morcos> so you don't have to downgrade it to use it in 0.10
6732017-08-31T20:06:24  <luke-jr> morcos: apparently we broke that in 0.13.1
6742017-08-31T20:06:24  <morcos> you never upgraded it
6752017-08-31T20:06:26  <BlueMatt> grrr, terminology
6762017-08-31T20:06:28  <morcos> yes i understand
6772017-08-31T20:06:31  <morcos> but stop saying downgrade
6782017-08-31T20:06:39  <BlueMatt> you downgraded your node
6792017-08-31T20:06:54  <morcos> that implies you take a bech32 segwit hd-split schnorr sig aggregation wallet with tons of txs and convert it back to some old format
6802017-08-31T20:06:58  <luke-jr> it sounds like a simple fix would be to just store txs stripped in the wallet
6812017-08-31T20:07:03  <sipa> luke-jr: a reason to not stre wallet txn as stripped: if you rebroadcast an unconfirmed tx, it needs to include the witness
6822017-08-31T20:07:12  <morcos> not that you were using an old format wallet in a new piece of software but not using any of those features
6832017-08-31T20:07:15  <jtimon> BlueMatt: right, to 14.2 sounds reasonable " just means you need to be able to downgrade to the latest stable of the previous version"
6842017-08-31T20:07:20  <luke-jr> sipa: does this break right now, if we received the tx with 0.12?
6852017-08-31T20:07:39  * BlueMatt -> food
6862017-08-31T20:07:45  <GAit> jnewbery: want me to just squash or rebase too?
6872017-08-31T20:07:48  <BlueMatt> to-be-continued next week :)
6882017-08-31T20:07:58  <luke-jr> BlueMatt: kk
6892017-08-31T20:08:17  <luke-jr> I need to get back to something too, so next week sgtm
6902017-08-31T20:09:16  <meshcollider> next week is sf right? will you guys have a meeting summary online or something for those that aren't going
6912017-08-31T20:09:30  <kanzure> i will type things
6922017-08-31T20:09:39  <meshcollider> awesome thanks :)
6932017-08-31T20:12:05  <achow101> What about doing a voice recording?
6942017-08-31T20:12:11  *** chjj has quit IRC
6952017-08-31T20:12:15  <kanzure> nah
6962017-08-31T20:12:44  <kanzure> https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.html
6972017-08-31T20:14:41  <jnewbery> GAit: no need to rebase if there are no merge conflicts
6982017-08-31T20:15:26  <GAit> jnewbery: didn't rebase - however last time while there was no merge conflict the semantic changed and broke the tests :)
6992017-08-31T20:15:37  <GAit> thanks
7002017-08-31T20:17:45  <kanzure> cfields: please clarify if that was a joke or not
7012017-08-31T20:17:53  <cfields> kanzure: heh, yes
7022017-08-31T20:18:10  <kanzure> oh sipa's list?
7032017-08-31T20:18:19  <kanzure> "yes" to an "or" tsk tsk
7042017-08-31T20:19:12  <bitcoin-git> [bitcoin] MeshCollider opened pull request #11208: Fixing offscreen GUI issue (master...201709_offscreen_fix) https://github.com/bitcoin/bitcoin/pull/11208
7052017-08-31T20:20:10  <kanzure> added.
7062017-08-31T20:23:15  *** tuberculo has joined #bitcoin-core-dev
7072017-08-31T20:24:17  *** c40d9b0743a91f40 has joined #bitcoin-core-dev
7082017-08-31T20:30:15  *** klkk has quit IRC
7092017-08-31T20:31:06  *** dermoth_ has joined #bitcoin-core-dev
7102017-08-31T20:31:23  *** dermoth has quit IRC
7112017-08-31T20:31:25  *** dermoth_ is now known as dermoth
7122017-08-31T20:32:44  *** RoyceX has joined #bitcoin-core-dev
7132017-08-31T20:33:45  *** Cheeseo has quit IRC
7142017-08-31T20:36:03  *** tuberculo has quit IRC
7152017-08-31T20:36:34  <gmaxwell> sipa: can you propose a BIP modification to say that anything that accepts p2sh embedded segwit should also accept the non-embedded form  or something
7162017-08-31T20:36:48  <gmaxwell> I can buy your argument that it's reasonable to support both forms.
7172017-08-31T20:36:55  <gmaxwell> But it's weird if if its totally adhoc.
7182017-08-31T20:39:53  <luke-jr> seems a bit late for that
7192017-08-31T20:40:18  <luke-jr> do other wallets support it?
7202017-08-31T20:40:21  *** Chris_Stewart_5 has quit IRC
7212017-08-31T20:40:39  <gmaxwell> ::sigh::
7222017-08-31T20:40:43  <gmaxwell> it's bad if its inconsistent.
7232017-08-31T20:40:56  <gmaxwell> "I converted this address, and it worked, I converted that address and the funds vanished into space"
7242017-08-31T20:41:26  <luke-jr> people shouldn't try to "convert" addresses anyway. :/
7252017-08-31T20:42:56  <gmaxwell> indeed, which is why I think it's bad to add both key types.
7262017-08-31T20:42:58  <kanzure> yep, wallets should only be expected to receive whatever was given
7272017-08-31T20:43:11  <kanzure> (by getnewaddress etc)
7282017-08-31T20:43:16  <gmaxwell> but we do end up with another migration problem with the later switch to bech32, which would be sad.
7292017-08-31T20:54:02  <sipa> luke-jr, gmaxwell: unfortunately, that means we'll be forced to have a separate chain for bech32 addresses
7302017-08-31T20:54:06  <sipa> perhaps that's the best solution
7312017-08-31T20:56:46  <instagibbs> sipa, in the case of migrating again?
7322017-08-31T20:56:49  <luke-jr> probably more future-proof too
7332017-08-31T20:59:08  <gmaxwell> sipa: that is what I expected us to do
7342017-08-31T20:59:43  <gmaxwell> we'll also have this same thing for future sig versions like a v1 with aggsig.
7352017-08-31T21:00:18  <gmaxwell> as an aside the masterkey lines in our dumps should include flags for this stuff
7362017-08-31T21:00:40  <gmaxwell> but I coudl also buy the parallel for v0 and p2sh embedded... it would have some migration advantages.
7372017-08-31T21:01:26  <gmaxwell> (I'm worried that we shouldn't do anything to delay supporting this though.)
7382017-08-31T21:10:33  <morcos> I'm not sure I understand why you have to switch to a new chain.  Why can't you just "upgrade" your old chain to support a new address type.. or is the idea that once you support bech32 you'll no longer support the p2sh version
7392017-08-31T21:10:36  <morcos> or that a new bech32 chain won't i mean
7402017-08-31T21:11:44  <sipa> morcos: if we want to be strict, and only accept payments to bech32 when a bech32 addr was given out, and p2sh/p2wpkh when that was given out, they need to be separate chains, or you need to drop support for one of them entirely
7412017-08-31T21:11:47  <gmaxwell> so if you are adding keys for both types, it means that people can 'convert' your addresses and have it work, which is a funds loss risk when they do it someplace where it doesn't work.
7422017-08-31T21:11:52  <sipa> otherwise you can't know when rescanning which is one
7432017-08-31T21:13:17  <gmaxwell> We could take a position that we'll always do dual p2sh embedded and native (at least for the forseeable future) in parallel... but that will still be a risk for every wallet that isn't us, and for bitcoin core users with explicitly imported keys, when something thinks it can convert.
7442017-08-31T21:13:56  <gmaxwell> and we cannot do dual-addresses for pre-segwit+segwit because of things like uncompressed keys.
7452017-08-31T21:15:54  <gmaxwell> Because as sipa points out p2sh embedding would work for _all_ segwit, we could realistically do dual support there.
7462017-08-31T21:16:23  <morcos> I don't know.  I guess I'm not 100% sold on the philosophy.   It kind of seems to me that if someone does pay you to an address you didn't give them.. You're going to want to find some way to recover those funds no?
7472017-08-31T21:17:10  <morcos> I mean I get why we don't want to encourage a culture of loosey-goosey hide the key in your backyard or however you put it gmaxwell
7482017-08-31T21:17:19  <gmaxwell> morcos: thats kind of the issue... then your keys are embedded in an HSM and it's virtually impossible for you to do that... or to do so you need to do dangerous crap with private keys,
7492017-08-31T21:18:11  <gmaxwell> So basically if this is supported as a reasonable and customary practice, then it creates an effective obligation to do it.
7502017-08-31T21:18:52  <morcos> But to me there is a tenous link btwn the fact that the wallet would be smart enough to accept it and people actually being encouraged to do it
7512017-08-31T21:19:14  <instagibbs> also doesn't this basically require someone to understand bech32, but decide to wrap in p2sh?
7522017-08-31T21:19:26  <morcos> You could even add some sort of flag or warning on txs that were received using unexpected address types
7532017-08-31T21:19:42  <luke-jr> if someone pays to an address I didn't give them, they burned the bitcoins. they didn't pay me.
7542017-08-31T21:19:44  <instagibbs> most cases should be the sender simply not understanding the bech32?
7552017-08-31T21:19:49  <gmaxwell> morcos: things that work are what people do, this is the lesson from history  -- in bitcoin but also in every internet protocol.  If we make it work we need to be ready to support it.
7562017-08-31T21:20:33  <gmaxwell> People deciding what to do don't read specs, they try them out and they do whatever works.
7572017-08-31T21:21:02  <gmaxwell> I think we could reasonably support p2sh-embedded and segwit duality. Sipa points out that it'll work universally.
7582017-08-31T21:21:03  <morcos> well perhaps we could solve the problem i'm more concerned with in a different way by making different paths in the HD wallet
7592017-08-31T21:21:10  <morcos> so the same key never was used for both
7602017-08-31T21:21:15  <morcos> but you don't have to change master keys
7612017-08-31T21:21:24  <gmaxwell> morcos: you do that by using a different path.
7622017-08-31T21:21:31  <morcos> the issue i don't like is invalidating peoples backups
7632017-08-31T21:21:36  <gmaxwell> Which is what other wallets are also doing for segwit suppot, fwiw.
7642017-08-31T21:21:48  <morcos> so when we're talking about switching to a new chain for bech32, we'r ejust talking about a new path?
7652017-08-31T21:22:00  <sipa> morcos: yes
7662017-08-31T21:22:01  <morcos> that seems much more reasonable to me
7672017-08-31T21:22:17  <gmaxwell> I assume but the backup is somewhat invalidated because the backup doesn't have the metadata to tell it what paths are used. This is also true for the hdsplit.
7682017-08-31T21:22:17  <sipa> and perhaps if we plan to do that, we should do the same for p2sh-p2wpkh
7692017-08-31T21:22:51  <morcos> ignore my objections then...   seems like we should do a quick online survey of other wallet providers and assess whether most have expected that p2sh wrapped == bech32, that is if you accept one you accept the other
7702017-08-31T21:22:51  <sipa> there is a distinction in that bech32 or not is probably something we do want to do on a per-key basis
7712017-08-31T21:22:58  <morcos> and unless thats nearly universal, we shouldn't introduce it
7722017-08-31T21:23:00  <luke-jr> gmaxwell: backups can be expected invalidated when -walletupgrade is used
7732017-08-31T21:23:20  <gmaxwell> Esp for BIP173; the transition can't really be done abruptly unless its seriously delayed.
7742017-08-31T21:23:35  <instagibbs> morcos, most are doing bip49 I think, which only is about nested
7752017-08-31T21:23:36  <morcos> luke-jr: why?  shouldn't you just be able to -upgrade your backup
7762017-08-31T21:23:45  <gmaxwell> while if we do dual embedded and native then probably I can use bech32 on day one, e.g. my exchange supports it, so I have it pay me via a 173 address.
7772017-08-31T21:23:46  <instagibbs> not sure what they're expecting to do with bech32
7782017-08-31T21:24:04  <sipa> morcos: that doesn't work for upgrading to hd, to hd split, nor for adding new chains
7792017-08-31T21:24:13  <gmaxwell> morcos: just the backup doesn't know where and when the pathing change happened.
7802017-08-31T21:24:23  <luke-jr> morcos: hmm, it might work in this case, but IMO we shouldn't *expect* it to
7812017-08-31T21:24:32  <gmaxwell> i suppose you could replay the same actions and have it work, but it's tricky and easy to screw up.
7822017-08-31T21:25:20  <gmaxwell> e.g. backup your wallet on day 0 with no segwith, use 100,000 keys... upgrade it later... use another 10000 keys... erase wallet... now how do you reproduce this...
7832017-08-31T21:25:41  <gmaxwell> you need to know to expand the keypool 100,000 keys, then switch...
7842017-08-31T21:25:42  <luke-jr> gmaxwell: if segwit uses a new path/chain, this would just work I guess
7852017-08-31T21:26:14  <morcos> well, i was assuming the path branch happened at the beginning, but maybe that was a bad assumption
7862017-08-31T21:26:18  <morcos> in which case you'd just look ahead whatever the number of keys is on all paths
7872017-08-31T21:26:31  <gmaxwell> yes, it should happen at the beggin... how do we know to go to 100,000...
7882017-08-31T21:26:33  <gmaxwell> okay, thats a more keypools solution.
7892017-08-31T21:26:48  <luke-jr> gmaxwell: start monitoring both chains at their beginning, and extend each as needed
7902017-08-31T21:26:51  <morcos> the same way we know to go to 100k if we never did anything and you backedup your wallet with nothing in it
7912017-08-31T21:26:55  <gmaxwell> perhaps... this has some other tradeoffs.
7922017-08-31T21:27:34  <morcos> i don't understand how you don't have to do that anyway
7932017-08-31T21:27:34  <gmaxwell> e.g. say we have 4 segwit versions, and so now we have 10 keypools.
7942017-08-31T21:27:34  <gmaxwell> but only one of them has ever been used.
7952017-08-31T21:28:10  <morcos> so what happens when you upgrade your wallet?  don't you have to still keep keypools for your old chains anyway?
7962017-08-31T21:28:40  <morcos> or are you suggesting the upgrade is the user saying, i have no pending payments forever in the future for any address i've ever given out
7972017-08-31T21:29:13  *** Cheeseo has joined #bitcoin-core-dev
7982017-08-31T21:29:17  <gmaxwell> yep. that was my thinking.. just import all the keys that are already used.
7992017-08-31T21:29:24  <luke-jr> gmaxwell: if we're worried about it, we should just stop using keypools?
8002017-08-31T21:29:28  <adiabat> not to complicate things further, but my wallet software supports bech32 / p2wpkh but ignores nested completely
8012017-08-31T21:29:30  <gmaxwell> it's not even clear to me that we should support upgrading.
8022017-08-31T21:30:14  <gmaxwell> for something that changes your key paths perhaps we should only support that for new wallets.   If you want old keys in it, you can import.
8032017-08-31T21:30:17  <sipa> gmaxwell: there is no 'import'
8042017-08-31T21:30:24  <gmaxwell> importmulti
8052017-08-31T21:30:33  <sipa> gmaxwell: the effect of an import is exactly the same as just adding a key
8062017-08-31T21:30:43  <sipa> gmaxwell: i mean that every key we generate is implicitly 'imported'
8072017-08-31T21:30:54  <gmaxwell> import doesn't have anything to do with maintaining a keypool.
8082017-08-31T21:30:55  <gmaxwell> yes, it's that PLUS keypool management.
8092017-08-31T21:31:01  <luke-jr> time to reboot, bbl
8102017-08-31T21:31:05  *** luke-jr has quit IRC
8112017-08-31T21:31:13  <sipa> gmaxwell: i just mean that is what we already doing
8122017-08-31T21:31:39  <sipa> gmaxwell: saying "switching to a new keypool and treating all the existing keys as imported" is exactly the same as "switching to a new keypool"
8132017-08-31T21:32:15  <gmaxwell> yes, but it's distinct from following all keypools which is what I was discussing with morcos.
8142017-08-31T21:32:46  <morcos> gmaxwell: yeah i think if i understand what sipa is saying, once you've made the decision to start giving out addresses on a new chain, you no longer need to maintain a keypool for your old chain
8152017-08-31T21:32:48  <sipa> ok, s/switching to/adding/g in my above statement
8162017-08-31T21:33:03  <sipa> still same thing - the 'importing' thing is besides the point
8172017-08-31T21:33:03  <morcos> youv've already got the current keypool as keys in your wallet, and its exactly as if you imported
8182017-08-31T21:33:09  <gmaxwell> morcos: right thats an option, but it's not 'backup durable'
8192017-08-31T21:33:18  <morcos> why not?
8202017-08-31T21:33:37  <gmaxwell> because you restore a backup then don't do the upgrade or do instantly before scanning all the keys
8212017-08-31T21:33:50  *** illpadrino has quit IRC
8222017-08-31T21:34:00  <morcos> hmm.. i see, its just more complicated to get it right i suppose
8232017-08-31T21:34:07  <gmaxwell> and when we do the upgrade to we trigger a full (pruning incompatible multihour long) rescan
8242017-08-31T21:34:16  <morcos> but the advantage of supporting 2 keypools is we can start issuing bech32 earlier
8252017-08-31T21:34:21  <morcos> which seems a big gain
8262017-08-31T21:34:48  <gmaxwell> Or we could just do dual-embedded and bech32.
8272017-08-31T21:35:03  <morcos> hmm
8282017-08-31T21:35:05  <gmaxwell> in which case it's just one keypool and we could use bech32 all the time, but there is a risk of people converting.
8292017-08-31T21:35:16  <gmaxwell> For rapid bech32 deployment that is best by far.
8302017-08-31T21:35:31  <morcos> but also means we can't ever easily stop supporting the old style
8312017-08-31T21:35:36  <gmaxwell> because it lets you immediately use bech32 when you have a counterparty that supports it.
8322017-08-31T21:35:59  <gmaxwell> morcos: right, we could for newer wallet 3 years from now, except for the risk of 'conversion'
8332017-08-31T21:36:33  <sipa> just in case that isn't clear: if you currently use addwitnessaddress, you'll accept both p2sh and native-witness outputs to that address
8342017-08-31T21:37:06  *** RubenSomsen has quit IRC
8352017-08-31T21:37:07  <morcos> and if you don't you'll accept neither?
8362017-08-31T21:37:22  <sipa> yes
8372017-08-31T21:38:27  <morcos> well i do think it makes sense to think about this comprehensively in the context of legacy -> hd -> hd-split -> p2shsegwit -> bech32 -> future witness versions
8382017-08-31T21:38:38  <morcos> there are different issues for each of those
8392017-08-31T21:39:12  <morcos> but i think we want the design to be something where people don't get confused understanding how it works
8402017-08-31T21:41:29  <gmaxwell> we really cannot do legacy and segwit doppleganging due to the uncompressed key issue.
8412017-08-31T21:41:35  <morcos> Imagine that each of those is considered a different path or whatever, and we introduced some concept of whether a path is active or not (meaning we are still potentially giving out addresses on it)  and once it's not active we don't need to maintain keypools anymore, we just have the historical keys
8422017-08-31T21:41:44  <sipa> gmaxwell: easy enough with a bit in the metadata
8432017-08-31T21:41:50  <gmaxwell> I think we can realistically do native + embedded doppleganging and support it forever.
8442017-08-31T21:41:53  <sipa> or just the addwitness approach
8452017-08-31T21:42:04  <gmaxwell> bit in the metadata is a backup disaster.
8462017-08-31T21:42:05  <morcos> When you upgrade you need to specify which ones you are still active on..  And there is a way to deactivate old types
8472017-08-31T21:42:18  <sipa> gmaxwell: it would also be added during hd topup
8482017-08-31T21:42:30  <gmaxwell> sipa: I don't understand how that works.
8492017-08-31T21:42:37  <gmaxwell> I mean where do the bits come from
8502017-08-31T21:43:01  <sipa> gmaxwell: once your wallet is segwit-enabled, you add it for every newly generated key (including auto topup)
8512017-08-31T21:43:15  <sipa> it means you can't recover with an old version anymore, but that's inevitable
8522017-08-31T21:44:25  <gmaxwell> but then you recover an old backup with a new wallet... will it then set the bit for everything
8532017-08-31T21:44:31  *** Dyaheon has quit IRC
8542017-08-31T21:44:39  <sipa> ah, i see
8552017-08-31T21:44:54  <gmaxwell> I'm sorry, I think this is all confused; or I am all confused.  Esp since we don't even really know if we are recovering or not at any point in time.
8562017-08-31T21:47:31  *** Dyaheon has joined #bitcoin-core-dev
8572017-08-31T21:48:39  <morcos> gmaxwell: I think when you said "that's a more keypools solution", I took that as a negative, but i'm not sure why it has to be a negative.   Have a keypool for every path / type of address.  Who cares?
8582017-08-31T21:50:43  <morcos> I don't think it causes any wallet bloat if you're comparing it to importing your keys to a new wallet as you upgrade.  It it causes in-memory bloat, that seems easy enough to optimize away, by leaving most of unlikely to be used keypools on disk.
8592017-08-31T21:51:38  <gmaxwell> two keypools, technically.  ends up being a megabyte of keypool for each or whatever with our current inefficient storage...
8602017-08-31T21:53:17  <gmaxwell> (change and not change, is the two pools)
8612017-08-31T21:53:36  *** Giszmo has quit IRC
8622017-08-31T21:54:14  *** btcdrak has quit IRC
8632017-08-31T21:54:15  <morcos> Yes, but don't you get that anyway, if you import to each version in turn as you're importing all the prior keypool keys
8642017-08-31T21:54:44  <gmaxwell> We could do that.  Also slower accepting blocks, because you now have a lot more keys to scan... but thats something that generally may need to be optimized.
8652017-08-31T21:55:05  <gmaxwell> morcos: if you do that, but most users eventually will have just started eventually with vXX and won't have any old ones
8662017-08-31T21:55:32  <morcos> yes, and so then you don't create the old ones
8672017-08-31T21:55:57  <gmaxwell> so then there is key metadata which says the oldest kind to build, and we build all later ones.
8682017-08-31T22:00:01  *** c40d9b0743a91f40 has quit IRC
8692017-08-31T22:17:31  *** meshcollider has quit IRC
8702017-08-31T22:20:23  *** c40d9b0743a91f40 has joined #bitcoin-core-dev
8712017-08-31T22:23:17  *** tloriato has joined #bitcoin-core-dev
8722017-08-31T22:23:17  *** Giszmo has joined #bitcoin-core-dev
8732017-08-31T22:26:54  <tloriato> Hello. I was testing the development of some ideas using the BitcoinCore wallet and the CLI's commands, and I came across the move command. Unfortunately the Docs states that "move will be removed in a later version of Bitcoin Core. " Does another command fulfils its duty? I've read the documentation on the official webpage and came out with empty hands. I don't want to develop an architecture around a command that will be e
8742017-08-31T22:28:05  <sipa> tloriato: the whole accounts subsystem is deprecated
8752017-08-31T22:28:19  <sipa> there won't be a replacement for move, as there would be nothing to observe its effect
8762017-08-31T22:29:18  <sipa> addresses will be able to have labels, and you'll be able to query for payments to specific labels, but labels don't have their own balance
8772017-08-31T22:30:31  <tloriato> i see it
8782017-08-31T22:30:46  <tloriato> well, thanks for the answer and clarification
8792017-08-31T22:31:30  <tloriato> i'd assume that the parameter to GetNewAddress would be the label instead of account when that happens?
8802017-08-31T22:31:40  <sipa> indeed
8812017-08-31T22:32:22  <tloriato> that's alright then! thank you
8822017-08-31T22:32:28  *** tloriato has quit IRC
8832017-08-31T22:38:01  *** Giszmo has quit IRC
8842017-08-31T22:55:56  *** luke-jr has joined #bitcoin-core-dev
8852017-08-31T23:05:24  *** Giszmo has joined #bitcoin-core-dev
8862017-08-31T23:07:51  *** JackH has quit IRC
8872017-08-31T23:15:21  *** JackH has joined #bitcoin-core-dev
8882017-08-31T23:16:08  *** JackH has quit IRC
8892017-08-31T23:16:11  *** vicenteH has quit IRC
8902017-08-31T23:17:09  *** jannes has quit IRC
8912017-08-31T23:17:14  *** JackH has joined #bitcoin-core-dev
8922017-08-31T23:25:06  *** Deadhand has quit IRC
8932017-08-31T23:26:34  *** Cheeseo has quit IRC
8942017-08-31T23:30:48  *** Deadhand has joined #bitcoin-core-dev
8952017-08-31T23:45:05  *** Giszmo has quit IRC
8962017-08-31T23:51:01  *** Dyaheon has quit IRC
8972017-08-31T23:52:40  *** Dyaheon has joined #bitcoin-core-dev
8982017-08-31T23:57:30  *** Chris_Stewart_5 has joined #bitcoin-core-dev
8992017-08-31T23:59:46  *** abpa has quit IRC