Topic: what (technically) enforces bitcoin not to exceed 21 million cap? - page 3. (Read 4929 times)

I never said it isn't.  Please read what I wrote.  Eventually the pool of unspent outputs which are valid on both forks will aproach zero.

DT, it is possible for a txn to be valid on two forks simultaneously...

Every once in a while I find my self entertained by something like this.  Then I think "What am I? 12 years old?".

It doesn't matter a given transaction over time will only be valid on one fork or another.

For example the coins from the first block after the fork would only be valid on the fixed reward fork.  Nodes on the the original fork would see it as invalid.

This also means any spend which uses those coins would also only be seen as valid on one fork.   Since the input of any tx is the output of prior tx it also invalidated all subsequent tx which use the change from that transaction.

While at day 0 most tx will be valid on both halves of the fork, like a metaphorical fork in the road, the two chains will diverage over time and eventually the vast majority of transactions will only be valid on a single fork.

This.  Sure anyone can make a new client which changes the Bitcoin protocol.  One way of looking at it is that altcoins are an example of this.   However nothing can force existing users to adopt the new "changed" client.   As long as they don't, their existing clients will reject blocks and transactions which violate their rules.

Anyone can fork Bitcoin, nobody can fork force you to use that fork.

Clients do not vote on protocol rules... They rigidly enforce them.

Yeah, assuming someone is sitting there cross broadcasting the transactions between the networks from the start, which isn't too unlikely I suppose (given that there are people posting mutated transactions pretty easily).

Over time though as they miss transactions here and there, or if they start too late, it will become harder and harder to do that (because it could register as a double spend on the network they are broadcasting to).

One other complication that may arise will be that miners will find blocks at different times on each chain - and since it's up to the miners which transactions they include, you'll see blocks with much different contents generated on each side over time. And you may see a transaction go through both chains, which is then confirmed on one chain but the tx-fee wasn't high enough for the other chain for quite some time and it remains unconfirmed over there for a while.

I dunno, overall it would be pretty interesting. But I think incentive to do this for monetary gain or for maliciousness towards bitcoin is pretty low. I would like to see what happens in a system where the chain is forked and two different rulesets/incentives are being applied, but every or some transaction(s) are cross-broadcast. I think one of the coins would drop to zero value and quickly die off, but I'm not sure.

Actually, if you send a transaction on one fork that spends an unspent output from the pre-fork chain, then the recipient of the transaction (or anyone else if they want to) can re-transmit the exact same transaction on the other fork as well.  So if you make a payment to someone with inflate-a-coin using pre-fork coins, then those same coins can be forced to be sent to that same address in the bitcoin network as well.

How is it determined on which chain of the fork a transmit applies? Such a fork does not change the transmit protocol.

Good clarification.

Coins you minted/spent going into the fork would be available on both sides - spending them on one side would not mean spending them on the other.

But coins minted/spent after the fork would not suddenly become available on the other side at the new address. Anything that happens after the fork becomes harder and harder (as more blocks are found) to reconcile with the other side - eventually you would (for all intents and purposes) end up with Bitcoin and an Altcoin.

Just to be clear, in a fork of the blockchain and the client like this, the coins would be on both sides of the fork - the value of one side would probably be different that the other, but you'd have coins in both forks, however many coins you had at the point of the fork. 

Then you could decide what to do with each - I think many would sell the inflation-coin fork, but who knows.

Consensus.


Yes. The miners with 49% of the hashing power would continue mining bitcoin and would therefore have 100% of the bitcoin hashing power. The miners with 51% of the hashing power would be mining some new crypto-currency that is a hard fork of the bitcoin blockchain.  They might try to call their new crypto-currency "bitcoin", but unless they can convince a significant majority of ALL USERS to switch to their inflate-a-coin currency, they will simply be mining an alt-coin that might have some niche appeal to a small subset of users.


The fact that most users and businesses are likely to continue to use the widely used and widely accepted bitcoin instead of yet another alt-coin.  If a market ever does develop for inflate-a-coin, since it is a fork, many people will sell all their inflate-a-coin balances from the forked chain to increase their bitcoin holdings.  This is likely to crash any inflate-a-coin value that starts to develop.


They can write any code they want.  The tricky part will be convincing everybody to use their new inflate-a-coin software wallet.  At that point, it's just yet another alt-coin.  People who believe in bitcoin will continue to use the old software, and new developers will come along to maintain it.  Meanwhile all the developers that decided to create the inflate-a-coin software will be left maintaining software for an alt-coin that forks from bitcoins.


Technically? Absolutely.  There are already hundreds of alt-coins that do exactly that.  Of course, I wouldn't call it "Bitcoin", but I suppose they might if they wanted to try to cause confusion between their alt coin and the original bitcoin.

Sure, the idea is pulled from asymtotes, but it's still implemented discretely/technically.

I don't think the people running just clients could do much about it - it's the miners who have to verify and record transactions including genesis transactions.

It is just coded in though - every time the block award adjusts all the software of miners/full nodes just "agrees" that the new block reward is halved. Eventually it just drops to zero - which is also coded in (distant future, beyond our lifetimes, and probably much much beyond the lifetime of this version of bitcoin).

As for just "deciding" to run another version of the code, what would happen is two separate networks would form - the Bitcoin-Old-Reward network and the Bitcoin-New-Reward network. Everyone would have to decide which network they wanted their coins to be on - and if the reward was increased every block, a lot of end users would choose to be on the old network where their coins would be perceived as more valuable. Miners are another story.

I think if some miners decided to make a change like that though, it would create an inconsistent separate network. The new coins generated on each network wouldn't be transferable = little incentive and no danger to rest of network.

Edit to your edit:

So yes, the dev team *can* create a different version of the client - then what we would have is just another alt-coin that some people decide to switch over to.

not the type of answer I was hoping to get. I think the question is clear. The thing that quantity never reaches 21mil is because of diminishing block rewards. And the diminishing block rewards is written in client. And the new version of client is redistributed each time by bitcoin developers. See the point?

this is not technics, but mathematics

21 million - is so-called "asymptote". You know what is asymptote from school (the simples example is function y=1/x)

The quantity will never EVEN REACH the asymptote.

Though I believe I have read quite a lot about Currency Supply, I realized I do not know sufficiently and do not feel satisfied. Some Scenarios;

1) client side: Say more than 51% total hash power of bitcoin client runners agreed to run a client that gives say 50 block reward instead of 25. Would this cause a fork in the chain? (I do not ask if clients would choose this or not, actually two largest pools can choose to agree on any kind of client if they want to). What incentives would keep majority of clients doing this apart from good will?

2) dev team side: Maybe more importantly, does anything prevent the bitcoin dev team to change the block reward halving to something else than they previously announced? What prevents them from NOT going towards the 21million cap. Are they technically able to reconfigure the next version of bitcoin clients for exceeding 21mil if they want so? In other words, can the dev team enforce say something like 1% yearly inflation if they want to?

edit: I stress that the question is not `would dev team...`, it is `can dev team...`.

thx for answers, cheers.