📅 Original date posted:2020-05-14
📝 Original message:В Thu, 14 May 2020 07:31:13 +0200
Ruben Somsen <rsomsen at gmail.com> wrote:
> Hi Dmitry,
>
> >While refund_tx_1 is in the mempool, Bob gives success_tx to the
> >friendly miner
>
> I see, so you're talking about prior to protocol completion, right
> after Alice sends Bob the success_tx. The reason this is not an issue
> is because Alice and Bob both had to misbehave in order for this to
> happen. Bob is misbehaving here because he should have published the
> success_tx before refund_tx_1 became valid, and Alice is misbehaving
> here because she should have sent the revoke_tx (which invalidates
> the success_tx) followed by refund_tx_2 (revealing her secret only
> AFTER Bob can no longer claim the BTC). In other words: yes, the
> protocol can fail if Alice and Bob together work towards that goal. A
> feature, not a bug. This won't happen if either of them doesn't want
> it to. I imagine this is difficult to model.
Right. But it should be noted that it is not enough that Bob publishes
success_tx before refund_tx_1 became valid. The success_tx needs to be
confirmed before refund_tx_1 became valid.
Only Bob can spend success_tx so this is unlikely to be the practical
problem, unless the original fee of success_tx is too small and Bob
epically screws up CPFP-ing it.
> >Bob will receive BTC, and the LTC can be locked forever, but Bob
> >doesn't
> care, he got his BTC.
>
> No, because diagram step 5 comes before step 6 -- Alice won't give
> her key until she learns secretBob.
I somehow missed it, and steps 5 and 6 in the diagram was not modelled
at all (on the other hand, it made the model simpler and I had
something working relatively quick). I now made the `signers_map` into
variable that can be changed to give Bob the ability to sign for Alice.
With that change, step 6 can be modelled, but this will add a bunch of
new txs to the model (each Alice&Bob spend will have 'Bob unilateral
override' case)
Dmitry Petukhov [ARCHIVE] /
npub10r…9afdw
2023-06-07 18:24:46
in reply to nevent1q…m5hf
Author Public Key
npub10r66s2stvnancx9axwnfc5a34asjkwkgmkq7ztm5hf30x7fa4szsv9afdwPublished at
2023-06-07 18:24:46Event JSON
{
"id": "70c042a4a4a2f104ce2de2462c1750fd962a223b6b1629f991a6c233a6739be9",
"pubkey": "78f5a82a0b64fb3c18bd33a69c53b1af612b3ac8dd81e12f74ba62f3793dac05",
"created_at": 1686162286,
"kind": 1,
"tags": [
[
"e",
"129e131197a70aa261cc74c8213f981c1dc64eff47d18af7549ba6d323ea7565",
"",
"root"
],
[
"e",
"22e6b632898b491a45323d48727e6abf740bcfaaf78689e397a078c97255af84",
"",
"reply"
],
[
"p",
"c4c73e48c7d7f313938a90d71ff5e4be5d01dd4157f98ed99adf14737bfb78e0"
]
],
"content": "📅 Original date posted:2020-05-14\n📝 Original message:В Thu, 14 May 2020 07:31:13 +0200\nRuben Somsen \u003crsomsen at gmail.com\u003e wrote:\n\n\u003e Hi Dmitry,\n\u003e \n\u003e \u003eWhile refund_tx_1 is in the mempool, Bob gives success_tx to the\n\u003e \u003efriendly miner\n\u003e \n\u003e I see, so you're talking about prior to protocol completion, right\n\u003e after Alice sends Bob the success_tx. The reason this is not an issue\n\u003e is because Alice and Bob both had to misbehave in order for this to\n\u003e happen. Bob is misbehaving here because he should have published the\n\u003e success_tx before refund_tx_1 became valid, and Alice is misbehaving\n\u003e here because she should have sent the revoke_tx (which invalidates\n\u003e the success_tx) followed by refund_tx_2 (revealing her secret only\n\u003e AFTER Bob can no longer claim the BTC). In other words: yes, the\n\u003e protocol can fail if Alice and Bob together work towards that goal. A\n\u003e feature, not a bug. This won't happen if either of them doesn't want\n\u003e it to. I imagine this is difficult to model.\n\nRight. But it should be noted that it is not enough that Bob publishes\nsuccess_tx before refund_tx_1 became valid. The success_tx needs to be\nconfirmed before refund_tx_1 became valid.\n\nOnly Bob can spend success_tx so this is unlikely to be the practical\nproblem, unless the original fee of success_tx is too small and Bob\nepically screws up CPFP-ing it.\n\n\u003e \u003eBob will receive BTC, and the LTC can be locked forever, but Bob\n\u003e \u003edoesn't \n\u003e care, he got his BTC.\n\u003e \n\u003e No, because diagram step 5 comes before step 6 -- Alice won't give\n\u003e her key until she learns secretBob.\n\nI somehow missed it, and steps 5 and 6 in the diagram was not modelled\nat all (on the other hand, it made the model simpler and I had\nsomething working relatively quick). I now made the `signers_map` into\nvariable that can be changed to give Bob the ability to sign for Alice.\n\nWith that change, step 6 can be modelled, but this will add a bunch of\nnew txs to the model (each Alice\u0026Bob spend will have 'Bob unilateral\noverride' case)",
"sig": "1d1f76f92ffe2bc50806da5a4f79299f9309de333cdfb3786934be5404e080097b0a569610b357db37c6758de212ef09bce2305495b859e3bb3b34b2e50a1c58"
}