Joseph Poon [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-27 📝 Original message: On Mon, Jul 27, 2015 at ...
📅 Original date posted:2015-07-27
📝 Original message:
On Mon, Jul 27, 2015 at 11:20:54AM +0930, Rusty Russell wrote:
> Yes, I assume that the HTLC gets eliminated by a commitment transaction
> update at (or before) that time.
>
> We could add an additional delay for this case, but it seems like
> overengineering?
To ensure that the older version of the transaction does not get
broadcast through a credible threat, there needs to be some contestation
period for one's own HTLC when one is redeeming funds.
However, there are less elegant solutions that are possible as a
stop-gap before a full malleability fix which permits you to generate
child transactions before signing the parent.
Current/unexpired HTLCs will have the same payout and enforcement, but
there is a risk of broadcasting older Commitments and stealing the HTLC
payout, e.g. transactions that are believed to be timed out but whose
preimages are known after-the-fact. Theft of the HTLC via broadcast of
expired Commitments can be mitigated by having some funds in reserve
available on one's own channel balance to ensure honesty. In effect, the
total value of the HTLCs must be below one's own reserve balance (for
both parties). The reserve balance must not be used ever.
Note that this presumes dual-funder. I'll go into single-funder model
later.
For example, if Alice and Bob have a channel with the latest Commitment:
0.49 to Alice (0.02 in permanent reserve)
0.50 to Bob (0.02 in permanent reserve)
0.01 HTLC Alice to Bob
This is a valid HTLC, since Alice's current channel balance not
allocated to HTLCs is 0.49. This balance must be at or above 0.02 at
all times throughout the life of the channel, until Alice closes it out
or does a final payment to zero it out and close. Similarly, Bob also
must maintain a balance of 0.02 throughout the life of the channel.
The sum of all HTLCs going from Alice to Bob must be at or (preferably)
below this 0.02 limit at all times before closing out the channel.
The result is if Alice broadcasts an old Commitment, Bob is assured that
the balance of the HTLC will be at or below 0.02. The maximum Alice can
send will be 0.98 in the channel, so even if she attempts to steal the
HTLC, Bob can be made whole by taking back all his funds, as well as all
of Alice's funds as penalty. Even if he is unable to take back the HTLC,
he will take all of Alice's funds in reserve, which is less than the
balance of all HTLCs in transit from Alice to Bob at all times
throughout the historical life of the channel.
Depending on how willing you are to enforce the HTLC past this point,
you can make the script substantially simpler, as well.
To fund this using single-funder, one should be very cognizant of risks
related to systemic risks related to trust asymmetry of the channel
counterparties. If we construct a model using single-funder, it requires
very shallow rebalancing of funding for symmetric trust, i.e. Alice
opens a channel to Bob first, then Bob opens a channel to Alice. This
initial channel funding would probably have a very high OP_CSV value.
For the OP_CSV value to be this high and functional without DoS risks,
it requires the number of LN hops to be fairly low during this channel
setup phase (but won't matter after), as they may be potentially locking
up money for a longer period of time if the HTLC payment is not
fulfilled). For OP_CLTV only (without OP_CSV) I think it'll be to the
point where it *requires* setting up two channels with the same person.
Personally, I have some reservations for models which have funds in
permanent reserve, but this model is a fairly good stop-gap before a
real malleability fix (SIGHASH_NOINPUT or segregated witness). This
model should be able to work with just OP_CLTV (and with OP_CSV too),
but may not be quite as fun. Also, to maximize fun under this model to
mitigate when a counteparty is a jerk, you should always make sure the
amount in permanent reserve is *always above* (not equal to) the value
encumbered in HTLCs.
--
Joseph Poon
Published at
2023-06-09 12:43:46Event JSON
{
"id": "003b753a1e3c70941ec7abeba774dca64fe3fa63f34c2b2ea7ac174ad1e4a1f5",
"pubkey": "ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211",
"created_at": 1686314626,
"kind": 1,
"tags": [
[
"e",
"136120fa9d254826614cb6c81e857559ae6ab498d602841cc63c63ab6debd5a9",
"",
"root"
],
[
"e",
"ee16432a32be8cef69b19028827cc3f9213a3b231f704d89aa0cbc2cebcf6e59",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-07-27\n📝 Original message:\nOn Mon, Jul 27, 2015 at 11:20:54AM +0930, Rusty Russell wrote:\n\u003e Yes, I assume that the HTLC gets eliminated by a commitment transaction\n\u003e update at (or before) that time.\n\u003e \n\u003e We could add an additional delay for this case, but it seems like\n\u003e overengineering?\n\nTo ensure that the older version of the transaction does not get\nbroadcast through a credible threat, there needs to be some contestation\nperiod for one's own HTLC when one is redeeming funds.\n\nHowever, there are less elegant solutions that are possible as a\nstop-gap before a full malleability fix which permits you to generate\nchild transactions before signing the parent.\n\nCurrent/unexpired HTLCs will have the same payout and enforcement, but\nthere is a risk of broadcasting older Commitments and stealing the HTLC\npayout, e.g. transactions that are believed to be timed out but whose\npreimages are known after-the-fact. Theft of the HTLC via broadcast of\nexpired Commitments can be mitigated by having some funds in reserve\navailable on one's own channel balance to ensure honesty. In effect, the\ntotal value of the HTLCs must be below one's own reserve balance (for\nboth parties). The reserve balance must not be used ever.\n\nNote that this presumes dual-funder. I'll go into single-funder model\nlater.\n\nFor example, if Alice and Bob have a channel with the latest Commitment:\n0.49 to Alice (0.02 in permanent reserve)\n0.50 to Bob (0.02 in permanent reserve)\n0.01 HTLC Alice to Bob\n\nThis is a valid HTLC, since Alice's current channel balance not\nallocated to HTLCs is 0.49. This balance must be at or above 0.02 at\nall times throughout the life of the channel, until Alice closes it out\nor does a final payment to zero it out and close. Similarly, Bob also\nmust maintain a balance of 0.02 throughout the life of the channel.\n\nThe sum of all HTLCs going from Alice to Bob must be at or (preferably)\nbelow this 0.02 limit at all times before closing out the channel.\n\nThe result is if Alice broadcasts an old Commitment, Bob is assured that\nthe balance of the HTLC will be at or below 0.02. The maximum Alice can\nsend will be 0.98 in the channel, so even if she attempts to steal the\nHTLC, Bob can be made whole by taking back all his funds, as well as all\nof Alice's funds as penalty. Even if he is unable to take back the HTLC,\nhe will take all of Alice's funds in reserve, which is less than the\nbalance of all HTLCs in transit from Alice to Bob at all times\nthroughout the historical life of the channel.\n\nDepending on how willing you are to enforce the HTLC past this point,\nyou can make the script substantially simpler, as well.\n\nTo fund this using single-funder, one should be very cognizant of risks\nrelated to systemic risks related to trust asymmetry of the channel\ncounterparties. If we construct a model using single-funder, it requires\nvery shallow rebalancing of funding for symmetric trust, i.e. Alice\nopens a channel to Bob first, then Bob opens a channel to Alice. This\ninitial channel funding would probably have a very high OP_CSV value.\nFor the OP_CSV value to be this high and functional without DoS risks,\nit requires the number of LN hops to be fairly low during this channel\nsetup phase (but won't matter after), as they may be potentially locking\nup money for a longer period of time if the HTLC payment is not\nfulfilled). For OP_CLTV only (without OP_CSV) I think it'll be to the\npoint where it *requires* setting up two channels with the same person.\n\nPersonally, I have some reservations for models which have funds in\npermanent reserve, but this model is a fairly good stop-gap before a\nreal malleability fix (SIGHASH_NOINPUT or segregated witness). This\nmodel should be able to work with just OP_CLTV (and with OP_CSV too),\nbut may not be quite as fun. Also, to maximize fun under this model to\nmitigate when a counteparty is a jerk, you should always make sure the\namount in permanent reserve is *always above* (not equal to) the value\nencumbered in HTLCs.\n\n-- \nJoseph Poon",
"sig": "0c66a1805b3f15aadb91ae3c9f9f13a75241a7a90d73604f430ae5ece3440bc9b2885842cc77856e2fa69ae0df8cd81a3d3c3b7723cbd897cca42e5ff6ebd4c5"
}