Forked block chain

[wingding]

If I want to grow a new private branch of the blockchain, can I do that and change the rules for block rewards? (with a rewritten client)  If this has been discussed previously I'd be thankful to know.

[Stephen Gornick]

If I want to grow a new private branch of the blockchain, can I do that and change the rules for block rewards? (with a rewritten client)  If this has been discussed previously I'd be thankful to know.

Are you asking about a hard fork that lets all existing bitcoins be spent on nodes running your rewritten client?  Yes, that's possible.  But blocks mined by your clients would not be accepted by any peer nodes running the Bitcoin-Qt/bitcoind client.

If you wanted to communicate among other peers who want to be on the fork with you then you could change the port number, set up your own dnsseed server and have your own little forked chain running, sure.  Knock yourself out ... if you have 400 Ghash/s (equivalent to nearly 7 Avalon ASICs) you'll get one block mined per day, so nearly a week for a transaction to reach six confirmations.  [Though you could edit this revised client to have it manually reset difficulty as-of a certain block]

[wingding]

If I want to grow a new private branch of the blockchain, can I do that and change the rules for block rewards? (with a rewritten client)  If this has been discussed previously I'd be thankful to know.

Are you asking about a hard fork that lets all existing bitcoins be spent on nodes running your rewritten client?  Yes, that's possible.  But blocks mined by your clients would not be accepted by any peer nodes running the Bitcoin-Qt/bitcoind client.

If you wanted to communicate among other peers who want to be on the fork with you then you could change the port number, set up your own dnsseed server and have your own little forked chains, sure.  Knock yourself out ... if you have 400 Ghash/s (equivalent to nearly 7 Avalon ASICs) you'll get one block mined per day, so nearly a week for a transaction to reach six confirmations.  [Though you could edit this revised client to have it manually reset difficulty as-of a certain block]

I guess my 'new' network can adjust difficulty to maintain similar block rate as for btc. However most important, I want different rules for block rewards, constant reward, not halving each 4 year. So the question is if there is anything that stops me from doing that since I am branching off the original chain.

[2_Thumbs_Up]

I've always thought of this for a way to start an alt-coin. The fact that all bitcoin holders automatically becomes alt-coin owners could give it som traction. Or it would just give people some free fraction of bitcoins as they trade their alt-coin for bitcoins as soon as the first exchange opens.

You would have to change the algorithm to find blocks though or you will be vulnerable to a 51% attack from the bitcoin mining pools.

[marra]

If I want to grow a new private branch of the blockchain, can I do that and change the rules for block rewards? (with a rewritten client)  If this has been discussed previously I'd be thankful to know.

Are you asking about a hard fork that lets all existing bitcoins be spent on nodes running your rewritten client?  Yes, that's possible.  But blocks mined by your clients would not be accepted by any peer nodes running the Bitcoin-Qt/bitcoind client.

If you wanted to communicate among other peers who want to be on the fork with you then you could change the port number, set up your own dnsseed server and have your own little forked chains, sure.  Knock yourself out ... if you have 400 Ghash/s (equivalent to nearly 7 Avalon ASICs) you'll get one block mined per day, so nearly a week for a transaction to reach six confirmations.  [Though you could edit this revised client to have it manually reset difficulty as-of a certain block]

I guess my 'new' network can adjust difficulty to maintain similar block rate as for btc. However most important, I want different rules for block rewards, constant reward, not halving each 4 year. So the question is if there is anything that stops me from doing that since I am branching off the original chain.

if you try to do that the correct term would be as if you dropped the fork on the floor...

[TierNolan]

I guess my 'new' network can adjust difficulty to maintain similar block rate as for btc. However most important, I want different rules for block rewards, constant reward, not halving each 4 year. So the question is if there is anything that stops me from doing that since I am branching off the original chain.

You could fork the chain by updating a checkpoint in the source code.  You need to mine one block and then set that block's hash as a checkpoint.  You then need to update the reward function in the code (wherever it is), and remove the decaying reward rule.  One problem you could have is that there is a max money constant somewhere, set to 21 million. 

[Stephen Gornick]

So the question is if there is anything that stops me from doing that since I am branching off the original chain.

When you go off on your own fork you can do whatever you want, including changing the rules for the block reward subsidy.  But again, that only exists on your own fork.  It doesn't matter if you start with your own genesis block or extend off of a bitcoin block.  

You would want to configure a node to relay transactions received on port 8333 so that they also get relayed to your fork.   Some of those transactions will be valid even on your fork but over time more and more transactions that are valid Bitcoin transactions will not confirm on your fork because they include an invalid INPUT as far as your fork is concerned.

The real risk is someone using a copy of their Bitcoin wallet.dat (or the private keys from that wallet.dat) with your fork -- the coins pre-fork are still valid spends on the Bitcoin blockchain as well as on your fork.  So it would be way to easy to lose money by accidentally sending valuable pre-fork coins thinking they are only as valuable as the post-fork coins.

Ya, that would get ugly in a hurry.

[astor]

I don't see a problem with this, on the contrary it seems like an excellent idea.

Your fork will have coins pre-distributed so you don't have the problems with early adaptors.

You could even apply some filter that defines which of the older coins are valid.  Or you could exclude all addresses with more than X coins.

Do whatever that maximizes the spread of the coins and minimizes variance.  The initial allocation of coins is one of the major problems that Satoshi had in his papers, and that is the reason for the constant rate given to miners.  However with an existing economy you can utilize the dillution that has already happened to your advantage.

I think this is a superior way of bootstrapping an alt-chain to maximize the economy.

[Stephen Gornick]

Your fork will have coins pre-distributed so you don't have the problems with early adaptors.

You might be overlooking the obvious. 

