📅 Original date posted:2018-01-24
📝 Original message:Den 25 jan. 2018 00:22 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
I think you misread my second proposal. The first step is not only to
publish the hash but to publish a *pair* consisting of the hash and the
transaction.
If the attacker changes the transaction on the wire, the user does not
care and will try again.
I guess I assumed you meant it otherwise because I didn't assume you
intended a commitment to the full transaction just without the asymmetric
key material.
You could treat it the same way as in my suggestion, let it expire and
prune it if the key material isn't published in time.
However... A sufficiently powerful attacker can deploy as soon as he sees
your published signature and key, delay its propagation to the miners,
force expiration and then *still* repeat the attack with his own forgery.
Honestly, as long as we need to allow any form of expiry + relying on
publication of the vulnerable algorithms result for verification, I think
the weakness will remain.
No expiration hurts in multiple ways like via DoS, or by locking in
potentially wrong (or straight up malicious) transactions.
---
There's one way out, I believe, which is quantum safe Zero-knowledge
proofs. Currently STARK:s are one variant presumed quantum safe. It would
be used to completely substitute the publication of the public key and
signatures, and this way we don't even need two-step commitments.
It does however likely require a hardfork to apply to old transactions. (I
can imagine an extension block type softfork method, in which case old
UTXO:s get locked on the mainchain to create equivalent valued extension
block funds.)
Without practical ZKP, and presuming no powerful QC attackers with the
ability to control the network (basically NSA level attackers), I do think
the Fawkes signature scheme is sufficient. Quantum attacks are likely to be
very expensive anyway, for the foreseeable future.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180125/45fe3cec/attachment.html>;
Natanael [ARCHIVE] /
npub179…lpmjt
2023-06-07 18:10:10
in reply to nevent1q…skqw
Author Public Key
npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjtPublished at
2023-06-07 18:10:10Event JSON
{
"id": "1fcec81714977955196772c413418266eaed0b110d2b73ccb416c4f2e7fc13a1",
"pubkey": "f14f3c71a4e63a12c842e4a50471263ada4b6cfde093fcb6588693a726b9b018",
"created_at": 1686161410,
"kind": 1,
"tags": [
[
"e",
"3098b6cd22aeee78f0db7c45c94594dc578b6094452b2f8e3129789af2cd6fd4",
"",
"root"
],
[
"e",
"de8732ba10777f55debb2da4ea8393e8fe3d815edd14e6aafeb3097382982fb4",
"",
"reply"
],
[
"p",
"c6d7a400897460d9a2c07bbad58731b6d04267edd75af42af45f471b04581ec2"
]
],
"content": "📅 Original date posted:2018-01-24\n📝 Original message:Den 25 jan. 2018 00:22 skrev \"Tim Ruffing via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e:\n\n\nI think you misread my second proposal. The first step is not only to\npublish the hash but to publish a *pair* consisting of the hash and the\ntransaction.\n\nIf the attacker changes the transaction on the wire, the user does not\ncare and will try again.\n\n\nI guess I assumed you meant it otherwise because I didn't assume you\nintended a commitment to the full transaction just without the asymmetric\nkey material.\n\nYou could treat it the same way as in my suggestion, let it expire and\nprune it if the key material isn't published in time.\n\nHowever... A sufficiently powerful attacker can deploy as soon as he sees\nyour published signature and key, delay its propagation to the miners,\nforce expiration and then *still* repeat the attack with his own forgery.\n\nHonestly, as long as we need to allow any form of expiry + relying on\npublication of the vulnerable algorithms result for verification, I think\nthe weakness will remain.\n\nNo expiration hurts in multiple ways like via DoS, or by locking in\npotentially wrong (or straight up malicious) transactions.\n\n---\n\nThere's one way out, I believe, which is quantum safe Zero-knowledge\nproofs. Currently STARK:s are one variant presumed quantum safe. It would\nbe used to completely substitute the publication of the public key and\nsignatures, and this way we don't even need two-step commitments.\n\nIt does however likely require a hardfork to apply to old transactions. (I\ncan imagine an extension block type softfork method, in which case old\nUTXO:s get locked on the mainchain to create equivalent valued extension\nblock funds.)\n\nWithout practical ZKP, and presuming no powerful QC attackers with the\nability to control the network (basically NSA level attackers), I do think\nthe Fawkes signature scheme is sufficient. Quantum attacks are likely to be\nvery expensive anyway, for the foreseeable future.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180125/45fe3cec/attachment.html\u003e",
"sig": "046f824b6d47368c720dde5357bfe660c5dec225ce9abcdbb36763b8cdb3ea853e2a1a979026248dae2b779d905b22794528b4b5a398974b7972c4cf345fd41d"
}