12021-03-17T02:56:58  *** stortz <stortz!c8b9cbcf@200.185.203.207> has quit IRC (Quit: Connection closed)
  22021-03-17T04:19:04  *** belcher_ <belcher_!~belcher@unaffiliated/belcher> has joined ##taproot-bip-review
  32021-03-17T04:22:45  *** belcher <belcher!~belcher@unaffiliated/belcher> has quit IRC (Ping timeout: 264 seconds)
  42021-03-17T04:48:44  *** shesek` <shesek`!~shesek@164.90.217.137> has joined ##taproot-bip-review
  52021-03-17T04:52:50  *** shesek <shesek!~shesek@unaffiliated/shesek> has quit IRC (Ping timeout: 264 seconds)
  62021-03-17T04:54:29  *** meshcollider <meshcollider!meshcollid@gateway/shell/ircnow/x-irngybgfmgpzypua> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in)
  72021-03-17T05:00:35  *** jonatack_ <jonatack_!~jon@37.171.42.2> has quit IRC (Ping timeout: 256 seconds)
  82021-03-17T05:09:47  *** meshcollider <meshcollider!meshcollid@gateway/shell/ircnow/x-qcfpgmsncdtvtiio> has joined ##taproot-bip-review
  92021-03-17T09:05:31  *** stortz <stortz!c8b9cbcf@200.185.203.207> has joined ##taproot-bip-review
 102021-03-17T09:55:26  *** belcher_ <belcher_!~belcher@unaffiliated/belcher> has quit IRC (*.net *.split)
 112021-03-17T10:03:22  *** belcher_ <belcher_!~belcher@unaffiliated/belcher> has joined ##taproot-bip-review
 122021-03-17T10:09:23  *** Teleportando <Teleportando!8eb30758@d142-179-7-88.bchsia.telus.net> has quit IRC (Ping timeout: 240 seconds)
 132021-03-17T12:38:00  *** belcher_ is now known as belcher
 142021-03-17T12:57:46  *** kabaum <kabaum!~kabaum@h-13-35.A163.priv.bahnhof.se> has joined ##taproot-bip-review
 152021-03-17T13:04:13  *** jonatack_ <jonatack_!~jon@37.169.45.97> has joined ##taproot-bip-review
 162021-03-17T13:28:31  *** jonatack_ <jonatack_!~jon@37.169.45.97> has quit IRC (Quit: jonatack_)
 172021-03-17T13:28:53  *** jonatack <jonatack!~jon@37.169.45.97> has joined ##taproot-bip-review
 182021-03-17T14:14:30  *** shesek`` <shesek``!~shesek@164.90.217.137> has joined ##taproot-bip-review
 192021-03-17T14:15:16  *** shesek` <shesek`!~shesek@164.90.217.137> has quit IRC (Remote host closed the connection)
 202021-03-17T14:36:33  *** shesek` <shesek`!~shesek@164.90.217.137> has joined ##taproot-bip-review
 212021-03-17T14:37:11  *** shesek`` <shesek``!~shesek@164.90.217.137> has quit IRC (Remote host closed the connection)
 222021-03-17T15:06:51  *** stortz <stortz!c8b9cbcf@200.185.203.207> has quit IRC (Quit: Connection closed)
 232021-03-17T16:25:09  *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has quit IRC (Remote host closed the connection)
 242021-03-17T16:26:30  *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has joined ##taproot-bip-review
 252021-03-17T16:26:31  *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has quit IRC (Client Quit)
 262021-03-17T17:02:54  <real_or_random> it's true that a lot of comments in this debate are handwaving and (to me) surprisingly superficial. that's usually not the depth on which the community debates technical issues
 272021-03-17T17:04:31  <real_or_random> (which does not mean that the comments are wrong. it
 282021-03-17T17:05:53  <real_or_random> I think a lot of people would agree that we should do research into a transition to post-quantum crypto. it's just currently not in the focus of many people
 292021-03-17T17:12:39  <real_or_random> I think it's reasonable to discuss ideas like the one mentioned by jeremyrubin now. I don't think it's reasonable to look into concrete post-quantum signatures now. There's still a lot of research in this area and we hopefully see some improvements
 302021-03-17T17:13:29  <maaku> real_or_random: the question for now is not whether we should do R&D into post-quantum crypto (I think everyone agrees we should), but whether bitcoin needs to be more defensive now in mitigating quantum crypto breaks
 312021-03-17T17:14:57  <real_or_random> you mean whether we should keep QC in mind when we change the system now?
 322021-03-17T17:15:17  <belcher> theres also a question of whether hashing pubkeys would actually work, is that really a method of post-quantum? is it worth the cost of extra bytes on the blockchain and losing the ability to do certain privacy things
 332021-03-17T17:17:18  <real_or_random> If you ask me, then it's a strong yes. We should be careful what we do now and evaluate what it will mean for a PQ world.
 342021-03-17T17:18:52  <real_or_random> but then if you ask me to do this evaluation, then the conclusion is that Bitcoin  without Taproot is broken if there's a quantum attacker. And Bitcoin is broken with Taproot if there's a quantum attacker
 352021-03-17T17:21:35  <real_or_random> belcher: Yep indeed. That's one of the hand waving parts. There seem to be a widespread belief that hashing pubkeys helps Bitcoin a PQ world.
 362021-03-17T17:22:11  <real_or_random> and that's just not true -- at least it's certainly not that simple.
 372021-03-17T17:22:38  <maaku> belcher: I'm not sure what you mean by "a question of whether hashing pubkeys would work"
 382021-03-17T17:24:03  <maaku> I know of no reason why a hashed pubkey--where the user treats the pubkey as key material--is not PQ secure
 392021-03-17T17:24:50  <maaku> the only two arguments against this I've seen are (1) the spending tx is vulnerable while it awaits confirmation, and (2) people share pubkeys
 402021-03-17T17:25:52  <maaku> (1) is a question of how fast, reliable, and expensive to produce early QC will be, and to some extent we just don't know
 412021-03-17T17:26:12  <maaku> [but not knowing for sure is not a good reason to avoid mitigating some possible outcomes]
 422021-03-17T17:27:08  <maaku> (2) is not a fixed aspect of the protocol. yes people reuse keys or share pubkeys with SPV servers & watchtowers. but we can design and transition to safer protocols where this is not done
 432021-03-17T17:29:47  <maaku> So if what you're saying is that "hashing pubkeys don't help Bitcoin in a PQ world because the pubkey ends up getting shared anyway" then my point is that with hashed pubkeys we have the option of be more careful with sharing pubkeys, but with naked pubkeys (e.g. Taproot) we do not have that option
 442021-03-17T17:30:31  *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has joined ##taproot-bip-review
 452021-03-17T17:32:21  <real_or_random> maaku: I keep pointing out that (1) is not even an issue in the end. We don't need to race with the attacker, there's a somewhat ugly but working two-step scheme that avoids the race ( https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015758.html )
 462021-03-17T17:34:45  <real_or_random> But I believe that (2) does not work out as you imagine it. People (and wallets) will up screw and not manage to keep pubkeys private even if they try
 472021-03-17T17:36:11  <real_or_random> And then yes, people do share and reuse pubkeys. So great that some UTXOs are protected. But it doesn't really help when others are not protected
 482021-03-17T17:36:26  *** lucasmoten__ <lucasmoten__!~lucasmote@136.144.35.169> has joined ##taproot-bip-review
 492021-03-17T17:37:52  <real_or_random> (This reminds me a little bit of the replace-by-fee debate with the two sides: 1) replace-by-fee makes it worse for people who accept zero-conf transactions and 2) zero-conf is not secure anyway -- not saying it's equivalent but it's similar)
 502021-03-17T17:37:58  <maaku> I'm not saying it will be easy.  Like avoiding key reuse, it's a public education thing that will require a lot of effort and you won't get everyone
 512021-03-17T17:38:42  <belcher> but if it fails then bitcoin fails, and we would have added extra data to the blockchain and stopped privacy tech like snicker and ring signatures from working for nothing
 522021-03-17T17:38:47  <maaku> But you don't need to get every single person to have proper key hygine. You just need to reduce the exposure from 50+% to maybe 15% or so
 532021-03-17T17:38:57  *** lucasmoten_ <lucasmoten_!~lucasmote@136.144.35.169> has quit IRC (Ping timeout: 264 seconds)
 542021-03-17T17:39:44  <belcher> there also the issue of how are things like payment channels and multisig custody meant to work without exposing pubkeys
 552021-03-17T17:39:52  <maaku> And (critically imho) get custodial infrastructure to move to PQ-secure key management protocol, which is easier because it's a countable number of big players
 562021-03-17T17:40:20  <real_or_random> with pubkeys publicly available, at least the situation is clear for everyone. If there's a quantum attacker, then the system is broken. In fact this could incentivize people to move their UTXOs to PQ (once it's in the protocol)
 572021-03-17T17:40:49  <maaku> belcher: a mistake I think you and BlueMatt and a few others are making is assuming that any pubkey sharing is automatically equivalent to Taproot's pubkey-in-the-utxoset
 582021-03-17T17:41:21  <belcher> why is that a mistake? say you open a payment channel with someone, but you're unlucky and they also run a quantum computer and so steal your money
 592021-03-17T17:41:30  <maaku> With LN for example, only the participants of a channel have a fundamental need to know the pubkeys. Everyone else finds out on channel closure
 602021-03-17T17:41:41  <luke-jr> belcher: so they steal your funds, not everyone's..
 612021-03-17T17:41:58  <belcher> luke-jr in other words lightning just stops working in a post-quantum world
 622021-03-17T17:42:17  <belcher> of course you can fix it, but you can fix anything by adopting PQ crypto so lets just do that
 632021-03-17T17:42:25  <maaku> sure. and "not having LN" != "everyone's coins stolen"
 642021-03-17T17:42:32  <luke-jr> belcher: *everything* just stops working in a PQ world
 652021-03-17T17:42:47  <belcher> luke-jr yep, thats my point, so why are holding up taproot for this?
 662021-03-17T17:42:48  <queip> lamport master race unaffected
 672021-03-17T17:42:50  <luke-jr> "no longer working" != "everyone's coins stolen"
 682021-03-17T17:42:58  <luke-jr> queip: no lamport in Bitcoin
 692021-03-17T17:43:13  <belcher> no longer working means no transactions and no miner fees paid to miners
 702021-03-17T17:43:17  <belcher> so bitcoin just stops really
 712021-03-17T17:43:28  <real_or_random> well that's a somewhat terrible form of security to hope that noone who knows your key will steal your money. ^^ I wouldn't want to have my money in this system
 722021-03-17T17:43:31  <belcher> even if your coins arent stolen on paper they are still frozen and useless to you
 732021-03-17T17:43:37  <luke-jr> miners could keep mining actually
 742021-03-17T17:43:37  <queip> acthuaaaaaaaly, couldn't a smart contract be written to require lamport signature? hmm
 752021-03-17T17:43:45  <maaku> And it's not the case that LN stops working, it just becomes more like ripplepay where you have to know and trust who you're entering a channel with.
 762021-03-17T17:44:00  <luke-jr> real_or_random: or just don't give anyone your key…
 772021-03-17T17:44:12  <maaku> But that trust doesn't go further than the next hop
 782021-03-17T17:44:16  <belcher> luke-jr miners would receive inflation coins, but they wouldnt be able to sell them anywhere, no transactions remember
 792021-03-17T17:44:29  <luke-jr> belcher: until PQ fix is deployed
 802021-03-17T17:44:35  <real_or_random> luke-jr: ok but then I can't use payment channels. not great either
 812021-03-17T17:44:42  <belcher> in the meantime miners have to pay electricity bills luke-jr
 822021-03-17T17:44:56  <real_or_random> ( luke-jr: you mentioned a gdoc? I don't see any link)
 832021-03-17T17:44:58  <luke-jr> real_or_random: nobody said it was great
 842021-03-17T17:45:18  <belcher> i think we all agree that post-quantum is a dark world, what we disagree about is whether its worthwhile blocking taproot over this
 852021-03-17T17:45:29  <luke-jr> real_or_random: meant that for the activation channel, sry
 862021-03-17T17:45:35  <belcher> blocking taproot and losing out on privacy tech like snicker and ring signatures*
 872021-03-17T17:46:14  <luke-jr> belcher: I don't agree with blocking Taproot over it
 882021-03-17T17:46:36  <belcher> then we agree :)
 892021-03-17T17:46:57  <real_or_random> a probably naive point: in fact noone is forced to use Taproot
 902021-03-17T17:47:30  <luke-jr> real_or_random: it's not nice to tell people "lose QC-resistance, or you don't get new features" either tho
 912021-03-17T17:47:33  <queip> belcher:  luke-jr  (victorious moment)  https://static.wikia.nocookie.net/mspaintadventures/images/0/00/Victorious_Moment.gif/revision/latest/scale-to-width-down/500?cb=20111104001229
 922021-03-17T17:48:27  <real_or_random> luke-jr: fully agree! my point is: but isn't that the same as telling people they shouldn't share their pubkey?
 932021-03-17T17:48:58  <luke-jr> real_or_random: rather, if you do, the consequences are your problem :P
 942021-03-17T17:49:02  <real_or_random> "lose QC resistance or you don't get LN" (with or without taproot...)
 952021-03-17T17:49:24  <luke-jr> real_or_random: option 3 ("only have trusted peers on LN") is also available
 962021-03-17T17:50:00  <real_or_random> right ok. but if you want trusted peers, we have probably more efficient systems ^^
 972021-03-17T17:50:07  <luke-jr> also, even with untrusted peers, your potential attacker set is much less than with public pubkeys
 982021-03-17T17:50:31  <luke-jr> real_or_random: using the same LN system makes you interoperable with non-trusted sends/receives
 992021-03-17T17:50:37  <maaku> real_or_random: I do think that is a naive point. Like segwit, taproot has a lot of ancillary benefits. It will be the new standard.
