CJP [ARCHIVE] on Nostr: 📅 Original date posted:2016-09-27 📝 Original message: You mentioned two ...
📅 Original date posted:2016-09-27
📝 Original message:
You mentioned two examples of out-of-band distribution of the pre-image:
from B (role 2) to B (role 1), and as a scenario assumption of C
receiving the pre-image out-of-band. I think there is no risk in this.
I think out-of-band distribution of the pre-image is not only harmless:
it is even desirable. If one of the intermediate nodes blocks the
regular distribution, the other ones can commit the transaction on their
channels as soon as they receive the pre-image (in- or out-of-band). The
node on the payee-side of the blocking node can enforce being paid by
the HTLC mechanism, and the node on the payer-side doesn't mind not
having to pay (but can still pay voluntarily). The only nodes
potentially losing funds are the ones that don't follow the regular
protocol.
If you don't have out-of-band distribution of the pre-image, one
blocking node can potentially keep all HTLCs on his payer-side locked
for quite some time (until their time-outs). Eventually they end up
being rolled back, with the blocking node again being the only one
losing funds (which is good).
The advantage of having your HTLCs resolved quickly, so those funds can
flow in the opposite direction quickly, might be a sufficient incentive
for non-regular distribution of the pre-image. In Amiko Pay,
payer->payee distribution is added next to payee->payer distribution,
but it's a voluntary thing, and people might decide to remove it from
their version of Amiko Pay, without any real harm being done.
CJP
Rusty Russell schreef op di 27-09-2016 om 11:33 [+0930]:
> Imagine the simple case where I pay C $4 in fees, via B:
>
> $5 $5 $1 $1
> A ---> B ---> C ---> B ---> A
> 4days 3days 2days 1day
>
> B can simply use the H-preimage it gets from A to fulfill the HTLC A
> offered, gaining $4 and ignoring C. If C somehow gets the preimage
> out-of-band, it can claim the $5 from B and then B can get its $1 from
> C.
>
> The risk (for B) is that C will wait until the C->B HTLC has expired,
> *then* use the B->C HTLC to collect $5, leaving B out-of-pocket.
>
> Now, there's nothing special about this: the game happens for normal
> fees too, especially since we don't know if two apparently-distinct
> nodes are actually identical. It's just more tempting when the fees are
> high.
>
> Fun!
>
> Thanks,
> Rusty.
Published at
2023-06-09 12:46:44Event JSON
{
"id": "d25dc34305acc782e4cbfecbe38f66f0a66deb92ee7a6d541088faa51ad4c4bb",
"pubkey": "880fa8c3080c3bd98e574cfcd6d6f53fd13e0516c40ea3f46295438b0c07bdf5",
"created_at": 1686314804,
"kind": 1,
"tags": [
[
"e",
"83cded9dca6cfd62f1e7b45aca30eb16b6a092cf43346161527cbf4bfa217683",
"",
"root"
],
[
"e",
"c4440ac1044f08727f77b8f28fa0d1eae1f1562497545b0e451970fa721edbca",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2016-09-27\n📝 Original message:\nYou mentioned two examples of out-of-band distribution of the pre-image:\nfrom B (role 2) to B (role 1), and as a scenario assumption of C\nreceiving the pre-image out-of-band. I think there is no risk in this.\n\nI think out-of-band distribution of the pre-image is not only harmless:\nit is even desirable. If one of the intermediate nodes blocks the\nregular distribution, the other ones can commit the transaction on their\nchannels as soon as they receive the pre-image (in- or out-of-band). The\nnode on the payee-side of the blocking node can enforce being paid by\nthe HTLC mechanism, and the node on the payer-side doesn't mind not\nhaving to pay (but can still pay voluntarily). The only nodes\npotentially losing funds are the ones that don't follow the regular\nprotocol.\n\nIf you don't have out-of-band distribution of the pre-image, one\nblocking node can potentially keep all HTLCs on his payer-side locked\nfor quite some time (until their time-outs). Eventually they end up\nbeing rolled back, with the blocking node again being the only one\nlosing funds (which is good).\n\nThe advantage of having your HTLCs resolved quickly, so those funds can\nflow in the opposite direction quickly, might be a sufficient incentive\nfor non-regular distribution of the pre-image. In Amiko Pay,\npayer-\u003epayee distribution is added next to payee-\u003epayer distribution,\nbut it's a voluntary thing, and people might decide to remove it from\ntheir version of Amiko Pay, without any real harm being done.\n\nCJP\n\n\nRusty Russell schreef op di 27-09-2016 om 11:33 [+0930]:\n\n\u003e Imagine the simple case where I pay C $4 in fees, via B:\n\u003e \n\u003e $5 $5 $1 $1\n\u003e A ---\u003e B ---\u003e C ---\u003e B ---\u003e A\n\u003e 4days 3days 2days 1day\n\u003e \n\u003e B can simply use the H-preimage it gets from A to fulfill the HTLC A\n\u003e offered, gaining $4 and ignoring C. If C somehow gets the preimage\n\u003e out-of-band, it can claim the $5 from B and then B can get its $1 from\n\u003e C.\n\u003e \n\u003e The risk (for B) is that C will wait until the C-\u003eB HTLC has expired,\n\u003e *then* use the B-\u003eC HTLC to collect $5, leaving B out-of-pocket.\n\u003e \n\u003e Now, there's nothing special about this: the game happens for normal\n\u003e fees too, especially since we don't know if two apparently-distinct\n\u003e nodes are actually identical. It's just more tempting when the fees are\n\u003e high.\n\u003e \n\u003e Fun!\n\u003e \n\u003e Thanks,\n\u003e Rusty.",
"sig": "a043cbc828d7445833153b74c8e26758a07cbe41f429a395abfe89adf0ba953b54b7a59ac1ec13f754a777c8611649c6324c8a48238fce66292d02cfe72b1ebd"
}