📅 Original date posted:2018-02-15
📝 Original message: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 confirming (censorship), then I
> can make my own commitment + transaction. The miners will see two
> commitments referencing the same UTXO - but can see only one
> transaction which match a valid challenge and spends them, which is
> mine. You gained nothing from the commitment.
Yes, I assume situation A:
* commitments never expire
* and there is no limit on the number of commitment for the same UTXO
As I understand, you mean "decommitment" when you say "transaction".
Please correct me if I'm wrong. I'll stick with "decommitment".
Let's assume the attacker blocks the decommitment by the honest user,
inserts his own malicious commitment and his own decommitment, which
should be valid for the malicious commitment. Then the miners will see
two commitments (the earlier commitment by the honest user and the
later one by the attacker).
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 malicious
commitment. But if the decommitment is chal, then this decommitment is
also valid for the commitment of the honest user, which is earliest
additionally. So the honest commitment wins. The attacker does not
succeed and everything is fine.
The reason why this works:
There is only one unique decommitment for the UTXO (assuming H_addr is
collision-resistant). The decommitment does not depend on the
commitment. The attacker cannot send a different decommitment, just
because there is none.
Maybe I'm wrong and I just don't understand your attack. In this case,
please explain it more detail.
Regards,
Tim
Tim Ruffing [ARCHIVE] /
npub1cm…dwkls
2023-06-07 18:10:39
in reply to nevent1q…jnjc
Author Public Key
npub1cmt6gqyfw3sdngkq0wadtpe3kmgyyeld6ad0g2h5tar3kpzcrmpqddwklsPublished at
2023-06-07 18:10:39Event JSON
{
"id": "e56c62a42f4086f45f6baecb0e845e4539aa5ba2dd0f00d1d02c65ecf4dbe06b",
"pubkey": "c6d7a400897460d9a2c07bbad58731b6d04267edd75af42af45f471b04581ec2",
"created_at": 1686161439,
"kind": 1,
"tags": [
[
"e",
"74cac95639ddcdb0a3025aa02802000639d0d8a449d57b4ca47e5dcff3c843f3",
"",
"root"
],
[
"e",
"81136f8eaffb69c5447502426a6c70e4b5e02ba38717c401d16717f82cc7b47d",
"",
"reply"
],
[
"p",
"f14f3c71a4e63a12c842e4a50471263ada4b6cfde093fcb6588693a726b9b018"
]
],
"content": "📅 Original date posted:2018-02-15\n📝 Original message:On Thu, 2018-02-15 at 21:27 +0100, Natanael wrote:\n\u003e I addressed this partially before, and this is unfortunately\n\u003e incomplete.\n\u003e \n\u003e Situation A: Regardless of expiration of commitments, we allow\n\u003e doubles. (Or no doubles allowed, but commitments expire.) \n\u003e \n\u003e If I can block your transaction from confirming (censorship), then I\n\u003e can make my own commitment + transaction. The miners will see two\n\u003e commitments referencing the same UTXO - but can see only one\n\u003e transaction which match a valid challenge and spends them, which is\n\u003e mine. You gained nothing from the commitment.\n\nYes, I assume situation A: \n * commitments never expire\n * and there is no limit on the number of commitment for the same UTXO\n\nAs I understand, you mean \"decommitment\" when you say \"transaction\".\nPlease correct me if I'm wrong. I'll stick with \"decommitment\".\n\nLet's assume the attacker blocks the decommitment by the honest user,\ninserts his own malicious commitment and his own decommitment, which\nshould be valid for the malicious commitment. Then the miners will see\ntwo commitments (the earlier commitment by the honest user and the\nlater one by the attacker).\n\nAlso, the miners will indeed see one valid decommitment. This\ndecommitment may have been sent by the attacker but it's the preimage\nchal of the address, because otherwise it's not valid for the malicious\ncommitment. But if the decommitment is chal, then this decommitment is\nalso valid for the commitment of the honest user, which is earliest\nadditionally. So the honest commitment wins. The attacker does not\nsucceed and everything is fine.\n\nThe reason why this works:\nThere is only one unique decommitment for the UTXO (assuming H_addr is\ncollision-resistant). The decommitment does not depend on the\ncommitment. The attacker cannot send a different decommitment, just\nbecause there is none.\n\nMaybe I'm wrong and I just don't understand your attack. In this case,\nplease explain it more detail.\n\nRegards,\nTim",
"sig": "860f3f8f05fb17ec0b711867dd1aa6b67f03aaf2c05199efac27c2f480619a530473eab8290a6fb293e372b38c2be9e2fe3bddd41ed815c62fce79d44f801024"
}