Question about closing channels

Could someone please explain exactly what happens when someone tries to "cheat", and is punished by losing all of their funds in their open channel?

Is the channel closed automatically when this happens? If so, how is the base layer tx fee amount controlled? How would the person (or people) being cheated know it's happening?

Practically, is this even likely to ever happen?

I've not been able to find a detailed explanation of this process. I'm sure there's an AA video out there somewhere that I just can't find.

Thanks in advance for any information or article/video links.

Posted May 29, 2019, 4:40 AM UTC

19
technifocal•

Could someone please explain exactly what happens when someone tries to "cheat"

Basically, whenever you sign a transaction the two participants of the channel get slightly different transactions.

Alice gets:

  1. Alice can take all the money in 7 days
  2. Bob can take all the money now, assuming he knows a secret that Alice knows

Bob gets:

  1. Bob can take all the money in 7 days
  2. Alice can take all the money now, assuming he knows a secret that Bob knows

When Alice/Bob update the transaction, they will reveal to each other their previous secret keys (this is called "reveal to revoke"). Alice now knows that if Bob starts the process to take the money in 7 days, she can steal all his funds and Bob knows the same thing as well. This is what happens when somebody tries to cheat (I.E. broadcast an old version of the transaction).

The "7 days" is actually measured in blocks, and can vary between each party. You can set your remote parties CSV with lnd using:

lnd openchannel --remote_csv_delay AMOUNT_IN_BLOCKS_HERE

1 block ~= 10 minutes

Is the channel closed automatically when this happens?

Yes, the justice transaction will steal all funds available in the channel and give them all to the legitimate party that caught the illegitimate party stealing.

How would the person (or people) being cheated know it's happening?

The software should deal with it automatically, and you'll just see your on-chain balance go up by more than expected. If you run:

lncli closedchannels

You'd see, I believe, BREACH_CLOSE as the close_type. All close statuses are available here

If so, how is the base layer tx fee amount controlled?

This is deemed when you open the transaction. Unilateral closes are always way more expensive than co-operative closes as it literally is a race against the clock. If the csv_delay expires, your counterparty can steal your funds.

You can see the agreed unilateral close fee with lnd by running:

lncli listchannels

"fee_per_kw" I believe is the agreed closing fee.

I also believe that there might be an upgrade to Lightning in the future that sets this value very low, then allows CPFP (child pays for parent) transactions to occur along with RBF (replace by fee) to slowly increase the fee as the clock gets closer to your counterparty being able to steal your funds.

Practically, is this even likely to ever happen?

No, because your counterparty is risking all their funds. Though, if you've been offline for six months then maybe.

I've not been able to find a detailed explanation of this process. I'm sure there's an AA video out there somewhere that I just can't find.

I think that Thaddeus Dryja has a video out there somewhere on this.

2
LinkamusOP•

Thank you for the detailed response. I suppose a concern I would have when it comes to setting the close fee when opening, is that you really don't know how congested the mempool is going to be when you close. I suppose RBF or CPFP could compensate for this like you said. However, a non-technical person is not going to understand this, so I'm curious to know how opening and closing fees in general are going to be automated in the future for the average Bitcoin user.

1
technifocal•

so I'm curious to know how opening and closing fees in general are going to be automated in the future for the average Bitcoin user.

I'm not affiliated with any of the major Lightning clients development, nor the BOLTs or design. I just want to get that out there. I do zero work for Lightning-based systems.

HOWEVER

I believe, and I might be wrong, that these are going to be automated in this sort of fashion:

  1. Open channel, set a really low unilateral close fee. Just enough to actually get relayed by clients (say, 1 sat/byte)
  2. If you need to COOPERATIVE_CLOSE a channel, then both your node and the counterparty node agree on a fee related to the current mempool, sign it, and close the channel. End of.
  3. If you need to unilaterally close the channel, whether due to a FORCE_CLOSE or BREACH_CLOSE, then you broadcast the previously signed extremely low fee (1 sat/byte) transaction
  4. Your node immediately broadcasts another transaction, once again for 1 sat/byte spending the above UXTO and moving it to an address solely owned by the user of the node
  5. Over time, directly related to the mempool's usage and how much longer you have left on until your counterparty can take the funds, you increase the fee of the child transaction. This is done fully automatically. For example, if you had 2016 blocks (2 weeks) until your counterparty could take your funds, every block you might consider raising the fee by 0.5 sats per byte (ending up at a total of 1008 sats per byte). Eventually, your transaction will be added to a block and will stop this reverse-bid process.

The above could all be 100% automated by your node, without the user ever really seeing it. Remember, in the end (with splicing/amp/whatnot) the user will never really know the difference between on-chain/off-chain other than on-chain has more fees.

Once again, this is just something I've read somewhere. I'm not 100% sure where, and it might have no relation to the actual design choices of what the various Lightning implementations want to do.

3
LinkamusOP•

!lntip 100

1
lntipbot•
1