13

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


12

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


6

Lightning payment channels are established by two parties Alice and Bob paying into a 2-of-2 multisignature address. Concurrently, they create two "exit-transactions", one for each participant which pay out the current allotment of the payment channel, txAliceExit_1 and txBobExit_1. These exit transactions lock the fund of the executing party for some blocks....


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

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

It seems that publishing a transaction that shouldn't be published (a "bad act") must involve publishing something the victim can use to unwind everything. Really, I should have asked the question that Murch answered for me (and the LN paper also answers it, but I didn't read it carefully enough the first time). That question is: "Does LN use ...


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

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

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 (...


2

When a channel is closed unilaterally, it requires two transactions by the closing party to move funds from a channel back into unilateral control. The closing party publishes their version of the commitment transaction to the network. The commitment transaction has a special condition for the closer's output. After the commitment transaction is included in ...


1

It's named "penalty transaction" by the specs :). Regarding your core question, you are right but this also requires this miner to be able to heal this block chain without a censored (the penalty) transaction. It therefore assumes that a single miner has more hashpower than the rest of the network combined. Thus it can be stated as such: The ...


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


1

Alice and Bob open a channel with a fixed balance equal to the amount in the multi-sig address. The channel opens with a balance sheet which includes proof for both Alice and Bob’s balance. Every update to the balance sheet requires action and cooperation from both Alice and Bob, so they must both be online, and each step is designed with contingencies ...


1

A commitment transaction is a transaction that sends person A's bitcoins to person A, and person B's bitcoins to an intermediate address (let's call it B*). B* can be spent by person B, but only after the input to that transaction is 1000 blocks deep (ie after about a week). But person A can also spend from B* if person A obtains B's commitment secret. So ...


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