On Wed, 2018-01-24 at 13:51 +0100, Natanael via bitcoin-dev wrote: > Sidenote: There's a risk here with interception, insertion of a new > commitment and getting the new transaction into the blockchain first. > However, I would suggest a mining policy here were two known > conflicting transactions with commitments are resolved such that the > one with the oldest commitment wins. How to address detection of > conflicting transactions with commitments older than confirmed > transactions isn't obvious. Some of these may be fully intentional by > the original owner, such as a regretted transaction.
Okay, I think my proposal was wrong... This looks better (feel free to break again): 1. Commit (H(classic_pk, tx), tx) to the blockchain, wait until confirmed 2. Reveal classic_pk in the blockchain Then the tx in the first valid commitment wins. If the attacker intercepts classic_pk, it won't help him. He cannot create the first valid commitment, because it is created already. (The reason is that the decommitment is canonical now; for all commitments, the decommitment is just classic_pk.) By the way, maybe I'm stating the obvious but Taproot (or similar) is indeed very nice for outputs generated in the future: You can have a path for a classical signature scheme and a path for a quantum-secure scheme. Best, Tim _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
