<p>It requires a hard fork because it would essentially be a redefinition of the base unit.</p>
<p>In Bitcoin, the base unit is the Satoshi. Amounts in transactions are counted with integers in sats. This ensures that there is no way for floating point arithmetic to cause any errors. In order to add more decimal points, this base unit would have to be redefined, and that is a hard fork.</p>
<p>As you pointed out, having the fractional sats in a different value does not work because enough fractional sats become whole sats and then old software will mark such transactions as invalid because the values don't match.</p>

CC BY-SA 4.0
2023-01-05T18:29:48.617Z
I don't think this is true; an extension-block like softfork can define a new type of transaction, with separate UTXOs that have higher granularity, and special conversion transactions between the two worlds in both ways.
Pieter Wuille
CC BY-SA 4.0
2023-01-05T19:28:58.767Z
Right, but wouldn't that also split the mempool, blockspace, and UTXO set between these two types of transactions and their outputs?
Murch
CC BY-SA 4.0
2023-01-05T21:35:25.867Z
UTXO set certainly (by definition almost; currently UTXOs cannot store sub-satoshi amounts...). Transactions, mempool, and blockspace would depend on the implementation; e.g. you could imagine a construction where these subsat-transactions are seen as having 0-value inputs and outputs by old nodes, but they do still see the transactions otherwise. I'm not claiming this is a particularly realistic option - just that it's technically possible with a softfork.
Pieter Wuille
CC BY-SA 4.0
2023-01-07T11:20:49.387Z
But such a soft fork would fall under the category of forced/evil soft forks, correct?
sutterseba
CC BY-SA 4.0
2023-01-07T14:06:06.937Z
@sutterseba Under the assumption everyone wants it, why would it be evil or forced?
Pieter Wuille
CC BY-SA 4.0
2023-01-07T17:16:13.423Z
The term "evil" is of course subjective, I am referring to this https://petertodd.org/2016/forced-soft-forks blog post. Since the UTXO set is split, old software must upgrade in order to use the "actual" bitcoin while in a "regular" (lacking for a better term) soft fork this is not the case.
sutterseba
CC BY-SA 4.0
2023-01-11T20:29:25.740Z
@sutterseba I don't know, I find that this concept of a forced soft fork is mostly useful as a demonstration that "soft fork" on itself has little to do with how invasive soft forks can be. As a definition, I feel it isn't well specified. If you really want to classify express properties of a consensus change besides convergence, it becomes a question of what pieces of software/infrastructure remain functional. See my own answer.
Pieter Wuille
CC BY-SA 4.0
2023-01-05T17:21:08.823Z
2023-01-05T17:27:00.753Z
2023-01-05T17:27:00.753Z
Ava Chow
<p>I think the answer depends on exactly how you define &quot;forced&quot; soft fork. I find that this concept of a forced soft fork is mostly useful as a demonstration that being a soft fork (in the sense of &quot;miners converge to a single chain as long as a majority enforces the new rules&quot;) is unrelated to how invasive a consensus change is to the ecosystem. If we actually want to discuss that impact, it's more informative to discuss it in terms of what old software/features remain functional/available.</p>
<h3>Soft forks in general</h3>
<p>As I suspect you already realized, it is certainly possible to add precision if you permit any kind of soft fork.</p>
<p>The easiest, and most extreme, way to show this is possible is through the mechanism described in the <a href="https://petertodd.org/2016/forced-soft-forks" rel="noreferrer">blog post</a> by Peter Todd you linked above. A &quot;Bitcoin 2.0&quot; is introduced, with possibly entirely new rules, and higher precision, and the consensus rules say that new blocks must be empty apart from a coinbase transaction that contains a hash of the 2.0 block data. Old nodes don't see the new block data at all, and thus anything is possible there. The UTXO set of new nodes is &quot;imported&quot; by copying that of old nodes at activation time, adding the extra precision in the process.</p>
<p>This is a soft fork in the strict sense of the word, but it would render all old Bitcoin software (not just validation nodes, but all miners/wallets/indexers/libraries/infrastructure/...) useless as they won't see the new transactions at all.</p>
<h3>As a one-way extension block</h3>
<p>A somewhat less invasive - but possibly more complex - approach is possible.</p>
<p>The idea is to still have the &quot;Bitcoin 2.0&quot; block data from the previous section, with transactions that operate on a higher-precision UTXO set, committed to in the coinbase of old blocks. However, old transactions can still remain in the old blocks, visible to old nodes.</p>
<p>In this case, the UTXO set isn't migrated from old to new upon activation, but instead whenever coin owners want to move their funds over. A special address type is defined by the softfork on the old block side, and funds sent to it are burned from the perspective of old nodes, but magically revived on the new side.</p>
<p>Old software remains functional, but can only see and interact with non-migrated funds.</p>
<h3>As a two-way extension block</h3>
<p>It's possible to go even further, and permit coins to be moved both ways between the old and new world.</p>
<p>Instead of having a burn address on the old side, use a transfer address which looks like an anyone-can-spend output on the old side. To move funds back, a special burn transaction is defined on the new side, and when included in a block, miners are required to construct a transaction on the old side spending some of the outputs sent to the transfer address, bringing them back into circulation there.</p>
<p>This means that funds that are moved over once from the old side to the new side are not stuck there, and it is possible even to move everything back.</p>
<p>However, old software can still not see any transactions or UTXOs in the new world.</p>
<h3>By truncating sub-sat amounts</h3>
<p>It is possible to go even further on the &quot;transparency-from-old-software&quot; scale</p>
<p>Instead of having two entirely different worlds (different transactions, different UTXOs, different block area, ...), represent transaction outputs as just having the rounded-down-to-integral-sats amount as what is visible to old nodes, but with extra (ignored by old software) data somewhere in the transaction to convey the subsat value. This is about as close as one can get in terms of having old software still see the transactions and UTXO data.</p>
<p>With just that, it does mean that any old-node-visible sat that gets broken up into sub-sat amounts cannot be recombined into old-node-visible sats - the amounts just wouldn't balance out from the perspective of old nodes which violates their consensus rules. If that's not desired, this is probably the simplest possible approach.</p>
<p>This can be mitigated too, but at significant complexity. Any transaction which breaks down sats to sub-sats must have a special (according to old software) anyone-can-spend output with the broken-down sats. Any transaction which recombines sub-sats into sats is then allowed to consume such outputs (but only on the condition, to new software, that the sub-sat amounts balance out) to account for the difference. The complexity is that this effectively implies a shared &quot;wallet&quot; of these anyone-can-spend outputs managed by all new-rules software collectively, with obvious costs and coordination difficulties that implies.</p>
<p>The advantage of an approach like this is that new-software users can send coins to old wallets within the same transaction even as sub-sat outputs.</p>

CC BY-SA 4.0
2023-01-11T16:51:31.667Z
2023-01-12T03:20:32.890Z
2023-01-12T03:20:32.890Z
Pieter Wuille
<p>There are quite a few threads already on this topic, but they all focus on the <a href="https://bitcoin.stackexchange.com/questions/122/will-we-ever-need-smaller-amounts-of-bitcoin-than-a-satoshi">necessity or possibility</a> for such a change. I understand that, even though it is difficult and would obviously require broad consensus, adding more decimal points to bitcoin is possible. This question is not about whether we would ever actually need/want such a change.</p>
<p>I am solely interested in the <strong>technical details as to why adding further divisibility requires a hard fork</strong> (or evil soft fork) and would not be possible with a &quot;regular&quot; soft fork. I would say I already have a good <em>feeling</em> why, but could not really explain it to someone else.</p>
<p>I have thought about &quot;separating&quot; the new decimal points in some way but that would most likely not work, since old software would not accept if someone wants to spend two 10000(.5) sat inputs to a 20001 sat output. The question of how old software would interpret a transaction with added decimal points in general is the main problem I guess.</p>
<p>However, how can we be sure that there isn't an elegant solution to this? Why would it require a major change of existing bitcoin software?</p>

CC BY-SA 4.0
2023-01-03T11:12:06.510Z
I don't remember the reference, but I think it was a mandatory soft fork about encasing the new economy in OP_RETURN payloads meant to be ignored by obsoleted nodes but interpreted by the soft fork enabled nodes according to newer more restrictive rules.
Mercedes
<consensus><soft-fork><satoshi><divisibility>
Why exactly would adding further divisibility to bitcoin require a hard fork?
sutterseba
# Why exactly would adding further divisibility to bitcoin require a hard fork?

(Asked by: username_0 on 2023-01-01)

There are quite a few threads already on this topic, but they all focus on the [necessity or possibility](https://bitcoin.stackexchange.com/questions/122/will-we-ever-need-smaller-amounts-of-bitcoin-than-a-satoshi) for such a change. I understand that, even though it is difficult and would obviously require broad consensus, adding more decimal points to bitcoin is possible. This question is not about whether we would ever actually need/want such a change.

I am solely interested in the **technical details as to why adding further divisibility requires a hard fork** (or evil soft fork) and would not be possible with a "regular" soft fork. I would say I already have a good *feeling* why, but could not really explain it to someone else.

I have thought about "separating" the new decimal points in some way but that would most likely not work, since old software would not accept if someone wants to spend two 10000(.5) sat inputs to a 20001 sat output. The question of how old software would interpret a transaction with added decimal points in general is the main problem I guess.

However, how can we be sure that there isn't an elegant solution to this? Why would it require a major change of existing bitcoin software?

**Tags:** consensus, soft-fork, satoshi, divisibility

> **Comments:**
> **username_1**: I don't remember the reference, but I think it was a mandatory soft fork about encasing the new economy in OP_RETURN payloads meant to be ignored by obsoleted nodes but interpreted by the soft fork enabled nodes according to newer more restrictive rules.  

---

## 2 answers

### Answer by username_3 on 2023-01-11. Score: 10 | Accepted answer

I think the answer depends on exactly how you define "forced" soft fork. I find that this concept of a forced soft fork is mostly useful as a demonstration that being a soft fork (in the sense of "miners converge to a single chain as long as a majority enforces the new rules") is unrelated to how invasive a consensus change is to the ecosystem. If we actually want to discuss that impact, it's more informative to discuss it in terms of what old software/features remain functional/available.

### Soft forks in general

As I suspect you already realized, it is certainly possible to add precision if you permit any kind of soft fork.

The easiest, and most extreme, way to show this is possible is through the mechanism described in the [blog post](https://petertodd.org/2016/forced-soft-forks) by Peter Todd you linked above. A "Bitcoin 2.0" is introduced, with possibly entirely new rules, and higher precision, and the consensus rules say that new blocks must be empty apart from a coinbase transaction that contains a hash of the 2.0 block data. Old nodes don't see the new block data at all, and thus anything is possible there. The UTXO set of new nodes is "imported" by copying that of old nodes at activation time, adding the extra precision in the process.

This is a soft fork in the strict sense of the word, but it would render all old Bitcoin software (not just validation nodes, but all miners/wallets/indexers/libraries/infrastructure/...) useless as they won't see the new transactions at all.

### As a one-way extension block

A somewhat less invasive - but possibly more complex - approach is possible.

The idea is to still have the "Bitcoin 2.0" block data from the previous section, with transactions that operate on a higher-precision UTXO set, committed to in the coinbase of old blocks. However, old transactions can still remain in the old blocks, visible to old nodes.

In this case, the UTXO set isn't migrated from old to new upon activation, but instead whenever coin owners want to move their funds over. A special address type is defined by the softfork on the old block side, and funds sent to it are burned from the perspective of old nodes, but magically revived on the new side.

Old software remains functional, but can only see and interact with non-migrated funds.

### As a two-way extension block

It's possible to go even further, and permit coins to be moved both ways between the old and new world.

Instead of having a burn address on the old side, use a transfer address which looks like an anyone-can-spend output on the old side. To move funds back, a special burn transaction is defined on the new side, and when included in a block, miners are required to construct a transaction on the old side spending some of the outputs sent to the transfer address, bringing them back into circulation there.

This means that funds that are moved over once from the old side to the new side are not stuck there, and it is possible even to move everything back.

However, old software can still not see any transactions or UTXOs in the new world.

### By truncating sub-sat amounts

It is possible to go even further on the "transparency-from-old-software" scale

Instead of having two entirely different worlds (different transactions, different UTXOs, different block area, ...), represent transaction outputs as just having the rounded-down-to-integral-sats amount as what is visible to old nodes, but with extra (ignored by old software) data somewhere in the transaction to convey the subsat value. This is about as close as one can get in terms of having old software still see the transactions and UTXO data.

With just that, it does mean that any old-node-visible sat that gets broken up into sub-sat amounts cannot be recombined into old-node-visible sats - the amounts just wouldn't balance out from the perspective of old nodes which violates their consensus rules. If that's not desired, this is probably the simplest possible approach.

This can be mitigated too, but at significant complexity. Any transaction which breaks down sats to sub-sats must have a special (according to old software) anyone-can-spend output with the broken-down sats. Any transaction which recombines sub-sats into sats is then allowed to consume such outputs (but only on the condition, to new software, that the sub-sat amounts balance out) to account for the difference. The complexity is that this effectively implies a shared "wallet" of these anyone-can-spend outputs managed by all new-rules software collectively, with obvious costs and coordination difficulties that implies.

The advantage of an approach like this is that new-software users can send coins to old wallets within the same transaction even as sub-sat outputs.


---

### Answer by username_2 on 2023-01-05. Score: 4

It requires a hard fork because it would essentially be a redefinition of the base unit.

In Bitcoin, the base unit is the Satoshi. Amounts in transactions are counted with integers in sats. This ensures that there is no way for floating point arithmetic to cause any errors. In order to add more decimal points, this base unit would have to be redefined, and that is a hard fork.

As you pointed out, having the fractional sats in a different value does not work because enough fractional sats become whole sats and then old software will mark such transactions as invalid because the values don't match.

> **Comments:**
> **username_3**: I don't think this is true; an extension-block like softfork can define a new type of transaction, with separate UTXOs that have higher granularity, and special conversion transactions between the two worlds in both ways.  
> **username_4**: Right, but wouldn't that also split the mempool, blockspace, and UTXO set between these two types of transactions and their outputs?  
> **username_3**: UTXO set certainly (by definition almost; currently UTXOs cannot store sub-satoshi amounts...). Transactions, mempool, and blockspace would depend on the implementation; e.g. you could imagine a construction where these subsat-transactions are seen as having 0-value inputs and outputs by old nodes, but they do still see the transactions otherwise. I'm not claiming this is a particularly realistic option - just that it's technically possible with a softfork.  
> **username_0**: But such a soft fork would fall under the category of forced/evil soft forks, correct?  
> **username_3**: @username_0 Under the assumption everyone wants it, why would it be evil or forced?  
> **username_0**: The term "evil" is of course subjective, I am referring to this https://petertodd.org/2016/forced-soft-forks blog post. Since the UTXO set is split, old software must upgrade in order to use the "actual" bitcoin while in a "regular" (lacking for a better term) soft fork this is not the case.  
> **username_3**: @username_0 I don't know, I find that this concept of a forced soft fork is mostly useful as a demonstration that "soft fork" on itself has little to do with how invasive soft forks can be. As a definition, I feel it isn't well specified. If you really want to classify express properties of a consensus change besides convergence, it becomes a question of what pieces of software/infrastructure remain functional. See my own answer.  

---

