📅 Original date posted:2018-02-15
📝 Original message:Den 15 feb. 2018 17:00 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
Consensus rules
===============
A decommitment d = chal spends a UTXO with address H_addr(chal), if
there exists a commitment c in the blockchain which references the UTXO
and which is the first commitment (among all referencing the UTXO) in
the blockchain such that
1. k = KDF(chal) correctly decrypts Dec(k, c)
and
2. tx = Dec(k, c) is a valid transaction to spend UTXO
The UTXO is spent as described by tx.
Commitments never expire.
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.
Situation B: We don't allow conflicting commitments, and they never expire.
I can now freeze everybody's funds trivially with invalid commitments,
because you can't validate a commitment without seeing a valid transaction
matching it - and exposing an uncommitted transaction breaks the security
promise of commitments.
Any additional data in the commitment but hash it the transaction is
pointless, because the security properties are the same. You can't freeze
an UTXO after only seeing a commitment, and for any two conflicting
transactions you may observe it does not matter at all if one references
UTXO:s or not since you already know both transactions' commitment ages
anyway. Oldest would win no matter the additional data.
Commitments work when the network can't easily be censored for long enough
to deploy the attack (at least for 2-3 blocks worth of time). They fail
when the attacker is capable of performing such an attack.
As I said previously, the only completely solid solution in all
circumstances is a quantum resistant Zero-knowledge proof algorithm, or
some equivalent method of proving knowledge of the key without revealing
any data that enables a quantum attack.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180215/7b046cd7/attachment.html>;
Natanael [ARCHIVE] /
npub179…lpmjt
2023-06-07 18:10:38
in reply to nevent1q…2slh
Author Public Key
npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjtPublished at
2023-06-07 18:10:38Event JSON
{
"id": "81136f8eaffb69c5447502426a6c70e4b5e02ba38717c401d16717f82cc7b47d",
"pubkey": "f14f3c71a4e63a12c842e4a50471263ada4b6cfde093fcb6588693a726b9b018",
"created_at": 1686161438,
"kind": 1,
"tags": [
[
"e",
"74cac95639ddcdb0a3025aa02802000639d0d8a449d57b4ca47e5dcff3c843f3",
"",
"root"
],
[
"e",
"0472a7ff5b1b29a276bcf44f46789cb2f44284751ecef091ddfb89eaedc5e0ea",
"",
"reply"
],
[
"p",
"c6d7a400897460d9a2c07bbad58731b6d04267edd75af42af45f471b04581ec2"
]
],
"content": "📅 Original date posted:2018-02-15\n📝 Original message:Den 15 feb. 2018 17:00 skrev \"Tim Ruffing via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e:\n\n\nConsensus rules\n===============\nA decommitment d = chal spends a UTXO with address H_addr(chal), if\nthere exists a commitment c in the blockchain which references the UTXO\nand which is the first commitment (among all referencing the UTXO) in\nthe blockchain such that\n1. k = KDF(chal) correctly decrypts Dec(k, c)\n and\n2. tx = Dec(k, c) is a valid transaction to spend UTXO\n\nThe UTXO is spent as described by tx.\nCommitments never expire.\n\n\nI addressed this partially before, and this is unfortunately incomplete.\n\nSituation A: Regardless of expiration of commitments, we allow doubles. (Or\nno doubles allowed, but commitments expire.)\n\nIf I can block your transaction from confirming (censorship), then I can\nmake my own commitment + transaction. The miners will see two commitments\nreferencing the same UTXO - but can see only one transaction which match a\nvalid challenge and spends them, which is mine. You gained nothing from the\ncommitment.\n\nSituation B: We don't allow conflicting commitments, and they never expire.\nI can now freeze everybody's funds trivially with invalid commitments,\nbecause you can't validate a commitment without seeing a valid transaction\nmatching it - and exposing an uncommitted transaction breaks the security\npromise of commitments.\n\nAny additional data in the commitment but hash it the transaction is\npointless, because the security properties are the same. You can't freeze\nan UTXO after only seeing a commitment, and for any two conflicting\ntransactions you may observe it does not matter at all if one references\nUTXO:s or not since you already know both transactions' commitment ages\nanyway. Oldest would win no matter the additional data.\n\nCommitments work when the network can't easily be censored for long enough\nto deploy the attack (at least for 2-3 blocks worth of time). They fail\nwhen the attacker is capable of performing such an attack.\n\nAs I said previously, the only completely solid solution in all\ncircumstances is a quantum resistant Zero-knowledge proof algorithm, or\nsome equivalent method of proving knowledge of the key without revealing\nany data that enables a quantum attack.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180215/7b046cd7/attachment.html\u003e",
"sig": "57b41a0bc9258e89525351523f5e5fa359dd14bbc602b027569e6f4201cca46a9ece489039fdef2f383ae89297ba768d17745df9f504be782767c48eb638ef06"
}