Bitcoin Forum

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]

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.

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.

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

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. 

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.

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.

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.

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.

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.

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-

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

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.

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. 

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

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.

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

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?

I mean scanning each chain, and if a transaction is included in one, it is added to the other (if valid in both).

I mean, what stops the recipient (or anyone else) from submitting the same (and already signed) transaction over again?

My thought is to use merged mining. So it would be the same algorithm to find blocks. One have to rearrange the block data structure for the alt-chain, so that main chain transactions are part of the nonce. Similar to what (I think) they do for namecoin.

Wingding
I have read your other posts
I think this discussion is very interesting as it deals with one issue that i think BitCoin will have to address sooner or later: a hard fork
I was reading another discussion regarding regulation which questioned the same option, only this time the goverment/regulators might wish to hardfork the blockchain and create a 'safer' coin, one that can be traced and taxed. In return this coin might have legitemacy in mainstream exchange and buisness which could up it's value.
Now the question was: which side of the fork would most current bitcoin users choose. Regulated high cap or freedom low cap?
Same question here, people might be pushed to make a choice.

But does having a choice not devalue both systems?

This is interesting but off-topic ;) (non-technical) and deserves a separate thread. But my opinion in short is: Governments will certainly take the technology in use with FIAT money - sometime and somehow. But they will not care about intercepting bitcoin.  

a government would just create their implementation, which is probably why they havn't cared much about bothering the bitcoin community because they can make use of the improving technology as well (I mean could intellgience agencies conduct covert operations with other intelligence agencies easier with crytocurrency, a though, easy that carrying around pallets of cash)

I read the ECB report regarding digital currency. It actually states that the effects of deflation are not predictable.
Your predictions make apealling sense, but are also subject to unknown factors yet to come or reoccur...

In short, we can only try to predict the future with our limited knowlage of the present.

I think that the first desicion to limit bitcoin production and keep it constantly deflatory might guard it from some of these unforseen events . It sort of allows it to 'fly low'

What i mean to say is that it might not be the most efficent way for the coin to be adapted, esp in current flactuation shifts, but it might be a safe guard from other hazards by constantly making an apeal to early adopters to 'get hold of some coins' and promise a deflative reward.
Keep in mind this currency in adopted by only a very small precent of the population right now, and although it has already very big gaps between 'rich' and 'poor' it still has a long way to go before it is widly adopted.

Still, i think your experiment, either by theory or real implementation is a valuble tool to learn more.

Good luck with it.