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
š 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