We’re rewarding the question askers & reputations are being recalculated! Read more.
12

In the image below from Rusty Russell's Deployable Lightning paper, you can see a visualization of the commitment transactions and their outputs: For each payment in a channel, there are two commitment transactions generated, one for Alice and one for Bob. Both Alice and Bob sign both commitment transactions, so they're both valid transactions (although ...


8

When you open a lightning channel, you will receive from the other person their revocation_basepoint, and for each commitment transaction, you will send to the other person a per_commitment_point. The revocation_basepoint has a revocation_basepoint_secret which is a secret key that the other person keeps to themselves. The per_commitment_point has a ...


3

You are right. If the dishonest party publishes an outdated commitment transaction it is most likely be accepted by the Bitcoin network. The key trick is that the old state has an output script that gives the other party the opportunity to spend all outputs (even the one that was supposed to belong to the dishonest party) with the so called breach remedy ...


3

Yes that is correct. Bob's revocation secret is used as an insurance policy for Alice. If she loses it, Bob will be able to act maliciously and get away with it. However, I want to add two things: At least in c-lightning, there is the HSM secret. This serves as a 256-bit seed for an HD wallet from which all key pairs (for Commitment Txs as well as for ...


2

When the total capacity of the channel is less than it costs to close the channel, neither party has an incentive to close the channel. If broadcasting an outdated commitment transaction returns some funds to the cheating party, the cheated party can create a transaction to claim all funds from the cheater. In the worst case, the justice transaction can ...


2

Based on your comments, I think one fundamental issue you're missing is that to pay with LN, the other party has to be online at the time. There's no question of "what happens if Bob is offline" because if he is offline, no payment is possible. The other thing you need to know - especially if you meant that Bob is offline after the payment was completed - ...


2

Doublespends are not possible, because a payment on LN is only considered finalized once both payment channel owners have revoked the previous state of the payment channel by handing their partner a breach remedy that invalidates the previous state. Thus, Bob should not hand over whatever service Alice was purchasing until the payment is finalized. Once the ...


2

So the question is: are commitment transactions between two nodes revoked through hashlocks or through private keys exchange? Either way will work, but hashlocks are simpler. They're described in section 4 of the paper you linked. In a private key exchange-based system, you need to store every breach remedy transaction, (about 250 bytes) but in a hashlock ...


2

The cost is proportional to the number of committed HTLCs on the channel at the time of closure. Each HTLC has an output in the commitment transaction which pays into either a HTLC-success transaction script or a HTLC-timeout transaction script, depending on whether the HTLC was incoming our outgoing. The commitment also usually has an output to the spender (...


1

As far as I know the lightning clients that I know of (LND, c-lightning) do not offer this possibility through their API. So you'd be right to patch the code yourself. For LND, you should have a look at the ForceClose, which is the code that handles unilateral closing of a channel. It uses a CloseTx which it get's from the wire. If you could change that Tx ...


1

1) An invalid commitment transaction remains a valid transaction on the bitcoin network until the funding TX output is spent. Each commitment transaction, once signed will remain valid until the channel funding transaction output (2/2 multisig) is spent by another commitment transaction or closing transaction. Even if a newer state has been negotiated ...


1

The assumption in your last question is wrong, since there is no exclusivity in the publishing of both transactions. They can be accepted into the ledger and as a matter of fact, the subsequent transaction can only be accepted if the first one has been published on the network. The first transaction, the Commitment transaction, has two outputs. The first ...


Only top voted, non community-wiki answers of a minimum length are eligible