From joseph at lightning.network Mon Jul 27 19:37:57 2015 From: joseph at lightning.network (Joseph Poon) Date: Mon, 27 Jul 2015 12:37:57 -0700 Subject: [Lightning-dev] Breach of contract? In-Reply-To: <87k2tmpdvl.fsf@rustcorp.com.au> References: <87k2tmpdvl.fsf@rustcorp.com.au> Message-ID: <20150727193714.GA16768@lightning.network> 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