4

The first three scenarios are indeed possible, the last one is identical to the second. This is called a collaborative close. It has the advantage of using a lower on-chain fee since the transactions are not time critical and the users get their coins back immediately (no dispute time). If the other node is unresponsive (offline or doesn't sign a ...


4

As far as I understand this is not needed. Let us assume we have an congested mempool and someone publishes an old channel state. This transaction will not be mined directly as the mempool is congested. The timelock during which this transaction can be revoked via the penalty mechanism is a relative one and starts as soon as the transaction is mined. So, ...


3

A lightning funding transaction is a P2WSH transaction, which appears on chain as paying to some random-looking script hash, but the redeemScript which can unlock and spend the money is not revealed on chain until the transaction gets spent (which is when the channel gets closed in Lightning's case). You can recreate the redeemScript if you know the funding ...


3

I don't know exactly how static channel backups are implemented in lnd and what is being saved there but I can give you some general thoughts and at least a partial answer. If A and B both lost their channel state but still have their master key / mnemonic seed they can probably derive the key that was used in the 2-2 multisig wallet that is used to encode ...


3

Many! If you look at the BOLTs ( lightning RFC) you will find many situations in which nodes must fail a channel (meaning a force close) if something happens in an unexpected way while communicating with a channel partner. This could be even as easy as an unresponsive channel partner while settling an htlc in which case you have to settle the htlc onchain. ...


2

Sorry René, it seems you fell into a Bcasher trap here ;) OP phrased his question very vaguely and then proceeded to cry CENSORSHIP when you admitted there might be some truth contained in what he alluded to. In reality, the case OP is alluding to is a very rare edge case that could ONLY occur, if the following things are ALL true: 1. You don't back up ...


2

The actual script implemented on Lightning Network is a little bit different from what you quoted. This is the script below and the specification is here OP_IF # Penalty transaction <revocationpubkey> OP_ELSE `to_self_delay` OP_CSV OP_DROP <local_delayedpubkey> OP_ENDIF OP_CHECKSIG I've created that transaction on ...


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

This will get easier in the future as exchanges will be implementing deposits and withdrawals via LN. At this time, if you need to deposit BTC and the exchange does not support LN deposits, I'm afraid you are stuck with closing channels for now. Perhaps there will be a way soon to rebalance the channels to minimize the number of closures required. ...


1

I will only give the answer for a mutual close. The situation for unilateral (forced) channel close should be similar only that you have too look in the commitment transactions and that you have to look for local_delayedpubkey instead of localpubkey. You can look at BOLT 03: Transactions where it is specified. In particular the section closing transaction. ...


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