Tim Ruffing [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-24 📝 Original message:On Wed, 2018-01-24 at ...
📅 Original date posted:2018-01-24
📝 Original message: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
📝 Original message: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