1002021-03-17T17:51:10  <maaku> And indeed part of the messaging around taproot is the privacy achieved by making all outputs look the same, which only happens if all outputs are taproot ;)
1012021-03-17T17:51:19  <luke-jr> there's also a middle ground between trusted and untrusted peers: you might just have peers you know the identity of, so you can sue if they rob yoyu
1022021-03-17T17:51:58  <maaku> But for example there are tons of people who want to move to Schnorr for lower fees and better protocols in multikey setups. It sucks that they're forced to put their pubkeys on chain.
1032021-03-17T17:52:12  <maaku> luke-jr: right. that's the ripplepay security model
1042021-03-17T17:52:25  <luke-jr> finally, you might be okay with risking 1% of your holdings in LN, while you want to keep the other 99% safe
1052021-03-17T17:52:33  <maaku> which lets ripplepay use IOUs instead of collateral
1062021-03-17T17:53:16  <luke-jr> which is probably the model I will personally use for Taproot (use it only for LN hot wallet, while my cold wallet remains p2pkh)
1072021-03-17T17:53:27  *** jonatack <jonatack!~jon@37.169.45.97> has quit IRC (Ping timeout: 265 seconds)
1082021-03-17T17:53:32  <belcher> taproot UTXOs cost exactly the same in bytes as p2wpkh single-sig, so many people have predicted that adoption wont be very fast at all
1092021-03-17T17:54:05  <luke-jr> I wonder if Taproot can be "sold" as a block size reduction without the actual size reduction/costs :P
1102021-03-17T17:54:23  <maaku> luke-jr: for super-long duration, consider p2wsh for the larger hash width
1112021-03-17T17:54:27  <belcher> it already is in many ways, like with the batch validation
1122021-03-17T17:54:30  *** jonatack <jonatack!~jon@37.169.45.97> has joined ##taproot-bip-review
1132021-03-17T17:54:31  <luke-jr> if it's significantly more efficient, it would reduce the CPU time even if not actual bytes
1142021-03-17T17:55:19  <maaku> nitpick, you don't need taproot for batch validation
1152021-03-17T17:55:25  <maaku> but yeah it has been sold that way
1162021-03-17T17:57:34  <maaku> maybe it's not obvious, but what I mean is that it could be a consensus rule that a block commits to which pubkeys are valid
1172021-03-17T17:57:37  <real_or_random> indeed, P2PKH with Schnorr sigs would also work for batch validation
1182021-03-17T17:57:41  <maaku> er, which signatures
1192021-03-17T17:57:50  <maaku> schnorr signatures are not needed
1202021-03-17T17:58:09  <real_or_random> maaku: ok can you elaborate? I don't understand
1212021-03-17T17:58:13  <luke-jr> but p2pkh doesn't support schnorr..
1222021-03-17T17:58:27  <maaku> real_or_random: ECDSA can be batch validated too
1232021-03-17T17:58:47  <maaku> the issue is not the signature scheme (although Schnorr's batch validation is easier to implement)
1242021-03-17T17:58:48  <real_or_random> luke-jr: bitcoin doesn't support schnorr either?
1252021-03-17T17:59:03  <maaku> but rather that bitcoin doesn't mandate that every signature be valid
1262021-03-17T17:59:13  <maaku> you can have a CHECKSIG NOT in a script
1272021-03-17T17:59:50  <maaku> and the design of CHECKMULTISIG does not specify which pubkeys go with which signatures, so the script verifier does trial-and-error checking
1282021-03-17T18:00:03  <maaku> but you could eliminate all of that
1292021-03-17T18:00:37  <maaku> (1) treat all CHECKSIG/CHECKMULTISIG as CHECKSIGVERIFY/CHECKMULTISIGVERIFY [maybe with a new tx.nVersion]
1302021-03-17T18:01:06  <maaku> (2) add a "hint" value which is a bitmask specifying which pubkeys to skip in CHECKMULTISIG
1312021-03-17T18:01:43  <maaku> the obvious place to put the hint field is the dummy value which gets popped off the stack in checkmultisig, but unfortunately Segwit prevents us from using that
1322021-03-17T18:02:47  <maaku> so instead you'd have to gather the hint values as extra out-of-band data and commit to them like the way blocks commit to witness data [unless someone can come up with another place to put the hint field in a witness]
1332021-03-17T18:03:09  <maaku> but if you did that, then you can batch validate ECDSA transactions just fine.
1342021-03-17T18:03:35  <luke-jr> just bump the witness version?
1352021-03-17T18:04:07  <belcher> if we're making soft forks and other changes to add batch validation to bitcoin, we may as well make a soft fork to add schnorr to also get batch validation
1362021-03-17T18:05:38  <real_or_random> maaku: this is part of BIP342 https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#design
1372021-03-17T18:05:39  <maaku> There's an implementation here: https://github.com/tradecraftio/tradecraft/pull/25
1382021-03-17T18:05:57  <real_or_random> (if we're talking about the same thing)
1392021-03-17T18:06:44  <maaku> real_or_random: yes I'm aware. what I'm saying is that you can do batch validation in regular old ECDSA-based CHECKMULTISIG as well
1402021-03-17T18:06:55  <real_or_random> and yeah, there are ECDSA batch validation schemes which I think are not as great as those for Schnorr sigs
1412021-03-17T18:07:16  <real_or_random> but I think noone in the discussion is opposing the Schnorr sig part of the softfork
1422021-03-17T18:07:27  <real_or_random> ok
1432021-03-17T19:53:56  *** mol_ <mol_!mol@gateway/vpn/protonvpn/molly> has joined ##taproot-bip-review
1442021-03-17T19:55:50  *** mol <mol!mol@gateway/vpn/protonvpn/molly> has quit IRC (Ping timeout: 264 seconds)
1452021-03-17T21:07:12  *** jonatack <jonatack!~jon@37.169.45.97> has quit IRC (Read error: Connection reset by peer)
1462021-03-17T21:07:39  *** jonatack <jonatack!~jon@37.169.45.97> has joined ##taproot-bip-review
1472021-03-17T21:49:04  *** jonatack_ <jonatack_!~jon@37.164.14.9> has joined ##taproot-bip-review
1482021-03-17T21:52:18  *** jonatack <jonatack!~jon@37.169.45.97> has quit IRC (Ping timeout: 246 seconds)
1492021-03-17T23:17:57  *** jonatack_ <jonatack_!~jon@37.164.14.9> has quit IRC (Ping timeout: 264 seconds)
1502021-03-17T23:22:43  *** mol_ <mol_!mol@gateway/vpn/protonvpn/molly> has quit IRC (Quit: Leaving)