12018-01-11T00:00:21 *** esotericnonsense has joined #bitcoin-core-dev
22018-01-11T00:02:01 *** JayBerg has joined #bitcoin-core-dev
32018-01-11T00:03:33 *** logicue has joined #bitcoin-core-dev
42018-01-11T00:05:02 *** promag has joined #bitcoin-core-dev
52018-01-11T00:05:04 *** CubicEar_ has quit IRC
62018-01-11T00:05:40 *** CubicEarths has joined #bitcoin-core-dev
72018-01-11T00:10:06 *** Chenpan has quit IRC
82018-01-11T00:12:52 *** logicue has quit IRC
92018-01-11T00:13:17 *** PaulCapestany has quit IRC
102018-01-11T00:14:31 <cols> hi
112018-01-11T00:15:17 *** PaulCapestany has joined #bitcoin-core-dev
122018-01-11T00:15:48 *** cols has quit IRC
132018-01-11T00:16:56 *** tectonic has quit IRC
142018-01-11T00:17:01 *** JayBerg has quit IRC
152018-01-11T00:20:36 *** Randolf has quit IRC
162018-01-11T00:23:33 *** Squidicuz has joined #bitcoin-core-dev
172018-01-11T00:24:14 *** esotericnonsense has quit IRC
182018-01-11T00:30:28 *** Squidicc has joined #bitcoin-core-dev
192018-01-11T00:34:43 *** JayBerg has joined #bitcoin-core-dev
202018-01-11T00:36:20 *** nullptr| has quit IRC
212018-01-11T00:42:29 *** nullptr| has joined #bitcoin-core-dev
222018-01-11T00:43:24 *** Murch has quit IRC
232018-01-11T00:50:19 *** AaronvanW has quit IRC
242018-01-11T00:50:55 *** AaronvanW has joined #bitcoin-core-dev
252018-01-11T00:53:03 *** larafale has quit IRC
262018-01-11T00:55:05 *** AaronvanW has quit IRC
272018-01-11T00:56:12 *** Randolf has joined #bitcoin-core-dev
282018-01-11T00:58:19 *** dgenr8 has joined #bitcoin-core-dev
292018-01-11T00:58:36 *** dabura667 has joined #bitcoin-core-dev
302018-01-11T00:58:37 *** esotericnonsense has joined #bitcoin-core-dev
312018-01-11T00:58:37 *** promag has quit IRC
322018-01-11T01:03:58 *** hirish is now known as hirishaway
332018-01-11T01:05:30 *** ossifrage has quit IRC
342018-01-11T01:05:54 *** ossifrage has joined #bitcoin-core-dev
352018-01-11T01:05:57 *** jb55 has quit IRC
362018-01-11T01:11:14 *** Krellan has quit IRC
372018-01-11T01:15:16 *** Emcy has joined #bitcoin-core-dev
382018-01-11T01:16:49 *** Emcy_ has quit IRC
392018-01-11T01:17:40 *** Krellan has joined #bitcoin-core-dev
402018-01-11T01:25:16 *** CubicEar_ has joined #bitcoin-core-dev
412018-01-11T01:25:24 *** bule has joined #bitcoin-core-dev
422018-01-11T01:27:32 *** bule2 has quit IRC
432018-01-11T01:29:00 *** Randolf has quit IRC
442018-01-11T01:29:19 *** CubicEarths has quit IRC
452018-01-11T01:37:51 *** CubicEar_ has quit IRC
462018-01-11T01:38:04 *** Tennis has quit IRC
472018-01-11T01:38:33 *** CubicEarths has joined #bitcoin-core-dev
482018-01-11T01:45:29 *** AaronvanW has joined #bitcoin-core-dev
492018-01-11T01:50:01 *** AaronvanW has quit IRC
502018-01-11T01:59:13 *** promag has joined #bitcoin-core-dev
512018-01-11T01:59:26 *** CubicEar_ has joined #bitcoin-core-dev
522018-01-11T02:01:11 *** Randolf has joined #bitcoin-core-dev
532018-01-11T02:02:35 *** CubicEarths has quit IRC
542018-01-11T02:07:11 *** promag has quit IRC
552018-01-11T02:07:29 *** bule2 has joined #bitcoin-core-dev
562018-01-11T02:11:52 *** bule has quit IRC
572018-01-11T02:19:40 *** logicue has joined #bitcoin-core-dev
582018-01-11T02:24:33 *** logicue has quit IRC
592018-01-11T02:24:34 *** jb55 has joined #bitcoin-core-dev
602018-01-11T02:24:44 *** jb55 has quit IRC
612018-01-11T02:25:04 *** jb55 has joined #bitcoin-core-dev
622018-01-11T02:39:22 *** CubicEar_ has quit IRC
632018-01-11T02:39:32 *** AaronvanW has joined #bitcoin-core-dev
642018-01-11T02:40:00 *** CubicEarths has joined #bitcoin-core-dev
652018-01-11T02:41:41 *** flokie has joined #bitcoin-core-dev
662018-01-11T02:42:33 *** PaulCapestany has quit IRC
672018-01-11T02:43:50 *** NicolasDorier has joined #bitcoin-core-dev
682018-01-11T02:44:20 *** PaulCapestany has joined #bitcoin-core-dev
692018-01-11T02:44:24 *** AaronvanW has quit IRC
702018-01-11T02:44:30 <bitcoin-git> [bitcoin] azuchi opened pull request #12143: [Doc] Fix link for BIP-159 pull request (master...fix-bip159-link) https://github.com/bitcoin/bitcoin/pull/12143
712018-01-11T02:54:56 *** JackH_ has joined #bitcoin-core-dev
722018-01-11T02:58:33 *** JackH has quit IRC
732018-01-11T03:02:32 *** bule2 has quit IRC
742018-01-11T03:05:15 *** steadguy has quit IRC
752018-01-11T03:06:06 *** steadguy has joined #bitcoin-core-dev
762018-01-11T03:08:38 *** Giszmo has joined #bitcoin-core-dev
772018-01-11T03:12:48 *** Victorsueca has quit IRC
782018-01-11T03:14:00 *** Victorsueca has joined #bitcoin-core-dev
792018-01-11T03:19:12 *** flokie has quit IRC
802018-01-11T03:25:51 *** esotericnonsense has quit IRC
812018-01-11T03:33:48 *** Krellan has quit IRC
822018-01-11T03:34:19 *** Krellan has joined #bitcoin-core-dev
832018-01-11T03:36:42 *** Emcy_ has joined #bitcoin-core-dev
842018-01-11T03:37:45 *** tknp has quit IRC
852018-01-11T03:38:32 *** belcher has quit IRC
862018-01-11T03:39:21 *** Emcy has quit IRC
872018-01-11T03:47:41 *** flokie has joined #bitcoin-core-dev
882018-01-11T03:51:44 *** contrapumpkin has joined #bitcoin-core-dev
892018-01-11T03:53:45 *** jb55 has quit IRC
902018-01-11T03:56:43 *** sanada has joined #bitcoin-core-dev
912018-01-11T04:08:34 *** arubi has quit IRC
922018-01-11T04:08:53 *** jb55 has joined #bitcoin-core-dev
932018-01-11T04:11:37 *** arubi has joined #bitcoin-core-dev
942018-01-11T04:16:38 *** JayBerg has quit IRC
952018-01-11T04:21:45 *** Giszmo has quit IRC
962018-01-11T04:21:54 *** contrapumpkin has quit IRC
972018-01-11T04:27:47 *** AaronvanW has joined #bitcoin-core-dev
982018-01-11T04:31:57 *** AaronvanW has quit IRC
992018-01-11T04:51:33 *** Jbstone has joined #bitcoin-core-dev
1002018-01-11T04:52:36 *** Jbstone has quit IRC
1012018-01-11T04:54:12 *** tknp has joined #bitcoin-core-dev
1022018-01-11T05:08:59 *** bule2 has joined #bitcoin-core-dev
1032018-01-11T05:15:04 *** a5m0_ has quit IRC
1042018-01-11T05:20:25 *** lnostdal has quit IRC
1052018-01-11T05:20:38 *** lnostdal has joined #bitcoin-core-dev
1062018-01-11T05:22:01 *** bule2 has quit IRC
1072018-01-11T05:23:02 *** promag has joined #bitcoin-core-dev
1082018-01-11T05:26:14 *** a5m0 has joined #bitcoin-core-dev
1092018-01-11T05:27:27 *** promag has quit IRC
1102018-01-11T05:31:19 *** CubicEar_ has joined #bitcoin-core-dev
1112018-01-11T05:34:41 *** CubicEarths has quit IRC
1122018-01-11T05:45:02 *** Krellan has quit IRC
1132018-01-11T05:45:41 *** Krellan has joined #bitcoin-core-dev
1142018-01-11T05:57:39 *** Victorsueca has quit IRC
1152018-01-11T05:58:15 *** CubicEar_ has quit IRC
1162018-01-11T05:58:47 *** Victorsueca has joined #bitcoin-core-dev
1172018-01-11T05:58:54 *** CubicEarths has joined #bitcoin-core-dev
1182018-01-11T06:06:55 *** CubicEar_ has joined #bitcoin-core-dev
1192018-01-11T06:10:52 *** CubicEarths has quit IRC
1202018-01-11T06:16:02 *** AaronvanW has joined #bitcoin-core-dev
1212018-01-11T06:16:25 *** flokie has quit IRC
1222018-01-11T06:20:30 *** AaronvanW has quit IRC
1232018-01-11T06:24:19 *** Krellan has quit IRC
1242018-01-11T06:27:26 *** Krellan has joined #bitcoin-core-dev
1252018-01-11T06:31:37 <bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/45173fa6fca9...b0d626d10f78
1262018-01-11T06:31:37 <bitcoin-git> bitcoin/master 91769d6 azuchi: [Doc] Fix link for bip 159 pull request
1272018-01-11T06:31:38 <bitcoin-git> bitcoin/master b0d626d Jonas Schnelli: Merge #12143: [Doc] Fix link for BIP-159 pull request...
1282018-01-11T06:32:08 *** Krellan has quit IRC
1292018-01-11T06:32:43 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #12143: [Doc] Fix link for BIP-159 pull request (master...fix-bip159-link) https://github.com/bitcoin/bitcoin/pull/12143
1302018-01-11T06:37:40 *** mrannanay has joined #bitcoin-core-dev
1312018-01-11T06:43:42 *** maaku has quit IRC
1322018-01-11T06:46:17 *** maaku has joined #bitcoin-core-dev
1332018-01-11T06:56:07 <bitcoin-git> [bitcoin] jonasschnelli pushed 13 new commits to master: https://github.com/bitcoin/bitcoin/compare/b0d626d10f78...d889c036cd6f
1342018-01-11T06:56:08 <bitcoin-git> bitcoin/master 0c8ea63 Pieter Wuille: Abstract out IsSolvable from Witnessifier
1352018-01-11T06:56:08 <bitcoin-git> bitcoin/master cbe1974 Pieter Wuille: [refactor] GetAccount{PubKey,Address} -> GetAccountDestination
1362018-01-11T06:56:09 <bitcoin-git> bitcoin/master 985c795 Pieter Wuille: Improve witness destination types and use them more
1372018-01-11T06:56:30 <bitcoin-git> [bitcoin] jonasschnelli closed pull request #11403: SegWit wallet support (master...201709_segwitwallet2) https://github.com/bitcoin/bitcoin/pull/11403
1382018-01-11T06:57:22 <meshcollider> \o/ awesome
1392018-01-11T06:57:27 *** Chenpan has joined #bitcoin-core-dev
1402018-01-11T07:00:58 <achow101> \O/
1412018-01-11T07:01:14 <sturles> git pull
1422018-01-11T07:01:31 <achow101> well time to rebase everything
1432018-01-11T07:04:44 *** mgeuirx has joined #bitcoin-core-dev
1442018-01-11T07:07:05 *** tknp has quit IRC
1452018-01-11T07:09:13 <jonasschnelli> Yes. Restart your rebase engines please. :)
1462018-01-11T07:09:54 <jouke> \o/
1472018-01-11T07:09:54 *** mgeuirx has quit IRC
1482018-01-11T07:10:02 *** AaronvanW has joined #bitcoin-core-dev
1492018-01-11T07:11:32 <rabidus> :)
1502018-01-11T07:14:43 *** AaronvanW has quit IRC
1512018-01-11T07:15:22 *** jouke has quit IRC
1522018-01-11T07:15:22 *** jouke has joined #bitcoin-core-dev
1532018-01-11T07:15:44 *** tectonic has joined #bitcoin-core-dev
1542018-01-11T07:17:29 *** Amuza has joined #bitcoin-core-dev
1552018-01-11T07:23:39 <meshcollider> When does wumpus get back again?
1562018-01-11T07:49:45 *** steadguy has quit IRC
1572018-01-11T07:55:37 <jonasschnelli> meshcollider: I though this week. But maybe its next.
1582018-01-11T07:55:44 <jonasschnelli> thought
1592018-01-11T07:57:30 *** zautomata has joined #bitcoin-core-dev
1602018-01-11T08:01:33 <provoostenator> Rebase party time! Congrats sipa on that merge.
1612018-01-11T08:04:09 *** AaronvanW has joined #bitcoin-core-dev
1622018-01-11T08:05:29 *** midnightmagic has quit IRC
1632018-01-11T08:08:27 *** AaronvanW has quit IRC
1642018-01-11T08:13:30 <jb55> will said party be... interactive?
1652018-01-11T08:15:47 * jb55 walks away slowly
1662018-01-11T08:18:56 *** CubicEar_ has quit IRC
1672018-01-11T08:19:25 <luke-jr> uh, not seeing the logic for wallet versioning there.. How do I configure my wallet to NOT upgrade?
1682018-01-11T08:19:35 *** CubicEarths has joined #bitcoin-core-dev
1692018-01-11T08:20:33 * provoostenator wonders if there is such a thing as VM rage after umpteen useless Windows 10 notifications
1702018-01-11T08:20:52 <sipa> luke-jr: you mean due to bech32 addresses in your label map?
1712018-01-11T08:23:06 <luke-jr> well, I would have expected ImplicitlyLearnRelatedKeyScripts to be conditional on the wallet being an upgraded version
1722018-01-11T08:23:14 <luke-jr> I don't even see a flag for the wallet version bump
1732018-01-11T08:23:37 <sipa> luke-jr: that doesn't affect the wallet file
1742018-01-11T08:24:19 <sipa> you can downgrade down to any segwit capable version
1752018-01-11T08:24:50 <luke-jr> But how do I upgrade without accepting Segwit payments?
1762018-01-11T08:25:36 <sipa> ah, you can't
1772018-01-11T08:26:10 <jonasschnelli> luke-jr: why would you want that? Can you elaborate the use case?
1782018-01-11T08:26:13 <luke-jr> when and why was that changed?
1792018-01-11T08:26:17 <luke-jr> jonasschnelli: to prevent block size increases
1802018-01-11T08:26:24 <sipa> sigh
1812018-01-11T08:27:07 <jonasschnelli> luke-jr: why would "not accepting" sw payment change that?
1822018-01-11T08:27:16 <jonasschnelli> (not talking about "not handing our SW addresses")
1832018-01-11T08:27:25 <jonasschnelli> *out
1842018-01-11T08:28:03 <luke-jr> jonasschnelli: someone can take a normal address from this, and modify it to a Segwit one, and the user won't even know it?
1852018-01-11T08:28:35 <sipa> luke-jr: that's a problem, but it's inherent to the wallet design
1862018-01-11T08:28:47 *** CubicEarths has quit IRC
1872018-01-11T08:28:54 <jonasschnelli> I see
1882018-01-11T08:28:59 <sipa> they can also convert p2pkh into p2pk etc
1892018-01-11T08:29:05 *** kabaum has joined #bitcoin-core-dev
1902018-01-11T08:29:46 <luke-jr> sipa: not without this change
1912018-01-11T08:29:53 <sipa> ?
1922018-01-11T08:30:06 <sipa> we have always accepted payments to p2pk
1932018-01-11T08:30:08 <luke-jr> without this change, it isn't possible to trick the user into accepting a segwit output
1942018-01-11T08:30:13 *** zautomata has quit IRC
1952018-01-11T08:30:53 *** Amuza has quit IRC
1962018-01-11T08:30:59 <sipa> yes, i don't see why that is any more of a problem than accepting p2pk instead of p2pkh (which grows the utxo set morez for example)
1972018-01-11T08:31:02 *** CubicEarths has joined #bitcoin-core-dev
1982018-01-11T08:31:15 <luke-jr> sipa: only segwit outputs enable block size increases
1992018-01-11T08:31:32 *** zautomata has joined #bitcoin-core-dev
2002018-01-11T08:31:43 <sipa> i think utxo growth is a far worse problem
2012018-01-11T08:31:44 <luke-jr> also, without a wallet version bump, old wallets won't receive properly for segwit addresses generated by newer software, I think?
2022018-01-11T08:31:45 <jonasschnelli> luke-jr: if you think this is an important feature (I don't), you may want to write a PR?
2032018-01-11T08:31:53 <sipa> luke-jr: they will
2042018-01-11T08:31:58 *** CubicEarths has quit IRC
2052018-01-11T08:32:03 <sipa> (down to 0.13.1)
2062018-01-11T08:32:20 <luke-jr> jonasschnelli: okay, although this was what I expected already from the discussions months ago planning it
2072018-01-11T08:32:33 *** CubicEarths has joined #bitcoin-core-dev
2082018-01-11T08:32:49 <luke-jr> sipa: I thought the wallet didn't get the data added permanently?
2092018-01-11T08:32:53 <sipa> it does
2102018-01-11T08:33:00 <sipa> read the PR description
2112018-01-11T08:33:06 <luke-jr> did that change at some point?
2122018-01-11T08:33:26 <sipa> yes, and there is even a design doc to explain it
2132018-01-11T08:33:49 <jonasschnelli> luke-jr: you didn't mentioned that point in 11403
2142018-01-11T08:34:07 <meshcollider> this one I think sipa is referring to https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2
2152018-01-11T08:35:39 *** kabaum_ has joined #bitcoin-core-dev
2162018-01-11T08:37:15 *** steadguy has joined #bitcoin-core-dev
2172018-01-11T08:37:42 *** Amuza has joined #bitcoin-core-dev
2182018-01-11T08:39:33 *** kabaum_ has left #bitcoin-core-dev
2192018-01-11T08:39:50 *** kabaum has quit IRC
2202018-01-11T08:40:17 *** kabaum has joined #bitcoin-core-dev
2212018-01-11T08:41:27 *** steadguy has quit IRC
2222018-01-11T08:42:24 *** tectonic has quit IRC
2232018-01-11T08:43:26 *** Amuza has quit IRC
2242018-01-11T08:44:48 <luke-jr> wouldn't the implicit in-memory redeemscript adding for old keys be sufficient if only applied to the keypool/new keys?
2252018-01-11T08:46:49 <sipa> read the design doc, it goes through all the scenarios it is intended to work in, and how they necessitate the implemented behaviour
2262018-01-11T08:46:52 *** CubicEar_ has joined #bitcoin-core-dev
2272018-01-11T08:47:52 *** zautomata1 has joined #bitcoin-core-dev
2282018-01-11T08:48:35 *** anome has joined #bitcoin-core-dev
2292018-01-11T08:49:32 *** CubicEarths has quit IRC
2302018-01-11T08:49:32 *** zautomata has quit IRC
2312018-01-11T08:50:35 *** Krellan has joined #bitcoin-core-dev
2322018-01-11T08:51:56 <luke-jr> sipa: I read it, but it's not clear to me why 1a requires it effect ALL keys, rather than just keypool (ie, unused at the time of the backup) and future
2332018-01-11T08:52:25 <luke-jr> labelled keys already have a non-segwit address assigned, and should never be seen in segwit form
2342018-01-11T08:53:37 <sipa> you can't know that you aren't using a restored backup which had a lost future in which the same key was used in a different address type
2352018-01-11T08:55:39 <luke-jr> hm, so 1) user backs up, 2) user makes a new address, 3) user restores backup, 4) user upgrades, 5) user makes a new segwit address overlapping the one in 2, 6) user downgrades, 7) user restores backup again
2362018-01-11T08:55:40 <luke-jr> ?
2372018-01-11T08:56:13 <sipa> the only way we can actually remove the ability to accept payment to a different address type than the one we know about is afaik by having separate keychains for each address type
2382018-01-11T08:56:51 <sipa> luke-jr: i don't think 6 and 7 are needed in that scenario
2392018-01-11T08:57:15 <sipa> and swap the segwit and legacy
2402018-01-11T08:57:17 <meshcollider> sipa: they are needed because the first address was legacy and the second was segwit i believe
2412018-01-11T08:57:18 <meshcollider> yeah
2422018-01-11T08:58:15 *** AaronvanW has joined #bitcoin-core-dev
2432018-01-11T08:58:26 <luke-jr> sipa: I don't understand.. step 2 can't make a segwit address since it's pre-upgrade
2442018-01-11T08:58:56 <sipa> someone first creates a backup, then creates a segwit address, then restores the backup, creates a legacy address with the same key, restarts
2452018-01-11T08:58:57 *** zautomata1 has quit IRC
2462018-01-11T08:59:00 *** Victorsueca has quit IRC
2472018-01-11T08:59:02 <sipa> no old versions involved even
2482018-01-11T08:59:34 <luke-jr> upon restoring the backup, that key would be in the keypool, so it would get the implied script
2492018-01-11T08:59:36 <sipa> the result is a file with no explicit segwit script, and a label for a legacy address for a certain key
2502018-01-11T09:00:09 <luke-jr> oh, add a restart and the implicit script disappears!
2512018-01-11T09:00:15 <meshcollider> yeah the legacy address has to be created on the old version so it doesnt hit the implicit addition of segwit scripts
2522018-01-11T09:00:18 *** Victorsueca has joined #bitcoin-core-dev
2532018-01-11T09:00:21 <meshcollider> oh
2542018-01-11T09:00:27 <sipa> no it doesn't
2552018-01-11T09:00:41 <meshcollider> yeah I got it now, right
2562018-01-11T09:00:53 <luke-jr> I thought I got it until "no it doesn't" :x
2572018-01-11T09:01:12 <luke-jr> unless that was a reply to meshcollider
2582018-01-11T09:01:16 <sipa> the "no it doesn't" is a response to meshcollider saying it needs an old version
2592018-01-11T09:01:19 <meshcollider> yeah that was a reply to me
2602018-01-11T09:01:21 <luke-jr> ah ok
2612018-01-11T09:01:38 *** jb55 has quit IRC
2622018-01-11T09:02:01 <sipa> i'm not sure this scenario is actually covered in thendocument though
2632018-01-11T09:02:38 <meshcollider> sipa: it is, just not so explicitly written out
2642018-01-11T09:02:57 *** AaronvanW has quit IRC
2652018-01-11T09:03:07 <sipa> may be worth spelling kt out
2662018-01-11T09:03:10 <sipa> *it
2672018-01-11T09:03:11 <meshcollider> it just stops at restoring the backup, it doesn't mention creating a new legacy address and restarting
2682018-01-11T09:03:13 <meshcollider> yeah
2692018-01-11T09:05:17 *** anome has quit IRC
2702018-01-11T09:07:57 *** CubicEar_ has quit IRC
2712018-01-11T09:08:12 <provoostenator> The step 1-7 scenario luke-jr describes above is somethign I'd like to try on top of #12134
2722018-01-11T09:08:14 <gribble> https://github.com/bitcoin/bitcoin/issues/12134 | [WIP] Build previous releases and run functional tests by Sjors · Pull Request #12134 · bitcoin/bitcoin · GitHub
2732018-01-11T09:11:30 <meshcollider> provoostenator: I've only looked briefly at that but won't adding cross version testing to travis be too slow
2742018-01-11T09:12:07 *** CubicEarths has joined #bitcoin-core-dev
2752018-01-11T09:12:22 <provoostenator> meshcollider: the releases are cached, so it's a one-off 30 minute thing (and only for one machine).
2762018-01-11T09:12:53 <meshcollider> provoostenator: oh ok, that's all good then :)
2772018-01-11T09:16:28 *** CubicEarths has quit IRC
2782018-01-11T09:17:03 *** CubicEarths has joined #bitcoin-core-dev
2792018-01-11T09:18:12 <luke-jr> sipa: PM
2802018-01-11T09:23:32 *** tectonic_ has joined #bitcoin-core-dev
2812018-01-11T09:28:31 <meshcollider> Does collaborators only mean members of the organization with write access to the repo? I'd previously assumed we'd be able to comment on PRs/issues even if they were locked because we were members but that doesn't appear to be the case
2822018-01-11T09:31:21 *** JackH_ has quit IRC
2832018-01-11T09:32:36 *** zautomata1 has joined #bitcoin-core-dev
2842018-01-11T09:34:24 *** dcousens has quit IRC
2852018-01-11T09:34:50 *** tectonic_ has quit IRC
2862018-01-11T09:34:55 *** dcousens has joined #bitcoin-core-dev
2872018-01-11T09:37:37 *** zautomata1 has quit IRC
2882018-01-11T09:38:15 *** midnightmagic has joined #bitcoin-core-dev
2892018-01-11T09:38:54 *** zautomata1 has joined #bitcoin-core-dev
2902018-01-11T09:39:14 *** anome has joined #bitcoin-core-dev
2912018-01-11T09:41:17 *** promag has joined #bitcoin-core-dev
2922018-01-11T09:47:00 *** logicue has joined #bitcoin-core-dev
2932018-01-11T09:48:09 *** logicue has quit IRC
2942018-01-11T09:53:02 *** AaronvanW has joined #bitcoin-core-dev
2952018-01-11T09:55:03 *** Krellan has quit IRC
2962018-01-11T09:56:19 *** tectonic_ has joined #bitcoin-core-dev
2972018-01-11T10:00:56 *** Xexe has joined #bitcoin-core-dev
2982018-01-11T10:02:51 *** zautomata1 has quit IRC
2992018-01-11T10:04:51 *** indistylo has joined #bitcoin-core-dev
3002018-01-11T10:05:45 *** Krellan has joined #bitcoin-core-dev
3012018-01-11T10:10:51 *** Krellan has quit IRC
3022018-01-11T10:12:02 *** tectonic_ has quit IRC
3032018-01-11T10:13:16 *** Guyver2 has joined #bitcoin-core-dev
3042018-01-11T10:13:59 *** timothy has joined #bitcoin-core-dev
3052018-01-11T10:17:03 *** tectonic has joined #bitcoin-core-dev
3062018-01-11T10:23:10 <provoostenator> Travis is in a bad mood today?
3072018-01-11T10:24:11 <zelest> must be Ultron
3082018-01-11T10:26:18 <meshcollider> provoostenator: are you referring to 11991? I restarted it for you
3092018-01-11T10:26:33 <meshcollider> sipa: if you're online maybe you could add Sjors to the org so he can restart travis too
3102018-01-11T10:30:15 <sipa> i'm just on my phone now, will do later
3112018-01-11T10:30:55 <provoostenator> meshcollider: 11991 and 12119
3122018-01-11T10:31:44 <meshcollider> provoostenator: 12119 failed 4 checks, are you sure that its travis fault not something wrong with your PR?
3132018-01-11T10:32:32 <provoostenator> I'm not ruling that out, but the errors seemed to be timeouts.
3142018-01-11T10:33:07 <meshcollider> ok we'll try it again and see :)
3152018-01-11T10:33:19 <provoostenator> I'll also run the full suite locally
3162018-01-11T10:39:08 *** Amuza has joined #bitcoin-core-dev
3172018-01-11T10:49:02 <bitcoin-git> [bitcoin] luke-jr opened pull request #12146: Wallet: Support disabling implicit Segwit operation (master...opt_wallet_segwit) https://github.com/bitcoin/bitcoin/pull/12146
3182018-01-11T10:54:00 <meshcollider> provoostenator: seems they're all failing again, so yeah must be something to do with the PR not travis
3192018-01-11T10:56:05 *** molz has quit IRC
3202018-01-11T10:56:26 *** arbitrary_guy has quit IRC
3212018-01-11T10:58:53 *** mlz has joined #bitcoin-core-dev
3222018-01-11T10:59:22 *** larafale has joined #bitcoin-core-dev
3232018-01-11T11:01:02 *** rzhang__ has joined #bitcoin-core-dev
3242018-01-11T11:08:04 *** lejitz has quit IRC
3252018-01-11T11:13:54 <bitcoin-git> [bitcoin] anvilcoin opened pull request #12148: Update README.md (master...master) https://github.com/bitcoin/bitcoin/pull/12148
3262018-01-11T11:14:06 <sturles> vi +
3272018-01-11T11:14:14 <sturles> Sorry..
3282018-01-11T11:15:42 <meshcollider> what do these people hope to achieve with PRs like that, do they honestly ever think it will get merged?
3292018-01-11T11:15:51 *** eck has quit IRC
3302018-01-11T11:16:58 <sipa> meshcollider: i believe they don't understand what 'pull' means in this context
3312018-01-11T11:18:21 <sipa> i believe many of them are just trying to make a clone or try making a simple change in their own cooy
3322018-01-11T11:18:35 *** AaronvanW has quit IRC
3332018-01-11T11:18:47 *** Randolf has quit IRC
3342018-01-11T11:20:21 <provoostenator> meshcollider: probably, but they both pass on my machine. 11991 fails with "/wallet/db.h:21:20: fatal error: db_cxx.h: No such file or directory" on one machine. I can try on a linux VM...
3352018-01-11T11:21:46 *** eck has joined #bitcoin-core-dev
3362018-01-11T11:22:04 <bitcoin-git> [bitcoin] fanquake closed pull request #12148: Update README.md (master...master) https://github.com/bitcoin/bitcoin/pull/12148
3372018-01-11T11:25:31 *** eck has quit IRC
3382018-01-11T11:25:45 *** eck has joined #bitcoin-core-dev
3392018-01-11T11:25:45 *** eck has quit IRC
3402018-01-11T11:27:04 *** eck has joined #bitcoin-core-dev
3412018-01-11T11:36:15 *** AaronvanW has joined #bitcoin-core-dev
3422018-01-11T11:51:44 <bitcoin-git> [bitcoin] kashyap2690 opened pull request #12149: Unlock Wallet Implemented. (master...master) https://github.com/bitcoin/bitcoin/pull/12149
3432018-01-11T12:00:58 <wumpus> congrats on merging segwit wallet support jonasschnelli
3442018-01-11T12:01:59 *** sugarpuff has quit IRC
3452018-01-11T12:02:35 *** sugarpuff has joined #bitcoin-core-dev
3462018-01-11T12:04:57 <wumpus> and sipa and everyone that reviewed ofcourse
3472018-01-11T12:07:16 *** Victorsueca has quit IRC
3482018-01-11T12:09:13 <provoostenator> luke-jr from the title and description of 12146 it's not immediatley clear what you're tying to do, but I'll study it later. If you mention the "-walletimplicitsegwit" flag explictly in the description, it's probably a bit more clear.
3492018-01-11T12:10:13 <provoostenator> It would also help to clarify how it's different from -addresstype=legacy, other than foot-shooting protection.
3502018-01-11T12:11:45 *** AaronvanW has joined #bitcoin-core-dev
3512018-01-11T12:12:27 <provoostenator> I assume we'll chat during todays meeting about what the earliest possible release date is, so people know how much time is left to get more stuff in?
3522018-01-11T12:13:10 <provoostenator> (particularly stuff related to SegWit)
3532018-01-11T12:13:42 <provoostenator> I'd say at least two weeks given some of the current discussion.
3542018-01-11T12:16:46 <wumpus> yes we should give some time for fixes after this merge and before the release
3552018-01-11T12:18:22 *** Amuza has quit IRC
3562018-01-11T12:18:30 <promag> there are some things to do
3572018-01-11T12:18:37 <provoostenator> Is there something we changed since v0.15.1 that causes newly created wallets to be incompatible with v0.15.1? If so, what compile / launch flag do I need to use for v0.15.1?
3582018-01-11T12:18:46 <promag> maybe sipa is working on those follow ups?
3592018-01-11T12:19:42 <provoostenator> (if not, then I'm during something wrong in my regtest setup, quite possible)
3602018-01-11T12:21:08 <wumpus> probably the segwit change caused newly created wallets to be incompatible with 0.15.x?
3612018-01-11T12:21:08 *** arubi has quit IRC
3622018-01-11T12:23:04 *** ossifrage has quit IRC
3632018-01-11T12:23:23 *** ossifrage has joined #bitcoin-core-dev
3642018-01-11T12:24:37 *** mariorz has quit IRC
3652018-01-11T12:24:58 *** mariorz has joined #bitcoin-core-dev
3662018-01-11T12:25:59 *** arubi has joined #bitcoin-core-dev
3672018-01-11T12:26:05 *** dgenr8 has quit IRC
3682018-01-11T12:26:23 *** maxim89 has joined #bitcoin-core-dev
3692018-01-11T12:26:25 <sipa> provoostenator: what fails? it should work fine as long as you don't create bech32 addresses
3702018-01-11T12:26:39 *** justanotheruser has quit IRC
3712018-01-11T12:27:03 *** dgenr8 has joined #bitcoin-core-dev
3722018-01-11T12:27:04 <sipa> provoostenator: oh, or the default key thing?
3732018-01-11T12:27:13 *** AndyS2 has quit IRC
3742018-01-11T12:27:26 <provoostenator> After I copy the wallet over to a 0.15 node and restart, it throws "Error loading wallet.dat: Wallet requires newer version of Bitcoin Core". I only added a legacy address.
3752018-01-11T12:27:42 *** AndyS2 has joined #bitcoin-core-dev
3762018-01-11T12:27:52 <provoostenator> default key thing?
3772018-01-11T12:28:28 <sipa> yes, i don't think you can use 0.16 wallets in 0.15
3782018-01-11T12:28:41 <sipa> but you can create a 0.15 wallet, use it 0.16, and then downgrade
3792018-01-11T12:29:14 <provoostenator> Ok, I'll use that approach in my backwards compatilibity test. It's more future proof anyway.
3802018-01-11T12:30:45 *** maxim89 has quit IRC
3812018-01-11T12:31:34 <wumpus> yes, that's the way to go
3822018-01-11T12:31:52 *** justanotheruser has joined #bitcoin-core-dev
3832018-01-11T12:32:04 <provoostenator> Anything around --with-incompatible-bdb that's worth testing?
3842018-01-11T12:37:00 *** hirishaway is now known as hirish
3852018-01-11T12:38:00 *** dabura667 has quit IRC
3862018-01-11T12:45:30 *** jtimon has quit IRC
3872018-01-11T12:46:02 *** laurentmt has joined #bitcoin-core-dev
3882018-01-11T12:46:51 *** laurentmt has quit IRC
3892018-01-11T12:47:24 *** wxss has joined #bitcoin-core-dev
3902018-01-11T13:01:47 *** lnostdal has quit IRC
3912018-01-11T13:02:00 *** CubicEarths has quit IRC
3922018-01-11T13:07:12 <bitcoin-git> [bitcoin] ryanofsky opened pull request #12150: Fix ListCoins test failure due to unset g_address_type, g_change_type (master...pr/listg) https://github.com/bitcoin/bitcoin/pull/12150
3932018-01-11T13:12:20 *** Chenpan has quit IRC
3942018-01-11T13:16:49 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d889c036cd6f...3c6286873e50
3952018-01-11T13:16:49 <bitcoin-git> bitcoin/master 2be2b5d Jacky C: Remove the ending slashes from RPC URI format.
3962018-01-11T13:16:50 <bitcoin-git> bitcoin/master 3c62868 Wladimir J. van der Laan: Merge #12112: Docs: Remove the ending slashes from RPC URI format....
3972018-01-11T13:17:32 <bitcoin-git> [bitcoin] laanwj closed pull request #12112: Docs: Remove the ending slashes from RPC URI format. (master...docs/multi-wallet_RPC_interface_correction) https://github.com/bitcoin/bitcoin/pull/12112
3982018-01-11T13:19:03 *** Chenpan has joined #bitcoin-core-dev
3992018-01-11T13:19:19 <bitcoin-git> [bitcoin] promag opened pull request #12151: Remove cs_main lock from blockToJSON and blockheaderToJSON (master...2018-01-blocktojson) https://github.com/bitcoin/bitcoin/pull/12151
4002018-01-11T13:23:19 *** indistylo has quit IRC
4012018-01-11T13:25:18 *** AaronvanW has quit IRC
4022018-01-11T13:26:45 *** AaronvanW has joined #bitcoin-core-dev
4032018-01-11T13:35:45 *** AaronvanW has quit IRC
4042018-01-11T13:40:32 *** will_ has joined #bitcoin-core-dev
4052018-01-11T13:41:13 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3c6286873e50...92a810d04b90
4062018-01-11T13:41:14 <bitcoin-git> bitcoin/master f765bb3 Russell Yanofsky: Fix ListCoins test failure due to unset g_address_type, g_change_type...
4072018-01-11T13:41:14 <bitcoin-git> bitcoin/master 92a810d MarcoFalke: Merge #12150: Fix ListCoins test failure due to unset g_address_type, g_change_type...
4082018-01-11T13:41:45 *** AaronvanW has joined #bitcoin-core-dev
4092018-01-11T13:41:54 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #12150: Fix ListCoins test failure due to unset g_address_type, g_change_type (master...pr/listg) https://github.com/bitcoin/bitcoin/pull/12150
4102018-01-11T13:46:56 *** promag has quit IRC
4112018-01-11T13:47:59 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/92a810d04b90...1d2eaba300bc
4122018-01-11T13:47:59 <bitcoin-git> bitcoin/master 35c2b1f Suhas Daftuar: Fix rare failure in p2p-segwit.py...
4132018-01-11T13:48:00 <bitcoin-git> bitcoin/master 1d2eaba Wladimir J. van der Laan: Merge #12133: [qa] Fix rare failure in p2p-segwit.py...
4142018-01-11T13:48:42 <bitcoin-git> [bitcoin] laanwj closed pull request #12133: [qa] Fix rare failure in p2p-segwit.py (master...2018-01-fix-p2p-segwit) https://github.com/bitcoin/bitcoin/pull/12133
4152018-01-11T13:50:53 *** Xexe has left #bitcoin-core-dev
4162018-01-11T14:01:07 *** promag has joined #bitcoin-core-dev
4172018-01-11T14:01:23 *** eck has quit IRC
4182018-01-11T14:02:51 *** voidmain13 has quit IRC
4192018-01-11T14:07:25 <provoostenator> sipa: what's the expected failure mode of downgrading a wallet with a bech32 address? Is it supposed to be fully recoverable when you upgrade?
4202018-01-11T14:08:11 <sipa> provoostenator: the failure mode is that RPCs may report weird addresses
4212018-01-11T14:08:22 <provoostenator> Ok, that's what I'm seeing...
4222018-01-11T14:08:36 <sipa> in particular one very short address that starts with a 3
4232018-01-11T14:08:44 <provoostenator> I'll just bake that into the test, although a more severe warning would be nice, at least after upgrade.
4242018-01-11T14:08:53 <sipa> it should be fixed by uograding again
4252018-01-11T14:09:08 <provoostenator> Nope, weird address sticks for me. But I'm trying that again now.
4262018-01-11T14:09:35 <provoostenator> Actually nvm, my bad.
4272018-01-11T14:09:44 *** Arielle33Wilkins has quit IRC
4282018-01-11T14:15:47 *** JayBerg has joined #bitcoin-core-dev
4292018-01-11T14:19:54 <bitcoin-git> [bitcoin] Sjors opened pull request #12152: [WIP] misc. backwards compatibility tests (master...previous-release-segwit-wallet-test) https://github.com/bitcoin/bitcoin/pull/12152
4302018-01-11T14:19:57 <provoostenator> It does recover. Any other scenarios I should add ^ ?
4312018-01-11T14:24:15 <sipa> provoostenator: have you seen my gist on segwit wallet?
4322018-01-11T14:24:29 <sipa> it explicitly lists a number of scenarios that are intended to work
4332018-01-11T14:24:58 <provoostenator> I read it in early December. It is still up to date? Back then it had several atlernative plans.
4342018-01-11T14:25:47 <provoostenator> So it's 1a and 3a now?
4352018-01-11T14:25:48 <sipa> yes, it is up to date
4362018-01-11T14:25:51 <sipa> and 5
4372018-01-11T14:26:09 <sipa> but the solutions don't matter for you, just the supported scenarios :)
4382018-01-11T14:26:32 <provoostenator> Ah yes, alright I'll see if can turn those into tests.
4392018-01-11T14:26:42 <bitcoin-git> [bitcoin] promag opened pull request #12153: Avoid permanent cs_main lock in getblockheader (master...2018-01-getblockheader) https://github.com/bitcoin/bitcoin/pull/12153
4402018-01-11T14:32:55 <provoostenator> sipa: might be a good idea to move that gist to the docs repo or some other easier to find spot? At least the current-facts part of it.
4412018-01-11T14:33:56 <sipa> provoostenator: perhaps, though such documents may get outfated soon
4422018-01-11T14:33:58 <sipa> *outdated
4432018-01-11T14:34:35 *** wtabata has joined #bitcoin-core-dev
4442018-01-11T14:35:09 *** Swifree has joined #bitcoin-core-dev
4452018-01-11T14:35:42 <provoostenator> In case of the wallet format, any proposed change should reference that document and we could consider a PR unfinished until a corresponding doc change PR is there. Hopefully eventually the wallet will be intuitive enough that the doc can be removed.
4462018-01-11T14:35:47 *** will_ has quit IRC
4472018-01-11T14:36:38 *** belcher_ has joined #bitcoin-core-dev
4482018-01-11T14:38:46 *** Victorsueca has joined #bitcoin-core-dev
4492018-01-11T14:39:39 *** Swifree has quit IRC
4502018-01-11T14:40:42 *** wtabata has quit IRC
4512018-01-11T14:41:02 *** wtabata has joined #bitcoin-core-dev
4522018-01-11T14:43:07 *** Murch has joined #bitcoin-core-dev
4532018-01-11T14:56:01 *** dcousens has quit IRC
4542018-01-11T14:56:16 *** dcousens has joined #bitcoin-core-dev
4552018-01-11T14:59:31 *** hirish is now known as hirishaway
4562018-01-11T15:00:35 *** Lauda has quit IRC
4572018-01-11T15:01:14 *** Lauda has joined #bitcoin-core-dev
4582018-01-11T15:02:37 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
4592018-01-11T15:02:37 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
4602018-01-11T15:06:23 *** hirishaway is now known as hirish
4612018-01-11T15:07:26 *** wtabata is now known as wtabat
4622018-01-11T15:07:30 *** wtabat is now known as wtabata
4632018-01-11T15:13:14 *** Judah16Tillman has joined #bitcoin-core-dev
4642018-01-11T15:16:58 *** anome has quit IRC
4652018-01-11T15:19:48 *** meshcollider has quit IRC
4662018-01-11T15:20:25 <promag> GH down?
4672018-01-11T15:21:59 *** JackH has joined #bitcoin-core-dev
4682018-01-11T15:24:02 *** hirish is now known as hirishaway
4692018-01-11T15:24:44 <instagibbs> promag, yes
4702018-01-11T15:24:51 *** hirishaway is now known as hirish
4712018-01-11T15:25:13 *** contrapumpkin has joined #bitcoin-core-dev
4722018-01-11T15:26:57 *** whphhg has quit IRC
4732018-01-11T15:27:25 *** wxss has quit IRC
4742018-01-11T15:28:35 *** Chenpan has quit IRC
4752018-01-11T15:30:19 *** arubi has quit IRC
4762018-01-11T15:31:13 *** arubi has joined #bitcoin-core-dev
4772018-01-11T15:32:32 *** JackH has quit IRC
4782018-01-11T15:33:38 *** whphhg has joined #bitcoin-core-dev
4792018-01-11T15:33:39 *** harrymm has joined #bitcoin-core-dev
4802018-01-11T15:44:49 *** anome has joined #bitcoin-core-dev
4812018-01-11T15:45:36 *** JackH has joined #bitcoin-core-dev
4822018-01-11T15:50:38 *** mrsc_ has joined #bitcoin-core-dev
4832018-01-11T15:53:03 *** mrsc has quit IRC
4842018-01-11T15:56:38 *** Chenpan has joined #bitcoin-core-dev
4852018-01-11T15:57:44 *** eck has joined #bitcoin-core-dev
4862018-01-11T15:57:56 *** unholymachine has quit IRC
4872018-01-11T15:58:34 *** unholymachine has joined #bitcoin-core-dev
4882018-01-11T16:00:09 *** Victorsueca has quit IRC
4892018-01-11T16:01:22 *** Victorsueca has joined #bitcoin-core-dev
4902018-01-11T16:02:50 *** eck has quit IRC
4912018-01-11T16:03:32 *** eck has joined #bitcoin-core-dev
4922018-01-11T16:04:49 *** Chenpan has quit IRC
4932018-01-11T16:05:20 *** Chenpan has joined #bitcoin-core-dev
4942018-01-11T16:09:59 *** contrapumpkin has quit IRC
4952018-01-11T16:27:24 *** contrapumpkin has joined #bitcoin-core-dev
4962018-01-11T16:43:33 *** Giszmo has joined #bitcoin-core-dev
4972018-01-11T16:43:34 *** wxss has joined #bitcoin-core-dev
4982018-01-11T16:53:37 *** Giszmo has quit IRC
4992018-01-11T16:54:42 *** Giszmo has joined #bitcoin-core-dev
5002018-01-11T17:01:02 *** Victorsueca has quit IRC
5012018-01-11T17:01:13 *** JayBerg has quit IRC
5022018-01-11T17:02:22 *** Victorsueca has joined #bitcoin-core-dev
5032018-01-11T17:05:58 *** promag has quit IRC
5042018-01-11T17:25:52 *** JayBerg has joined #bitcoin-core-dev
5052018-01-11T17:27:55 *** Krellan has joined #bitcoin-core-dev
5062018-01-11T17:28:09 *** JayBerg has quit IRC
5072018-01-11T17:29:02 *** jb55 has joined #bitcoin-core-dev
5082018-01-11T17:29:12 *** JayBerg has joined #bitcoin-core-dev
5092018-01-11T17:32:46 *** Krellan has quit IRC
5102018-01-11T17:33:35 *** JayBerg has quit IRC
5112018-01-11T17:34:48 *** Ephraim has joined #bitcoin-core-dev
5122018-01-11T17:35:45 <Ephraim> help
5132018-01-11T17:38:23 *** timothy has quit IRC
5142018-01-11T17:38:35 *** belcher_ has quit IRC
5152018-01-11T17:38:46 *** laurentmt has joined #bitcoin-core-dev
5162018-01-11T17:38:52 *** tripleslash has joined #bitcoin-core-dev
5172018-01-11T17:38:53 *** tripleslash has quit IRC
5182018-01-11T17:39:23 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1d2eaba300bc...0910cbe4ef31
5192018-01-11T17:39:23 <bitcoin-git> bitcoin/master 18be3ab Chris Stewart: Adding test case for SINGLE|ANYONECANPAY hash type in tx_valid.json
5202018-01-11T17:39:24 <bitcoin-git> bitcoin/master 0910cbe MarcoFalke: Merge #12082: Adding test case for SINGLE|ANYONECANPAY hash type in tx_valid.json...
5212018-01-11T17:39:28 *** tripleslash has joined #bitcoin-core-dev
5222018-01-11T17:40:03 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #12082: Adding test case for SINGLE|ANYONECANPAY hash type in tx_valid.json (master...add_tx_valid_singleanyonecanpay) https://github.com/bitcoin/bitcoin/pull/12082
5232018-01-11T17:40:29 *** Ephraim has quit IRC
5242018-01-11T17:47:05 *** indistylo has joined #bitcoin-core-dev
5252018-01-11T17:49:11 *** Emcy has joined #bitcoin-core-dev
5262018-01-11T17:51:04 *** anome has quit IRC
5272018-01-11T17:51:35 *** Emcy_ has quit IRC
5282018-01-11T17:52:59 *** Murch has quit IRC
5292018-01-11T17:53:37 <achow101> what's wrong with travis today?
5302018-01-11T17:54:16 *** AaronvanW has quit IRC
5312018-01-11T17:54:52 *** AaronvanW has joined #bitcoin-core-dev
5322018-01-11T17:55:38 <wumpus> what is it doing?
5332018-01-11T17:56:04 *** rebel84 has joined #bitcoin-core-dev
5342018-01-11T17:57:00 *** Murch has joined #bitcoin-core-dev
5352018-01-11T17:58:50 *** indistylo has quit IRC
5362018-01-11T17:59:14 *** AaronvanW has quit IRC
5372018-01-11T17:59:49 *** indistylo has joined #bitcoin-core-dev
5382018-01-11T18:00:20 *** AaronvanW has joined #bitcoin-core-dev
5392018-01-11T18:03:15 *** rebel84 has quit IRC
5402018-01-11T18:07:46 *** JayBerg has joined #bitcoin-core-dev
5412018-01-11T18:12:24 *** JayBerg has quit IRC
5422018-01-11T18:14:09 <achow101> nvm. I was just confused as to how 8 of the most recent PRs were failing travis. thought it was a problem travis but its actually a problem with those 8 PRs :/
5432018-01-11T18:16:05 *** indistylo has quit IRC
5442018-01-11T18:16:25 *** Victorsueca has quit IRC
5452018-01-11T18:16:41 *** isis has quit IRC
5462018-01-11T18:17:36 *** Victorsueca has joined #bitcoin-core-dev
5472018-01-11T18:20:17 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5482018-01-11T18:28:52 *** AaronvanW has quit IRC
5492018-01-11T18:29:30 *** AaronvanW has joined #bitcoin-core-dev
5502018-01-11T18:31:47 *** m8tion has quit IRC
5512018-01-11T18:32:25 *** m8tion has joined #bitcoin-core-dev
5522018-01-11T18:33:37 *** anome has joined #bitcoin-core-dev
5532018-01-11T18:33:51 *** AaronvanW has quit IRC
5542018-01-11T18:34:27 *** Chris_Stewart_5 has quit IRC
5552018-01-11T18:36:24 <wumpus> indeed, master is passing according to my mails
5562018-01-11T18:37:32 *** anome has quit IRC
5572018-01-11T18:38:12 *** wraithm has joined #bitcoin-core-dev
5582018-01-11T18:39:53 *** anome has joined #bitcoin-core-dev
5592018-01-11T18:41:55 *** anome has quit IRC
5602018-01-11T18:43:31 *** anome has joined #bitcoin-core-dev
5612018-01-11T18:44:23 *** jtimon has joined #bitcoin-core-dev
5622018-01-11T18:46:41 *** m8tion has quit IRC
5632018-01-11T18:48:28 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5642018-01-11T18:52:17 *** anome has quit IRC
5652018-01-11T18:53:31 *** laurentmt has quit IRC
5662018-01-11T18:57:15 *** meshcollider has joined #bitcoin-core-dev
5672018-01-11T18:57:30 *** clarkmoody has joined #bitcoin-core-dev
5682018-01-11T18:59:41 <wumpus> meeting?
5692018-01-11T18:59:44 <jtimon> hi
5702018-01-11T18:59:50 <jonasschnelli> yes
5712018-01-11T19:00:15 <wumpus> #startmeeting
5722018-01-11T19:00:15 <lightningbot> Meeting started Thu Jan 11 19:00:15 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
5732018-01-11T19:00:15 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
5742018-01-11T19:00:21 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag
5752018-01-11T19:00:38 <meshcollider> hi
5762018-01-11T19:00:40 <wumpus> congrats everyone on merging segwit wallet!
5772018-01-11T19:00:47 <meshcollider> \o/
5782018-01-11T19:00:48 <achow101> hi
5792018-01-11T19:01:04 <wumpus> I think we should focus this meeting on what there is to do still for 0.16
5802018-01-11T19:01:21 <provoostenator> hi
5812018-01-11T19:01:22 <wumpus> I've just updated https://github.com/bitcoin/bitcoin/milestone/30 removing everything that isn't either a bugfix or has to do with segwit
5822018-01-11T19:01:25 <instagibbs> hi
5832018-01-11T19:01:31 <instagibbs> \o/ so great to see
5842018-01-11T19:01:32 <wumpus> (well, moving it forward to 0.17)
5852018-01-11T19:02:18 <provoostenator> I'd like to get either #11991 or #11937 in so non-tech-savy people can actually use bech32.
5862018-01-11T19:02:21 <gribble> https://github.com/bitcoin/bitcoin/issues/11991 | [qt] Receive: checkbox for bech32 address by Sjors · Pull Request #11991 · bitcoin/bitcoin · GitHub
5872018-01-11T19:02:23 <wumpus> so that is the "high priority" list for now, if there's anything that should be added let me know
5882018-01-11T19:02:23 <gribble> https://github.com/bitcoin/bitcoin/issues/11937 | Qt: Setting for deciding address type (legacy, p2sh or bech32) by hsjoberg · Pull Request #11937 · bitcoin/bitcoin · GitHub
5892018-01-11T19:02:27 <BlueMatt> #11281 needs rebase and resolution of current discussion
5902018-01-11T19:02:31 <gribble> https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
5912018-01-11T19:02:40 <jonasschnelli> Will do soon
5922018-01-11T19:02:46 <wumpus> provoostenator: agreed
5932018-01-11T19:02:59 <provoostenator> I'll try to keep them fresh based on feedback.
5942018-01-11T19:03:05 <instagibbs> -qt support for address types i think is a big ? still
5952018-01-11T19:03:08 <jonasschnelli> Yes. I also think 11991 11937 should go into 0.16
5962018-01-11T19:03:09 *** Chris_St1 has joined #bitcoin-core-dev
5972018-01-11T19:03:13 <BlueMatt> I believe there's still pending segwit wallet stuff in some rpcs that are still TODO
5982018-01-11T19:03:14 <BlueMatt> sipa?
5992018-01-11T19:03:15 <achow101> If 11281 goes in, I would like to also have #11200
6002018-01-11T19:03:17 <gribble> https://github.com/bitcoin/bitcoin/issues/11200 | Allow for aborting rescans and canceling showProgress dialogs by achow101 · Pull Request #11200 · bitcoin/bitcoin · GitHub
6012018-01-11T19:03:35 *** Chris_Stewart_5 has quit IRC
6022018-01-11T19:03:36 <cfields> hi, here
6032018-01-11T19:04:05 <achow101> also #12101 and #12104 are bugfix-ish
6042018-01-11T19:04:06 <provoostenator> bech32 change behavior is nice to have; #11991 is mostly for my own OCD and I can just run that myself
6052018-01-11T19:04:07 <gribble> https://github.com/bitcoin/bitcoin/issues/12101 | Clamp walletpassphrase timeout to 2^31 seconds and check its bounds by achow101 · Pull Request #12101 · bitcoin/bitcoin · GitHub
6062018-01-11T19:04:08 <gribble> https://github.com/bitcoin/bitcoin/issues/12104 | HTTP Error 404: Not Found
6072018-01-11T19:04:09 <gribble> https://github.com/bitcoin/bitcoin/issues/11991 | [qt] Receive: checkbox for bech32 address by Sjors · Pull Request #11991 · bitcoin/bitcoin · GitHub
6082018-01-11T19:04:32 <achow101> s/12024/12104
6092018-01-11T19:04:33 <BlueMatt> do we want to fix the non-regression rpc too-many-sockets thing given its an upstream bug? cfields?
6102018-01-11T19:04:37 <provoostenator> (sorry, I meant #12119)
6112018-01-11T19:04:39 <gribble> https://github.com/bitcoin/bitcoin/issues/12119 | [wallet] use bech32 change address if any destination is bech32 by Sjors · Pull Request #12119 · bitcoin/bitcoin · GitHub
6122018-01-11T19:04:43 *** Murch has quit IRC
6132018-01-11T19:04:49 *** JayBerg has joined #bitcoin-core-dev
6142018-01-11T19:05:06 <cfields> BlueMatt: yes, I'll clean that up and PR it today. What's not clear, though, is if we should attempt to max out available fds.
6152018-01-11T19:05:08 <wumpus> 11200 seems more like a feature and isn't necessarily segwit related
6162018-01-11T19:05:25 <wumpus> more for 0.17
6172018-01-11T19:05:44 *** Krellan has joined #bitcoin-core-dev
6182018-01-11T19:06:20 <provoostenator> wumpus: when you move something to 0.17 does that mean it be merged before 0.16 is branched off, or does it not have that meaning?
6192018-01-11T19:06:30 <provoostenator> *it won't
6202018-01-11T19:06:45 <wumpus> provoostenator: yes
6212018-01-11T19:06:57 *** Judah16Tillman has quit IRC
6222018-01-11T19:07:28 <BlueMatt> wumpus: tend to agree re: 11200, though I'd still very much like to see #11281
6232018-01-11T19:07:31 <gribble> https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
6242018-01-11T19:07:34 <meshcollider> Will we have the signing certificates ready for the release? jonasschnelli cfields
6252018-01-11T19:07:49 <cfields> wumpus: consider the maxing fd's question a topic suggestion. I'm unsure what to do there.
6262018-01-11T19:07:58 <wumpus> BlueMatt: isn't that one already on there?
6272018-01-11T19:08:16 <jonasschnelli> meshcollider: at least there is a static non distributed RSA cert now available... (OSX).
6282018-01-11T19:08:32 <BlueMatt> wumpus: it is, was just re-enforcing :)
6292018-01-11T19:08:35 <meshcollider> jonasschnelli: ok
6302018-01-11T19:08:47 <jonasschnelli> (but no clue about Windows) topic?
6312018-01-11T19:08:52 <cfields> meshcollider: yes, we didn't get the threshold key setup in time, so we have a temporary key now. Presumably for 0.16 only.
6322018-01-11T19:09:17 <wumpus> BlueMatt: but yes I agree keeping that, it's more of a fix I guess (but also not really)
6332018-01-11T19:09:22 *** promag has joined #bitcoin-core-dev
6342018-01-11T19:09:38 <promag> o/
6352018-01-11T19:10:08 <cfields> meshcollider: I've written up a few little things worth committing, I'll PR those today as well.
6362018-01-11T19:10:09 <wumpus> great news regarding the signing key
6372018-01-11T19:10:15 <wumpus> cfields: ok, topic noted
6382018-01-11T19:11:22 <cfields> oh, on to me then?
6392018-01-11T19:11:45 <cfields> #11785 is what I'm unsure about
6402018-01-11T19:11:45 *** Murch has joined #bitcoin-core-dev
6412018-01-11T19:11:46 <gribble> https://github.com/bitcoin/bitcoin/issues/11785 | Raise the open fd limit to the maximum allowed by vii · Pull Request #11785 · bitcoin/bitcoin · GitHub
6422018-01-11T19:11:48 <wumpus> #topic maxing out fds
6432018-01-11T19:12:15 <wumpus> oops, accidentelly tagged #12101 0.17 while it should be 0.16
6442018-01-11T19:12:16 <provoostenator> As discussed earlier today: what's the minimum time before we branch of 0.16? So there's some time to test stuff and fix PR's.
6452018-01-11T19:12:17 <gribble> https://github.com/bitcoin/bitcoin/issues/12101 | Clamp walletpassphrase timeout to 2^31 seconds and check its bounds by achow101 · Pull Request #12101 · bitcoin/bitcoin · GitHub
6462018-01-11T19:12:27 <cfields> tl;dr: there was an issue where fd's could be maxed out causing crashes and weird behavior. Let's assume that we get that issue under control. Should we still attempt to bump up our fd limit?
6472018-01-11T19:12:46 *** Murch has quit IRC
6482018-01-11T19:13:12 <wumpus> cfields: I'm not sure that should be default behavior, how much is it frowned upon if daemons do that, don't know how other software handles it?
6492018-01-11T19:13:33 <wumpus> cfields: I think the usual way is to leave ulimit setting to the user/sysadmin
6502018-01-11T19:13:49 <ryanofsky> provoostenator, i think normally there is a feature freeze on master before creating the release branch
6512018-01-11T19:14:16 <wumpus> yes, normally there's a feature freeze
6522018-01-11T19:14:34 <wumpus> I also need to open translations for 0.16
6532018-01-11T19:14:35 <cfields> wumpus: I tend to agree with that. IMO if we're bumping into fd issues, we want to see them rather than mask them
6542018-01-11T19:14:58 <cfields> but iirc gmaxwell was generally in favor of a general bump
6552018-01-11T19:15:02 <wumpus> cfields: indeed, we should try to be robust against them, or at least exit with a clear error if that it's not possible
6562018-01-11T19:15:22 *** indistylo has joined #bitcoin-core-dev
6572018-01-11T19:15:33 <cfields> wumpus: ok, mind commenting there? I'll poke gmaxwell again about it too
6582018-01-11T19:15:45 <cfields> </topic>
6592018-01-11T19:15:51 <wumpus> cfields: sure
6602018-01-11T19:15:59 <cfields> thanks :)
6612018-01-11T19:16:01 <wumpus> other topics?
6622018-01-11T19:16:04 <jonasschnelli> I have a short disussion request for 11281
6632018-01-11T19:16:07 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/11281/commits/b2cc7020956cfd36925e4957493cd28d1d6f672e
6642018-01-11T19:16:16 <jonasschnelli> Is that a concern (see commit above)=
6652018-01-11T19:16:17 <jonasschnelli> ?
6662018-01-11T19:16:35 <jtimon> wumpus what are these "fds" to max out?
6672018-01-11T19:16:40 <wumpus> #topic "Avoid permanent cs_main/cs_wallet lock during RescanFromTime" discussion (jonasschnelli)
6682018-01-11T19:16:44 <jonasschnelli> sipa brought up the point, but I think it's okay if we just mention that in the rpc help
6692018-01-11T19:16:45 <wumpus> jtimon: "file descriptors"
6702018-01-11T19:16:49 <jtimon> thanks
6712018-01-11T19:17:23 <jonasschnelli> background: you may import a key and can see it's there but the related transactions are (still) missing
6722018-01-11T19:17:33 <achow101> I think it's fine to mention that in the help
6732018-01-11T19:17:34 <jonasschnelli> since the lock is released now
6742018-01-11T19:17:41 * BlueMatt is fine with the documentation fix, we cant always block the world waiting on things to be consistent
6752018-01-11T19:17:52 <BlueMatt> but sipa is the one who brought it up and apparently is mia today
6762018-01-11T19:18:05 <jonasschnelli> Okay. Lets wait on his feedback
6772018-01-11T19:18:08 <achow101> the alternative would be to block those calls during a rescan, right?
6782018-01-11T19:18:09 <jonasschnelli> </topic>
6792018-01-11T19:18:17 <wumpus> other topics?
6802018-01-11T19:18:20 <promag> what happens today if you import and then it crashes?
6812018-01-11T19:18:24 <jnewbery> Other PRs that would be nice for 0.16 are the RPC changes in #7965 (#10583, #11415, #10579)
6822018-01-11T19:18:26 <gribble> https://github.com/bitcoin/bitcoin/issues/7965 | Remaining instances of ENABLE_WALLET in `libbitcoin_server.a` · Issue #7965 · bitcoin/bitcoin · GitHub
6832018-01-11T19:18:29 <gribble> https://github.com/bitcoin/bitcoin/issues/10583 | [RPC] Split part of validateaddress into getaddressinfo by achow101 · Pull Request #10583 · bitcoin/bitcoin · GitHub
6842018-01-11T19:18:32 <gribble> https://github.com/bitcoin/bitcoin/issues/11415 | [RPC] Disallow using addresses in createmultisig by achow101 · Pull Request #11415 · bitcoin/bitcoin · GitHub
6852018-01-11T19:18:33 <jonasschnelli> promag: I guess the same problem
6862018-01-11T19:18:35 <gribble> https://github.com/bitcoin/bitcoin/issues/10579 | [RPC] Split signrawtransaction into wallet and non-wallet RPC command by achow101 · Pull Request #10579 · bitcoin/bitcoin · GitHub
6872018-01-11T19:18:47 <kanzure> hi.
6882018-01-11T19:18:48 <wumpus> jnewbery: those have nothing to do with segwit, so I moved them to 0.17
6892018-01-11T19:19:02 <jonasschnelli> Agree
6902018-01-11T19:19:19 <jnewbery> Shame. They deprecate the RPCs but don't remove them, so we're stuck with those wallet dependencies until v0.18
6912018-01-11T19:19:46 <wumpus> if we do a "theme release" at all we need to focus, sorry
6922018-01-11T19:19:48 <promag> jonasschnelli: should we "mark" those addresses until the rescan finishes?
6932018-01-11T19:19:51 <ryanofsky> 11415 maybe could be merged now
6942018-01-11T19:19:58 <jtimon> do #8994 and #10757 have a chance to get merged for 0.16 if I fix the nits?
6952018-01-11T19:20:00 <promag> jonasschnelli: future work I guess
6962018-01-11T19:20:01 <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
6972018-01-11T19:20:05 <gribble> https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
6982018-01-11T19:20:13 <jonasschnelli> promag: Yes... probably... need to think about that first
6992018-01-11T19:20:19 <wumpus> no, we're not adding non-segwit features for 0.16
7002018-01-11T19:20:29 <BlueMatt> wumpus: oooo, "theme release", can we start themeing based on cocktails like openwrt?
7012018-01-11T19:20:41 <achow101> presumably 0.17 will be sooner than the usual 6 months?
7022018-01-11T19:20:48 <ryanofsky> ok so feature freeze has already started?
7032018-01-11T19:20:51 <wumpus> BlueMatt: lol!
7042018-01-11T19:21:02 <instagibbs> ryanofsky, non-segwit ff i believe so
7052018-01-11T19:21:04 <jonasschnelli> I think since merging SW wallet freeze is active
7062018-01-11T19:21:06 <wumpus> ryanofsky: for non-segwit things, yes, for segwit things it's open for sicussion
7072018-01-11T19:21:07 <cfields> BlueMatt: by that you mean "white russian" (or something) for ~5 years, iirc?
7082018-01-11T19:21:07 <instagibbs> qt stuff might still be required
7092018-01-11T19:21:08 <BlueMatt> yes, didnt we say feature freeze when segwit wallet got merged
7102018-01-11T19:21:10 <achow101> ryanofsky: I'm guessing feature freeze started last night as soon as 11403 merged
7112018-01-11T19:21:22 <wumpus> BlueMatt: yes
7122018-01-11T19:21:22 <BlueMatt> cfields: yea......
7132018-01-11T19:21:31 <jtimon> achow101: really? I thought 0.16 was the exception and we're getting close to its regular planned non ahead of time date
7142018-01-11T19:21:39 <jonasschnelli> no
7152018-01-11T19:21:42 <promag> btw, 17 theme is?
7162018-01-11T19:21:53 <wumpus> achow101: we could do 0.17 sooner, but one thing at a time please, this is for discussion once 0.16 is out of the door :)
7172018-01-11T19:21:57 <BlueMatt> promag: white russian, apparently
7182018-01-11T19:22:13 <wumpus> no theme for 0.17, no themes again please, back to simply time based releases
7192018-01-11T19:22:24 <meshcollider> wumpus: you mean 17.0 ;)
7202018-01-11T19:22:34 <provoostenator> Given that the world demands SegWit from the Core wallet, I tend to agree about feature freeze for non-SegWit stuff.
7212018-01-11T19:22:43 <jtimon> BlueMatt: it seems tohe feature freeze is being done sooner than that
7222018-01-11T19:22:49 <provoostenator> And I guess it's about hte regular time to release anyway?
7232018-01-11T19:22:52 <wumpus> segwit was an exception because that was 'promised' for 0.15.1, I don't think this should become routine
7242018-01-11T19:23:27 <achow101> provoostenator: I think there's still 2 months left for the usual timing
7252018-01-11T19:23:51 <wumpus> yes, we're intentionally trying to do the release sooner than the usual planning
7262018-01-11T19:24:12 <wumpus> (e.g. the one in #11449 is worst-case)
7272018-01-11T19:24:13 <gribble> https://github.com/bitcoin/bitcoin/issues/11449 | Release schedule for 0.16.0 · Issue #11449 · bitcoin/bitcoin · GitHub
7282018-01-11T19:24:30 <MarcoFalke> Is #10387 a blocker for 0.16?
7292018-01-11T19:24:33 <gribble> https://github.com/bitcoin/bitcoin/issues/10387 | Eventually connect to NODE_NETWORK_LIMITED peers by jonasschnelli · Pull Request #10387 · bitcoin/bitcoin · GitHub
7302018-01-11T19:24:34 *** jeremymbolin has joined #bitcoin-core-dev
7312018-01-11T19:24:50 <jonasschnelli> MarcoFalke: no... can go into 0.17 IMO
7322018-01-11T19:24:53 <wumpus> MarcoFalke: I don't know, let's discuss
7332018-01-11T19:24:54 <jonasschnelli> Or why would it be?
7342018-01-11T19:24:59 <jtimon> I thought the only blocker for 0.16 was #11403 ?
7352018-01-11T19:25:03 <BlueMatt> its pending on gmaxwell, just need his ack, I think
7362018-01-11T19:25:05 <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
7372018-01-11T19:25:34 <BlueMatt> but, its def a "feature"
7382018-01-11T19:25:38 <jonasschnelli> 10387 is independent from the BIP159 signalling.... connecting would be nice though, but includes some risks.. so no hurry with that
7392018-01-11T19:25:39 <BlueMatt> we're doing the bit announce on master already
7402018-01-11T19:25:46 <wumpus> ok moving it to 0.17
7412018-01-11T19:25:48 <BlueMatt> so thats ok for it to go 17
7422018-01-11T19:26:14 <jonasschnelli> Ah,.. did 10387 still had the 0.16 tag?, Yes. Needs a 0.17 then
7432018-01-11T19:26:35 <wumpus> that leaves 13 open things in https://github.com/bitcoin/bitcoin/milestone/30
7442018-01-11T19:26:51 <wumpus> (including the release notes and the release schedule itself)
7452018-01-11T19:27:25 <sipa> oops, i'm here
7462018-01-11T19:27:33 <BlueMatt> lol
7472018-01-11T19:27:35 <sipa> timezone confusion
7482018-01-11T19:28:02 <BlueMatt> sipa: plx comment on 11281
7492018-01-11T19:28:02 <jonasschnelli> we need a core meeting alarm/notification service
7502018-01-11T19:28:12 <BlueMatt> also pending segwit wallet work
7512018-01-11T19:28:16 <BlueMatt> whats still missing?
7522018-01-11T19:28:18 <meshcollider> Does anything actually need to be done for #11048
7532018-01-11T19:28:19 <gribble> https://github.com/bitcoin/bitcoin/issues/11048 | Weird gettransaction details on testnet with segwit · Issue #11048 · bitcoin/bitcoin · GitHub
7542018-01-11T19:28:20 <jonasschnelli> sipa, Bluemat refers to https://github.com/bitcoin/bitcoin/pull/11281/commits/b2cc7020956cfd36925e4957493cd28d1d6f672e
7552018-01-11T19:28:40 <provoostenator> How do I add myself to the fancy meeting username mention ping?
7562018-01-11T19:28:55 <instagibbs> gotta tip wumpus some bch
7572018-01-11T19:28:59 *** jeremymbolin has quit IRC
7582018-01-11T19:29:23 <achow101> lol
7592018-01-11T19:29:23 <meshcollider> instagibbs: lol
7602018-01-11T19:29:25 <sipa> yeah will do, on my phone in a bar now
7612018-01-11T19:29:33 *** machaans has joined #bitcoin-core-dev
7622018-01-11T19:29:36 <instagibbs> RWC?
7632018-01-11T19:29:40 <wumpus> instagibbs: please no, no need to threaten me, will add him :)
7642018-01-11T19:29:51 <sipa> instagibbs: yes
7652018-01-11T19:29:52 *** gmaxwell has joined #bitcoin-core-dev
7662018-01-11T19:30:18 <BlueMatt> sipa: woke up in a bar?
7672018-01-11T19:30:42 <sipa> BlueMatt: just charged my phone and saw your signal msg
7682018-01-11T19:30:43 <jonasschnelli> heh
7692018-01-11T19:31:22 <cfields> so apparrently BlueMatt is the core meeting alarm service
7702018-01-11T19:31:26 <instagibbs> provoostenator, what's the status of -qt PR for 0.16? I'm kind of out of it but am willing to test with my branch
7712018-01-11T19:32:05 <wumpus> any other topics?
7722018-01-11T19:32:06 *** Krellan has quit IRC
7732018-01-11T19:32:19 <luke-jr> hi
7742018-01-11T19:32:27 <provoostenator> instagibbs: #11991
7752018-01-11T19:32:27 <bitcoin-git> [bitcoin] kekimusmaximus opened pull request #12158: Avoid unnecessary copy of objects. (master...avoid_copies) https://github.com/bitcoin/bitcoin/pull/12158
7762018-01-11T19:32:30 <gribble> https://github.com/bitcoin/bitcoin/issues/11991 | [qt] Receive: checkbox for bech32 address by Sjors · Pull Request #11991 · bitcoin/bitcoin · GitHub
7772018-01-11T19:32:37 <BlueMatt> lol, ok, everyone's here, start over now?
7782018-01-11T19:32:39 <luke-jr> #12146 should be tagged 0.16 too
7792018-01-11T19:32:40 <gribble> https://github.com/bitcoin/bitcoin/issues/12146 | Wallet: Support disabling implicit Segwit operation by luke-jr · Pull Request #12146 · bitcoin/bitcoin · GitHub
7802018-01-11T19:32:56 <provoostenator> Bit of discussion about the UI... but otherwise ready to go.
7812018-01-11T19:33:03 <gmaxwell> ^ 11991 seems like an obvious and easy win.
7822018-01-11T19:33:16 <sipa> #11991
7832018-01-11T19:33:19 <gribble> https://github.com/bitcoin/bitcoin/issues/11991 | [qt] Receive: checkbox for bech32 address by Sjors · Pull Request #11991 · bitcoin/bitcoin · GitHub
7842018-01-11T19:33:44 <luke-jr> indeed, I'd also suggest the bech32 change thing
7852018-01-11T19:34:20 <gmaxwell> yes, the "use native change if destinations are native"? I think that makes a lot of sense.
7862018-01-11T19:34:24 <luke-jr> #12119
7872018-01-11T19:34:26 <gribble> https://github.com/bitcoin/bitcoin/issues/12119 | [wallet] use bech32 change address if any destination is bech32 by Sjors · Pull Request #12119 · bitcoin/bitcoin · GitHub
7882018-01-11T19:34:41 <provoostenator> bech32 change thing needs a small refactor which I'll try to do tomorrow. But also has some discussion about which circumstances should trigger bech32 use. Please weigh in...
7892018-01-11T19:34:48 <wumpus> both 11991 and 12119 are already in the 0.16 milestone
7902018-01-11T19:34:53 <gmaxwell> The whole reason we didn't _always_ use native change was privacy, but if the outputs are native, then that same argument says we should use native.
7912018-01-11T19:35:08 <provoostenator> What about inputs?
7922018-01-11T19:35:17 <sipa> arguably you could just uniformly ranomly pick the address type of 1 of the inputs, and make the change that
7932018-01-11T19:35:26 <gmaxwell> provoostenator: I think they're irrelevant.
7942018-01-11T19:35:41 <wumpus> sipa: sounds like a plan
7952018-01-11T19:35:47 <gmaxwell> sipa: I don't think that makes any sense.
7962018-01-11T19:35:53 <provoostenator> As in: if any input or any output is bech32, use bech32, unless changeaddress param says otherwise. .... ok, why intput irrelevant?
7972018-01-11T19:35:54 <luke-jr> wumpus: 12146 isn't yet.
7982018-01-11T19:36:04 * sipa meh 12146
7992018-01-11T19:36:09 <wumpus> luke-jr: seems like that needs some more discussion
8002018-01-11T19:36:09 <gmaxwell> Why would it possibly be relevant in any way?
8012018-01-11T19:36:13 <instagibbs> we want to frustrate chain analysis, mimicking the payment as much as possible is ++
8022018-01-11T19:36:19 <promag> gmaxwell: what if someone wants 0.16 to behave like 0.15?
8032018-01-11T19:36:39 <luke-jr> wumpus: releasing Segwit wallet without it is a problem for people who don't want to use Segwit.
8042018-01-11T19:36:43 <provoostenator> We also want to reduce fees.
8052018-01-11T19:36:50 <gmaxwell> The only reason to not always use native, assuming you are using segwit to begin with in your wallet, is that it would make it easier to tell which of the outputs are change.
8062018-01-11T19:36:56 <jonasschnelli> luke-jr: define don't use?
8072018-01-11T19:37:16 <wumpus> luke-jr: just don't use the segwit address types then?
8082018-01-11T19:37:17 <gmaxwell> But that doesn't apply if the outputs (any of them, arguably) are native.
8092018-01-11T19:37:20 <luke-jr> jonasschnelli: never have a Segwit UTXO despite what anyone else may do
8102018-01-11T19:37:25 <provoostenator> So in other words, if you're spending from a bech32 address, there's no reason _not_ to use a native address as change?
8112018-01-11T19:37:39 <luke-jr> wumpus: without 12146, people can malleate your address and you'll never know
8122018-01-11T19:37:39 <gmaxwell> provoostenator: no!
8132018-01-11T19:37:42 <instagibbs> provoostenator, ??
8142018-01-11T19:37:52 <wumpus> is address malleation a thing now?
8152018-01-11T19:37:59 <provoostenator> It saves fees and there's no privacy downside, what am I missing?
8162018-01-11T19:38:07 <sipa> luke-jr: they can already
8172018-01-11T19:38:11 <gmaxwell> Again, inputs are irrelevant-- I can't figure out why you think inputs are at all relevant.
8182018-01-11T19:38:12 <jonasschnelli> provoostenator: he's worried about block size increase
8192018-01-11T19:38:17 <sipa> and have forever
8202018-01-11T19:38:24 <jonasschnelli> as sipa said,.. it was also possible by p2pk -> p2pkh
8212018-01-11T19:38:27 <luke-jr> sipa: with 12146, you would at least notice / not accept it
8222018-01-11T19:38:36 <sipa> luke-jr: why not? it's cheaper!
8232018-01-11T19:38:38 <jonasschnelli> s/was/is
8242018-01-11T19:38:48 <luke-jr> sipa: what?
8252018-01-11T19:39:03 <wumpus> would anyone use that at all, why would it be worth maintaining?
8262018-01-11T19:39:12 <sipa> you're lucky if someone sends you a witness output instead anyone of p2pkh
8272018-01-11T19:39:13 <jonasschnelli> I think luke-jr argument are more political/philosophical then technical/economical
8282018-01-11T19:39:20 <wumpus> it just complicates all kinds of logic
8292018-01-11T19:39:29 <gmaxwell> provoostenator: the privacy downside arises when your pay to a non-segwit destination. If you pay a non-segwit destination but make a native output as change, then which of the outputs is change is far more easily identified.
8302018-01-11T19:39:30 <luke-jr> wumpus: because using Segwit enables miners to increase block size, and has no benefits for the current wallet.
8312018-01-11T19:39:37 <instagibbs> i think this is going to be another "no one else agrees" type argument, sorry luke-jr
8322018-01-11T19:39:39 <sipa> (i think it's really bad that we accept outputs to addresses we didn'â give out)
8332018-01-11T19:39:41 <BlueMatt> provoostenator: its still a privacy leak, you're (probably) much, much more likely to use non-bech32 outputs as non-change, so irrespective of the inputs you'd be pretty clearly tagging your change output
8342018-01-11T19:40:06 <sipa> but it's not specific to segwit, and needs fixing independently
8352018-01-11T19:40:07 <instagibbs> simply not handing out those addresses should be enough... sender doesn't care if you want to spend more later
8362018-01-11T19:40:10 <BlueMatt> provoostenator: in fact, even worse, you're tagging it *because* your inputs are bech32 you're making clear that you support segwit in your wallet, so the bech32 output is *most likely* the change
8372018-01-11T19:40:27 <luke-jr> instagibbs: the sender can trick you into accepting Segwit without 12146
8382018-01-11T19:40:27 <wumpus> instagibbs: indeed
8392018-01-11T19:40:35 <instagibbs> luke-jr, worse, the sender *wont know* you don't implictly convert, leading to a orphaned utxo!
8402018-01-11T19:40:36 <wumpus> 'trick you into accepting segwit'
8412018-01-11T19:40:48 <instagibbs> whatever jerk is doing that
8422018-01-11T19:40:48 <gmaxwell> But if the other outputs are native, then this issue doesn't exist.
8432018-01-11T19:41:00 <luke-jr> instagibbs: orphaned UTXO is exactly the expected outcome
8442018-01-11T19:41:04 <luke-jr> instagibbs: and that's his fault
8452018-01-11T19:41:06 <Chris_St1> so the debate is whether we are creating the change output as the same script type as the payment output in a two output scenario?
8462018-01-11T19:41:07 <instagibbs> .....
8472018-01-11T19:41:11 <wumpus> man, that sounds like it should be prosecuted as a war crime
8482018-01-11T19:41:11 *** Tennis has joined #bitcoin-core-dev
8492018-01-11T19:41:32 <provoostenator> Alright, so rule should be: ignore inputs, if any output is bech32, use bech32 for change, unless setting overrides?
8502018-01-11T19:41:36 <luke-jr> Chris_St1: there's two parallel conversations going on here now :/
8512018-01-11T19:41:49 <provoostenator> luke-jr: yes, IRC needs threads
8522018-01-11T19:42:09 <wumpus> #topic when to use bech32 for change
8532018-01-11T19:42:11 <wumpus> ^^
8542018-01-11T19:42:13 <meshcollider> provoostenator: yes that's most sensible
8552018-01-11T19:42:16 <BlueMatt> provoostenator: thats not a bad idea, imo
8562018-01-11T19:42:17 <Chris_St1> what about when there are more than two outputs? Or are we just worried about GUI?
8572018-01-11T19:42:19 * jtimon thinks about what "trick you into accepting segwit" may mean...
8582018-01-11T19:42:31 <instagibbs> Chris_St1, privacy mostly
8592018-01-11T19:42:37 <gmaxwell> provoostenator: thats my belief.
8602018-01-11T19:42:41 <meshcollider> Was sipa suggestion of random choice serious or a joke
8612018-01-11T19:42:44 <provoostenator> Chris_St1: _any_ output, not _all_
8622018-01-11T19:42:47 *** tripleslash has quit IRC
8632018-01-11T19:42:49 <instagibbs> meshcollider, serious to me, makes sense
8642018-01-11T19:43:00 <luke-jr> IMO any output makes sense.
8652018-01-11T19:43:01 <gmaxwell> provoostenator: I think someone could reasonable argue that it should be "if a majority" rather than any.
8662018-01-11T19:43:03 <cfields> don't you lose the change privacy if there's a mix of segwit output types, though?
8672018-01-11T19:43:04 <meshcollider> Yeah was unsure if there's any downside
8682018-01-11T19:43:09 <wumpus> meshcollider: I think he was serious, it makes sense, less deterministic the change choice the better
8692018-01-11T19:43:20 *** tripleslash has joined #bitcoin-core-dev
8702018-01-11T19:43:33 <Chris_St1> instagibbs: yes, but what if you a 3 segwit payment outputs and 2 p2pkh payment outputs, what is the change type?
8712018-01-11T19:43:37 <gmaxwell> I think "all" is obviously too strong.
8722018-01-11T19:43:37 <cfields> if there's a p2wsh output and change goes to p2wpkh, that's obvious
8732018-01-11T19:43:53 <instagibbs> Chris_St1, arguments to be had. Could flip weighted coin, could just pick the cheapest to mimic
8742018-01-11T19:44:00 <instagibbs> (native)
8752018-01-11T19:44:03 <gmaxwell> cfields: "segwit" here means native.
8762018-01-11T19:44:04 <morcos> I don't think its worth going overboard with complication. If you are super privacy conscious you can manually do what you want, otherwise we should make the default what makes sense for the network.
8772018-01-11T19:44:11 <morcos> So I like provoostenator's idea
8782018-01-11T19:44:15 *** mgeuirx has joined #bitcoin-core-dev
8792018-01-11T19:44:24 <provoostenator> Chris_St1: bech32 in my proposal s well as the majority proposol (which I think it's a bit complicated...)
8802018-01-11T19:44:28 <Chris_St1> morcos: But that erodes the privacy of *everyone*. see zcash?
8812018-01-11T19:44:59 <morcos> Chris_St1: i don't think that analogy applies
8822018-01-11T19:45:03 <gmaxwell> Any is what I proposed on the PR, though I noted that "majority" would also be defensible. Requiring all, or worse, not using native even if all are native is bad for privacy.
8832018-01-11T19:45:07 <BlueMatt> yea, majority-are-native or signle-is-native are both fine with me
8842018-01-11T19:45:13 <luke-jr> weighed random?
8852018-01-11T19:45:16 *** AaronvanW has joined #bitcoin-core-dev
8862018-01-11T19:45:31 <gmaxwell> I think it's okay to bias some here towards the more cost effective form.
8872018-01-11T19:45:36 <morcos> well maybe, but thats why we're preservign some level of privacy... in that we only use bech32 for change if we're paying at least one bech32 address
8882018-01-11T19:45:37 <wumpus> yes
8892018-01-11T19:45:38 <instagibbs> hiding with other segwit wallets imo is your best bet anyways...
8902018-01-11T19:45:49 <gmaxwell> also the difference between these things only matters for sendmany...
8912018-01-11T19:45:51 *** JayBerg has quit IRC
8922018-01-11T19:45:52 <provoostenator> luke-jr: I that would be a great way for me to demonstrate my C++ incompetence :-)
8932018-01-11T19:46:07 * sipa is fine with (if not otherwise configured) using any bech32 -> change is bech32
8942018-01-11T19:46:23 *** Chris_St1 has quit IRC
8952018-01-11T19:46:25 <jnewbery> any-output-is-native seems reasonable to me
8962018-01-11T19:46:25 *** Victorsueca has quit IRC
8972018-01-11T19:46:32 *** Chris_Stewart_5 has joined #bitcoin-core-dev
8982018-01-11T19:46:41 <achow101> same
8992018-01-11T19:46:42 <gmaxwell> sipa: I think my suggestion was "unless configured that change should be legacy, change is native if any output is native".
9002018-01-11T19:46:57 <morcos> i think non-determinism in what kind of change address you have is just ick.. especially since the p2sh-wrapped kind is temporary
9012018-01-11T19:47:00 <provoostenator> As for luke-jr's point: having some flag to completely opt-out of SegWit seems reasonable to me.
9022018-01-11T19:47:04 <gmaxwell> (or if anyone felt that was too strong, change is native unless the majority is non-native; but it seems no one does)
9032018-01-11T19:47:05 <sipa> gmaxwell: and p2sh-p2wsh otherwise?
9042018-01-11T19:47:13 <gmaxwell> sipa: yes.
9052018-01-11T19:47:20 <sipa> makes snese
9062018-01-11T19:47:35 <Chris_Stewart_5> gmaxwell: by native you mean p2wpkh?
9072018-01-11T19:47:37 *** Victorsueca has joined #bitcoin-core-dev
9082018-01-11T19:47:41 <gmaxwell> sipa: so if you set yourself to be legacy, you'll stay legacy regardless, in order to respect any weird requirement to avoid creating segwit outputs.
9092018-01-11T19:48:08 <instagibbs> morcos, if it has native change is native is entirely determinstic, luckily
9102018-01-11T19:48:21 <instagibbs> sorry, has native, comma, change is native
9112018-01-11T19:48:52 <gmaxwell> morcos: I think you were responding to things like "weighed random change types"
9122018-01-11T19:49:03 <morcos> correct
9132018-01-11T19:49:06 <BlueMatt> more topics?
9142018-01-11T19:49:24 <luke-jr> back to 12146?
9152018-01-11T19:49:26 <gmaxwell> yea, I could go for weighed-random change types if the choice were otherwise neutral, but it's not.
9162018-01-11T19:49:31 * BlueMatt notes that it really would be nice to see #12118 in 0.16, just because its really a free 5% speedup in removeForBlock which is a big chunk of block validation latency....
9172018-01-11T19:49:33 <gribble> https://github.com/bitcoin/bitcoin/issues/12118 | Sort mempool by min(feerate, ancestor_feerate) by sdaftuar · Pull Request #12118 · bitcoin/bitcoin · GitHub
9182018-01-11T19:49:39 *** Krellan has joined #bitcoin-core-dev
9192018-01-11T19:49:45 <instagibbs> luke-jr, Creating utxo bloat to *slightly* reduce blocksize is weird weird feature to add imo
9202018-01-11T19:49:51 <instagibbs> (if we've transitioned)
9212018-01-11T19:49:57 <luke-jr> instagibbs: it's not UTXO bloat.
9222018-01-11T19:50:10 <BlueMatt> luke-jr: nack, just use 0.15.1 and focus on the real fix of splitting hd chain
9232018-01-11T19:50:11 <instagibbs> the scenario here is that some joker pays you, and you don't want to spend it, right?
9242018-01-11T19:50:25 <morcos> +1 BlueMatt
9252018-01-11T19:50:30 <BlueMatt> alternatively, this could be accomplished by using labels/accounts
9262018-01-11T19:50:40 <BlueMatt> label addresses and then payments will show up without the labels
9272018-01-11T19:50:44 <luke-jr> instagibbs: more or less
9282018-01-11T19:50:57 <luke-jr> BlueMatt: NACK, to myself and many others, mandatory Segwit wallet is a regression
9292018-01-11T19:51:06 <BlueMatt> then dont use 0.16
9302018-01-11T19:51:15 <luke-jr> so 0.15 is supported forever?
9312018-01-11T19:51:19 <gmaxwell> luke's argument is lame but there are other arguments for the position... But I think it's ultimately futile.
9322018-01-11T19:51:21 <luke-jr> including new features?
9332018-01-11T19:51:31 <morcos> luke-jr: right, but thats basically the only feature, so just dont use it until we have the version that doesn't accept all variations of key encoding
9342018-01-11T19:51:32 <BlueMatt> if you want the option, do the real fix, not the dirty hack of working like 0.15.1
9352018-01-11T19:51:33 <gmaxwell> luke-jr: by anyone who cares to support it
9362018-01-11T19:51:36 <instagibbs> This feature doesn't make any sense to me though.
9372018-01-11T19:51:55 <luke-jr> BlueMatt: there isn't a better fix
9382018-01-11T19:51:56 <BlueMatt> (the real fix being splitting the hd chain so that we never identify as ours addresses other than the ones we gave out)
9392018-01-11T19:52:07 <morcos> ^ it's in sipas gist
9402018-01-11T19:52:11 <achow101> luke-jr: the real fix is using different hd paths
9412018-01-11T19:52:13 <sipa> indeed.
9422018-01-11T19:52:14 <BlueMatt> which sipa proposed (I believe to much agreement) as the long-term route for the wallet
9432018-01-11T19:52:15 <luke-jr> BlueMatt: that's more than a fix. :p
9442018-01-11T19:52:17 <gmaxwell> instagibbs: it's very bad that we support showing funds paid to addresses we never issued. It invites really bad behavior that can cause irrecoverable funds loss. But the ship has already sailed on that.
9452018-01-11T19:52:23 <instagibbs> gmaxwell, no I get the issue
9462018-01-11T19:52:30 <instagibbs> I don't get his fix, it's one-sided
9472018-01-11T19:52:39 <gmaxwell> ah.
9482018-01-11T19:52:56 <morcos> we all agree to fixing that, what we don't care about is that we are temporarily makign it worse for the case of giving out legacy and receiving segwit
9492018-01-11T19:52:57 <instagibbs> sender has no clue you won't accept it!(outside of us wagging fingers to not try it)
9502018-01-11T19:53:02 <gmaxwell> Well thats because his motivation isn't one of the sensible ones, it's because he's discouraging people from using segwit to keep the blocksize down.
9512018-01-11T19:53:10 <BlueMatt> luke-jr: it is more than a fix for your specific issue, but its much nicer and isnt ridiculous from a ux/maintainability perspective
9522018-01-11T19:53:13 <luke-jr> that is a sensible one
9532018-01-11T19:53:15 <BlueMatt> we dont need more options in the wallet...
9542018-01-11T19:53:19 <instagibbs> anyways, all i have to say. Let's fix the wallet.
9552018-01-11T19:53:35 <gmaxwell> I don't share his concern, but even if I did-- his fix isn't needed for it: anyone autoconverting an address has a serious risk of funds loss already.
9562018-01-11T19:53:41 <provoostenator> luke-jr: what's wrong with launching with -addresstype=legacy?
9572018-01-11T19:53:42 <luke-jr> BlueMatt: 12146 is trivial
9582018-01-11T19:53:44 <morcos> luke-jr: would it help if we we very publicly communicated that our philosophy is to not accept payments except for addresses which have been given out?
9592018-01-11T19:53:45 <wumpus> certainly not options that only exist for some political goal and no one will actually use nor test
9602018-01-11T19:54:14 <morcos> we discussed doing that when we were making this change, b/c we knew we'd be making things worse on that front, but we'd already crossed the bridge with addwitnessaddress
9612018-01-11T19:54:18 <luke-jr> provoostenator: the current code will still accept Segwit payments to malleated addresses
9622018-01-11T19:54:18 <morcos> and other variants
9632018-01-11T19:54:19 *** indistylo has quit IRC
9642018-01-11T19:54:25 <BlueMatt> anyway, one more review on #12118 and slipping in past feature freeze would make me very happy...good to keep the march of performance improvements in block validation latency moving :)
9652018-01-11T19:54:27 <gribble> https://github.com/bitcoin/bitcoin/issues/12118 | Sort mempool by min(feerate, ancestor_feerate) by sdaftuar · Pull Request #12118 · bitcoin/bitcoin · GitHub
9662018-01-11T19:54:41 <gmaxwell> luke-jr: your change isn't needed to prevent autoconverting. Anyone who 'autoconverts' will have casual funds loss due to converted outputs being unreconized by older software, and _unrecoverable loss_ due to uncompressed pubkeys and potentially HSMs.
9672018-01-11T19:54:45 <cfields> instagibbs: at best, if you wag your finger and I'm forced to re-send a non-witness tx, that's 2x the tx's for that interaction. Not doing much to reduce block size...
9682018-01-11T19:55:08 <provoostenator> luke-jr: oh, you mean someone sees the public key after you spend it and then figures out how to send to its SegWit equivalent? I'm not sure if that actually works, see my backwards compatibility test PR.
9692018-01-11T19:55:13 <gmaxwell> luke-jr: that should be ample discouragement there.
9702018-01-11T19:55:16 <wumpus> morcos: would make sense to document that, though I wouldn't know where!
9712018-01-11T19:55:28 <jnewbery> Doesn't seem to me like this needs to be discussed for v0.16 release. Luke can maintain his patch in knots and everyone is happy. And then we can reconsider 12146 for 0.16.1
9722018-01-11T19:55:28 <instagibbs> cfields, what we need is a way of bloating the weight without taking up serialization space lol
9732018-01-11T19:55:30 <luke-jr> gmaxwell: all the more reason to allow people to avoid accepting the attempts
9742018-01-11T19:55:35 <provoostenator> But I don't see the point in ignoring such a transaction. There's certainly no way to stop it.
9752018-01-11T19:55:37 <achow101> provoostenator: given a p2pkh address, you can easily make the p2wpkh output without needing to see a transaction
9762018-01-11T19:55:38 <morcos> We can use the @bitcoin twitter handle maybe
9772018-01-11T19:55:48 <meshcollider> provoostenator: you don't need the public key, segwit addresses use PKH too
9782018-01-11T19:56:02 <wumpus> but a warning against 'malleating' addresses would make sense, I mean it's bad form and just because bitcoin core happens to accept it doesn't mean other wallets do
9792018-01-11T19:56:03 <luke-jr> provoostenator: it's an invalid payment
9802018-01-11T19:56:06 <gmaxwell> And yes, as morocos said, we knew that our handling of segwit would increase the risk that someone falsely believed they could autoconvert. It was a tradeoff we made, otherwise segwit support would be delayed behind a massive redesign.
9812018-01-11T19:56:23 <luke-jr> morcos: It would probably be good to do so, but I'm not sure it accomplishes the same thing
9822018-01-11T19:56:40 <luke-jr> also, you *can't* malleate right now
9832018-01-11T19:56:41 <morcos> yes, so lets spend our time doing the redesign and communicating our intentions
9842018-01-11T19:56:42 <cfields> instagibbs: heh
9852018-01-11T19:56:50 <morcos> you can do other forms of malleation
9862018-01-11T19:56:52 <BlueMatt> </topic>? It seems like everyone agrees outside of luke, and there is a *real* solution...also easy to not use 0.16 for now
9872018-01-11T19:56:59 <sipa> luke-jr: you can use p2pk instead of p2pkh
9882018-01-11T19:57:04 <wumpus> BlueMatt: yes, any other topics?
9892018-01-11T19:57:07 <Chris_Stewart_5> PSA: if anyone is interested in talking more about #12131 or #12132 there is a development channel that some work has been occurring in: #bitcoin-mast
9902018-01-11T19:57:08 <gribble> https://github.com/bitcoin/bitcoin/issues/12131 | [BIP-98 + BIP-116] MERKLEBRANCHVERIFY by kallewoof · Pull Request #12131 · bitcoin/bitcoin · GitHub
9912018-01-11T19:57:10 <gribble> https://github.com/bitcoin/bitcoin/issues/12132 | [BIP-117] Tail call semantics by kallewoof · Pull Request #12132 · bitcoin/bitcoin · GitHub
9922018-01-11T19:57:12 <wumpus> oh 3 minutes to go
9932018-01-11T19:57:12 <luke-jr> sipa: only if you know the key, which only the recipient does
9942018-01-11T19:57:27 <morcos> aren't those a bit premature for PR's?
9952018-01-11T19:57:29 <arubi> sipa, then I'll trick you into accepting some big bare n-of-m with a bunch of pubkeys
9962018-01-11T19:57:29 <achow101> luke-jr: you can malleate it to a p2sh nested p2pkh
9972018-01-11T19:57:34 <gmaxwell> luke-jr: I think it's adequate enough to let people know that if they do that, they _will_ lose funds, its effectively a guarentee. some switch to willfully ignore the outputs in a recoverable way wouldn't help that message at all.
9982018-01-11T19:57:37 <arubi> (all of yours)
9992018-01-11T19:57:41 <gmaxwell> and basically no one but you would set it.
10002018-01-11T19:57:41 <morcos> is there any consensus at all around wanting those features?
10012018-01-11T19:57:51 <luke-jr> achow101: nope, pretty sure we won't accept that without adding it to the wallet explicitly
10022018-01-11T19:58:09 <sipa> achow101: as luke-jr says
10032018-01-11T19:58:14 <luke-jr> gmaxwell: I don't agree only I would set it.
10042018-01-11T19:58:24 <gmaxwell> luke-jr: you can malleat addresses now fwiw, this is a long term design flaw in the wallet.
10052018-01-11T19:58:31 <gmaxwell> oh sipa pointed that out too
10062018-01-11T19:58:39 <luke-jr> gmaxwell: but you can't, as I pointed out
10072018-01-11T19:58:39 <wumpus> there's not really incentive for anyone to set a 'ignore some payments to me' setting, real user complaints are about not receiving payments...
10082018-01-11T19:58:41 <Chris_Stewart_5> morcos: I would say they are premature -- but I think they are definitely worht exploring more
10092018-01-11T19:58:41 <instagibbs> you can send people naked multisig...
10102018-01-11T19:58:42 <instagibbs> lol
10112018-01-11T19:58:51 <Chris_Stewart_5> if that was directed at me
10122018-01-11T19:58:55 <sipa> instagibbs: indeed
10132018-01-11T19:58:58 <luke-jr> instagibbs: !
10142018-01-11T19:59:03 <gmaxwell> luke-jr: something like 80% of addresses are reused...
10152018-01-11T19:59:05 <arubi> and with a bunch of pubkeys
10162018-01-11T19:59:19 <morcos> Chris_Stewart_5: yes... i just wasnt sure if i was behind the times...
10172018-01-11T19:59:27 <luke-jr> gmaxwell: unsupported use case, not relevant to the discussion, but instagibbs found an example case
10182018-01-11T19:59:27 <gmaxwell> as wumpus says, the incentives are against setting that knob.
10192018-01-11T19:59:40 <instagibbs> I guess that's another argument, there are tons of ways of malleating it, let's just fix the wallet instead.
10202018-01-11T19:59:42 <Chris_Stewart_5> morcos: Also why we should discuss the development in a separate channel IMO as it is a little speculative still
10212018-01-11T19:59:44 <wumpus> gmaxwell: also thanks to some exchanges that have a limit on the number of deposit addresses
10222018-01-11T19:59:46 <sipa> instagibbs: indeed
10232018-01-11T20:00:02 *** AaronvanW has quit IRC
10242018-01-11T20:00:06 <sipa> DING
10252018-01-11T20:00:10 <wumpus> #endmeeting
10262018-01-11T20:00:10 <lightningbot> Meeting ended Thu Jan 11 20:00:10 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
10272018-01-11T20:00:10 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-01-11-19.00.html
10282018-01-11T20:00:10 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-01-11-19.00.txt
10292018-01-11T20:00:10 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-01-11-19.00.log.html
10302018-01-11T20:00:23 * luke-jr glares at a certain Amazon wrapper that won't let him generate even a second address at all
10312018-01-11T20:00:49 <gmaxwell> Yea, thats my point: regardless of any willfully-ignore-naughty-payments-knob other vectors exist... and if someone does segwit convert random stuff, they're going to lose funds in an unrecoverable way.
10322018-01-11T20:01:27 <meshcollider> Since when do all PR mentions get added to the minutes
10332018-01-11T20:01:43 <achow101> I don't think any wallet that people use actually does that sort of conversion. It would have to be someone either being malicious or using their own faulty software
10342018-01-11T20:02:05 <gmaxwell> achow101: no of course not, it will immediately cause unrecoverable funds loss.
10352018-01-11T20:02:20 <luke-jr> so outcome of conversation: I consider it reasonable to not have 12146 (so I won't be too upset if it doesn't get in), but not quite so reasonable to reject it for no reason (so I will be disappointed).
10362018-01-11T20:02:32 <gmaxwell> achow101: one of the concerns we had with the design we used here is we chose a design where it will sometimes work... and this may encourage someone to try it with the belief that it always works.
10372018-01-11T20:03:09 <gmaxwell> achow101: which is unfortunate, but no option was great.
10382018-01-11T20:03:30 <luke-jr> btw, if someone can quickly unlock #11403 for conversation, I'd like to Post-merge utACK it
10392018-01-11T20:03:35 <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
10402018-01-11T20:03:52 <meshcollider> Yeah why can't all members comment on locked PRs/issues
10412018-01-11T20:04:06 <achow101> meshcollider: you need to have write access to the repo
10422018-01-11T20:04:11 <achow101> which means you could commit
10432018-01-11T20:04:12 <gmaxwell> achow101: and an opt out knob really doesn't educate people more: The issue with it working at all is people incorrectly thinking that they can do it and people can collect their funds simply by upgrading. Adding a knob would make it so that they falsely believed people could collect their funds simply by flipping the knob back.
10442018-01-11T20:04:24 <gmaxwell> achow101: when in reality some people are still using uncompressed keys...
10452018-01-11T20:04:28 <BlueMatt> luke-jr: lol no? outcome is consider it as-is unreasonable, but if you want to fix the broader issue, sounds great!
10462018-01-11T20:04:43 <gmaxwell> meshcollider: github sucks.
10472018-01-11T20:04:51 <achow101> gmaxwell: oh yeah, uncompressed keys. that would be a problem
10482018-01-11T20:04:59 <gmaxwell> achow101: or HSMs.
10492018-01-11T20:05:07 <achow101> lol, armory has that problem...
10502018-01-11T20:05:18 <gmaxwell> Someone could have their key potted in a hardware device where it can never be exported.. and which can't sign segwit style.
10512018-01-11T20:07:11 <gmaxwell> when we talked about our style of segwit support, the concern was raised that because conversion would sometimes work it might cause fools and madmen to think it always works... Unfortunately, we didn't really have any good alternative for segwit support. Among other reasons backwards supporting the addwitnessaddress stuff more or less required us to go this route for now.
10522018-01-11T20:09:49 <gmaxwell> also geesh, please don't call someone manipulating your address malleation.
10532018-01-11T20:10:17 <wumpus> bitcoiners like to overload words with as many as possible different meanings
10542018-01-11T20:10:17 <gmaxwell> We already have far too many morons out there confused due to existing reuse of the word.
10552018-01-11T20:10:35 <luke-jr> gmaxwell: what do we call it then?
10562018-01-11T20:11:02 <luke-jr> mutilation? :p
10572018-01-11T20:11:42 <gmaxwell> Conversion? I dunno. though the surrounding issues could also arise without any conversion.
10582018-01-11T20:12:36 <gmaxwell> For example, a wallet could plausably not scan for any change outputs because it knows all that it creates. If I go find one of your prior change addresses and pay it there is no reason to think the wallet would ever see it. ... and in existing software (e.g. bitcoin core) the payment wouldn't show up even if it did see the funds.
10592018-01-11T20:12:38 <meshcollider> Hmm achow101 all branches are protected so then write access still does not allow members to push to them without explicit permission right?
10602018-01-11T20:13:08 <wumpus> meshcollider: correct
10612018-01-11T20:13:37 <achow101> meshcollider: oh!
10622018-01-11T20:13:47 <gmaxwell> luke-jr: AFAIK there is no common term for "someone attempted to 'pay me' by digging a hole in by back yard and leaving an envelope of money in it"... because outside of bitcoin no one is that @#$@# stupid. :)
10632018-01-11T20:13:48 *** Brandt13Hartmann has joined #bitcoin-core-dev
10642018-01-11T20:14:12 <luke-jr> gmaxwell: conversion is too innocent-sounding IMO
10652018-01-11T20:14:25 <achow101> write access means you can also tag things
10662018-01-11T20:14:26 <instagibbs> gmaxwell, IsChange logic is also kind loopy...
10672018-01-11T20:14:33 <luke-jr> anyway, gotta run
10682018-01-11T20:15:10 <cfields> out of curiosity, how to handle this with segwit v1? enforce incompatibility with all previous witness versions?
10692018-01-11T20:15:41 <sipa> cfields: have split chains first
10702018-01-11T20:15:48 <gmaxwell> every address type should be its own chain.
10712018-01-11T20:15:53 <sipa> that ^
10722018-01-11T20:16:06 <gmaxwell> so you just wouldn't see such a payment.
10732018-01-11T20:16:43 <cfields> right, ok
10742018-01-11T20:16:45 *** AaronvanW has joined #bitcoin-core-dev
10752018-01-11T20:16:49 <meshcollider> achow101: that could be a benefit :) but no I guess write access is too potent still
10762018-01-11T20:16:59 <gmaxwell> that would have been the prefered path for segwit wallet support, but it requires much more major changes _AND_ isn't compatible with the addwitness stuff people were already doing.
10772018-01-11T20:17:22 <gmaxwell> meshcollider: part of the problem with that too is that github might randomly stir what 'write access' could do at any time.
10782018-01-11T20:18:02 <meshcollider> gmaxwell: mhm true, the permission system doesn't seem very flexible
10792018-01-11T20:18:15 <cfields> petertod1: ping. Is there any canonical format for an opentimestamps proof?
10802018-01-11T20:18:52 <gmaxwell> github in general has a lot of anti features.
10812018-01-11T20:20:17 <gmaxwell> there was some thread on reddit where one group of ignorant people was screaming at another group of ignorant people with at claim that 0.16 wouldn't be out for a year because some random and usless github milestone "percentage" page said such and such.
10822018-01-11T20:20:23 *** machaans has quit IRC
10832018-01-11T20:20:50 <meshcollider> Heh
10842018-01-11T20:21:28 *** promag has quit IRC
10852018-01-11T20:22:09 *** owowo has quit IRC
10862018-01-11T20:22:53 <provoostenator> gmaxwell: I really like Github's code review UI, except that it doesn't email the full thread if someone says "fixed" in response to inline comment.
10872018-01-11T20:23:12 *** Deacyde has joined #bitcoin-core-dev
10882018-01-11T20:23:25 <gmaxwell> the code review has gotten better at least.
10892018-01-11T20:23:26 *** goatpig has joined #bitcoin-core-dev
10902018-01-11T20:23:35 <provoostenator> Github also completely breaks down if a PR or issue becomes political.
10912018-01-11T20:24:19 <gmaxwell> not just 'political' but linked to on any part of the internet mostly populated by idiots.
10922018-01-11T20:24:31 <provoostenator> It was almost impossible to have a sane discussion about replay protection on the btc1 repo; you'd have 3 people making serious arguments and 100 ranting comments from others, including from people who do write code.
10932018-01-11T20:24:35 <gmaxwell> god help anyone who gets their repository linked in a youtube comment.
10942018-01-11T20:24:50 *** Deacydal has quit IRC
10952018-01-11T20:25:17 <provoostenator> I suppose "political" is a euphemism for "linked to on any part of the internet mostly populated by idiots"
10962018-01-11T20:25:18 <Chris_Stewart_5> lol
10972018-01-11T20:25:38 <gmaxwell> They're highly correlated at least. :)
10982018-01-11T20:26:08 <provoostenator> I sometimes tweet out PR's; haven't seen too negative results for the Core ones, but I would think twice doing that for anything contentious.
10992018-01-11T20:28:31 <gmaxwell> I'm not sure about any of your tweets, but sometimes it does.
11002018-01-11T20:28:58 <gmaxwell> e.g. the announcements re the merge of the segwit PR inspired a half dozen really nasty comments on that PR (which people just deleted)
11012018-01-11T20:29:17 *** anome has joined #bitcoin-core-dev
11022018-01-11T20:30:03 *** owowo has joined #bitcoin-core-dev
11032018-01-11T20:30:57 *** Brandt13Hartmann has quit IRC
11042018-01-11T20:33:42 <provoostenator> I only have 1.5K followers and anyone who SegWit has probably unfollowed me by now.
11052018-01-11T20:33:57 *** dcousens has quit IRC
11062018-01-11T20:33:57 <provoostenator> *who hates
11072018-01-11T20:34:26 *** dcousens has joined #bitcoin-core-dev
11082018-01-11T20:37:11 *** anome has quit IRC
11092018-01-11T20:37:53 <provoostenator> gmaxwell: I'm guessing from the replies it was this tweet that attracted those folks: https://twitter.com/theonevortex/status/951479475908194304
11102018-01-11T20:38:15 *** hitesh8791 has joined #bitcoin-core-dev
11112018-01-11T20:38:26 *** owowo has quit IRC
11122018-01-11T20:39:13 *** hitesh8791_ has joined #bitcoin-core-dev
11132018-01-11T20:43:04 *** hitesh8791 has quit IRC
11142018-01-11T20:43:29 <bitcoin-git> [bitcoin] kekimusmaximus opened pull request #12159: Use the character based overload for std::string::find. (master...use_char_overload_find) https://github.com/bitcoin/bitcoin/pull/12159
11152018-01-11T20:43:36 *** owowo has joined #bitcoin-core-dev
11162018-01-11T20:43:36 *** owowo has joined #bitcoin-core-dev
11172018-01-11T20:43:36 *** owowo has joined #bitcoin-core-dev
11182018-01-11T20:43:39 *** hitesh8791_ has quit IRC
11192018-01-11T20:46:49 *** promag has joined #bitcoin-core-dev
11202018-01-11T20:49:23 <gmaxwell> I probably should have brought up #11739 during the meetings.
11212018-01-11T20:49:25 <gribble> https://github.com/bitcoin/bitcoin/issues/11739 | RFC: Enforce SCRIPT_VERIFY_P2SH and SCRIPT_VERIFY_WITNESS from genesis by sdaftuar · Pull Request #11739 · bitcoin/bitcoin · GitHub
11222018-01-11T20:58:06 <promag> late suggestion, but how about -changetype=auto? (being that the default)
11232018-01-11T21:04:38 *** flokie has joined #bitcoin-core-dev
11242018-01-11T21:08:30 *** AaronvanW has quit IRC
11252018-01-11T21:09:10 *** mrannanay has quit IRC
11262018-01-11T21:10:27 *** Chris_Stewart_5 has quit IRC
11272018-01-11T21:13:49 *** Juana5Kunde has joined #bitcoin-core-dev
11282018-01-11T21:16:48 *** Chenpan has quit IRC
11292018-01-11T21:17:05 *** jtimon has quit IRC
11302018-01-11T21:17:24 *** AaronvanW has joined #bitcoin-core-dev
11312018-01-11T21:18:05 *** CubicEarths has joined #bitcoin-core-dev
11322018-01-11T21:22:55 *** Juana5Kunde has quit IRC
11332018-01-11T21:30:13 <BlueMatt> jonasschnelli: I think you broke on rebase of #11281 - you deleted the pwallet->UpdateTimeFirstKey(1); call in importprivkey
11342018-01-11T21:30:17 <gribble> https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
11352018-01-11T21:30:30 *** mike_28 has joined #bitcoin-core-dev
11362018-01-11T21:35:45 * BlueMatt is of the opinion #12118 can be merged
11372018-01-11T21:35:47 <gribble> https://github.com/bitcoin/bitcoin/issues/12118 | Sort mempool by min(feerate, ancestor_feerate) by sdaftuar · Pull Request #12118 · bitcoin/bitcoin · GitHub
11382018-01-11T21:37:29 <instagibbs> provoostenator, I think we have different definitions of actionable, haha
11392018-01-11T21:44:28 *** jtimon has joined #bitcoin-core-dev
11402018-01-11T21:48:55 *** quitobro has joined #bitcoin-core-dev
11412018-01-11T21:56:20 <sipa> instagibbs: is "cheaper" actionable? (just trying to understand your definition)
11422018-01-11T21:56:24 *** mike_28 has quit IRC
11432018-01-11T21:58:11 *** Victorsueca has quit IRC
11442018-01-11T21:59:21 *** Victorsueca has joined #bitcoin-core-dev
11452018-01-11T22:02:05 *** Krellan has quit IRC
11462018-01-11T22:03:00 *** Krellan has joined #bitcoin-core-dev
11472018-01-11T22:03:58 *** clarkmoody_ has joined #bitcoin-core-dev
11482018-01-11T22:04:03 <instagibbs> sipa, of course it is, but the comment was about privacy(which we agree users won't be able to act on)
11492018-01-11T22:05:52 <sipa> instagibbs: i'm confused
11502018-01-11T22:06:16 <sipa> instagibbs: how is "cheaper" actionable but "better privacy" isn't?
11512018-01-11T22:06:44 <instagibbs> the language says "may" or somesuch, and if the user googles, or whatever, they'll find nothing. I *guess* the could just get scared and never set it.
11522018-01-11T22:06:54 <instagibbs> so I take it back, whatever, it's just a super verbose message imo
11532018-01-11T22:06:56 *** clarkmoody has quit IRC
11542018-01-11T22:07:20 <sipa> instagibbs: oh no disagreement that it's too verbose
11552018-01-11T22:07:53 <instagibbs> also if uptake is quick(doubt, but possible) that users will be confronted with the message and go the wrong direction
11562018-01-11T22:08:25 <instagibbs> i think release notes might be the best place
11572018-01-11T22:14:06 *** Monique75Upton has joined #bitcoin-core-dev
11582018-01-11T22:14:37 <bitcoin-git> [bitcoin] jnewbery opened pull request #12166: [docs] Clarify -walletdir usage (master...clarify_walletdir_usage) https://github.com/bitcoin/bitcoin/pull/12166
11592018-01-11T22:18:49 *** Monique75Upton has quit IRC
11602018-01-11T22:19:08 *** goatpig has quit IRC
11612018-01-11T22:20:34 <sipa> instagibbs: agree
11622018-01-11T22:21:18 *** quitobro has quit IRC
11632018-01-11T22:28:13 <promag> block index skiplist and GetAncestor don't require any lock right? it's computed before a blockindex is given out?
11642018-01-11T22:28:23 *** arbitrary_guy has joined #bitcoin-core-dev
11652018-01-11T22:29:13 *** cheese_ has joined #bitcoin-core-dev
11662018-01-11T22:32:11 <sipa> promag: indeed
11672018-01-11T22:32:29 <sipa> every CBlockIndex has those permanently set
11682018-01-11T22:32:30 <promag> ty
11692018-01-11T22:36:12 *** unholymachine has quit IRC
11702018-01-11T22:36:18 *** cheese_ has quit IRC
11712018-01-11T22:36:44 *** unholymachine has joined #bitcoin-core-dev
11722018-01-11T22:37:13 *** quitobro has joined #bitcoin-core-dev
11732018-01-11T22:39:08 *** AaronvanW has quit IRC
11742018-01-11T22:39:42 *** belcher_ has joined #bitcoin-core-dev
11752018-01-11T22:42:52 *** quitobro has quit IRC
11762018-01-11T22:43:09 <BlueMatt> promag: re: #11041: why do you want to use LookupBlockIndex inside CChainState?
11772018-01-11T22:43:11 <gribble> https://github.com/bitcoin/bitcoin/issues/11041 | Add LookupBlockIndex by promag · Pull Request #11041 · bitcoin/bitcoin · GitHub
11782018-01-11T22:43:21 <promag> BlueMatt: hold on there
11792018-01-11T22:43:27 <promag> I'll make it const
11802018-01-11T22:43:36 <BlueMatt> please dont do that in the same pr :(
11812018-01-11T22:43:43 <BlueMatt> dont really want to delay it further
11822018-01-11T22:43:49 <promag> and in validation.cpp just use mapBlockIndex directly
11832018-01-11T22:43:50 <BlueMatt> unless you want to make things more scripted-diff...
11842018-01-11T22:43:59 <BlueMatt> no, not validation.cpp, CChainState
11852018-01-11T22:44:10 <BlueMatt> outside of CChainState should all be const CBlockIndex, even in validation.cpp
11862018-01-11T22:44:17 <BlueMatt> but that may not be trivially possible quite yet
11872018-01-11T22:45:23 <BlueMatt> promag: you saw my outstanding pr to constify them with scritped-diffs, right? You're welcome to replace it if you want, but no use duplicating effort wholesale...
11882018-01-11T22:45:34 *** cheese_ has joined #bitcoin-core-dev
11892018-01-11T22:45:51 *** AaronvanW has joined #bitcoin-core-dev
11902018-01-11T22:46:13 <BlueMatt> promag: also, generally, that pr is already one giant commit that does like 3 things....please try to script what you can and cut it down
11912018-01-11T22:46:24 <promag> +1
11922018-01-11T22:47:20 *** tknp has joined #bitcoin-core-dev
11932018-01-11T22:50:25 *** niska has quit IRC
11942018-01-11T22:51:26 <promag> curiosity, an off chain block could have 0 confirmations, why -1?
11952018-01-11T22:51:27 *** nullptr| has quit IRC
11962018-01-11T22:51:41 *** cheese_ has quit IRC
11972018-01-11T22:51:57 *** booyah has quit IRC
11982018-01-11T22:52:03 *** Lauda has quit IRC
11992018-01-11T22:52:20 *** niska has joined #bitcoin-core-dev
12002018-01-11T22:52:58 *** nullptr| has joined #bitcoin-core-dev
12012018-01-11T22:53:51 *** Lauda has joined #bitcoin-core-dev
12022018-01-11T22:53:57 *** instagibbs has quit IRC
12032018-01-11T22:55:05 *** kakobrekla has quit IRC
12042018-01-11T22:55:35 *** dcousens has quit IRC
12052018-01-11T22:57:02 *** instagibbs has joined #bitcoin-core-dev
12062018-01-11T22:58:31 *** kakobrekla has joined #bitcoin-core-dev
12072018-01-11T22:58:59 *** wraithm has quit IRC
12082018-01-11T23:01:05 *** Guyver2 has quit IRC
12092018-01-11T23:10:39 *** Chris_Stewart_5 has joined #bitcoin-core-dev
12102018-01-11T23:14:03 *** Michaela63Kassul has joined #bitcoin-core-dev
12112018-01-11T23:16:50 *** booyah has joined #bitcoin-core-dev
12122018-01-11T23:19:26 *** JackH has quit IRC
12132018-01-11T23:31:55 *** MarcoFalke has quit IRC
12142018-01-11T23:36:31 *** esparragow has joined #bitcoin-core-dev
12152018-01-11T23:37:49 *** esparragow has quit IRC
12162018-01-11T23:40:49 *** Michaela63Kassul has quit IRC
12172018-01-11T23:52:56 <promag> gmaxwell: "it's a mistake to say "bech32" -- there is no address involved with change"
12182018-01-11T23:53:54 <promag> listunspent includes changes right? what will be "address" for change utxo?
12192018-01-11T23:56:09 <sipa> yes, bech32
12202018-01-11T23:56:32 <gmaxwell> promag: you're missing my point. One can use scripts which no address can be defined.
12212018-01-11T23:56:38 <gmaxwell> er s/can be/is/
12222018-01-11T23:56:51 <sipa> but if bech32 didn't exist, there would just be no way to show an address for such outputs, but they would have been totally possible to use
12232018-01-11T23:56:59 <gmaxwell> And if there were no bech32 defined we still could be using p2wpkh as change.
12242018-01-11T23:57:15 <gmaxwell> The fact that there is an address is incidental.
12252018-01-11T23:57:59 <gmaxwell> There are also other address encodings for that same script, e.g. BIP142 (though hopefully no one uses them)
12262018-01-11T23:58:40 <sipa> for certain types of addresses there even exist no address that can be derived from the output (e.g. ECDH based constructions like stealth addresses or CT)
12272018-01-11T23:59:17 *** larafale has quit IRC
12282018-01-11T23:59:18 <sipa> listunspent would just be unable to show an address for such outputs