Hi Tim,

Just read through your post, thanks for the heads up - I only just joined this mailing list.

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 then use a higher fee (or relationship with a miner) to effectively turn your original "d" transaction into a double-spend, with the forged transaction sending all your funds to the adversary.

I'm pretty confident that a PQ DSA is required to prevent front-running, and that no "commit-reveal" scheme will be secure without one.

The other issue with your approach is that if it is rolled out today, it will effectively double transaction volumes - this is what I tried to solve in solutions 2 and 3 in my article by instead modifying the address generation process.

Regards,

Tristan

On Tue, Feb 13, 2018 at 2:50 AM, Tim Ruffing via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
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 aims to avoid the issues that you've
mentioned in your blog post.

Best,
Tim

On Tue, 2018-02-13 at 01:13 +1100, Tristan Hoy via bitcoin-dev wrote:
> Hi all,
>
> Recently I've been exploring what a post-quantum attack on Bitcoin
> would actually look like, and what options exist for mitigating it.
>
> I've put up a draft of my research here: https://medium.com/@tristanh
> oy/11271f430c41
>
> In summary:
> 1) None of the recommended post-quantum DSAs (XMSS, SPHINCS) are
> scalable
> 2) This is a rapidly advancing space and committment to a specific
> post-quantum DSA now would be premature
> 3) I've identified a strategy (solution 3 in the draft) that
> mitigates against the worst case scenario (unexpectedly early attack
> on ECDSA) without requiring any changes to the Bitcoin protocol or
> total committment to a specific post-quantum DSA that will likely be
> superseded in the next 3-5 years
> 4) This strategy also serves as a secure means of transferring
> balances into a post-quantum DSA address space, even in the event
> that ECDSA is fully compromised and the transition is reactionary
>
> The proposal is a change to key generation only and will be
> implemented by wallet providers.
>
> Feedback would be most appreciated.
>
> Regards,
>
> Tristan
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev