Increase currency divisibility with soft-fork

[jl2012]

Increasing currency divisibility is listed as a hardfork in bitcoin wiki: https://en.bitcoin.it/wiki/Hardfork_Wishlist#Currency_changes

Actually it could be done with a soft-fork. (This is only for academic discussion. I don't think we will ever need to divide a satoshi)

1. Redefine OP_NOP1 as OP_PBTC (1pBTC = 1,000 nBTC = 10,000 satoshi)

2a. To mint pBTC, the total output value must be smaller than the total input value (let it be n satoshi)

2b. With n satoshi sacrificed, the user may, in the scripts of other outputs, embed this command

Code:

<amount> OP_PBTC OP_DROP

The sum of <amount>  must be equal to or less than 10000n

2c. Instead of taking n satoshi as fee, miner can only take not more than

Code:

n - SUM(<amount>/10000)

So SUM(<amount>/10000) satoshi will be destroyed in the minting process

3. Transfer of pBTC follows existing rules: the total amount of pBTC in the outputs must be less than or equal to the total amount of pBTC in inputs. In the "less than" case, miner will take it as fee by embedding OP_PBTC in coinbase output(s)

4. In about 2049, the miner reward will drop from 0.09765625 to 0.04882812, with 0.5 satoshi lost. At that time, miners will be allowed to include extra 5000pBTC in their coinbase output(s).  

5. The effective value of an output is amount of satoshi + amount of pBTC/10000 .

6. It will not break existing clients, but they will underestimate the true value of an OP_PBTC output.

Notes:

1. Minting of pBTC is an one way process. It is not possible to "merge" 10000 pBTC to make it become a traditional satoshi again. This will be a hard-fork

2. pBTC is actually a special type of smart property/colored coin

3. Comparing with a hard-fork, there is at least 3 bytes of overhead (an OP_PBTC, an OP_DROP, and an extra OP_PUSH for <amount>). However, it is more economic than a hard-fork if there is no pBTC in output.

4. We will face the same miner reward problem again after a few reward-halve: 5000pBTC->2500->1250->625->312->156

5. With a similar scheme, we can further divide pBTC with soft-fork

[1714992744]

1714992744

[1714992744]

1714992744

[1714992744]

1714992744

[jackjack]

If we really need to use sub-satoshi units (which I highly doubt) and if a hard-fork is possible, the far simplest solution would be to make the output value a 9-byte (or 10 or more) long value

nvm I missed the point

[Mike Hearn]

These things need to be hard forks. All kinds of software assumes 1 coin = 100 million satoshis and that this is the smallest value unit. For instance there are assertions in bitcoinj that throw exceptions if you get a URI that has too many decimal places (it won't round the URI for you).

Even if you downgrade all existing nodes to a weaker security model (bad idea!) it won't help that most software will still be incompatible with your new definition of a Bitcoin. That means to do it you need a global "flag day" anyway, at which point everyone agrees old software will get left behind, Y2K style. And then you may as well make it a hard fork.

[jl2012]

These things need to be hard forks. All kinds of software assumes 1 coin = 100 million satoshis and that this is the smallest value unit. For instance there are assertions in bitcoinj that throw exceptions if you get a URI that has too many decimal places (it won't round the URI for you).

Even if you downgrade all existing nodes to a weaker security model (bad idea!) it won't help that most software will still be incompatible with your new definition of a Bitcoin. That means to do it you need a global "flag day" anyway, at which point everyone agrees old software will get left behind, Y2K style. And then you may as well make it a hard fork.

With soft-fork, miners are obliged to upgrade anyway because they have to follow the majority of hashing power. In a hard-fork, the fork may persist for a long time.

Non-mining old full-nodes will still work. It just can't do sub-satoshi transactions and turn into SPV-level security. However, SPV-level security is still much better than being left in an abandoned fork.

For SPV nodes like bitcoinj, nothing has changed. AFAIK bitcoinj is not even supporting P2SH and is still working.

[Mike Hearn]

Eh? It makes no difference to how long the fork lasts. If miners don't follow a majority rule change then they'll end up wasting hash power on a shorter chain regardless of the fork type.

Being left on an abandoned fork is preferable, actually. The reason is that you will (a) get a fork alert, once Matt's change is merged in and (b) your app will essentially break instead of silently appearing to work but with a lower security level. It's usually better for things to break loudly than silently become insecure. It'll get fixed fast if the node operator cares.

My point was not about bitcoinj specifically, but about the software built on top of Bitcoin more generally. There  are tons of websites, custom scripts, protocol re-implementations etc that assume the current protocol rules, so if you change something as fundamental as how many coins there are in existence, all that software needs to be audited for the old assumptions and fixed. Even basic things like code which formats satoshis into human-readable BTC values needs to be adjusted. That's a lot of work by a lot of people, so there needs to be plenty of lead time and a flag day.

[Saturn7]

just think if we did need to split a satoshi it would be because each btc would be worth at least $1 million.

Let's all aim to have this problem.   

[kjj]

The script is the absolute worst place imaginable to tinker with value.

[jl2012]

The script is the absolute worst place imaginable to tinker with value.

Script is the only place to include arbitrary data and get signed. I can't see any other option without a hard-fork.

[Peter Todd]

Actually it could be done with a soft-fork. (This is only for academic discussion. I don't think we will ever need to divide a satoshi)

I think people are forgetting what you said here about "academic discussion"

Your idea is clever and says a lot about your understanding of the Bitcoin protocol, regardless of whether or not we'll ever use it or whether or not it'd be easier to do a hard-fork. (though by the time we do need to start thinking about sub-satoshi's it may very well be the case that hard-forks are impossibly impractical and clever/ugly hacks are required)

[kjj]

The script is the absolute worst place imaginable to tinker with value.

Script is the only place to include arbitrary data and get signed. I can't see any other option without a hard-fork.

I'm well aware of that.  It is still the worst place for it.

And think about it in context.  This is a soft fork in name only.  If it was needed for economic reasons, everyone would need to upgrade anyway.  Might as well do it hard so that the people left behind know that they've been left behind.

[jl2012]

The script is the absolute worst place imaginable to tinker with value.

Script is the only place to include arbitrary data and get signed. I can't see any other option without a hard-fork.

I'm well aware of that.  It is still the worst place for it.

And think about it in context.  This is a soft fork in name only.  If it was needed for economic reasons, everyone would need to upgrade anyway.  Might as well do it hard so that the people left behind know that they've been left behind.

Since it is the ONLY place for it, so I can argue it is the BEST place for it.

Any old clients will work as usual without upgrade. They just can't send and receive sub-satoshi payment. There needs to be new block version and tx version for such upgrade. The client should give a warning when it sees a flooding of blocks and txs of unknown version, so people will know there are some new rules on the network.

[kjj]

The script is the absolute worst place imaginable to tinker with value.

Script is the only place to include arbitrary data and get signed. I can't see any other option without a hard-fork.

I'm well aware of that.  It is still the worst place for it.

And think about it in context.  This is a soft fork in name only.  If it was needed for economic reasons, everyone would need to upgrade anyway.  Might as well do it hard so that the people left behind know that they've been left behind.

Since it is the ONLY place for it, so I can argue it is the BEST place for it.

Any old clients will work as usual without upgrade. They just can't send and receive sub-satoshi payment. There needs to be new block version and tx version for such upgrade. The client should give a warning when it sees a flooding of blocks and txs of unknown version, so people will know there are some new rules on the network.

I disagree.  Script nonsense is the ONLY place for it, the WORST place for it, and the BEST place for it, all at once.  Very clear indication to stay the hell away.  I'd prefer a hard fork any day.

Since the script can contain arbitrary data, we could shovel all sorts of garbage into it.  And it isn't like people haven't suggested plenty of crap already*, or that they won't go on to dream up much more.  Best not to tempt them, particularly not with something that already has an actual field.

At any rate, none of us will ever need to worry about it.  If the value grows so fast that we need to change the scaling factor for economic reasons before we want to do it for aesthetic reasons**, we'll all be so rich we can hire people to do it for us.

* Yes, I'm looking at you, colored coin scheme de jour.

** Daddy, why did Satoshi make the value field so narrow?  My Speak & Spell has 128 bit registers.

[jl2012]

The script is the absolute worst place imaginable to tinker with value.

Script is the only place to include arbitrary data and get signed. I can't see any other option without a hard-fork.

I'm well aware of that.  It is still the worst place for it.

And think about it in context.  This is a soft fork in name only.  If it was needed for economic reasons, everyone would need to upgrade anyway.  Might as well do it hard so that the people left behind know that they've been left behind.

Since it is the ONLY place for it, so I can argue it is the BEST place for it.

Any old clients will work as usual without upgrade. They just can't send and receive sub-satoshi payment. There needs to be new block version and tx version for such upgrade. The client should give a warning when it sees a flooding of blocks and txs of unknown version, so people will know there are some new rules on the network.

I disagree.  Script nonsense is the ONLY place for it, the WORST place for it, and the BEST place for it, all at once.  Very clear indication to stay the hell away.  I'd prefer a hard fork any day.

Since the script can contain arbitrary data, we could shovel all sorts of garbage into it.  And it isn't like people haven't suggested plenty of crap already*, or that they won't go on to dream up much more.  Best not to tempt them, particularly not with something that already has an actual field.

At any rate, none of us will ever need to worry about it.  If the value grows so fast that we need to change the scaling factor for economic reasons before we want to do it for aesthetic reasons**, we'll all be so rich we can hire people to do it for us.

* Yes, I'm looking at you, colored coin scheme de jour.

** Daddy, why did Satoshi make the value field so narrow?  My Speak & Spell has 128 bit registers.

Please don't just scream "no data in script". Provide some technical reasons for that.

There are so many data manipulating OP codes in script, so I don't think scripts were not supposed to store any data.

Whether we will need to worry about this, or whether we will become very rich, is irrelevant to this technical discussion

[kjj]

Please don't just scream "no data in script". Provide some technical reasons for that.

There are so many data manipulating OP codes in script, so I don't think scripts were not supposed to store any data.

Whether we will need to worry about this, or whether we will become very rich, is irrelevant to this technical discussion

I would think that the nearby field named "value" that is used to store the value of a vout is a very good technical reason not to have a "paravalue" field.  Incidentally, this is the exact same technical reason why IPv6 wasn't implemented by adding address fields to TCP.  Ok, so maybe IPv6 as an example makes your case instead of mine, but if we ignore the politics and look at the technology, I think I still come out ahead.

Upon further contemplation, I think that IPv6 is the right example.  The IPv4 shortage is now something like 20 years old.  If they had just decided in the 90s to pick a date in the far future, like 2005 or something, and just forced everyone to switch, IPv4 would just be a fading memory now.  Instead, they squandered years (and probably billions of dollars) on crutches.

Also, we have a tendency to call the end of the transaction by the odd name "script".  As if "script" was the end instead of the means.  If we made a point to call it "redemption criteria", people would at least look a bit guilty when they try to stash random stuff in it.