cryptocurrencies and monetary supply (growth rates)

[tytus]

I am for b) [no reward halving] [or d) as explained later] in favor of increased inflation. I don't see a dramatic problem with changing the code.

We have to ask pool operators about their opinion. We can ask them to present their view and miners will just switch to the pool with the view they share :-)
If the pool operators agree with the change we have the majority of new blocks generated with the new software. All other solo miners will also update to get the 50BTC reward. Merchants will update to receive incoming transactions [otherwise they will see no transactions, only transactions generated by a minority of clients that were not updated].
If the number of not updated clients is small, they will not have enough hashing power to generate new blocks.
The change will also teach the network about the feasibility to introduce changes and how to do it in the future.

The better change (d) is as follows:

there is a minimum required transaction fee of 0.01% (much better than the current unpredictable fee). [And here comes the new part] The miner collects all transactions fees in the current block + a reward equal to all fees generated 6 blocks ago. The current block fees are paid from the "account" that sent the funds. The reward (second part) represent newly generated coins that facilitate inflation at a rate proportional to the volume of transactions. The delay of ~6 blocks is needed to prevent miners from profiting from fake transactions. The delayed "confirmation" can be used also to introduce theft protection [the owner of the sending account can cancel the previous transaction in the time frame of 6 blocks]. Of course "6" is just an arbitrary number AND the transaction canceling is a completely separate issue.

[1713495573]

1713495573

[1713495573]

1713495573

[1713495573]

1713495573

[1713495573]

1713495573

[1713495573]

1713495573

[Etlase2]

Don't be silly!  You can't use subtraction because eventually you'd get negative numbers which means miners would have to PAY bitcoins to mine a block!!!  

But seriously your proposal would result in a probably trivially different curve, you were extremely rude in proposing it, and who cares nobody is going to move to an alt-coin for this trivial issue.

I was rude because D&T is a non-stop sycophant that can't imagine that there is something that bitcoin maybe didn't get right. It's not as if this has been our first exchange. "No bitshift? Must mean floating points!" Asinine. And he calls into question my ability to think like a programmer. His posts are almost always dishonest when it comes to bitcoin's shortcomings, so I often have to set him straight for the non-initiated that may be reading.

[muyuu]

I am for b) [no reward halving] [or d) as explained later] in favor of increased inflation. I don't see a dramatic problem with changing the code.

We have to ask pool operators about their opinion. We can ask them to present their view and miners will just switch to the pool with the view they share :-)
If the pool operators agree with the change we have the majority of new blocks generated with the new software. All other solo miners will also update to get the 50BTC reward. Merchants will update to receive incoming transactions [otherwise they will see no transactions, only transactions generated by a minority of clients that were not updated].
If the number of not updated clients is small, they will not have enough hashing power to generate new blocks.
The change will also teach the network about the feasibility to introduce changes and how to do it in the future.

This "introducing changes in the future" is a double-edged sword. It also ends with the perception of long-term predictability of supply. It would be the most radical thing to ever happen to the system.

The better change (d) is as follows:

there is a minimum required transaction fee of 0.01% (much better than the current unpredictable fee). [And here comes the new part] The miner collects all transactions fees in the current block + a reward equal to all fees generated 6 blocks ago. The current block fees are paid from the "account" that sent the funds. The reward (second part) represent newly generated coins that facilitate inflation at a rate proportional to the volume of transactions. The delay of ~6 blocks is needed to prevent miners from profiting from fake transactions. The delayed "confirmation" can be used also to introduce theft protection [the owner of the sending account can cancel the previous transaction in the time frame of 6 blocks]. Of course "6" is just an arbitrary number AND the transaction canceling is a completely separate issue.

This is intriguing but it introduces an unpredictable element, as transactions could end up being very substantial long term, and could also be minimal as payments got centralised in "bitcoin bank accounts" with even lower commission for payments inside of their system. So what happens if transaction fees are exploited as a means of multiplying supply by a cartel of miners? (talking about newly generated coins proportional to previous fees). This probably deserves experimentation but it would take a long while to see potential problems and exploits.

[nevafuse]

Overall, I wouldn't change much about bitcoin.  Unfortunately, there's no ideal way of distributing 21 million units of currency.  The initial high rate of inflation is necessary to distribute & promote trade.  If anything, I would have created a shorter window to distribute all 21 million units.  That way transaction fees would be more important by now.  But no one could have predicted how fast bitcoin would take off.  In either case, the shrinking block reward will be a good thing.  Inflation will decrease, causing prices to rise.  Higher transaction fees may be required preventing groups like Satoshi Dice from creating such small/unnecessary transactions that create unnecessary work for everyone else when validating transactions.

Satoshi made a mistake in having such stark drops. It would be much better if the exchange rate could rise gradually as the mining reward drops gradually. Oh well.

