3 ms·

LN's security model relies on being able to close a channel before a certain block. This means that there will be periods of time that paying the fee to close a

LN's security model relies on being able to close a channel before a certain block. This means that there will be periods of time that paying the fee to close a channel in time will be cost prohibitive and the security property evaporates. That being said we really should see exchange -> exchange txs be conducted over large LN channels, it could off load a lot of pressure off the chain.

Klathmon 9y ago
There is a method (which is already in LN) to prevent this which will stop the nSequence countdown if blocks are congested. From the LN paper: >For example, if a parent transaction output is spent by a child with a nSequence value of 10, one must wait 10 confirmations before the transaction becomes valid. However, if the timestop flag has been set, the counting of confirmations stops, even with new blocks. If 6 confirmations have elapsed (4 more are necessary for the transaction to be valid), and the timestop block has been set on the 7th block, that block does not count towards the nSequence requirement of 10 confirmations; the child is still at 6 blocks for the relative confirmation value. >This gives sufficient time and block-space for transactions at the current auxiliary timestop block height to enter into the blockchain, which can prevent systemic attackers from successfully attacking the system. It's not perfect by any means (a malicious miner with a significant portion of the hashpower could never set the timestop bit and spam the mempool at the same time), but it mostly removes this worry in a "normal congestion" scenario, and makes it require a pretty large portion of global hashpower as well as very VERY deep pockets to pull it off in a "malicious" scenario.
- XR0CSWV3h3kZWg 9y ago
  the main repo doesn't seem to have the string timestop in it. Nor does any of the bips. What BIP was this implemented in? Seems like a decent idea, although I don't see why miners would be incentivized to set timestop and the paper suggests that timestop is set to 1 whenever the block is full. The blocks are almost always full, so is it just up to the miner to choose if time is stopped or not?
  - Klathmon 9y ago
    I actually don't think there is a BIP for it yet... So I guess I was mistaken saying it's already part of LN (it's part of the paper, but not of any implementations). But the idea relies on miners "doing the right thing", and in this case since there isn't any downside for following this rule, the assumption is that miners will act in good faith. >The blocks are almost always full, so is it just up to the miner to choose if time is stopped or not? It's not necessarily if the block is full that the bit is set, but rather if there is "network congestion". This can mean many things to many people, but the assumption is that if fees go up significantly over a short period of time, that could indicate congestion which miners would set the bit on, or perhaps if the mempool of pending transactions gets over a certain BTC amount, it could be set. Also, I completely forgot to mention the other piece that makes all of this much less worrisome. If you need to broadcast any transactions to prevent "theft" of your BTC, you will receive all of the BTC in the channel by doing so. This gives you the ability to make a child-pays-for-parent transaction with the UXTOs from the channel closure (in a contract revocation scenario) with an absurdly high transaction fee to guarantee inclusion in the next block (basically using ALL of the other party's money as the transaction fee). Technically, the other party in the channel could also do a CPFP to try to get their transaction included before yours, but as long your side of the channel never went to 0 at any point, you will always be able to "outspend" the other party for transaction fees.

Klathmon 9y ago

There is a method (which is already in LN) to prevent this which will stop the nSequence countdown if blocks are congested. From the LN paper: >For example, if a parent transaction output is spent by a child with a nSequence value of 10, one must wait 10 confirmations before the transaction becomes valid. However, if the timestop flag has been set, the counting of confirmations stops, even with new blocks. If 6 confirmations have elapsed (4 more are necessary for the transaction to be valid), and the timestop block has been set on the 7th block, that block does not count towards the nSequence requirement of 10 confirmations; the child is still at 6 blocks for the relative confirmation value. >This gives sufficient time and block-space for transactions at the current auxiliary timestop block height to enter into the blockchain, which can prevent systemic attackers from successfully attacking the system. It's not perfect by any means (a malicious miner with a significant portion of the hashpower could never set the timestop bit and spam the mempool at the same time), but it mostly removes this worry in a "normal congestion" scenario, and makes it require a pretty large portion of global hashpower as well as very VERY deep pockets to pull it off in a "malicious" scenario.

XR0CSWV3h3kZWg 9y ago
the main repo doesn't seem to have the string timestop in it. Nor does any of the bips. What BIP was this implemented in? Seems like a decent idea, although I don't see why miners would be incentivized to set timestop and the paper suggests that timestop is set to 1 whenever the block is full. The blocks are almost always full, so is it just up to the miner to choose if time is stopped or not?
- Klathmon 9y ago
  I actually don't think there is a BIP for it yet... So I guess I was mistaken saying it's already part of LN (it's part of the paper, but not of any implementations). But the idea relies on miners "doing the right thing", and in this case since there isn't any downside for following this rule, the assumption is that miners will act in good faith. >The blocks are almost always full, so is it just up to the miner to choose if time is stopped or not? It's not necessarily if the block is full that the bit is set, but rather if there is "network congestion". This can mean many things to many people, but the assumption is that if fees go up significantly over a short period of time, that could indicate congestion which miners would set the bit on, or perhaps if the mempool of pending transactions gets over a certain BTC amount, it could be set. Also, I completely forgot to mention the other piece that makes all of this much less worrisome. If you need to broadcast any transactions to prevent "theft" of your BTC, you will receive all of the BTC in the channel by doing so. This gives you the ability to make a child-pays-for-parent transaction with the UXTOs from the channel closure (in a contract revocation scenario) with an absurdly high transaction fee to guarantee inclusion in the next block (basically using ALL of the other party's money as the transaction fee). Technically, the other party in the channel could also do a CPFP to try to get their transaction included before yours, but as long your side of the channel never went to 0 at any point, you will always be able to "outspend" the other party for transaction fees.