12021-03-15T01:03:25 *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has quit IRC (Ping timeout: 256 seconds)
22021-03-15T01:05:26 *** stortz <stortz!c8b9cbcf@200.185.203.207> has quit IRC (Quit: Connection closed)
32021-03-15T01:55:35 *** dr_orlovsky <dr_orlovsky!~dr-orlovs@31.14.40.19> has quit IRC (Quit: ZNC 1.8.0 - https://znc.in)
42021-03-15T01:55:48 *** dr-orlovsky <dr-orlovsky!~dr-orlovs@31.14.40.19> has joined ##taproot-bip-review
52021-03-15T02:18:31 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Quit: ZNC - http://znc.sourceforge.net)
62021-03-15T02:20:56 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined ##taproot-bip-review
72021-03-15T04:02:14 *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has joined ##taproot-bip-review
82021-03-15T04:19:01 *** belcher_ <belcher_!~belcher@unaffiliated/belcher> has joined ##taproot-bip-review
92021-03-15T04:22:37 *** belcher <belcher!~belcher@unaffiliated/belcher> has quit IRC (Ping timeout: 276 seconds)
102021-03-15T05:05:42 *** mol <mol!mol@gateway/vpn/protonvpn/molly> has quit IRC (Remote host closed the connection)
112021-03-15T05:06:45 *** mol <mol!mol@gateway/vpn/protonvpn/molly> has joined ##taproot-bip-review
122021-03-15T05:07:12 *** mol <mol!mol@gateway/vpn/protonvpn/molly> has quit IRC (Remote host closed the connection)
132021-03-15T05:07:35 *** mol <mol!mol@gateway/vpn/protonvpn/molly> has joined ##taproot-bip-review
142021-03-15T08:46:57 *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has quit IRC (Ping timeout: 256 seconds)
152021-03-15T09:24:45 *** jonatack <jonatack!~jon@37.164.116.224> has joined ##taproot-bip-review
162021-03-15T09:28:39 *** kabaum <kabaum!~kabaum@h-13-35.A163.priv.bahnhof.se> has quit IRC (Quit: Leaving)
172021-03-15T09:55:41 *** mol_ <mol_!mol@gateway/vpn/protonvpn/molly> has joined ##taproot-bip-review
182021-03-15T09:58:24 *** mol <mol!mol@gateway/vpn/protonvpn/molly> has quit IRC (Ping timeout: 245 seconds)
192021-03-15T10:41:08 *** mol_ <mol_!mol@gateway/vpn/protonvpn/molly> has quit IRC (Quit: Leaving)
202021-03-15T11:35:21 *** jonatack <jonatack!~jon@37.164.116.224> has quit IRC (Ping timeout: 264 seconds)
212021-03-15T11:36:07 *** jonatack <jonatack!~jon@37.164.116.224> has joined ##taproot-bip-review
222021-03-15T11:36:28 *** jonatack <jonatack!~jon@37.164.116.224> has quit IRC (Read error: Connection reset by peer)
232021-03-15T11:36:58 *** jonatack <jonatack!~jon@37.164.116.224> has joined ##taproot-bip-review
242021-03-15T12:30:02 *** jonatack <jonatack!~jon@37.164.116.224> has quit IRC (Quit: jonatack)
252021-03-15T12:54:16 *** jonatack <jonatack!~jon@37.164.116.224> has joined ##taproot-bip-review
262021-03-15T14:23:28 *** jonatack <jonatack!~jon@37.164.116.224> has quit IRC (Read error: Connection reset by peer)
272021-03-15T14:23:56 *** jonatack <jonatack!~jon@37.164.116.224> has joined ##taproot-bip-review
282021-03-15T14:28:45 *** belcher_ is now known as belcher
292021-03-15T14:51:35 *** mol <mol!mol@gateway/vpn/protonvpn/molly> has joined ##taproot-bip-review
302021-03-15T14:57:12 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Quit: ZNC - http://znc.sourceforge.net)
312021-03-15T14:57:33 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined ##taproot-bip-review
322021-03-15T16:48:59 *** RusAlex <RusAlex!~Chel@unaffiliated/rusalex> has quit IRC (Ping timeout: 265 seconds)
332021-03-15T16:54:33 *** lukedashjr <lukedashjr!~luke-jr@unaffiliated/luke-jr> has joined ##taproot-bip-review
342021-03-15T16:57:09 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Ping timeout: 245 seconds)
352021-03-15T16:58:30 *** jonatack <jonatack!~jon@37.164.116.224> has quit IRC (Ping timeout: 246 seconds)
362021-03-15T16:58:48 *** lukedashjr is now known as luke-jr
372021-03-15T17:10:01 *** RusAlex_ <RusAlex_!~Chel@BSN-77-82-41.static.siol.net> has joined ##taproot-bip-review
382021-03-15T17:10:56 *** provoostenator_ <provoostenator_!~quassel@provoostenator.sprovoost.nl> has joined ##taproot-bip-review
392021-03-15T17:11:07 *** jonatack <jonatack!~jon@37.164.116.224> has joined ##taproot-bip-review
402021-03-15T17:14:03 *** provoostenator <provoostenator!~quassel@provoostenator.sprovoost.nl> has quit IRC (Ping timeout: 265 seconds)
412021-03-15T18:03:58 *** robert_spigler <robert_spigler!robertspig@gateway/shell/matrix.org/x-xaqdenlnphxppscx> has quit IRC (*.net *.split)
422021-03-15T18:05:10 *** robert_spigler <robert_spigler!robertspig@gateway/shell/matrix.org/x-xaqdenlnphxppscx> has joined ##taproot-bip-review
432021-03-15T18:08:01 *** robert_spigler <robert_spigler!robertspig@gateway/shell/matrix.org/x-xaqdenlnphxppscx> has quit IRC (Ping timeout: 265 seconds)
442021-03-15T18:08:04 *** amptwo <amptwo!segwitmatr@gateway/shell/matrix.org/x-ktvdpnpgzkfylprk> has quit IRC (Ping timeout: 241 seconds)
452021-03-15T18:18:27 *** jonatack_ <jonatack_!~jon@37.172.178.208> has joined ##taproot-bip-review
462021-03-15T18:19:41 *** jonatack_ <jonatack_!~jon@37.172.178.208> has quit IRC (Read error: Connection reset by peer)
472021-03-15T18:20:10 *** jonatack_ <jonatack_!~jon@37.172.178.208> has joined ##taproot-bip-review
482021-03-15T18:21:49 *** jonatack <jonatack!~jon@37.164.116.224> has quit IRC (Ping timeout: 260 seconds)
492021-03-15T18:38:01 *** amptwo <amptwo!segwitmatr@gateway/shell/matrix.org/x-qkvyvxbkyxdsaiae> has joined ##taproot-bip-review
502021-03-15T18:54:34 *** jeremyrubin <jeremyrubin!~jr@024-176-247-182.res.spectrum.com> has joined ##taproot-bip-review
512021-03-15T19:18:28 *** robert_spigler <robert_spigler!robertspig@gateway/shell/matrix.org/x-ynqouhvuqnikmhoj> has joined ##taproot-bip-review
522021-03-15T19:19:40 <michaelfolkson> Posting here (as off topic in original channel) https://freicoin.substack.com/p/why-im-against-taproot
532021-03-15T19:20:22 <michaelfolkson> There was a lot of discussion on unhashed public keys and future quantum resistance
542021-03-15T19:20:30 <michaelfolkson> eg https://bitcoin.stackexchange.com/questions/93047/could-taproot-create-larger-security-risks-or-even-hinder-future-protocol-adjust
552021-03-15T19:21:26 <michaelfolkson> So I don't think from a quick skim read there is anything that hasn't been discussed previously here but still may be an interesting read
562021-03-15T19:25:09 <maaku> It's correct that this isn't anything which hasn't been discussed previously, because I raised these concerns in 2019
572021-03-15T19:26:00 <maaku> But the point is more that I think these concerns are still inadequately addressed in the Taproot proposal, and I've seen nothing since then to convince me otherwise.
582021-03-15T19:26:18 *** jonatack_ <jonatack_!~jon@37.172.178.208> has quit IRC (Ping timeout: 245 seconds)
592021-03-15T19:27:49 <maaku> If anything, what's changed since then is clear demonstration of quantum computer technology (e.g. the quantum supremacy achieved a year ago)
602021-03-15T19:28:42 *** jonatack_ <jonatack_!jon@gateway/vpn/airvpn/jonatack> has joined ##taproot-bip-review
612021-03-15T19:30:56 <michaelfolkson> It would be a much weaker upgrade functionality wise if public keys were hashed. That is the only suggestion re quantum resistance?
622021-03-15T19:31:25 <michaelfolkson> (As I said I've only skim read so far)
632021-03-15T19:34:44 <maaku> There's much more that should be done to make bitcoin quantum secure, which I mention near the end.
642021-03-15T19:34:56 <maaku> But concerning Taproot, that's out of scope.
652021-03-15T19:35:05 <michaelfolkson> Right
662021-03-15T19:35:13 <maaku> My key concern is that it doesn't make the situation worse, which naked pubkeys does.
672021-03-15T19:35:32 <maaku> And really I don't think "it would be a much weaker upgrade functionality wise" is accurate.
682021-03-15T19:36:19 <maaku> 95% of the benefit of taproot is Schnorr, no? I don't think the fact you can shave off 32 bytes per input is a serious, compelling benefit. More like icing on the cake.
692021-03-15T19:37:07 <maaku> *Schnorr + MAST
702021-03-15T19:39:07 *** jonatack_ <jonatack_!jon@gateway/vpn/airvpn/jonatack> has quit IRC (Ping timeout: 256 seconds)
712021-03-15T19:40:21 *** jonatack_ <jonatack_!~jon@37.172.178.208> has joined ##taproot-bip-review
722021-03-15T19:56:41 <michaelfolkson> If you want to do math with the Schnorr public keys you can't do that math with hashes of the Schnorr public keys?
732021-03-15T19:57:11 <michaelfolkson> Isn't that the major feature they bring?
742021-03-15T19:58:25 <michaelfolkson> The space savings for single Schnorr sigs vs ECDSA sigs are small
752021-03-15T20:00:03 <luke-jr> IMO it'd make sense to add an optional hash layer, but I'm not sure it's worth halting everything for that. It can be added later..
762021-03-15T20:02:45 <maaku> michaelfolkson: there's literally not a single use for that in the consensus logic
772021-03-15T20:03:41 <maaku> it's purely a ancillary thing that lets you do things like compact ring signatures which prove you have *a* bitcoin without revealing which bitcoin
782021-03-15T20:03:55 <michaelfolkson> I think if you care that much about your public key being hashed you just keep to SegWit v0 and don't use v1. I don't think most people care about it until a point in time in the (possibly far) future where quantum is a concern
792021-03-15T20:04:33 <maaku> note I said "compact" -- you can use bulletproofs to do the same thing if it is behind a hash, but it'll be 10kB instead of 100B
802021-03-15T20:04:48 <michaelfolkson> maaku: Not in consensus logic. But uses, applications will be built on top. They can't be built on top if public keys are all hashed
812021-03-15T20:05:11 <maaku> there really aren't that many application use cases
822021-03-15T20:05:23 <maaku> feel free to point them out if you know any, but afaik there isn't
832021-03-15T20:05:37 <maaku> the ring signature thing is only semi-practical one I know of, and even that is kinda contrived
842021-03-15T20:06:03 <michaelfolkson> MuSig?
852021-03-15T20:06:23 <maaku> doesn't require naked pubkeys
862021-03-15T20:06:24 <michaelfolkson> PTLCs?
872021-03-15T20:07:03 <maaku> pltc?
882021-03-15T20:07:40 <michaelfolkson> Possible upgrade to Lightning. Replacing HTLCs with PTLCs (point timelocked contracts)
892021-03-15T20:07:48 <maaku> michaelfolkson: two points on just using the existing v0 outputs: (1) you can't do musig with Segwit v0, so if I want a simple multikey setup you need to use v1
902021-03-15T20:08:18 <maaku> afaik those don't require naked pubkeys either
912021-03-15T20:08:29 <maaku> maybe there's some confusion here?
922021-03-15T20:08:44 <maaku> you can share pubkeys with the other parties. that doesn't mean you need to bake it into the utxo set
932021-03-15T20:09:06 <michaelfolkson> MuSig doesn't require unhashed pubkeys? I'd need to revisit the math, the math I have seen uses unhashed pubkeys
942021-03-15T20:09:28 <maaku> michaelfolkson: yes, but you share those with the other parties you're working with
952021-03-15T20:09:38 <maaku> it doesn't need an unhashed pubkey on the chain when you make the output
962021-03-15T20:09:54 <maaku> you share pubkeys, you do musig, then you hash the result
972021-03-15T20:10:03 <michaelfolkson> PTLCs, you definitely want to be able to do math using the pubkeys for smart contract like stuff on Lightning. That's part of why they are cool
982021-03-15T20:10:32 <maaku> there's no reason anyone not involved with the output needs to know the pubkey (unless you're doing that compact ring signature thing, which is literally the only example I know of)
992021-03-15T20:11:22 <maaku> michaelfolkson: do you understand what I'm saying about sharing pubkeys with other parties vs baking them onto the chain in the utxo set?
1002021-03-15T20:12:15 <maaku> the second point about using v0 addresses as a fix: it doesn't protect me from the fact that everyone else is upgrading to segwit and making their coins vulnerable
1012021-03-15T20:12:44 <maaku> as noted by sipa, some 1/3 of all bitcoins are currently quantum vulnerable and it would be devastating for those to be stolen at once
1022021-03-15T20:13:01 <maaku> we should be reducing that number, not growing it
1032021-03-15T20:13:10 <maaku> so long as it remains that large or bigger, it's a ticking time bomb
1042021-03-15T20:13:12 <michaelfolkson> I get that distinction, yes. I just haven't given enough thought to what this Taproot proposal would have looked like and which applications it would (not) have enabled had it hashed all the pubkeys
1052021-03-15T20:14:07 <michaelfolkson> sipa would say 1/3 is more than big enough. Whether it is a 1/3 or 2/3 doesn't really matter in this quantum doomsday scenario
1062021-03-15T20:14:08 <maaku> it doesn't change the cryptography of schnorr at all. putting the pubkey behind a hash would support all the same protocols on top in exactly the same way
1072021-03-15T20:14:20 <maaku> just with 32 more bytes per input witness
1082021-03-15T20:14:21 <michaelfolkson> (I think without him being here to confirm)
1092021-03-15T20:15:43 <maaku> with a concerted effort we could get the number of vulneralbe coins down to 10% of the supply
1102021-03-15T20:16:01 <maaku> and those coins would be mostly Satoshi's plus some other early lost coins
1112021-03-15T20:16:27 <maaku> those coins suddenly moving wouldn't destroy bitcoin
1122021-03-15T20:16:58 <maaku> so my point is we should strive for that, while it is obtainable
1132021-03-15T20:17:24 <maaku> if we give in and say "well, bitcoin if fucked anyway" then what are we doing here? why are we wasting our life on this?
1142021-03-15T20:18:01 <michaelfolkson> I don't think anyone is saying stop all research on quantum resistant cryptography
1152021-03-15T20:18:06 <maaku> presumably sipa and others think we can deploy post-quantum cryptography in time to save ourselves from the apocoalypse.
1162021-03-15T20:18:42 <maaku> but taproot shortens the window by removing the extra layer of security hashed outputs gave us
1172021-03-15T20:19:03 <michaelfolkson> It is just a guess on when it is needed. Some people (like you) think we need it within a decade. Others think we need it in multiple decades
1182021-03-15T20:19:33 <maaku> and counters efforts to get people to move to quantum-secure output formats (e.g. P2WSH without key reuse)
1192021-03-15T20:21:12 <maaku> i would love to see a credible prediction that it is multiple decades out, but afaict the data doesn't support that
1202021-03-15T20:22:09 <maaku> many published articles (like this one i was just forwarded: https://arxiv.org/abs/1710.10377) make a prediction of crypto breaks in the ~10 year timeframe or less
1212021-03-15T20:23:43 <maaku> NIST believes RSA will be rendered insecure by 2030, which is basically the same level of difficulty as breaking secp256k1
1222021-03-15T20:23:53 *** pigeons <pigeons!~pigeons@androzani.sysevolve.com> has quit IRC (Ping timeout: 256 seconds)
1232021-03-15T20:23:59 <maaku> s/believes/is operating under the assumption that/
1242021-03-15T20:24:01 *** pigeons <pigeons!~pigeons@androzani.sysevolve.com> has joined ##taproot-bip-review
1252021-03-15T20:24:24 *** pigeons is now known as Guest30742
1262021-03-15T20:24:49 <luke-jr> michaelfolkson: Segwit v0 doesn't have Schnorr or any of the other improvements..
1272021-03-15T20:25:21 <michaelfolkson> We don't know. It could be within a decade, it could not. I would bet not. It is an entirely new field, I don't think there will be a tidal wave of improvements within a decade. But I could be wrong
1282021-03-15T20:25:42 <midnight> lol @ apocalypse.
1292021-03-15T20:26:38 <michaelfolkson> luke-jr: Right but if you really really cared about public keys not being hashed maybe you'd prioritize that over the improvements
1302021-03-15T20:27:41 <michaelfolkson> I don't think many people do care. They care that people are working on quantum resistant crypto and they care that they'll be able to move their coins when they need to. But apart from that
1312021-03-15T20:28:22 <luke-jr> "they'll be able to move their coins when they need to" is a guarantee lost with Taproot
1322021-03-15T20:28:45 <michaelfolkson> Explain?
1332021-03-15T20:29:24 <luke-jr> we can't predict the future, but so long as coins are secured by a hash, we can handle it so long as we know the moment quantum happens
1342021-03-15T20:29:48 <luke-jr> and why should we force an unnecessary tradeoff between security and functionality?
1352021-03-15T20:30:09 <michaelfolkson> Oh I see. You're making the point that the quantum doomsday scenario could come out of nowhere with no advance warning
1362021-03-15T20:30:17 <maaku> if you have a v0 P2WSH output then it still has 128 bits of security post-quantum (arguably 80 bits because the block Merkle hash itself is collision vulnerable)
1372021-03-15T20:30:44 <maaku> if it is a naked pubkey (Taproot v1), then you're fucked as soon as a big enough quantum computer is built
1382021-03-15T20:30:56 <michaelfolkson> I find that unlikely. If the best thing state actors can do with state of the art quantum computers is steal Bitcoin we're probably in a new world
1392021-03-15T20:30:56 <maaku> everything the attacker needs is already in the utxo set
1402021-03-15T20:31:37 <luke-jr> michaelfolkson: we're not very far from that world
1412021-03-15T20:32:07 <luke-jr> also, doing X with QC doesn't preclude also doing Y
1422021-03-15T20:32:28 <maaku> michaelfolkson: it's taken 5 years from segwit being merged into core for segwit usage to reach 50%. why do you think we can move to post-quantum crypto (which isn't even near ready yet) any more quickly than that?
1432021-03-15T20:32:31 <luke-jr> you're also assuming state actors are going to be first ;)
1442021-03-15T20:33:16 <michaelfolkson> maaku: Because there would be more urgency if you were literally going to lose your coins if you didn't upgrade
1452021-03-15T20:33:17 <robert_spigler> maaku: you're claiming that a pubkeyhash-taproot version has no downside except larger input size?
1462021-03-15T20:33:33 <maaku> robert_spigler: correct
1472021-03-15T20:33:49 <robert_spigler> If that's true, I really don't understand the reasoning
1482021-03-15T20:34:40 <robert_spigler> Upgrading nodes should decrease the % of QC vulnerable bitcoin, not increase it
1492021-03-15T20:35:18 <robert_spigler> I understand the point that there is still improvements that would have to be made regardless, but we shouldn't be making things worse?
1502021-03-15T20:36:28 <luke-jr> according to belcher, it gets ring signature privacy for Lightning channels, and "snicker coinjoin"
1512021-03-15T20:37:01 <belcher> yes, allows someone to prove they own a UTXO without revealing which UTXO, so imagine the privacy benefits for when downloading the lightning graph but without actually knowing which UTXOs are payment channels
1522021-03-15T20:37:06 <belcher> it allows*
1532021-03-15T20:37:25 <luke-jr> belcher: does it let you prove the amount too?
1542021-03-15T20:37:57 <belcher> i think so, one way of proving the range is to include all UTXOs which have amounts in a certain ranges in the ring sig
1552021-03-15T20:38:29 <luke-jr> I suppose the risk to making it optional, is that it really only makes sense for people to use the hash version for themselves..? tragedy of the commons?
1562021-03-15T20:38:34 <robert_spigler> Ok, so there are considerable trade-offs. With QC being decades away. I don't know why I'm letting myself get drawn into this. I imagine this was all discussed during years of review...
1572021-03-15T20:38:41 <maaku> belcher: it doesn't get rid of that capability, it just makes it 100x as expensive to make such a proof.
1582021-03-15T20:38:53 <maaku> I don't think it should be a show stopper since these are non-consensus use cases.
1592021-03-15T20:38:55 <belcher> maaku LN wallets on mobile phones are already pretty slow
1602021-03-15T20:39:20 <belcher> also quantum computers could just by run by miners, they could derive the privkey from unconfirmed transactions and just steal those... quantum computers dont operate with bruteforce, they are in fact pretty fast (assuming they're implemented by electrons jumping around inside atoms, well that takes a few femtoseconds, much less than 10+ minutes)
1612021-03-15T20:39:24 <luke-jr> belcher: outsource that job to your full node?
1622021-03-15T20:39:45 <luke-jr> belcher: that's not a concern if you don't transact
1632021-03-15T20:39:56 <belcher> luke-jr so then bitcoin dies because nobody can transact
1642021-03-15T20:40:05 <luke-jr> belcher: no, so then Bitcoin upgrades
1652021-03-15T20:40:10 <maaku> robert_spigler: I think the onus is on you to show that QC is decades away, since the academic, industry, and government agencies all predict it by 2030-3032
1662021-03-15T20:40:22 <michaelfolkson> robert_spigler: Haha right. But it is an interesting thought experiment designing this from scratch with hashed public keys. I never thought about MuSig assuming hashed public keys
1672021-03-15T20:40:37 <belcher> giving up tangible privacy benefits for security based on machines which nobody knows if we're even able to build, and where its pretty unlikely that hashing pubkeys actually provides security? that seems like an awful tradeoff
1682021-03-15T20:40:41 <maaku> and it was discussed in 2018/2019
1692021-03-15T20:40:53 <michaelfolkson> Maybe the QC will be able to break hash functions too. Then we really can go home
1702021-03-15T20:41:03 <luke-jr> belcher: hashing definitely provides security; it just doesn't negate the need to upgrade post-quantum
1712021-03-15T20:41:12 <luke-jr> michaelfolkson: afaik that's not a possibility
1722021-03-15T20:41:25 <michaelfolkson> Back to stones or whatever
1732021-03-15T20:41:30 <belcher> luke-jr it doesnt provide security, it means nobody can transact and basically bitcoin is dead then anyway, cant have a useful money that you cant spend
1742021-03-15T20:41:40 <belcher> if people are concerned about QC they should work on post-quantum cryptography, not promote solutions that dont actually work
1752021-03-15T20:41:43 <robert_spigler> NIST has entered it's third/selection round for PQ crypto. Estimates 2025 for selection
1762021-03-15T20:41:48 <luke-jr> belcher: we can all resume spending after the upgrade; you can't do that without the hash
1772021-03-15T20:41:59 <belcher> the "hashes provide quantum security" was made up by people who wanted to discourage address reuse for privacy reasons
1782021-03-15T20:42:01 <luke-jr> belcher: most people are not qualified to work on post-quantum
1792021-03-15T20:42:48 <luke-jr> maaku: btw, have you posted this to the ML at some point?
1802021-03-15T20:43:05 <belcher> luke-jr in the meantime bitcoin is dead, it has no transaction volume, it has no price, it has nothing funding miners... how long would that "quantum pause" last? probably months or years until someone invents QC and adds it to bitcoin, so yeah bitcoin is dead in that situation
1812021-03-15T20:43:35 <luke-jr> belcher: no
1822021-03-15T20:43:52 <belcher> not to mention, if you're worried about QC you dont have to use taproot
1832021-03-15T20:44:01 <belcher> just send your coins to a p2wpkh address
1842021-03-15T20:44:06 <luke-jr> but then you lose the actual taproot features
1852021-03-15T20:44:29 <belcher> you loads basically everything during this "quantum pause"
1862021-03-15T20:44:33 <belcher> lose*
1872021-03-15T20:44:41 <luke-jr> apples and oranges
1882021-03-15T20:44:57 <luke-jr> quantum pause only occurs in the worst case scenario, and you're proposing losing everything in the interim
1892021-03-15T20:45:04 <belcher> what taproot features are you concerned about? multisig which is a bit smaller on-chain
1902021-03-15T20:45:04 <luke-jr> s/everything/everything new/
1912021-03-15T20:45:14 <luke-jr> belcher: also more efficient; and hides scripts; etc
1922021-03-15T20:45:22 <luke-jr> the things people *actually* care about taproot for..
1932021-03-15T20:45:41 <belcher> just pay a bit more in miner fees for a multisig with OP_CHECKMULTISIG, you wont be spending your coins for years anyway
1942021-03-15T20:45:44 <maaku> luke-jr: I haven't been on the mailing list in years. i think i'd have to join to post? feel free to send it there
1952021-03-15T20:45:51 <belcher> you can already hide scripts with p2sh anyway
1962021-03-15T20:45:57 <luke-jr> belcher: now you're just trolling -.-
1972021-03-15T20:46:15 <maaku> belcher: solving ECDL requires hundreds of billlions of gate operations. it's going to take time
1982021-03-15T20:46:54 <maaku> with currently predicted technology it would be on the order of hours to days. even with massive improvements it would still take many seconds to minutes
1992021-03-15T20:46:55 <luke-jr> maaku: I don't think you need to join to post.
2002021-03-15T20:47:04 <belcher> it cant take longer than the decoherence lifetime
2012021-03-15T20:47:32 <belcher> any quantum algorithm that takes so long wont be useful because the system will just decohere in that time
2022021-03-15T20:47:38 <maaku> yes, which is why lower error rates (AKA extending decoherence lifetime) is a key part of advancing QC
2032021-03-15T20:47:48 <maaku> but there are roadmaps to achieving that
2042021-03-15T20:48:09 <belcher> theres transactions in the mempool that have been unconfirmed for weeks at this point
2052021-03-15T20:48:48 <maaku> a successful first or second generation crypto-breaking QC could probably snipe one or two transactions per block, but the vast majority would get through safely
2062021-03-15T20:49:45 <maaku> and there are second-order schemes you can come up with where there is a forward block chain where you commit to transactions before you reveal them, and there's a settling period to find the tx with the oldest commitment
2072021-03-15T20:49:59 <belcher> nobody is stopping people working on that
2082021-03-15T20:50:22 <maaku> but such things don't work with naked pubkeys!
2092021-03-15T20:50:36 <belcher> so people can send their coins to p2wpkh addresses
2102021-03-15T20:50:40 <maaku> that would let the attacker batch process the whole utxo set and then start stealing wily-nilly
2112021-03-15T20:50:44 <belcher> they cost the same in miner fees as a taproot spend
2122021-03-15T20:51:11 <belcher> remember they also need to avoid their hardware wallets, because those send xpub keys to the hardware wallet servers by default
2132021-03-15T20:51:23 <luke-jr> yes, they should
2142021-03-15T20:51:28 <luke-jr> even regardless of QC
2152021-03-15T20:51:32 <belcher> agreed
2162021-03-15T20:51:44 <luke-jr> belcher: you're convincing me we should hash ;)
2172021-03-15T20:51:45 <belcher> but for this, we're being asked to give up concrete privacy benefits in return for a scheme which wont even save bitcoin
2182021-03-15T20:52:21 <luke-jr> belcher: didn't you say we can get that benefit with 100x more work?
2192021-03-15T20:52:25 <luke-jr> with a hash
2202021-03-15T20:52:47 <luke-jr> (does that apply to snicker coinjoin as well?)
2212021-03-15T20:52:49 <belcher> luke-jr at some points it becomes pointless, its like making blocks bigger, sure its *possible* but it just makes LN nodes harder to run
2222021-03-15T20:53:10 <luke-jr> belcher: surely it's still trivial compared to the normal work of a full ndoe?
2232021-03-15T20:53:20 <luke-jr> if this creates more incentive to run your own full node, that's GOOD
2242021-03-15T20:53:22 <belcher> and as i mention anyone concerned about their own coins doesnt need to use taproot like they dont today
2252021-03-15T20:53:32 <luke-jr> then why activate taproot?
2262021-03-15T20:53:35 <maaku> I gave that 100x estimate, as a back-of-the-envelope guesstimate based on size of bulletproof sha256 preimage proof vs size of schnorr signature
2272021-03-15T20:53:41 <belcher> so people who want to use it are able to luke-jr
2282021-03-15T20:53:55 <luke-jr> belcher: what about people who want to use it, but not endanger themselves to quantum?
2292021-03-15T20:54:30 <belcher> luke-jr you cant use taproot without making transactions, during the quantum pause nobody can safely make transactions
2302021-03-15T20:54:33 <luke-jr> maaku: but my point is, it's still possible..
2312021-03-15T20:54:54 <luke-jr> belcher: ugh, are you intentionally being dense? or you really don't get it?
2322021-03-15T20:55:21 <belcher> ok so ad hominems are fine now?
2332021-03-15T20:55:34 <belcher> you accused me of trolling already before
2342021-03-15T20:55:42 <luke-jr> so stop trolling
2352021-03-15T20:56:17 <belcher> if we're using personal arguments, i find it interesting that just as we'd agreed on an activation mechanism we start to hear quantum FUD and thats coming from someone who actually works on their own altcoin competitor to bitcoin
2362021-03-15T20:56:47 *** bsm117532 <bsm117532!~bsm117532@unaffiliated/bsm117532> has quit IRC (*.net *.split)
2372021-03-15T20:56:55 <maaku> luke-jr: yes, sorry I just wanted to clarify the origin of the number. You can use bulletproofs or any other zkp system to do private LN channels or the coinjoin thing
2382021-03-15T20:57:06 <luke-jr> belcher: Freicoin isn't a competitor to Bitcoin. It's fundamentally different at an economic level. In any case, ad hominems are not welcome.
2392021-03-15T20:57:14 *** bsm117532 <bsm117532!~bsm117532@unaffiliated/bsm117532> has joined ##taproot-bip-review
2402021-03-15T20:57:37 <belcher> well just like in the block size / segwit discussions we had people with interests coming in causing trouble and working against bitcoin's interests
2412021-03-15T20:58:38 <luke-jr> belcher: if he didn't have logical points, I wouldn't even be discussing them
2422021-03-15T20:59:33 <maaku> belcher: I'm not a fan of bitcoin's economic model, but I think we all suffer from being tribalistic. when I have something that I think is of value to the bitcoin space I share it, like I did with forward blocks in 2018, and I'm doing now
2432021-03-15T20:59:44 <maaku> we are stronger by working together
2442021-03-15T21:00:23 <maaku> I'm sorry if you feel that this was a delayed criticism.
2452021-03-15T21:00:46 <belcher> forward blocks is another great example actually, that was abusing a bug in order to add bigger blocks to bitcoin and increase the costs of running a full node
2462021-03-15T21:00:49 <luke-jr> hmm, maaku, this blog post says you posted it 2 hours ago, but I'm pretty sure it's older?
2472021-03-15T21:00:58 <maaku> I made this point directly to Pieter and a few others in the 2018-2019 timeframe, when the first taproot branches were being worked on. I commented on some pull requests.
2482021-03-15T21:01:07 <belcher> i know any lurkers here wouldnt be taking advice about segwit from roger ver or jihan wu
2492021-03-15T21:01:28 <maaku> The consensus was against my concerns so I moved on. I don't believe that a single developer should be able to shout "NACK!" and stop a proposal.
2502021-03-15T21:02:22 <maaku> But in discussions with others in ##taproot-activation and ##uasf channels, and with some of my coworkers I was surprised to find that there were many who were completely ignorant of Taproot's QC risks
2512021-03-15T21:02:28 <belcher> nobody is ever forced into using taproot, they cant be, if they are concerned about QC they can just not use it, indeed taproot single-sig costs the same in miner fees as p2wpkh so it wont even cost them much more in most cases
2522021-03-15T21:02:40 <belcher> all of bitcoin has QC risks
2532021-03-15T21:02:44 <maaku> So I wrote up this article over the weekend to explain
2542021-03-15T21:03:13 * luke-jr wonders how "37% of bitcoins are vulnerable to QC, harming my own" is really any different from "37% of bitcoins haven't been mined yet"
2552021-03-15T21:04:02 <maaku> If people are aware of the risk and think it is acceptable and activate regardless, fine. I did my duty. I disagree, but I'd consider it fair.
2562021-03-15T21:04:16 <michaelfolkson> I knew of this QC argument for unhashed public keys and I'd seen Pieter address it on many, many occasions. I didn't know that you maaku felt so strongly about it that you'd effectively NACK Taproot as it is designed and implemented
2572021-03-15T21:04:36 <michaelfolkson> That was new information to me
2582021-03-15T21:04:49 <maaku> luke-jr: as I mention in the article, I think it is very important to distinguish whether those coins are early lost coinbases vs. binance's cold wallet
2592021-03-15T21:06:04 <belcher> coinbase/binance cold wallets can easily transfer coins to regular multisig addresses that exists today, they hold billions in USD in value so the slightly higher miner fee because the multisig spends are a bit bigger is no issue for them
2602021-03-15T21:06:23 <belcher> if all else was equal there could be argument, but by adding hashed pubkeys we lose other benefits
2612021-03-15T21:07:01 <maaku> michaelfolkson: also I think it's fair to say that development in the QC space in the last few years have made me more concerned
2622021-03-15T21:07:23 <maaku> I think I would have been swayed by the "we have time to fix it" argument in 2018 in a way that I wouldn't be now.
2632021-03-15T21:07:45 <maaku> both because of advances in QC and because of how long it has taken to get a comparatively simple Taproot out the door
2642021-03-15T21:08:18 <luke-jr> michaelfolkson: in light of not having any gains, I'd be tempted to NACK it as well - except we can just add the hash on easily enough so..
2652021-03-15T21:12:04 *** mol <mol!mol@gateway/vpn/protonvpn/molly> has quit IRC (Remote host closed the connection)
2662021-03-15T21:12:16 *** mol <mol!mol@gateway/vpn/protonvpn/molly> has joined ##taproot-bip-review
2672021-03-15T21:22:54 <luke-jr> https://dpaste.com/GGUZAP3BH anything to add/correct? maaku belcher michaelfolkson robert_spigler
2682021-03-15T21:25:04 <maaku> "use more CPU time" -> "use significantly more CPU time and bandwidth"; a factor of ~100x is not to be glossed over
2692021-03-15T21:25:11 <luke-jr> bandwidth too?
2702021-03-15T21:25:22 <maaku> proof sizes are correspondingly larger
2712021-03-15T21:25:28 <luke-jr> but just privately, right? not flood
2722021-03-15T21:25:47 <maaku> yeah this is all for off-chain protocols, like LN node channel announcements
2732021-03-15T21:26:16 <maaku> which is why I'm comfortable trading off a 100x performance gain
2742021-03-15T21:26:36 <maaku> If it was a 100x hit to an on-chain protocol, I'd agree that'd be a problem. But it's not.
2752021-03-15T21:26:38 <belcher> we lose the possibility of non-interactively deriving a keypair belonging to a UTXO, which is used by snicker
2762021-03-15T21:27:03 <luke-jr> belcher: oh, so snicker isn't included in this? :/
2772021-03-15T21:27:23 <luke-jr> belcher: you mean a third-party UTXO, right? because you certainly can for your own..
2782021-03-15T21:27:24 <belcher> yes, snicker is a protocol for doing coinjoins, its nothing to do with lightning
2792021-03-15T21:27:28 <maaku> belcher: snicker needs to do that for random utxos?
2802021-03-15T21:27:56 <michaelfolkson> luke-jr: Please make it clear that Pieter has addressed this concern on many, many occasions and perhaps include a link too
2812021-03-15T21:28:09 <luke-jr> michaelfolkson: isn't that covered in maaku's blog?
2822021-03-15T21:28:14 <luke-jr> or you mean he's addressed it other places too?
2832021-03-15T21:28:25 <luke-jr> what should I link? (and read, I guess)
2842021-03-15T21:29:05 <robert_spigler> also, even w/ pubkeyhash, bitcoin could still be stolen because the pubkey is published on spend
2852021-03-15T21:29:21 <michaelfolkson> If you give me some time I'll try to find more. For now I have to hand...
2862021-03-15T21:29:24 <michaelfolkson> https://bitcoin.stackexchange.com/questions/93047/could-taproot-create-larger-security-risks-or-even-hinder-future-protocol-adjust
2872021-03-15T21:29:30 <maaku> I just skimmed the snicker bip. Putting keys behind a hash would add a round.
2882021-03-15T21:29:35 <luke-jr> robert_spigler: we don't have a fix for that - Bitcoin would need to freeze period
2892021-03-15T21:29:43 <michaelfolkson> https://bitcoin.stackexchange.com/questions/91049/why-does-hashing-public-keys-not-actually-provide-any-quantum-resistance
2902021-03-15T21:30:02 <belcher> maaku the whole point of snicker is that it is non-interactive, its in the name "snicker"
2912021-03-15T21:30:07 <robert_spigler> luke-jr: yes
2922021-03-15T21:30:13 <michaelfolkson> https://bitcoin.stackexchange.com/questions/95123/what-are-the-potential-attacks-against-ecdsa-that-would-be-possible-if-we-used-r/
2932021-03-15T21:30:32 <maaku> belcher: but what I don't understand is how you choose a party to interact with?
2942021-03-15T21:30:36 <luke-jr> michaelfolkson: the first one appears n/a?
2952021-03-15T21:30:51 <michaelfolkson> ?
2962021-03-15T21:30:53 <maaku> picking rando utxos from the chain would be inefficient.
2972021-03-15T21:31:00 <michaelfolkson> https://bitcoin.stackexchange.com/questions/93047/could-taproot-create-larger-security-risks-or-even-hinder-future-protocol-adjust
2982021-03-15T21:31:00 <luke-jr> michaelfolkson: it's about Schnorr itself
2992021-03-15T21:31:16 <maaku> presumably someone would broadcast their willingness to participate in future snicker coinjoins
3002021-03-15T21:31:40 <maaku> in the hashed-taproot model, that braodcast could contain the underlying key/script
3012021-03-15T21:31:42 <michaelfolkson> luke-jr: It is on quantum security
3022021-03-15T21:32:20 <luke-jr> michaelfolkson: but not the specific scope of this discussion IMO
3032021-03-15T21:32:41 <michaelfolkson> Second one? https://bitcoin.stackexchange.com/questions/91049/why-does-hashing-public-keys-not-actually-provide-any-quantum-resistance
3042021-03-15T21:32:50 <maaku> michaelfolkson: to my knowledge Pieter has never addressed this concern
3052021-03-15T21:33:13 <michaelfolkson> He has on Twitter, StackExchange and I think (but I'd need to check) mailing list
3062021-03-15T21:33:23 <maaku> in the thing you link to Pieter misunderstands the author and spends his reply thinking DSA means the specific algorithm rather than "digital signature" as the asker meant
3072021-03-15T21:33:58 <maaku> I specifically address my problems with the twitter comments in my blog
3082021-03-15T21:34:57 <robert_spigler> IMO, this answers the question very well
3092021-03-15T21:34:58 <robert_spigler> https://bitcoin.stackexchange.com/questions/91049/why-does-hashing-public-keys-not-actually-provide-any-quantum-resistance
3102021-03-15T21:35:01 <luke-jr> michaelfolkson: the second one seems to be addressing "more is needed", but dismisses the fact that some resistance isn't zero
3112021-03-15T21:35:39 <michaelfolkson> Regardless. My ask is that in Luke's mailing list post it is made clear that this has been a known and well discussed topic. Just to avoid the "At the last minute bug in Taproot found" FUD
3122021-03-15T21:36:04 <robert_spigler> agreed
3132021-03-15T21:36:21 <michaelfolkson> If they actually read maaku's post it isn't a problem. But many won't read it and just take away summary
3142021-03-15T21:37:40 <luke-jr> michaelfolkson: first paragraph seems to say that
3152021-03-15T21:37:56 <maaku> luke-jr: hold on i got sidetracked let me review what you wrote again
3162021-03-15T21:38:04 <luke-jr> wait, I'll post an updated one
3172021-03-15T21:38:14 <luke-jr> https://dpaste.com/G5K6VWFZE
3182021-03-15T21:40:47 <maaku> luke-jr: looks factually correct
3192021-03-15T21:41:06 <belcher> "Note that in all circumstances, Bitcoin is endangered when QC becomes a reality, but pre-Taproot, it is possible for the network to "pause" while a full quantum-safe fix is developed, and then resume transacting. With Taproot as-is, it could very well become an unrecoverable situation if QC go online prior to having a full quantum-safe solution." <---- this not true at all because 1) its an unrecoverable situation today 2) taproot
3202021-03-15T21:41:07 <belcher> users can send their coins to hashes pubkey addresses
3212021-03-15T21:41:31 <belcher> "Also, what I didn't know myself until today, is that we do not actually gain anything from this: the features proposed to make use of the raw keys being public prior to spending can be implemented with hashed keys as well." <--- didnt mention that it breaks snicker or anything else with non-interactive keypair derivation from a UTXO
3222021-03-15T21:41:36 <michaelfolkson> "we do not actually gain anything from this"
3232021-03-15T21:41:46 <michaelfolkson> I dispute this. But it can argued on the mailing list
3242021-03-15T21:42:07 <belcher> also by making lightning wallets be required to do 100x as much work, it makes them harder to run... and if you disagree then why not just increase the block size by 100x and argue that we dont lose anything either
3252021-03-15T21:43:23 <michaelfolkson> You need unhashed public keys to do math (addition, subtraction)
3262021-03-15T21:43:47 <belcher> yep, the snicker trick relies on EC addition
3272021-03-15T21:45:01 <belcher> nobody is saying the unhashed pubkeys thing is quantum safe because few things in bitcoin are, the real argument is that the concrete privacy benefits we know about today are worth the slightly increased risk in the hypothetical future where QC becomes reality
3282021-03-15T21:46:15 <robert_spigler> agree with belcher and michaelfolkson comments
3292021-03-15T21:47:33 <luke-jr> belcher: It's bad if people run Lightning without a full node, which requires much more work
3302021-03-15T21:48:09 <belcher> luke-jr if its bad to add extra resources requirements to full nodes by increasing the block size, then its also bad to add extra resource requirements to lightning wallets by increasing what they have to do
3312021-03-15T21:48:42 <luke-jr> belcher: no
3322021-03-15T21:48:43 <belcher> most likely if hashed pubkeys are used lightning will just never implement that and we'll stay with the current less-private situation we have today
3332021-03-15T21:49:37 <belcher> fwiw snicker basically requires users to use full nodes
3342021-03-15T21:49:50 <belcher> allowing snicker then provides more of an incentive for more full nodes to be out there
3352021-03-15T21:58:23 <belcher> also i just realized, LN wallets which make use of this ring signature proof thingy need to use a full node anyway, regardless of whether the pubkey is hashed or not, because they always need to know what the UTXO set is
3362021-03-15T21:58:59 <luke-jr> great, so non-fullnode users are not even an argument against it
3372021-03-15T21:59:09 <belcher> yep, requiring hashed pubkeys doesnt change user's requirements to have a full node
3382021-03-15T21:59:32 <belcher> cheap ring signature proofs would actually help the cause, because the LN devs are more likely to add the feature if its cheap
3392021-03-15T21:59:45 <belcher> LN having that feature increases the incentives for full nodes to be used
3402021-03-15T21:59:58 <luke-jr> if it needs a full node anyway, how is it cheap?
3412021-03-15T22:00:20 <belcher> some of the cost of the proof is bandwidth in sending it around via the LN p2p network
3422021-03-15T22:00:37 <belcher> that bandwidth would be smaller if pubkeys are not hashed, because it would avoid the big zkp
3432021-03-15T22:00:48 <luke-jr> hmm
3442021-03-15T22:12:13 *** stortz <stortz!c8b9cbcf@200.185.203.207> has joined ##taproot-bip-review
3452021-03-15T22:24:33 <luke-jr> [20:48:48] <maaku> a successful first or second generation crypto-breaking QC could probably snipe one or two transactions per block, but the vast majority would get through safely
3462021-03-15T22:24:43 <luke-jr> maaku: is that even if the miner is in on it?
3472021-03-15T22:47:16 <maaku> luke-jr: yeah it doesn't matter who
3482021-03-15T22:47:47 <maaku> you'd have to seriously scale up operations (build a bunch of QC) to be mining the mempool for all but a few transactions here and there
3492021-03-15T22:48:48 <luke-jr> I'm confused because I thought it was ~instantaneous once you had a QC
3502021-03-15T22:48:56 <maaku> and you'd still be limited by the fact that e.g. if it takes 1hr to break a key, many tx (especially high value tx) will spend less time than that in the mempool
3512021-03-15T22:49:28 <maaku> luke-jr: current estimates are ~100 billion gate operations for a 256-bit ECDL break
3522021-03-15T22:49:49 <luke-jr> I don't know how to interpret that. So that's the 1 hour per key?
3532021-03-15T22:49:54 <luke-jr> and it can only break one at a time?
3542021-03-15T22:50:10 <maaku> even at 1Ghz that's 100s
3552021-03-15T22:50:38 <maaku> and real first generation machines are no likely to operate at 1Ghz
3562021-03-15T22:51:08 <maaku> and one machine can only break one at a time
3572021-03-15T22:55:26 <maaku> it's theoretically possible that it could get fast enough to break keys in less than a second per key. that's within theoretical bounds
3582021-03-15T22:55:35 <maaku> I just don't think it's likely for the first few generations of QC
3592021-03-15T23:00:14 <luke-jr> makes sense
3602021-03-15T23:42:21 <maaku> One my points in the blog post was that algorithmic advances are coming too though.
3612021-03-15T23:42:39 <maaku> I feel less comfortable predicting those, since we are likely to hit a wall at some point.
3622021-03-15T23:43:37 <maaku> But it is likely that by 2030 when there are QC that are maybe able to reverse a secp256k1 pubkey, there will be some algorithmic improvements which reduce the number of gates required
3632021-03-15T23:44:24 <maaku> For example, there was a recent paper (last year? I'll try to find it) which reduced the difficulty of breaking 2048 bit RSA from a similar ~100 billion gates to ~100 million.
3642021-03-15T23:44:30 <robert_spigler> ð Stupid question, but what am I doing wrong re: responding to the ML?
3652021-03-15T23:44:41 <maaku> A 10^3 improvement obviously has effects on both timeline and calculation latency
3662021-03-15T23:45:37 <robert_spigler> Matt saw it, but it didn't show up in thread or on bitcoin-dev archive
3672021-03-15T23:46:51 <maaku> Here it is. 20 million gates: https://arxiv.org/abs/1905.09749
3682021-03-15T23:48:05 <maaku> robert_spigler: did you reply to matt directly? i usually reply-all for mailing list stuff
3692021-03-15T23:48:24 <robert_spigler> Yeah, I replied all (to bitcoin-dev, and Matt)
3702021-03-15T23:49:37 <robert_spigler> Same thing happened to my posting about my BIP proposal the other day...had a response by SomberNight. Replied all, never appeared on bitcoin-dev
3712021-03-15T23:59:17 <luke-jr> robert_spigler: sometimes moderators need to approve messages