I agree w/ whoever wrote this.  Whether it was a mistake or a choice, these drastic drops are unnecessary compared to doing it gradually.

There are permanently lost coins though. If halving goes on indefinitely as soon as in 30 years time we might have more coins lost than generated, because generation will be extremely low.

This is true, but we can always move the decimal point if a satoshi isn't small enough.

[DeathAndTaxes]

I am for b) [no reward halving] [or d) as explained later] in favor of increased inflation. I don't see a dramatic problem with changing the code.

We have to ask pool operators about their opinion. We can ask them to present their view and miners will just switch to the pool with the view they share :-)

There are roughly 20,000 nodes.  Most aren't miners.  You can't simply change the miners you would need to convince all the nodes to switch.  First that means convincing enough trusted developers to code the changes.  It also requires enough users, exchanges, merchants to implement the new code.  If there are nodes with incompatible codebases on the internet at the same time each will produce their own valid network and reject blocks/tx from the other nodes.  Essentially a permanent hard fork.  If you only convince some of the miners to switch they will simply produce blocks (and coins) that nobody uses.   The users who don't switch will produce tx (and fees) accepted by other users and merchants and exchanges who don't switch.   That means there is economic value for miners who don't switch.  Difficulty will fall and thus the revenue per MH/s will rise simply by not switching. Essentially miners will go where the money is.

While in theory it is possible it is far more complex than just convincing some pools to switch.  Even relatively non-controversial breaking changes have taken a very long time to get accomplished (and involved some spririted debate).  You can't force a change like this.  It has to be accepted willingly by a super majority of all users, developers, merchants, exchanges, and miners. 

Merchants will update to receive incoming transactions [otherwise they will see no transactions, only transactions generated by a minority of clients that were not updated].

Merchants don't need to update if their customers are running the old nodes.  Customers don't need to update if their merchants are running the old nodes.

If the number of not updated clients is small, they will not have enough hashing power to generate new blocks.
The change will also teach the network about the feasibility to introduce changes and how to do it in the future.

Clients =/- miners but if the number of miners is small but still a significant fraction of total (say 25%) in time difficulty will fall and the miners who remain on the old fork will see their revenue per MH/s rise.  Miners on the new fork are taking a risk they will simply be mining worthless blocks (and coins) accepted by nobody.

The better change (d) is as follows:
there is a minimum required transaction fee of 0.01% (much better than the current unpredictable fee).

The bitcoin network doesn't know the intended amount of the tx only the sum of the inputs and outputs.  If for example the client chooses a 100 BTC input to pay a 1 BTC tx you would be charged on the 100 BTC.  0.01% is likely too low to produce the revenue necessary to protect the network.  For example PayPal has ~$100 B in transaction volume per year.  At 0.01% that would only produce ~ $10M in revenue for miners.  Also the "cost" of a tx is based on its size not value.  Charging more for higher value but smaller tx and less for lower value but larger tx creates a break between price and cost.

The critical resource of the blockchain is KB.  A 1,000,000 BTC tx is just as easy to process as a 1 BTC tx however a 100 kb tx will require 100x as much storage into perpetuity as a 1 kb tx.

[muyuu]

There are permanently lost coins though. If halving goes on indefinitely as soon as in 30 years time we might have more coins lost than generated, because generation will be extremely low.

This is true, but we can always move the decimal point if a satoshi isn't small enough.

It's not the precision problem, but the extreme long term reward towards not using the coins. I think 0% is radical enough, -0.01% (let's say) sounds just wrong. Granted, it's not a deal breaker, but I don't think it's desirable.

I am for b) [no reward halving] [or d) as explained later] in favor of increased inflation. I don't see a dramatic problem with changing the code.

We have to ask pool operators about their opinion. We can ask them to present their view and miners will just switch to the pool with the view they share :-)

There are roughly 20,000 nodes.  Most aren't miners.  You can't simply change the miners you would need to convince all the nodes to switch.  First that means convincing enough trusted developers to code the changes.  It also requires enough users, exchanges, merchants to implement the new code.  If there are nodes with incompatible codebases on the internet at the same time each will produce their own valid network and reject blocks/tx from the other nodes.  Essentially a permanent hard fork.  If you only convince some of the miners to switch they will simply produce blocks (and coins) that nobody uses.   The users who don't switch will produce tx (and fees) accepted by other users and merchants and exchanges who don't switch.   That means there is economic value for miners who don't switch.  Difficulty will fall and thus the revenue per MH/s will rise simply by not switching. Essentially miners will go where the money is.

While in theory it is possible it is far more complex than just convincing some pools to switch.  Even relatively non-controversial breaking changes have taken a very long time to get accomplished (and involved some spririted debate).  You can't force a change like this.  It has to be accepted willingly by a super majority of all users, developers, merchants, exchanges, and miners. 

