📅 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
Tim Ruffing [ARCHIVE] /
npub1cm…dwkls
2023-06-07 18:10:10
in reply to nevent1q…c5l4
Author Public Key
npub1cmt6gqyfw3sdngkq0wadtpe3kmgyyeld6ad0g2h5tar3kpzcrmpqddwklsSeen on
wss://relay.nostr.bandPublished at
2023-06-07 18:10:10Event JSON
{
"id": "5d1af6f673c5d012dce866ba5cb2eb6f53e9c5104567f7bf313022b77c2a4a63",
"pubkey": "c6d7a400897460d9a2c07bbad58731b6d04267edd75af42af45f471b04581ec2",
"created_at": 1686161410,
"kind": 1,
"tags": [
[
"e",
"3098b6cd22aeee78f0db7c45c94594dc578b6094452b2f8e3129789af2cd6fd4",
"",
"root"
],
[
"e",
"352f269c66db731dd950561abec6ba36144fecf361cfa8d3ef669cc469c678c6",
"",
"reply"
],
[
"p",
"f14f3c71a4e63a12c842e4a50471263ada4b6cfde093fcb6588693a726b9b018"
]
],
"content": "📅 Original date posted:2018-01-24\n📝 Original message:On Wed, 2018-01-24 at 13:51 +0100, Natanael via bitcoin-dev wrote:\n\u003e Sidenote: There's a risk here with interception, insertion of a new\n\u003e commitment and getting the new transaction into the blockchain first.\n\u003e However, I would suggest a mining policy here were two known\n\u003e conflicting transactions with commitments are resolved such that the\n\u003e one with the oldest commitment wins. How to address detection of\n\u003e conflicting transactions with commitments older than confirmed\n\u003e transactions isn't obvious. Some of these may be fully intentional by\n\u003e the original owner, such as a regretted transaction.\n\nOkay, I think my proposal was wrong...\n\nThis looks better (feel free to break again):\n1. Commit (H(classic_pk, tx), tx) to the blockchain, wait until confirmed\n2. Reveal classic_pk in the blockchain\n\nThen the tx in the first valid commitment wins. If the attacker\nintercepts classic_pk, it won't help him. He cannot create the first\nvalid commitment, because it is created already. (The reason is that\nthe decommitment is canonical now; for all commitments, the\ndecommitment is just classic_pk.)\n\nBy the way, maybe I'm stating the obvious but Taproot (or similar) is\nindeed very nice for outputs generated in the future: You can have a\npath for a classical signature scheme and a path for a quantum-secure\nscheme.\n\nBest,\nTim",
"sig": "983894a1b864db28c2833dbd640927b930a4bf386a4b8d33598602e743f813b8a4e7c6be85b0887f6f48dafb7b2cc345bdac72c610924d0b0c208a5b3bd87765"
}