Re: [bitcoin-dev] Transition to post-quantum

- It would be hard to prove you have access to an x that can produce H(g^x) in a way that doesn't expose g^x and isn't one of those slow, interactive bit-encryption algorithms. - Instead a simple scheme would publish a transaction to the blockchain that lists: - pre-quantum signature -

Re: [bitcoin-dev] Transition to post-quantum

On Thu, 2018-02-15 at 23:44 +0100, Natanael wrote: > If your argument is that we publish the full transaction minus the > public key and signatures, just committing to it, and then revealing > that later (which means an attacker can't modify the transaction in > advance in a way that produces a

Re: [bitcoin-dev] Transition to post-quantum

Small correction, see edited quote Den 15 feb. 2018 23:44 skrev "Natanael" : Allowing expiration retains insecurity, while *NOT* allowing expiration makes it a trivial DoS target. ___ bitcoin-dev mailing list

Re: [bitcoin-dev] Transition to post-quantum

Den 15 feb. 2018 22:58 skrev "Tim Ruffing via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: Also, the miners will indeed see one valid decommitment. This decommitment may have been sent by the attacker but it's the preimage chal of the address, because otherwise it's not valid for the

Re: [bitcoin-dev] Transition to post-quantum

On Thu, 2018-02-15 at 21:27 +0100, Natanael wrote: > I addressed this partially before, and this is unfortunately > incomplete. > > Situation A: Regardless of expiration of commitments, we allow > doubles. (Or no doubles allowed, but commitments expire.) > > If I can block your transaction from

Re: [bitcoin-dev] Transition to post-quantum

Den 15 feb. 2018 17:00 skrev "Tim Ruffing via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: Consensus rules === A decommitment d = chal spends a UTXO with address H_addr(chal), if there exists a commitment c in the blockchain which references the UTXO and which is the first

Re: [bitcoin-dev] Transition to post-quantum

First of all, there is indeed an issue in my proposal: The idea was to include a classic signature to make sure that, if (for whatever reason) you have revealed classic_pk already. However, the problem is that if you have revealed classic_pk, then everybody can effectively prevent you from

Re: [bitcoin-dev] Transition to post-quantum

On Tue, 2018-02-13 at 08:32 +1100, Tristan Hoy wrote: > In a post-quantum world, your second "d" type transaction is > completely forgeable, which means it is vulnerable to front-running. > An adversary capable of breaking ECDSA needs only listen for these > transactions, obtain "classic_sk" and

Re: [bitcoin-dev] Transition to post-quantum

Hi Tristan, Regarding the "Post-Quantum Address Recovery" part (I haven't read the other parts), you may be interested in my message to the list from last month and the rest of the thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015659.html This is an approach which