Bitcoin Forum
May 07, 2024, 08:56:49 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How to do a clean hard fork leaving 2-chains  (Read 957 times)
danielW (OP)
Sr. Member
****
Offline Offline

Activity: 277
Merit: 253


View Profile
February 21, 2016, 09:50:00 AM
 #1

Ok so the scenario: An economic minority wants to fork bitcoin to increase block size, and leave 2 viable coins and chains.

So to do that it would be necessary to change the proof-of-work algorithm in the hard-fork. This will mean the bigger chain hash-power can not double spend the smaller chain trivially.


- Ok The first criteria for a clean hard fork is that people who have spending control of coins on the old chain have exclusive spending control of coins on new chain.

 
This criteria is satisfied by default in a hard fork.


- Second criteria relates to transactions of the separate coins and I would ask for some input as to how this could be done.

1 scenario) transaction on new chain will not be valid  transactions on old chain. Transactions on old chain will be valid transactions on new chain.  

2) transactions on new chain will not be valid transactions on old chain. Transactions on old chain will not be valid transactions on new chain.  


Essentially I just want advice on how a clean hard fork into a altcoin could be done so that the two chains can function alongside each other.
1715115409
Hero Member
*
Offline Offline

Posts: 1715115409

View Profile Personal Message (Offline)

Ignore
1715115409
Reply with quote  #2

1715115409
Report to moderator
1715115409
Hero Member
*
Offline Offline

Posts: 1715115409

View Profile Personal Message (Offline)

Ignore
1715115409
Reply with quote  #2

1715115409
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715115409
Hero Member
*
Offline Offline

Posts: 1715115409

View Profile Personal Message (Offline)

Ignore
1715115409
Reply with quote  #2

1715115409
Report to moderator
1715115409
Hero Member
*
Offline Offline

Posts: 1715115409

View Profile Personal Message (Offline)

Ignore
1715115409
Reply with quote  #2

1715115409
Report to moderator
Jet Cash
Legendary
*
Offline Offline

Activity: 2702
Merit: 2456


https://JetCash.com


View Profile WWW
February 21, 2016, 03:34:28 PM
 #2

Why would you want to do this?

Wouldn't it be easier just to start an alt.

Offgrid campers allow you to enjoy life and preserve your health and wealth.
Save old Cars - my project to save old cars from scrapage schemes, and to reduce the sale of new cars.
My new Bitcoin transfer address is - bc1q9gtz8e40en6glgxwk4eujuau2fk5wxrprs6fys
achow101
Staff
Legendary
*
Offline Offline

Activity: 3388
Merit: 6631


Just writing some code


View Profile WWW
February 21, 2016, 05:11:42 PM
 #3

1 scenario) transaction on new chain will not be valid  transactions on old chain. Transactions on old chain will be valid transactions on new chain.  
Well if participants on the altcoin had tainted their coins with some of the coins produced after the fork, then the transactions on the new chain would be invalid on the old chain. Any transaction that spent outputs created previous to the fork would be valid on the new chain. However any transaction that spent outputs created after the fork would not.

2) transactions on new chain will not be valid transactions on old chain. Transactions on old chain will not be valid transactions on new chain.  
That is harder to do, in fact, I don't think it is possible. But you can completely separate into an altcoin by changing other parameters. Every coin has 4 "magic" bytes which identify the coin that the block or transaction belongs to. By changing the magic bytes, the blocks and transactions of one chain are ignored by the other, essentially separating the two networks.

Also, to do a fork like this, you need to set checkpoints into the forked blockchain and when it does fork, it is easier if the forked part is an invalid block on the old blockchain.

DannyHamilton
Legendary
*
Offline Offline

Activity: 3388
Merit: 4653



View Profile
February 21, 2016, 11:38:36 PM
 #4

If you are intentionally trying to fork with an economic minority, I'd think it wouldn't be too difficult to redefine the transaction outputs in your fork such that transactions which are valid in one fork are invalid in the other fork.  As such, any blocks on one fork would also be invalid on the other fork.

Seems like a foolish thing to do, but it shouldn't be too difficult to accomplish.
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1132


View Profile WWW
February 22, 2016, 12:06:24 AM
 #5

1 scenario) transaction on new chain will not be valid  transactions on old chain. Transactions on old chain will be valid transactions on new chain.  
Well if participants on the altcoin had tainted their coins with some of the coins produced after the fork, then the transactions on the new chain would be invalid on the old chain. Any transaction that spent outputs created previous to the fork would be valid on the new chain. However any transaction that spent outputs created after the fork would not.

2) transactions on new chain will not be valid transactions on old chain. Transactions on old chain will not be valid transactions on new chain.  
That is harder to do, in fact, I don't think it is possible. But you can completely separate into an altcoin by changing other parameters. Every coin has 4 "magic" bytes which identify the coin that the block or transaction belongs to. By changing the magic bytes, the blocks and transactions of one chain are ignored by the other, essentially separating the two networks.

Also, to do a fork like this, you need to set checkpoints into the forked blockchain and when it does fork, it is easier if the forked part is an invalid block on the old blockchain.
just changing the magic number is not enough, that only affects the network protocol.
Which means if all other parameters are the same, just rebroadcasting on the other network and it is accepted (assuming it is valid in other ways)

