Why exactly would adding further divisibility to bitcoin require a hard fork?

Question

There are quite a few threads already on this topic, but they all focus on the necessity or possibility 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?

Answer 1

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 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 2

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.