š
Original date posted:2019-08-21
š Original message:Please see the github issues and the twitter discussion (e.g. here:
https://twitter.com/stefanwouldgo/status/1163801056423403520) for similar
points other people including me have made. At this point I feel there are
quite a few unclear points in the presentation and it is not clear to me if
they can be salvaged.
Am Mi., 21. Aug. 2019 um 09:32 Uhr schrieb ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> Good morning Maxim,
>
> The Deaf Bob Attack
> ===================
>
> It seems to me that Bob can promote the N3 problem to the N2 problem.
>
> Suppose Alice contacts Bob to get the data.
> However, Bob happens to have lost the data in a tragic boating accident.
>
> Now, supposedly what Alice does in this case would be to broadcast the
> HTLC settlement transaction, whose signature was provided by Bob during
> protocol setup.
>
> But this seems unworkable.
>
> * If Bob managed to sign the HTLC settlement transaction, what `SIGHASH`
> flags did Bob sign with?
> * If it was `SIGHASH_ALL` or `SIGHASH_SINGLE`, then Bob already selected
> the decryption key at setup time.
> * If it was `SIGHASH_NONE`, then Alice could put any SCRIPT, including
> `<Alice> OP_CHECKSIG`.
>
> If Bob already selected the decryption key at setup time, then Bob can
> ignore Alice.
>
> * If Alice does not publish the HTLC settlement transaction, then Bob will
> eventually enter the N2 state and get the stake+reward.
> * If Alice *does* publish the HTLC settlement transaction, without Bob
> giving the encrypted data, then Bob can just use the hashlock and reveal
> the decryption key.
> * The decryption key is useless without the encrypted data!
>
> It seems this part is not workable?
> As the decryption key is embedded in the HTLC, Alice cannot get a
> signature from Bob without the decryption key already being selected by Bob
> (and thus already claimable even without any data being returned by Bob).
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190821/25a4c8a0/attachment-0001.html>;
Stefan Richter [ARCHIVE] /
npub19fā¦f4wf0
2023-06-07 18:20:21
in reply to nevent1qā¦8rtj
Author Public Key
npub19fnl48y9j4fk9w0a284mqvszq6fuppelqp2tcxf0s37l95avdtussf4wf0Seen on
wss://relay.nostr.bandPublished at
2023-06-07 18:20:21Event JSON
{
"id": "ff8d182e9ae9a1b808c5c963ae40e21ad0039ca464cc2bc9869baecf522af6c4",
"pubkey": "2a67fa9c85955362b9fd51ebb032020693c0873f0054bc192f847df2d3ac6af9",
"created_at": 1686162021,
"kind": 1,
"tags": [
[
"e",
"cbd4b96f21fec5023d1976c2c29ae5116ec786a2492353eb535ff28845278ef1",
"",
"root"
],
[
"e",
"919e9aef36c7dae35b37bc9fa1b16f5f845507df1069ca2a284b8f82af63f073",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "š
Original date posted:2019-08-21\nš Original message:Please see the github issues and the twitter discussion (e.g. here:\nhttps://twitter.com/stefanwouldgo/status/1163801056423403520) for similar\npoints other people including me have made. At this point I feel there are\nquite a few unclear points in the presentation and it is not clear to me if\nthey can be salvaged.\n\nAm Mi., 21. Aug. 2019 um 09:32 Uhr schrieb ZmnSCPxj via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e:\n\n\u003e Good morning Maxim,\n\u003e\n\u003e The Deaf Bob Attack\n\u003e ===================\n\u003e\n\u003e It seems to me that Bob can promote the N3 problem to the N2 problem.\n\u003e\n\u003e Suppose Alice contacts Bob to get the data.\n\u003e However, Bob happens to have lost the data in a tragic boating accident.\n\u003e\n\u003e Now, supposedly what Alice does in this case would be to broadcast the\n\u003e HTLC settlement transaction, whose signature was provided by Bob during\n\u003e protocol setup.\n\u003e\n\u003e But this seems unworkable.\n\u003e\n\u003e * If Bob managed to sign the HTLC settlement transaction, what `SIGHASH`\n\u003e flags did Bob sign with?\n\u003e * If it was `SIGHASH_ALL` or `SIGHASH_SINGLE`, then Bob already selected\n\u003e the decryption key at setup time.\n\u003e * If it was `SIGHASH_NONE`, then Alice could put any SCRIPT, including\n\u003e `\u003cAlice\u003e OP_CHECKSIG`.\n\u003e\n\u003e If Bob already selected the decryption key at setup time, then Bob can\n\u003e ignore Alice.\n\u003e\n\u003e * If Alice does not publish the HTLC settlement transaction, then Bob will\n\u003e eventually enter the N2 state and get the stake+reward.\n\u003e * If Alice *does* publish the HTLC settlement transaction, without Bob\n\u003e giving the encrypted data, then Bob can just use the hashlock and reveal\n\u003e the decryption key.\n\u003e * The decryption key is useless without the encrypted data!\n\u003e\n\u003e It seems this part is not workable?\n\u003e As the decryption key is embedded in the HTLC, Alice cannot get a\n\u003e signature from Bob without the decryption key already being selected by Bob\n\u003e (and thus already claimable even without any data being returned by Bob).\n\u003e\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190821/25a4c8a0/attachment-0001.html\u003e",
"sig": "fe01bf28bb6fb210ca9e1aecd6466b946d4fc2f6e0950dbebe32ee7bca5fb4e1ae4d298363ec052442323d9d676090ac4547a56680c5b32a6f991f3890897d3e"
}