James

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1132


View Profile WWW
February 22, 2016, 12:09:47 AM
 #6

I think you would need at least a 4 hour gap to avoid the +/-2 hour leeway on timestamps and additionally some other method to avoid double spending based on using tainted inputs.

Actually it wont be double spending if to use a tainted input as it is following the protocol for both forks.

In essence having two versions after a hardfork doubles the coin supply. Kind of a little violation of the 21 million coin promise.

But if the ripple way is acceptable, then push forward for this

James

See: https://bitcointalk.org/index.php?topic=1157679.0

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
spartacusrex
Hero Member
*****
Offline Offline

Activity: 718
Merit: 545



View Profile
February 22, 2016, 05:39:57 PM
 #7

I think I see where you're coming from..

If you could 'muck about' with the protocol a bit, this might work :

In each transaction you would need to but a block hash ID which would need to be in the final chain that this txn is eventually added to. (This has been discussed before as a way for users to vote for their preferred chain. This is not currently a feature of Bitcoin.)

This way your txn could only be added to one fork. Not both.

Then, if someone can show you have signed a txn for a fork chain, you balance on the other chain, goes to zero.

Example :

Bob has 10 btc.

Then there is fork and 2 chains appear.

Bob now has 10 btc on each chain.

Bob spends his coins and chooses 1 of the chains. (By choosing a block hash ID in the chain he wants) 

Sam posts Bob's txn on the other fork chain, and this sets Bob's address to zero, by burning the coins. hehe..

Now both chains can exist, without everyone getting double their money. And txns on 1 chain are not valid on the other.

..

ps.. Just thinking out loud really.. can see some timing issues rearing up..

pps.. Just wondering if you could then trade/exchange from 1 fork chain to the other.. hmm..

Life is Code.
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1132


View Profile WWW
February 22, 2016, 10:46:42 PM
 #8

I think I see where you're coming from..

If you could 'muck about' with the protocol a bit, this might work :

In each transaction you would need to but a block hash ID which would need to be in the final chain that this txn is eventually added to. (This has been discussed before as a way for users to vote for their preferred chain. This is not currently a feature of Bitcoin.)

This way your txn could only be added to one fork. Not both.

Then, if someone can show you have signed a txn for a fork chain, you balance on the other chain, goes to zero.

Example :

Bob has 10 btc.

Then there is fork and 2 chains appear.

Bob now has 10 btc on each chain.

Bob spends his coins and chooses 1 of the chains. (By choosing a block hash ID in the chain he wants) 

Sam posts Bob's txn on the other fork chain, and this sets Bob's address to zero, by burning the coins. hehe..

Now both chains can exist, without everyone getting double their money. And txns on 1 chain are not valid on the other.

..

ps.. Just thinking out loud really.. can see some timing issues rearing up..

pps.. Just wondering if you could then trade/exchange from 1 fork chain to the other.. hmm..
The fundamental issue about anything like this is that if you can understand all that you can make a windfall, at the cost of some poor small business that didnt

It seems no way to force everybody to run the latest software at the same moment, especially high volume places that might not want to shutdown until the slow time of day (or week)

So any solution needs to take into account that pre-hardfork and post-hardfork versions are running and that there will be bots written by guys that understand the above trying to find the laggards who still honor the invalid utxo

That is why a total shutdown seems to be required to get past not only the +/- 2 hours (4 hours worst case) timestamp tolerance, but migration time.

It could be like Hardfork Saturday GMT (that is the only day of the week that is a weekend all over the world).

It should be really easy to get all 6000+ nodes to coordinate the shutdown and update at the same time.

James

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
watashi-kokoto
Sr. Member
****
Offline Offline

Activity: 682
Merit: 269



View Profile
February 24, 2016, 12:06:28 PM
 #9

The easiest way is to create an altcoin. Simply create a premine, giving free altcoin to all Bitcoin wallets. Next, start mining the altcoin, generating new coins following the Bitcoin schedule.

If your marketing strategy is sound, your altcoin will be able to reach the same level of adoption the coin called Clams.
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1132


View Profile WWW
February 24, 2016, 01:28:39 PM
 #10

The easiest way is to create an altcoin. Simply create a premine, giving free altcoin to all Bitcoin wallets. Next, start mining the altcoin, generating new coins following the Bitcoin schedule.

If your marketing strategy is sound, your altcoin will be able to reach the same level of adoption the coin called Clams.
last I checked Clams tx per block is about 5 per hour: http://khashier.com/chain/Clam
BTC usage is closer to 8000

anyway the topic is about how to do a clean hardfork and end up with 2 bitcoins, each with whatever amount of people choose to move to it. without allowing for double spends or doubling the coin supply.

I have just the advice: DONT DO IT

James

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
watashi-kokoto
Sr. Member
****
Offline Offline

Activity: 682
Merit: 269



View Profile
February 28, 2016, 07:26:32 PM
 #11

I have just the advice: DONT DO IT


DO IT

Now you have every possible advice Smiley
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!