Bitcoin Forum
June 18, 2019, 04:20:33 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Hard forking with a mature LN  (Read 182 times)
cellard
Legendary
*
Offline Offline

Activity: 1372
Merit: 1209


View Profile
August 07, 2018, 03:58:51 PM
 #1

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.
1560831633
Hero Member
*
Offline Offline

Posts: 1560831633

View Profile Personal Message (Offline)

Ignore
1560831633
Reply with quote  #2

1560831633
Report to moderator

0% MINING FEES FOR THE NEXT MONTH. GET PAID IN BTC, ETH, XMR or RVN.

www.cudominer.com Learn More
Easily run CudoOS from a USB flash drive.
Designed for rigs. Manage your mining remotely from Cudo Console.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1560831633
Hero Member
*
Offline Offline

Posts: 1560831633

View Profile Personal Message (Offline)

Ignore
1560831633
Reply with quote  #2

1560831633
Report to moderator
1560831633
Hero Member
*
Offline Offline

Posts: 1560831633

View Profile Personal Message (Offline)

Ignore
1560831633
Reply with quote  #2

1560831633
Report to moderator
1560831633
Hero Member
*
Offline Offline

Posts: 1560831633

View Profile Personal Message (Offline)

Ignore
1560831633
Reply with quote  #2

1560831633
Report to moderator
BitCryptex
Hero Member
*****
Offline Offline

Activity: 602
Merit: 766


Write @BitCryptex or quote my post to notify me


View Profile WWW
August 07, 2018, 06:32:55 PM
Merited by LeGaulois (1)
 #2

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.

d5000
Legendary
*
Offline Offline

Activity: 2114
Merit: 1493


Decentralization Maximalist


View Profile
August 07, 2018, 08:09:37 PM
 #3

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.

Carlton Banks
Legendary
*
Offline Offline

Activity: 2394
Merit: 1682



View Profile
August 07, 2018, 08:21:56 PM
Merited by Foxpup (3)
 #4

Huh

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.

Vires in numeris
cellard
Legendary
*
Offline Offline

Activity: 1372
Merit: 1209


View Profile
August 08, 2018, 01:55:05 PM
Merited by LeGaulois (1)
 #5

Huh

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.

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.
BitCryptex
Hero Member
*****
Offline Offline

Activity: 602
Merit: 766


Write @BitCryptex or quote my post to notify me


View Profile WWW
August 08, 2018, 05:50:19 PM
 #6

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.

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.

d5000
Legendary
*
Offline Offline

Activity: 2114
Merit: 1493


Decentralization Maximalist


View Profile
August 08, 2018, 07:11:35 PM
 #7

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.

Carlton Banks
Legendary
*
Offline Offline

Activity: 2394
Merit: 1682



View Profile
August 08, 2018, 07:43:24 PM
Merited by LeGaulois (1)
 #8

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:

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


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.

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.

Vires in numeris
leonair
Sr. Member
****
Offline Offline

Activity: 658
Merit: 285


KnowNoBorders.io


View Profile
August 09, 2018, 06:52:18 PM
 #9

Huh

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.

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.

   ▄▄██████▄▄
  ████████████
███▄▄
 ██████████████▀▀▀██▄
████████████████   ▀██▄
████████████████     ▀██
██████████████       ██▌
██████████████        ▐██
██▌▀▀██████▀▀         ▐██
▐██                   ██▌
 ██▄                 ▄██
  ▀██▄             ▄██▀
    ▀██▄▄▄     ▄▄▄██▀
      ▀▀█████████▀▀





███████████████████████████
███████████▀▀         ▀▀███
████████▀   ▄▄██▄  ▀█▄  ▀██
██████▀  ▄████████▄  ▀█  ██
████▀  ▄██████▄▀  ██▄    ██
███▀  ██████▄▀  ▄▀████▄  ██
██▀  █████▄▀  ▄▀██████  ▄██
██  ▀███▄▀  ▄▀███████  ▄███
██    ▀██▄▄▀███████▀  ▄████
██  █▄  ▀████████▀  ▄██████
██▄  ▀█▄  ▀██▀▀   ▄████████
███▄▄         ▄▄███████████
███████████████████████████
███████████████████████████
████████▀▀       ▀▀████████
█████▀   ▄ ▀███▀ ▄   ▀█████
████  ▄████▄ ▀ ▄████▄  ████
███  ▄ ▀███▀ ▄ ▀███▀ ▄  ███
██  ▄██ ▀▀ ▄███▄ ▀▀ ██▄  ██
██  █▀ ▄█ ███████ █▄ ▀█  ██
██   ▄███▄ █████ ▄███▄   ██
███  ████▀ ▄▄▄▄▄ ▀████  ███
████  ▀ ▄ ▀█████▀ ▄ ▀  ████
█████▄  ▀▀▄ ███ ▄▀▀  ▄█████
████████▄▄       ▄▄████████
███████████████████████████
████████     INDUSTRY LEADING BITCOIN SPORTSBOOK     ████████
LIVE
STREAMING
DAILY PRICE
BOOSTS
LIVE DEALER
CASINO
FAST & SECURE
PAYMENTS
███████████████████████████
████████▀▀       ▀▀████████
█████▀  ▄█▄  ▀  ▄▄   ▀█████
████  ▄  ▀    ▀█████▄  ████
███  ▀█▀   ▀█▄   ▀▀██▄  ███
██  ▄    █▄  ▀██▄▄  ▀█▄  ██
██  █▀ ▄  ▀█▄  ▀███▄  ▀  ██
██    ▄██  ▀██▄  ▀███▄   ██
███  ▀████  ▀███▄  ▀█▀  ███
████  ▀████  ▀████▄    ████
█████▄   ▀▀█▄  ▀▀▀   ▄█████
████████▄▄       ▄▄████████
███████████████████████████
███████████████████████████
████████▀▀ █████ ▀▀████████
█████▀    ▄█████▄    ▀█████
██████▄▄█▀▀ ▄▄▄ ▀▀█▄▄██████
███▀███▀ ▄███▀███▄ ▀███▀███
██   █ ▄██▀     ▀██▄ █   ██
██   █ ██         ██ █   ██
██   █ ▀██▄▄█ █▄▄██▀ █   ██
███▄███▄ ▀██▄▄▄██▀ ▄███▄███
██████▀▀█▄▄ ▀▀▀ ▄▄█▀▀██████
█████▄    ▀█████▀    ▄█████
████████▄▄ █████ ▄▄████████
███████████████████████████





[.
WIN WITH US!
]
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!