Bitcoin Forum
June 27, 2024, 10:05:56 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How to handle fragmentation and later reunification?  (Read 196 times)
phosphor1897 (OP)
Newbie
*
Offline Offline

Activity: 26
Merit: 11


View Profile
January 01, 2019, 10:15:08 AM
Last edit: January 01, 2019, 02:11:35 PM by phosphor1897
Merited by suchmoon (4), DarkStar_ (4), ABCbits (2)
 #1

Hi

Surely this is not a new question, but I did not know what to search, so I apologize if this is a repeat. That said, I am hoping someone can shed some light on how bitcoin would behave in a hypothetical future scenario:

1. Consider a scenario in which the internet no longer exists, in that it has been broken up due to some sort of strife causing the internet backbone and ISPs to no longer work. Probably we won't have electrical grid either, but many crypto-minded people I know are prepared for this.
2. Say these people, members of their respective communities, create their own networks, effectively creating an internet (or intranet) for their own communities. From here they can serve their community many services. i.e. backups of wikipedia, provide various services, entertainment, cell service via open source solutions, etc.
3. One of the many services these communities can and will probably implement, is bitcoin, and they continue to mine blocks.
4. Many of these communities exist, and thus, many independent bitcoin chains (forks I guess?) with different histories.
5. Some years later, the internet backbone is re-enabled, and these bitcoin nodes across all these disparate communities now can reach each other.

What happens? Does the "longest chain win" and thus all communities, except that which had the longest chain somehow, are now considered untrue -- effectively reversing the transactions of all communities that reunify except the one that happened to have the longest chain?

Is there a cryptocurrency that is better suited to this type of fragmentation->reunification series of events, or does bitcoin handle this?

Another way to put it is how would these disparate bitcoin merge multiple histories and provide a managed way to deal with those "merge conflicts" ?

It seems to me that once fragmented, nodes should never re-unify, and should instead trade against each other on some market. i.e. BTC-CommunityX and BTC-CommunityY would have to both exist independently... but what if you're not an expert at blockchain and you're just the community member standing up all these services and bitcoin just happens to be the solution you went for, and suddenly the network reunifies, all your history is suddenly lost?

Thank you.

edit: fixed a run on sentence
reactorjuno
Member
**
Offline Offline

Activity: 322
Merit: 43


View Profile
January 01, 2019, 12:39:51 PM
 #2

My first intuitive response was that it would never re-unify as well, however I am no expert but that is a very interesting question.

I don't think anyone in "Bitcoin Discussion" will give you a constructive reply, this topic should be moved to "Development and technical discussion" here > https://bitcointalk.org/index.php?board=6.0  I asked a moderator to move it.
ABCbits
Legendary
*
Offline Offline

Activity: 2912
Merit: 7596


Crypto Swap Exchange


View Profile
January 02, 2019, 07:46:58 PM
Merited by suchmoon (4), phosphor1897 (2), reactorjuno (1)
 #3

What happens? Does the "longest chain win" and thus all communities, except that which had the longest chain somehow, are now considered untrue -- effectively reversing the transactions of all communities that reunify except the one that happened to have the longest chain?

By default, that happens expect it's not "longest chain win", but "chain with biggest proof-of-work/hash-rate"

Is there a cryptocurrency that is better suited to this type of fragmentation->reunification series of events, or does bitcoin handle this?

That depends on your perspective, but other cryptocurrency have different solutions such as :
1. On some PoS-based cryptocurrency, block made by address/node with biggest coins is considered as "longest chain"
2. Few cryptocurrency use validator who determine which transaction/block is valid

Another way to put it is how would these disparate bitcoin merge multiple histories and provide a managed way to deal with those "merge conflicts" ?

Solving merge conflict is impossible without human involvement, which makes decentralization pretty much useless. Additionally, you would mess up with blocks hash and re-computation is required.

It seems to me that once fragmented, nodes should never re-unify, and should instead trade against each other on some market. i.e. BTC-CommunityX and BTC-CommunityY would have to both exist independently... but what if you're not an expert at blockchain and you're just the community member standing up all these services and bitcoin just happens to be the solution you went for, and suddenly the network reunifies, all your history is suddenly lost?

Yes, i also agree it's the best solution.

But there are cheap way to prevent lose history when connected to nodes with "chain with biggest proof-of-work/hash-rate" and it's called checkpoint. Basically it makes a node reject block/chain which don't have same block hash on specific block height.
So if at least one people have enough knowledge to read documentation, source-code and made minor modification, then the problem is solved (since Bitcoin used checkpoint feature)

█▀▀▀











█▄▄▄
▀▀▀▀▀▀▀▀▀▀▀
e
▄▄▄▄▄▄▄▄▄▄▄
█████████████
████████████▄███
██▐███████▄█████▀
█████████▄████▀
███▐████▄███▀
████▐██████▀
█████▀█████
███████████▄
████████████▄
██▄█████▀█████▄
▄█████████▀█████▀
███████████▀██▀
████▀█████████
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
c.h.
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀█











▄▄▄█
▄██████▄▄▄
█████████████▄▄
███████████████
███████████████
███████████████
███████████████
███░░█████████
███▌▐█████████
█████████████
███████████▀
██████████▀
████████▀
▀██▀▀
aliashraf
Legendary
*
Offline Offline

Activity: 1456
Merit: 1174

Always remember the cause!


View Profile WWW
January 02, 2019, 09:22:15 PM
Merited by phosphor1897 (3)
 #4

Excellent problem, I've been working on this for a while  Wink
We would need some tweaks in the code,
difficulty should be readjusted,
block reward should be minimized or even cut temporarily,
a new opcode, CHOOSE_FRAGMENT should be implemented and in a specific period of time (like in a month) users can just use this opcode,
within this period a synchronization process should guarantee no "double fragment", ...

Thereafter fragments would be able to operate normally. Once the internet is back, UTXOs can be merged and agreed upon.

The merge phase needs another improvement which is needed right now and ignored for unknown reasons: fast synchronization using committed UTXOs and having pruned full nodes with minimum resource and fast bootstrap phase, which was my starting point to think about this scenario as one application.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!