The spend transactions from the "pre-distributed"  coins would be valid on both sides of the fork.  Thus if bitcoin is trading at $90, let's say, and you are asking me to pay 10,000 ?TC for a pizza then I'm certainly not going to be using my pre-distributed coins and instead would only be using ones whose coinbase occurred post-fork.

And even putting that aside, you've got a fork that is extremely vulnerable to 51% attack.

[astor]

Your fork will have coins pre-distributed so you don't have the problems with early adaptors.

You might be overlooking the obvious. 

The spend transactions from the "pre-distributed"  coins would be valid on both sides of the fork.  Thus if bitcoin is trading at $90, let's say, and you are asking me to pay 10,000 ?TC for a pizza then I'm certainly not going to be using my pre-distributed coins and instead would only be using ones whose coinbase occurred post-fork.

And even putting that aside, you've got a fork that is extremely vulnerable to 51% attack.

I don't understand your objection.  The coins that are valid on both sides of the fork have nothing to do with each other.  They have no effect on each other.  If you spend 10.000 ?TC of pre-forck ?TCs, it has no effect on your bitcoins.

[TierNolan]

I don't understand your objection.  The coins that are valid on both sides of the fork have nothing to do with each other. 

The point is that if you sign the transaction in one fork, the recipient can submit the same transaction to the main chain and also get your coin there.

The only way around it is to have a different signing system on the fork.  For example, the rule could be that a script is valid on the fork if the signature is valid for the script or the script with "ALT-CHAIN-1" appended to it.

Transactions on the main chain would continue to be valid on the fork, but once you sign a coin to a script with the suffix, then they are no longer transferred in lock step.

[wabber]

The blockchain is publicly available data. You can print it out to use it as your toilet paper or you can use it to feed your program with data. What your  program does with that data is up to your program only.

[markm]

A constant block-reward fork was already create a couple of years ago, it is called GRouPcoin and the reward is 50 coins per block forever.

-MarkM-

[wingding]

I don't see a problem with this, on the contrary it seems like an excellent idea.

Your fork will have coins pre-distributed so you don't have the problems with early adaptors.

You could even apply some filter that defines which of the older coins are valid.  Or you could exclude all addresses with more than X coins.

Do whatever that maximizes the spread of the coins and minimizes variance.  The initial allocation of coins is one of the major problems that Satoshi had in his papers, and that is the reason for the constant rate given to miners.  However with an existing economy you can utilize the dillution that has already happened to your advantage.

I think this is a superior way of bootstrapping an alt-chain to maximize the economy.

Yes, it is more or less what I had in mind. But that is another discussion and can be found here:
https://bitcointalk.org/index.php?topic=181488.0

[DannyHamilton]

I don't understand your objection.  The coins that are valid on both sides of the fork have nothing to do with each other. 

The point is that if you sign the transaction in one fork, the recipient can submit the same transaction to the main chain and also get your coin there.
- snip -

If I found myself at all tempted to use both forks, I think I'd create a set of addresses that I owned in both forks and send all my pre-fork coins to my own addresses to split them.

Example:

Pre-fork output for 10 BTC is sent to address 1AAAAA

Fork occurs

I create address 1BBBBBB and 1CCCCCC in both wallets.

I transmit a transaction to my BTC peers spending the 10 BTC output previously received at 1AAAAA and assigning 10BTC to address 1BBBBBB.
I transmit a transaction to my alt-coin peers spending the 10 BTC output previously received at 1AAAAA and assigning 10BTC to address 1CCCCCC.

Once both transactions have made it into their respective blockchains, I can now safely spend the 10 BTC in both networks without fear of the transaction being re-broadcast on the competing network.

If someone were to capture and re-broadcast either of my initital transactions to the competing netowrk, the coins would still be under my control, and I could re-attempt to move them using the same technique.

[TierNolan]

If I found myself at all tempted to use both forks, I think I'd create a set of addresses that I owned in both forks and send all my pre-fork coins to my own addresses to split them.

Sounds good.  The forked client should do that automatically.

In fact, as a courtesy, maybe the forked chain would monitor the main chain and include transactions. 

[wingding]

I don't understand your objection.  The coins that are valid on both sides of the fork have nothing to do with each other. 

The point is that if you sign the transaction in one fork, the recipient can submit the same transaction to the main chain and also get your coin there.

But how is re-broadcasting prevented in the main chain as it is?

[AlexMerced]

To sum up the problem

Pre-Fork and Post-Fork Chains are not fungible, but the client will treat them as such.

Several Problems Can occur:

- You lose track of pre-fork coins and end up using them at the lower market value of post fork chains
- the amount of coins in the bitcoin economy shrinks as pre-fork coins will get long in the post-fork economy until somebody goes through the block chain to determine which are which or create a client that distriguishes between the two(which can be a very BIG problem)


IMHO, I think the ethical thing to do would be to start a whole new blockchain with a new genesis block as much as that can be a paid.

[DannyHamilton]

I don't understand your objection.  The coins that are valid on both sides of the fork have nothing to do with each other. 

The point is that if you sign the transaction in one fork, the recipient can submit the same transaction to the main chain and also get your coin there.

But how is re-broadcasting prevented in the main chain as it is?

Re-broadcasting from where?  You need the private key to sign the transaction.

[yona]

I've always thought of this for a way to start an alt-coin. The fact that all bitcoin holders automatically becomes alt-coin owners could give it som traction. Or it would just give people some free fraction of bitcoins as they trade their alt-coin for bitcoins as soon as the first exchange opens.

You would have to change the algorithm to find blocks though or you will be vulnerable to a 51% attack from the bitcoin mining pools.

Does changing the algorithm have to mean it's not sha2 and does not fit new asics created for bitcoin or is there an option to change only the output req?