Compatibility-breaking changes have been introduced already if I'm not mistaken. No need to do a Rube-Goldberg sync operation, it suffices with agreeing the future block # that makes the change effective and broadcast an alert to upgrade with enough time in advance, this is something Gavin and a couple client devs can single-handedly achieve. We shouldn't pretend this cannot be done, we can just give our honest recommendation to avoid it.

The better change (d) is as follows:
there is a minimum required transaction fee of 0.01% (much better than the current unpredictable fee).

The bitcoin network doesn't know the intended amount of the tx only the sum of the inputs and outputs.  If for example the client chooses a 100 BTC input to pay a 1 BTC tx you would be charged on the 100 BTC.  0.01% is likely too low to produce the revenue necessary to protect the network.  For example PayPal has ~$100 B in transaction volume per year.  At 0.01% that would only produce ~ $10M in revenue for miners.  Also the "cost" of a tx is based on its size not value.  Charging more for higher value but smaller tx and less for lower value but larger tx creates a break between price and cost.

The critical resource of the blockchain is KB.  A 1,000,000 BTC tx is just as easy to process as a 1 BTC tx however a 100 kb tx will require 100x as much storage into perpetuity as a 1 kb tx.

The resource is measured in KB, but the economic significance of the reward in BTC. It probably should be a mixture of the two, but a % big enough on value would be simpler and practical (expenditures are not decided on KBs, but on cost, if you want the user to worry about internal implementation of the blockchain I think we're fu**ed).

[Etlase2]

Compatibility-breaking changes have been introduced already if I'm not mistaken.

AFAIK only one has, and that was because of a bug in the software that allowed someone to create several billion coins. This was also very early on when a breaking change was easy to introduce.

No need to do a Rube-Goldberg sync operation, it suffices with agreeing the future block # that makes the change effective and broadcast an alert to upgrade with enough time in advance, this is something Gavin and a couple client devs can single-handedly achieve. We shouldn't pretend this cannot be done, we can just give our honest recommendation to avoid it.

D&T is right though that everyone, everyone, has to agree. Mt.Gox has to simply say "I reject your code change" and nobody in their right minds would use that fork since Mt.Gox is currently the center of the bitcoin universe. It can be done, but something like changing the coin distribution is never going to have a consensus and it is better to just create a new currency if you feel very strongly about such a thing.

[muyuu]

D&T is right though that everyone, everyone, has to agree. Mt.Gox has to simply say "I reject your code change" and nobody in their right minds would use that fork since Mt.Gox is currently the center of the bitcoin universe. It can be done, but something like changing the coin distribution is never going to have a consensus and it is better to just create a new currency if you feel very strongly about such a thing.

MtGox will take any change in bitcoind.

Let's not pretend Gavin & co. cannot introduce this change. Let's just admit the truth: it would be a dangerous precedent and ought to be avoided.

Not everyone, just a big enough majority, can introduce basically any change you can think of. Obviously it won't happen against the will of the big players though.

[DeathAndTaxes]

So MtGox will take a change that works against their best interests rather than just use the pre-change code?  Really?

Who do you think is in the driver's seat.  Those with marketshare power of the developers?  Had MtGox or DeepBit refused to accept P2SH we wouldn't have it right now.  Hopefully Bitcoin becomes more democratic over time but the idea that the developers can dictate something against the wishes of the majority of stakeholders is just silly.

Nobody is saying you TECHNICALLY couldn't change Bitcoin.  There is no technical obstacle.  It just won't happen.  There is a huge SOCIETAL obstacle.  Changing the minting rate would undermine confidence in Bitcoin.  Less confidence in Bitcoin is bad for MtGox shareholders.  They aren't going to support something which isn't needed, isn't wanted by a majority of users, and provides no benefit to them.   Even if it personally benefited them one would hope they would be smart enough to realize the disruptions it would cause would damage the Bitcoin brand and thus their company value.

We may see major breaking changes for security flaws, for new transaction types, for post-quantum encryption as a precaution (if ever necessary), for new address types (if ECDSA is partially or full compromised).   The issue isn't technical it is societal (the Bitcoin community/society).  You will never get the consensus necessary for something as controversial as changing the minting rate.  Even the developers (who BTW are not homogeneous in thinking) don't have that kind of influence.

[muyuu]

Yes, the premise being that they think it wouldn't be better.

[muyuu]

I was rude because D&T is a non-stop sycophant that can't imagine that there is something that bitcoin maybe didn't get right. It's not as if this has been our first exchange. "No bitshift? Must mean floating points!" Asinine. And he calls into question my ability to think like a programmer. His posts are almost always dishonest when it comes to bitcoin's shortcomings, so I often have to set him straight for the non-initiated that may be reading.

That was uncalled for IMO. D&T never claimed such thing, he just said that the bit shift was a justified decision as could have been some other option.

Anyway, I hope the discussion doesn't die off because of some silly feud.

[Etlase2]

That was uncalled for IMO. D&T never claimed such thing, he just said that the bit shift was a justified decision as could have been some other option.

Actually, after insulting me for saying His Holiness the Divine Bitcoin Creator made a mistake, he only mentioned floating points (and several times) as the alternative. Then went on again to expound on upon the properties of bitshifting and how accurate it is. Vehemently supporting the design decision while ignoring other possible decisions and only giving a terrible decision as the alternative is patently dishonest posting in my book. It's a false dilemma.

[Melbustus]

That was uncalled for IMO. D&T never claimed such thing, he just said that the bit shift was a justified decision as could have been some other option.

Actually, after insulting me for saying His Holiness the Divine Bitcoin Creator made a mistake, he only mentioned floating points (and several times) as the alternative. Then went on again to expound on upon the properties of bitshifting and how accurate it is. Vehemently supporting the design decision while ignoring other possible decisions and only giving a terrible decision as the alternative is patently dishonest posting in my book. It's a false dilemma.

The greater point being made was that one needs to consider simplicity of implementation, and potentially back off of some ideal design points if the implementation demands appear too great. A beautiful but complex design may never be implemented while a less ideal (though still good) design that simplifies implementation significantly probably has an order of magnitude greater chance of becoming reality.

As a software developer, I can very much appreciate that sentiment.

[Etlase2]

Point taken, but since you are doing the same thing (sans insult) I have to remind you that orderly subtraction is not a particularly demanding or complex concept. We're talking about the simplest of mathematical operations that is run once per block. Compared to the thousands of point multiplications or billions of hash operations per second.

[Melbustus]

Point taken, but since you are doing the same thing (sans insult) I have to remind you that orderly subtraction is not a particularly demanding or complex concept. We're talking about the simplest of mathematical operations that is run once per block. Compared to the thousands of point multiplications or billions of hash operations per second.

My point is general; I'm not arguing one specific feature/implementation-detail.

[tytus]

The subject of this thread is important but we have just killed the discussion with some irrelevant details. Maybe we should start a new thread and ask pool operators personally for a statement.

[muyuu]

The subject of this thread is important but we have just killed the discussion with some irrelevant details. Maybe we should start a new thread and ask pool operators personally for a statement.

Honestly I don't think these ideas should be applied to bitcoin itself, but rather to a new alt-coin.

Another option I had been thinking of is a "sigmoid" kind of supply function: start with a small block to allow people some time to join, generate a bigger coin base during a big block period (say, 6 months later and going on for a few years), then start reducing the block reward again until some low rate is achieved, or allow a fixed final block reward forever.

[Etlase2]

Honestly I don't think these ideas should be applied to bitcoin itself, but rather to a new alt-coin.

Another option I had been thinking of is a "sigmoid" kind of supply function: start with a small block to allow people some time to join, generate a bigger coin base during a big block period (say, 6 months later and going on for a few years), then start reducing the block reward again until some low rate is achieved, or allow a fixed final block reward forever.

This was suggested a long while back and was termed "ease-in, ease-out." Whatever Satoshi's intent with the distribution curve, it is what it is and bitcoin has momentum. I don't think that any alt coin that only changes this property has any chance of competing at this point. In the great grand scheme of things, it is probably not all that usefully different.

[muyuu]

Honestly I don't think these ideas should be applied to bitcoin itself, but rather to a new alt-coin.

Another option I had been thinking of is a "sigmoid" kind of supply function: start with a small block to allow people some time to join, generate a bigger coin base during a big block period (say, 6 months later and going on for a few years), then start reducing the block reward again until some low rate is achieved, or allow a fixed final block reward forever.

This was suggested a long while back and was termed "ease-in, ease-out." Whatever Satoshi's intent with the distribution curve, it is what it is and bitcoin has momentum. I don't think that any alt coin that only changes this property has any chance of competing at this point. In the great grand scheme of things, it is probably not all that usefully different.

Yep, I agree with all that. There must be more to it than this. I have a lot of ideas but I wanted to leave this post to the particular problem of supply.

[Adrian-x]

Yep, I agree with all that. There must be more to it than this. I have a lot of ideas but I wanted to leave this post to the particular problem of supply.

I don't want to belittle the idea, but I feel adjusting the supply is problematic.

The only problems I have with the supply are:
1) I wasn't supplied enough BTC when it was below $1
2) My supplies only increases with a few BTC cents a day.  (to be halves soon)

An asumption is the supply will eventually be fixed, it won't. total suply will actually be negative.
I for one have already lost (taken out of circulation over 10 BTC never to be found) and I am sure there will be many more. Just think about all those people who will die never revelling the paper wallet to be burned with all their other stuff after they are gone.

To the economy's credit everyone's BTC will be worth more.

I think the focus should be how to get sum not how to get more, that way what you have grows in value.