Topic: Hard forking with a mature LN (Read 291 times)

It's an interesting question for him because he hadn't thought about it yet so with that he'll surely talk to someone that will benefit his mind to think for an answer. It shows that he's not perfect and normal, the modern technologies and aspects nowadays are drastically changing the world so Andreas needs time to think about it that's why he paused.

I agree that he's not a developer of Bitcoin instead a spokesperson of it. Not all answered hypothetical questions are being implemented even though it's interesting in our minds.

I'm pretty sure the code itself contains logic that responds to forks, but I'm not at all familiar with it. The reason why that sort of thing hasn't appeared on the Lightning mailing list is that it's not about Lightning as a protocol, and presumably would be discussed on the bitcoin list instead



If we ignore the fact that removing the tx replay attack has been proposed (and so might be rendered irrelevant in future anyway), I agree that the effects of hard forks not by the Core devs will be negligible, and may even make such forks sufficiently more difficult to execute that they become less realistic (at a minimum the potential for forking changes to the consensus code becomes either narrower in scope, or more difficult to write in a way that maintains the stability of payment channels that exist on the new blockchain post-fork)

When it comes to hard forks that the Core devs design, I refer to my previous answer: both sets of devs, both for Lightning implementations and the Bitcoin blockchain are aware that problems are possible. If Andreas Antonopolous wasn't prepared to answer that question, then that's not a significant thing to happen, he had less than a few seconds to consider the implications and answered a general question with a decent general answer. An accomplished cryptocurrency programmer would almost certainly have provided a more substantial reply, but that's not Andreas' job.

Thanks BitCryptex.

I have re-thought about the "scam potential" in this context (I've also searched the lightning-dev mailing list for related discussion, but without success) and I now tend to agree that while a certain danger exists, it may not be relevant enough to change the Lightning code to follow hard forks, because of the following reasons:

1) Bigger hard forks almost always implement some form of replay protection, which would make this attack impossible because the old "state transaction" wouldn't be valid in this chain - both parties would have to re-sign it
2) A hard fork without replay protection, which results in a coin of significant value, is not an event that happens every day. If it happens, it is maybe enough to simply react manually (with a LN code update).
3) I have thought about a scenario when an attacker launches multiple forks without replay protection to make (automatic) following of every chain almost impossible and then attack LN channels, but it is very unlikely that these forks could achieve any significant price. So the attacker would sit on a lot of worthless coins and even is in danger to expose his secret and lose his BTC holdings in LN channels (if LN-penalty is used).

The airdrop problem (when in the case of hard forks with replay protection, LN users woudn't get benefitted automatically with "free coins") would persist, however. But are fork-airdrops really a critical feature for most users? BCH may have been an unique fork in the sense that it was able to achieve a price of 10% of the BTC price and more, while most other forks are, at best, near the 1% mark.

Currently, we can't do much to protect ourselves. Hard-forks may break all available rules and there is nothing we can do to prevent any future hard-fork from being used like you have described. The only solution that comes to my mind is syncing up the Lightning Network node with multiple chains but that would require some code changes and it would definitely take up too much resources. I am one of those who don't care about hard-forks like Bitcoin Gold and Bitcoin Private and I don't bother with claiming coins on the other chains. Think for a moment if running multiple full nodes is worth the hassle of setting them up and paying for a server which is powerful enough.

Who has said that Andreas A is a god that must know all answers? I just pointed at how the guy is usually very sharp and answers right away and he had to think about it.

He's not a developer but he isn't clueless when it comes to programing. He's as much of a developer as Jonh Nash was... both weren't really developers but this doesn't mean you can't be bright enough to understand and comment on the game theory involving Bitcoin. Not that im comparing Jonh Nash to Andreas, Jonh Nash was obviously a smarter guy and yet he wasn't a developer of Bitcoin, of Lightning or anything, and im sure if he took a look at Bitcoin he would understand the game theory involving the incentives and lack of them in the different situations that could arise, and that is as important as being a good developer whose shits gold in form of code but then ends up getting rekt because the game theory wasn't on point.

Andreas Antonopoulos doesn't know the answer to a question, WHAT ARE WE GOING TO DO


I'm not sure if anyone's noticed, but Andreas is just a guy who ends up in common Bitcoin based videos on the internet. He's not a developer for any implementation of Bitcoin or Lightning, or for anything. So what has his lack of preparation for such a question, 1 time, got to do with anything at all?

FYI, Lightning devs are aware of the issues with hard forks. Maybe the real problem is that you're not looking for information in a place you could actually expect to find answers.

Interesting question, and worthy to be discussed in depth.

For me, the problem could be actually the other way around: Could hard forks compromise Lightning's security model?

Let's have Alice and Bob opening a LN channel opened at block X, a hard fork at block Y, with chains BTC1 and BTC2 emerging from it.

In theory, if BTC2 doesn't implement replay protection measures, the channel would be active in both chains, BTC1 and BTC2, because it is based on transactions based on outputs of the part of the chain valid in both chains. So Alice and Bob  would have both "BTC1 coins" and "BTC2 coins" in the channel.

If I'm not missing something, this would make it mandatory for Lightning implementations to be aware of all chains that could emerge from hard-forks without replay protection, and to be able to broadcast "punishment transactions" into both networks (if using "LN-penalty"). Otherwise, Alice could scam Bob trying to settle the old channel state only at chain BTC2, if Bob is not aware of it.

I agree with Andreas that second layer solutions make hardforking more difficult. Lightning Network clients require their users to run a full Bitcoin node. What would happen if one of the channel's participants decided to follow some other hardfork? Would the other participant appear as offline in that case? You can still close the channel forcefully but this might affect the overall payment routing efficiency of the whole network.

I don't really think that it will make hard-forking completely impossible. Because of that, less hardforks might succeed in the future - possibly less airdrops, but the time before each important hardfork might have to be extended to avoid situations in which someone will not be able to update the node's software on time. There will be always one question, which chain is the right one? This might cause some disruption just like Bitcoin Cash did one year ago - merchants stopped accepting payments for some time.

In an scenario where many things are already working within LN and are tied to opened smart contracts and whatnot... does it make it harder to reach a consensus for hard fork?

If this doesn't make sense please see this video with Andreas A:

https://www.youtube.com/watch?v=4KiWkwo48k0&t=4m10s

Question: "Do you think second layer solutions to scale make hardforks exponentially harder to do"

So will LN, once a mature economy is running on it, make it even more impossible to hardfork? He has a hard time answering that, I would like to hear your thoughts on this.