--- Log opened Wed Mar 17 00:00:58 2021
02:05 -!- stortz [c8b9cbcf@200.185.203.207] has joined ##taproot-bip-review
02:55 -!- Netsplit *.net <-> *.split quits: belcher_
03:03 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-bip-review
03:09 -!- Teleportando [8eb30758@d142-179-7-88.bchsia.telus.net] has quit [Ping timeout: 240 seconds]
05:38 -!- belcher_ is now known as belcher
05:57 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has joined ##taproot-bip-review
06:04 -!- jonatack_ [~jon@37.169.45.97] has joined ##taproot-bip-review
06:28 -!- jonatack_ [~jon@37.169.45.97] has quit [Quit: jonatack_]
06:28 -!- jonatack [~jon@37.169.45.97] has joined ##taproot-bip-review
07:14 -!- shesek`` [~shesek@164.90.217.137] has joined ##taproot-bip-review
07:15 -!- shesek` [~shesek@164.90.217.137] has quit [Remote host closed the connection]
07:36 -!- shesek` [~shesek@164.90.217.137] has joined ##taproot-bip-review
07:37 -!- shesek`` [~shesek@164.90.217.137] has quit [Remote host closed the connection]
08:06 -!- stortz [c8b9cbcf@200.185.203.207] has quit [Quit: Connection closed]
09:25 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Remote host closed the connection]
09:26 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-bip-review
09:26 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Client Quit]
10:02 < 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
10:04 < real_or_random> (which does not mean that the comments are wrong. it
10:05 < 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
10:12 < 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
10:13 < 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
10:14 < real_or_random> you mean whether we should keep QC in mind when we change the system now?
10:15 < 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
10:17 < 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.
10:18 < 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
10:21 < 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.
10:22 < real_or_random> and that's just not true -- at least it's certainly not that simple.
10:22 < maaku> belcher: I'm not sure what you mean by "a question of whether hashing pubkeys would work"
10:24 < maaku> I know of no reason why a hashed pubkey--where the user treats the pubkey as key material--is not PQ secure
10:24 < 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
10:25 < 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
10:26 < maaku> [but not knowing for sure is not a good reason to avoid mitigating some possible outcomes]
10:27 < 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
10:29 < 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
10:30 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-bip-review
10:32 < 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 )
10:34 < 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
10:36 < 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
10:36 -!- lucasmoten__ [~lucasmote@136.144.35.169] has joined ##taproot-bip-review
10:37 < 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)
10:37 < 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
10:38 < 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
10:38 < 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
10:38 -!- lucasmoten_ [~lucasmote@136.144.35.169] has quit [Ping timeout: 264 seconds]
10:39 < belcher> there also the issue of how are things like payment channels and multisig custody meant to work without exposing pubkeys
10:39 < 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
10:40 < 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)
10:40 < 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
10:41 < 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
10:41 < 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
10:41 < luke-jr> belcher: so they steal your funds, not everyone's..
10:41 < belcher> luke-jr in other words lightning just stops working in a post-quantum world
10:42 < belcher> of course you can fix it, but you can fix anything by adopting PQ crypto so lets just do that
10:42 < maaku> sure. and "not having LN" != "everyone's coins stolen"
10:42 < luke-jr> belcher: *everything* just stops working in a PQ world
10:42 < belcher> luke-jr yep, thats my point, so why are holding up taproot for this?
10:42 < queip> lamport master race unaffected
10:42 < luke-jr> "no longer working" != "everyone's coins stolen"
10:42 < luke-jr> queip: no lamport in Bitcoin
10:43 < belcher> no longer working means no transactions and no miner fees paid to miners
10:43 < belcher> so bitcoin just stops really
10:43 < 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
10:43 < belcher> even if your coins arent stolen on paper they are still frozen and useless to you
10:43 < luke-jr> miners could keep mining actually
10:43 < queip> acthuaaaaaaaly, couldn't a smart contract be written to require lamport signature? hmm
10:43 < 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.
10:44 < luke-jr> real_or_random: or just don't give anyone your key…
10:44 < maaku> But that trust doesn't go further than the next hop
10:44 < belcher> luke-jr miners would receive inflation coins, but they wouldnt be able to sell them anywhere, no transactions remember
10:44 < luke-jr> belcher: until PQ fix is deployed
10:44 < real_or_random> luke-jr: ok but then I can't use payment channels. not great either
10:44 < belcher> in the meantime miners have to pay electricity bills luke-jr
10:44 < real_or_random> ( luke-jr: you mentioned a gdoc? I don't see any link)
10:44 < luke-jr> real_or_random: nobody said it was great
10:45 < 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
10:45 < luke-jr> real_or_random: meant that for the activation channel, sry
10:45 < belcher> blocking taproot and losing out on privacy tech like snicker and ring signatures*
10:46 < luke-jr> belcher: I don't agree with blocking Taproot over it
10:46 < belcher> then we agree :)
10:46 < real_or_random> a probably naive point: in fact noone is forced to use Taproot
10:47 < luke-jr> real_or_random: it's not nice to tell people "lose QC-resistance, or you don't get new features" either tho
10:47 < 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
10:48 < 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?
10:48 < luke-jr> real_or_random: rather, if you do, the consequences are your problem :P
10:49 < real_or_random> "lose QC resistance or you don't get LN" (with or without taproot...)
10:49 < luke-jr> real_or_random: option 3 ("only have trusted peers on LN") is also available
10:50 < real_or_random> right ok. but if you want trusted peers, we have probably more efficient systems ^^
10:50 < luke-jr> also, even with untrusted peers, your potential attacker set is much less than with public pubkeys
10:50 < luke-jr> real_or_random: using the same LN system makes you interoperable with non-trusted sends/receives
10:50 < 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.
10:51 < 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 ;)
10:51 < 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
10:51 < 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.
10:52 < maaku> luke-jr: right. that's the ripplepay security model
10:52 < luke-jr> finally, you might be okay with risking 1% of your holdings in LN, while you want to keep the other 99% safe
10:52 < maaku> which lets ripplepay use IOUs instead of collateral
10:53 < 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)
10:53 -!- jonatack [~jon@37.169.45.97] has quit [Ping timeout: 265 seconds]
10:53 < 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
10:54 < luke-jr> I wonder if Taproot can be "sold" as a block size reduction without the actual size reduction/costs :P
10:54 < maaku> luke-jr: for super-long duration, consider p2wsh for the larger hash width
10:54 < belcher> it already is in many ways, like with the batch validation
10:54 -!- jonatack [~jon@37.169.45.97] has joined ##taproot-bip-review
10:54 < luke-jr> if it's significantly more efficient, it would reduce the CPU time even if not actual bytes
10:55 < maaku> nitpick, you don't need taproot for batch validation
10:55 < maaku> but yeah it has been sold that way
10:57 < 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
10:57 < real_or_random> indeed, P2PKH with Schnorr sigs would also work for batch validation
10:57 < maaku> er, which signatures
10:57 < maaku> schnorr signatures are not needed
10:58 < real_or_random> maaku: ok can you elaborate? I don't understand
10:58 < luke-jr> but p2pkh doesn't support schnorr..
10:58 < maaku> real_or_random: ECDSA can be batch validated too
10:58 < maaku> the issue is not the signature scheme (although Schnorr's batch validation is easier to implement)
10:58 < real_or_random> luke-jr: bitcoin doesn't support schnorr either?
10:59 < maaku> but rather that bitcoin doesn't mandate that every signature be valid
10:59 < maaku> you can have a CHECKSIG NOT in a script
10:59 < maaku> and the design of CHECKMULTISIG does not specify which pubkeys go with which signatures, so the script verifier does trial-and-error checking
11:00 < maaku> but you could eliminate all of that
11:00 < maaku> (1) treat all CHECKSIG/CHECKMULTISIG as CHECKSIGVERIFY/CHECKMULTISIGVERIFY [maybe with a new tx.nVersion]
11:01 < maaku> (2) add a "hint" value which is a bitmask specifying which pubkeys to skip in CHECKMULTISIG
11:01 < 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
11:02 < 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]
11:03 < maaku> but if you did that, then you can batch validate ECDSA transactions just fine.
11:03 < luke-jr> just bump the witness version?
11:04 < 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
11:05 < real_or_random> maaku: this is part of BIP342 https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#design
11:05 < maaku> There's an implementation here: https://github.com/tradecraftio/tradecraft/pull/25
11:05 < real_or_random> (if we're talking about the same thing)
11:06 < 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
11:06 < real_or_random> and yeah, there are ECDSA batch validation schemes which I think are not as great as those for Schnorr sigs
11:07 < real_or_random> but I think noone in the discussion is opposing the Schnorr sig part of the softfork
11:07 < real_or_random> ok
12:53 -!- mol_ [mol@gateway/vpn/protonvpn/molly] has joined ##taproot-bip-review
12:55 -!- mol [mol@gateway/vpn/protonvpn/molly] has quit [Ping timeout: 264 seconds]
14:07 -!- jonatack [~jon@37.169.45.97] has quit [Read error: Connection reset by peer]
14:07 -!- jonatack [~jon@37.169.45.97] has joined ##taproot-bip-review
14:49 -!- jonatack_ [~jon@37.164.14.9] has joined ##taproot-bip-review
14:52 -!- jonatack [~jon@37.169.45.97] has quit [Ping timeout: 246 seconds]
16:17 -!- jonatack_ [~jon@37.164.14.9] has quit [Ping timeout: 264 seconds]
16:22 -!- mol_ [mol@gateway/vpn/protonvpn/molly] has quit [Quit: Leaving]
17:11 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
20:00 -!- mol [mol@gateway/vpn/protonvpn/molly] has joined ##taproot-bip-review
20:14 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-bip-review
21:01 -!- shesek` [~shesek@164.90.217.137] has quit [Remote host closed the connection]
21:06 -!- shesek [~shesek@164.90.217.137] has joined ##taproot-bip-review
21:06 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
21:06 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review
21:19 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-bip-review
21:22 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds]
23:02 -!- mol_ [mol@gateway/vpn/protonvpn/molly] has joined ##taproot-bip-review
23:02 -!- lucasmoten__ [~lucasmote@136.144.35.169] has quit [Read error: Connection reset by peer]
23:02 -!- lucasmoten__ [~lucasmote@136.144.35.169] has joined ##taproot-bip-review
23:05 -!- mol [mol@gateway/vpn/protonvpn/molly] has quit [Ping timeout: 245 seconds]
23:12 -!- RusAlex_ [~Chel@BSN-77-82-41.static.siol.net] has quit [Quit: WeeChat 3.0]
23:12 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-bip-review
--- Log closed Thu Mar 18 00:00:59 2021