Re: [bitcoin-dev] PSA: Taproot loss of quantum protections
Erik, > Does anyone think it would it be useful to write up a more official, and even partly functional plan for Bitcoin to use zero-knowledge proofs to transition to quantum resistance? yes, this would be appreciated very much! Andrew Chow's write-up gives already some high-level idea, but a more detailed exposition would be essential for further discussion. thank you, Martin On Mon, Mar 22, 2021 at 3:47 PM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The argument that hashed public addresses provide meaningful quantum > resistance is flawed *when considered in the context*.of Bitcoin > itself. > > This article by Andrew Chow is easy to read and makes a strong case > against the quantum utility of hashed public keys: > > https://cryptowords.github.io/why-does-hashing-public-keys-not-actually-provide-any-quantum-resistance > > And then, of course, one should be mindful of the case against quantum > computing itself - it is neither inevitable nor "just around the > corner". Mikhail Dyakonov summarized the arguments well here: > https://t.co/cgrfrroTTT?amp=1. > > My current stance (at my company at least) is that planning for > quantum computing should be limited to "a provable and written ability > to upgrade if it becomes clear that it's necessary." > > Does anyone think it would it be useful to write up a more official, > and even partly functional plan for Bitcoin to use zero-knowledge > proofs to transition to quantum resistance? > > - Erik Aronesty > CTO, Atkama > > On Mon, Mar 15, 2021 at 5:48 PM Luke Dashjr via bitcoin-dev > wrote: > > > > I do not personally see this as a reason to NACK Taproot, but it has > become > > clear to me over the past week or so that many others are unaware of this > > tradeoff, so I am sharing it here to ensure the wider community is aware > of > > it and can make their own judgements. > > > > Mark Friedenbach explains on his blog: > > https://freicoin.substack.com/p/why-im-against-taproot > > > > In short, Taproot loses an important safety protection against quantum. > > 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. > > > > 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. > > It would use significantly more CPU time and bandwidth (between private > > parties, not on-chain), but there should be no shortage of that for > anyone > > running a full node (indeed, CPU time is freed up by Taproot!); at > worst, it > > would create an incentive for more people to use their own full node, > which > > is a good thing! > > > > Despite this, I still don't think it's a reason to NACK Taproot: it > should be > > fairly trivial to add a hash on top in an additional softfork and fix > this. > > > > In addition to the points made by Mark, I also want to add two more, in > > response to Pieter's "you can't claim much security if 37% of the supply > is > > at risk" argument. This argument is based in part on the fact that many > > people reuse Bitcoin invoice addresses. > > > > First, so long as we have hash-based addresses as a best practice, we can > > continue to shrink the percentage of bitcoins affected through social > efforts > > discouraging address use. If the standard loses the hash, the situation > > cannot be improved, and will indeed only get worse. > > > > Second, when/if quantum does compromise these coins, so long as they are > > neglected or abandoned/lost coins (inherent in the current model), it > can be > > seen as equivalent to Bitcoin mining. At the end of the day, 37% of > supply > > minable by QCs is really no different than 37% minable by ASICs. (We've > seen > > far higher %s available for mining obviously.) > > > > To conclude, I recommend anyone using Bitcoin to read Mark's article, my > > thoughts, and any other arguments on the topic; decide if this is a > concern > > to you, and make your own post(s) accordingly. Mark has conceded the > argument > > (AFAIK he doesn't have an interest in bitcoins anyway), and I do not > consider > > it a showstopper - so if anyone else out there does, please make yourself > > known ASAP since Taproot has already moved on to the activation phase > and it > > is likely software will be released within the next month or two as > things > > stand. > > > > Luke > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > __
Re: [bitcoin-dev] Timelocks and Lightning on MimbleWimble
Isn't there some way to "rebase" a relative lock-time to some anchor even further in the past while cancelling out the intermediate transactions? best regards, Martin On Thu, Sep 19, 2019 at 9:52 AM ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Good morning list, > > I was reading transcript of recent talk: > https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/blockchain-design-patterns/ > > And in section "Taproot: main idea": > > > Q: Can you do timelocks iwth adaptor signatures? > > > > ... > > > > A: This is one way it's being proposed by mimblewimble; but this > requires the ability to aggregate signatures across transactions. > > > > Q: No, there's two transactions already existing. Before locktime, you > can spend wit hthe adaptor signature one like atomic swaps. After locktime, > the other one becomes valid and you can spend with that. They just double > spend each other. > > > > A: You'd have to diagram that out for me. There's a few ways to do this, > some that I know, but yours isn't one of them. > > I believe what is being referred to here is to simply have an `nLockTime` > transaction that is signed by all participants first, and serves as the > "timelock" path. > Then, another transaction is created, for which adaptor signatures are > given, before completing the ritual to create a "hashlock" path. > > I find it surprising that this is not well-known. > I describe it here tangentially, for instance: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016888.html > The section "Payjoin2swap Swap Protocol" refers to "pre-swap transaction" > and "pre-swap backout transaction", which are `nLockTime`d transactions. > Later transactions then use a Scriptless Script-like construction to > transfer information about a secret scalar x. > > My understanding of MimbleWimble is that: > > * There must exist a proof-of-knowledge of the sum of blinding factors > used. > This can be trivially had by using a signature of this sum, signing an > empty message or "kernel". > * I believe I have seen at least one proposal (I cannot find it again now) > where the "kernel" is replaced with an `nLockTime`-equivalent. > Basically, the `nLockTime` would have to be explicitly published, and it > would be rejected for a block if the `nLockTime` was less than the block > height. > * There may or may not exist some kind of proof where the message being > signed is an integer that is known to be no greater than a particular > value, and multiple signatures that signed a lower value can somehow be > aggregated to a higher value, which serves this purpose as well, but is > compressible. > > My understanding is thus that the above `nLockTime` technique is what is > indeed intended for MimbleWimble cross-system atomic swaps. > > > > However, I believe that Lightning and similar offchain protocols are **not > possible** on MimbleWimble, at least if we want to retain its "magical > shrinking blockchain" property. > > All practical channel constructions with indefinite lifetime require the > use of *relative* locktime. > Of note is that `nLockTime` represents an *absolute* lifetime. > > The only practical channel constructions I know of that do not require > *relative* locktime (mostly various variants of Spilman channels) have a > fixed lifetime, i.e. the channel will have to be closed before the lifetime > arrives. > This is impractical for a scaling network. > > It seems to me that some kind of "timeout" is always necessary, similar to > the timeout used in SPV-proof sidechains, in order to allow an existing > claimed-latest-state to be proven as not-actually-latest. > > * In Poon-Dryja, knowledge of the revocation key by the other side proves > the published claimed-latest-state is not-actually-latest and awards the > entire amount to the other party. > * This key can only be presented during the timeout, a security > parameter. > * In Decker-Wattenhofer decrementing-`nSequence` channels, a kickoff > starts this timeout, and only the smallest-timeout state gets onchain, due > to it having a time advantage over all other versions. > * In indefinite-lifetime Spilman channels (also described in the > Decker-Wattenhofer paper), the absolute-timelock initial backoff > transaction is replaced with a kickoff + relative-locktime transaction. > * In Decker-Russell-Osuntokun, each update transaction has an imposed > `nSequence` that forces a state transaction to be delayed compared to the > update transaction it is paired with. > > It seems that all practical offchain updateable cryptocurrency systems, > some kind of "timeout" is needed during which participants have an > opportunity to claim an alternative version of some previous claim of > correct state. > > This timeout could be implemented as either relative or absolute lock > time, but obviously an absolute locktime would create a limit on the > lifetime of the channel. > Thus, if we were
