📅 Original date posted:2020-05-14
📝 Original message:В Wed, 13 May 2020 21:03:17 +0200
Ruben Somsen <rsomsen at gmail.com> wrote:
> Or perhaps you're referring to the issue ZmnSCPxj pointed out after
> that, where refund transaction #1 and the success transaction could
> both become valid at the same time. It would make sense for the test
> to pick up on that, but I believe that is ultimately also not an
> issue (see my last reply in the thread).
This one.
The issue as I see it: Bob can not broadcast success_tx and wait until
Alice has broadcasted refund_tx_1. While refund_tx_1 is in the mempool,
Bob gives success_tx to the friendly miner to have a chance to
invalidate success_tx. Bob already learned secretAlice, so he grabs
his LTC back. If the Bob-friendly miner has luck, success_tx is
confirmed while refund_tx_1 is invalidated, and Bob now have both LTC
and BTC, while Alice is out of her BTC.
> >I did not understand what the destination of Alice&Bob cooperative
> >spend
> of refund_tx#1 will be
>
> This transaction can be spent by Alice & Bob right away or by Alice a
> day later (in relative time, so the tx has to confirm first). The
> Alice & Bob condition is there purely to ensure that Bob can spend
> the money before Alice once he receives her key at the end of the
> protocol.
Ah, so this is possible because of the step 5 in the diagram: ``Alice
gives Bob her key ("Alice")'' -- As I understand, this is a way to deny
Alice to use refund_tx_1.
Then if Alice gives her _key_ to Bob before Bob has to share secretBob
via success_tx, could Bob just spend the Alice&Bob output of the
very first, "commitment" transaction that locks BTC ? Bob will receive
BTC, and the LTC can be locked forever, but Bob doesn't care, he got
his BTC.
Dmitry Petukhov [ARCHIVE] /
npub10r…9afdw
2023-06-07 18:24:45
in reply to nevent1q…a5wl
Author Public Key
npub10r66s2stvnancx9axwnfc5a34asjkwkgmkq7ztm5hf30x7fa4szsv9afdwPublished at
2023-06-07 18:24:45Event JSON
{
"id": "bdd6c9cdb928b672dfb4218f405a9ffe9c90a440e9fd3510d6a28bbd3d477c2e",
"pubkey": "78f5a82a0b64fb3c18bd33a69c53b1af612b3ac8dd81e12f74ba62f3793dac05",
"created_at": 1686162285,
"kind": 1,
"tags": [
[
"e",
"129e131197a70aa261cc74c8213f981c1dc64eff47d18af7549ba6d323ea7565",
"",
"root"
],
[
"e",
"92df60c9d6f035c9779fab1865d8335d93adfee79f2312b3068aa46ede2bc4c4",
"",
"reply"
],
[
"p",
"c4c73e48c7d7f313938a90d71ff5e4be5d01dd4157f98ed99adf14737bfb78e0"
]
],
"content": "📅 Original date posted:2020-05-14\n📝 Original message:В Wed, 13 May 2020 21:03:17 +0200\nRuben Somsen \u003crsomsen at gmail.com\u003e wrote:\n\n\u003e Or perhaps you're referring to the issue ZmnSCPxj pointed out after\n\u003e that, where refund transaction #1 and the success transaction could\n\u003e both become valid at the same time. It would make sense for the test\n\u003e to pick up on that, but I believe that is ultimately also not an\n\u003e issue (see my last reply in the thread).\n\nThis one.\n\nThe issue as I see it: Bob can not broadcast success_tx and wait until\nAlice has broadcasted refund_tx_1. While refund_tx_1 is in the mempool,\nBob gives success_tx to the friendly miner to have a chance to\ninvalidate success_tx. Bob already learned secretAlice, so he grabs\nhis LTC back. If the Bob-friendly miner has luck, success_tx is\nconfirmed while refund_tx_1 is invalidated, and Bob now have both LTC\nand BTC, while Alice is out of her BTC.\n\n\u003e \u003eI did not understand what the destination of Alice\u0026Bob cooperative\n\u003e \u003espend \n\u003e of refund_tx#1 will be\n\u003e \n\u003e This transaction can be spent by Alice \u0026 Bob right away or by Alice a\n\u003e day later (in relative time, so the tx has to confirm first). The\n\u003e Alice \u0026 Bob condition is there purely to ensure that Bob can spend\n\u003e the money before Alice once he receives her key at the end of the\n\u003e protocol.\n\nAh, so this is possible because of the step 5 in the diagram: ``Alice\ngives Bob her key (\"Alice\")'' -- As I understand, this is a way to deny\nAlice to use refund_tx_1.\n\nThen if Alice gives her _key_ to Bob before Bob has to share secretBob\nvia success_tx, could Bob just spend the Alice\u0026Bob output of the\nvery first, \"commitment\" transaction that locks BTC ? Bob will receive\nBTC, and the LTC can be locked forever, but Bob doesn't care, he got\nhis BTC.",
"sig": "e69d99c2b69b0505890779cb1e3135a1f490a05da5bac6b23e6d9375a1f15560562c6b65ce08dd0de63bbc5cf9996ed1803a45cce27fdb60d8a0ae534bdfcd28"
}