Representing fractional satoshis in difficulty-like format

[coinlatte]

For now, we have 64-bit numbers for representing amounts. We have satoshis as the smallest units and we have maximum coin supply of 21 million coins. That means we need at most 51 bits to represent any amount now. In the future, sooner or later, introducing fractional satoshis would be needed. The easiest way to expand it further when we use all 64 bits is just expanding it to 128-bit or even 256-bit number, but it seems unnecessary. We already have 256-bit targets expressed as 32-bit numbers when we deal with difficulty. The same method can be used to introduce fractional satoshis: one byte could be used to allow going up to 256 times smaller amounts than now, and the rest could be used to express the shifted value.

Some examples:

Code:

21 million coins: 000775f05a074000
one satoshi:      0000000000000001
one millisatoshi: 0a00000000000001
one microsatoshi: 1400000000000001
one nanosatoshi:  1e00000000000001
one picosatoshi:  2800000000000001
one femtosatoshi: 3200000000000001
one attosatoshi:  3c00000000000001

That also means that it will be impossible to express some amounts, but it is by design, just to avoid paying 0.000000001234567890123456789012345678901234567890 BTC in single output. I think that 56 bits should be sufficient to express any amount precisely enough, and the first 8 bits just allow to shift them to the right and express smaller amounts in this way.

[1715129041]

1715129041

[1715129041]

1715129041

[sheenshane]

It might time will come and across on that fractional amount in the future if Bitcoin will become very expensive.  The only way to buy for a cheap amount is the xx amount of bit numbers to determine the amount.

For now, the smallest one that we heard is the satoshi or sats for transaction fee and it's rare we even heard a bit or even a millibit.

However, here's a thread for Bitcoin Table of Units, and as I can see on that thread the smallest unit is tam-bitcoin that I thought before the smallest one is the satoshi amount. 

[NotATether]

It's a good idea but a soft-fork is needed to deploy this since this will change the formatting of locking scripts. They have 8-byte values hardcoded in the schema, so a second 8-byte value would have to be introduced immediately after it and then use it as a lower quadword for the satoshi amount while the original 8-byte value that appears first is used as a higher quadword.

So to represent an amount 0x000000001234567890abcdef00000000 fractional satoshis for example, we'd write each 8-byte value in little-endian like this:

7856341200000000    00000000efdcba90

And it will allow us to represent units as small as 2^-64 satoshis without using the Lightning Network.

[PrimeNumber7]

It's a good idea but a soft-fork is needed

The current consensus rules dictate that the smallest fraction of a bitcoin is one satoshi. The OP's proposal will only be needed if this consensus rule changes. In order to change a consensus rule, a hard fork will be necessary, therefore any fork involving the OPs proposal might as well be part of a hard fork.

[vjudeu]

The current consensus rules dictate that the smallest fraction of a bitcoin is one satoshi. The OP's proposal will only be needed if this consensus rule changes. In order to change a consensus rule, a hard fork will be necessary, therefore any fork involving the OPs proposal might as well be part of a hard fork.

No hard fork is needed. Segwit was introduced by allowing everyone to spend that coins, in this way all old nodes accepted it, just signatures were attached in some additional block, invisible to the old nodes. Here it could be done in a similar way: by placing zero satoshis in such outputs. Then, all old nodes will correctly add it, as it would change nothing during addition, but all new nodes would handle it correctly. All old nodes would receive zero bytes where values should come, but all new nodes would store, process and send them as non-zero values in the new format.

[PrimeNumber7]

When someone spends outputs that have a fraction of a satoshi, the transaction will appear to be invalid because it violates consensus rules. If you can send a fraction of a satoshi, you can also send 1.5 satoshi in an output.

[vjudeu]

When someone spends outputs that have a fraction of a satoshi, the transaction will appear to be invalid because it violates consensus rules. If you can send a fraction of a satoshi, you can also send 1.5 satoshi in an output.

Spending zero satoshi is backward-compatible. New amounts will be visible only by new clients, the old ones will see moving zero satoshis from some inputs to zero satoshis to some outputs. It is similar as in Segwit: if you run some old client, you see no signatures in Segwit inputs.

[NotATether]

Spending zero satoshi is backward-compatible. New amounts will be visible only by new clients, the old ones will see moving zero satoshis from some inputs to zero satoshis to some outputs.

I don't think this particular case is completely backward compatible because suppose you have the following balance and spend amount:

balance 10.X satoshis, spending 0.Y satoshis, Y > X

It'll look like zero sats to old clients but they won't be able to figure out why the true remainder that all the newer clients are seeing is 9 sats - keeping in mind that old clients will ignore the decimals - instead of 10.

I'm not sure if it will break tx verification in those versions. Did Core ever do arithmetic on addresses and inputs as part of the verification process?

[aliashraf]

Total world GDP  is like 80 trillion USD (2017); for any volume of annual trade, just a tiny fraction  is needed as the medium of exchange.
For fractions of Satoshi to be necessary you need bitcoin to have a value above 10 million dollars where each Satoshi worth more than 10 cent, then we will have 210 trillion dollars money volume which is ways more than enough for total global trade.

[j2002ba2]

When someone spends outputs that have a fraction of a satoshi, the transaction will appear to be invalid because it violates consensus rules. If you can send a fraction of a satoshi, you can also send 1.5 satoshi in an output.

Spending zero satoshi is backward-compatible. New amounts will be visible only by new clients, the old ones will see moving zero satoshis from some inputs to zero satoshis to some outputs. It is similar as in Segwit: if you run some old client, you see no signatures in Segwit inputs.

Unfortunately it's not backward-compatible. Let the new amounts be 1.9 and 1.9, the old will be 1 and 1. Adding the new amounts we have 3.8, the old ones see only 2. Let the new outputs be 3.1 and 0.7. What about the old outputs? We cannot put 3 and 0, the old ones can spend only 2. The new outputs diverge further and further from old ones. In fact old amounts become fake.

One could avoid this by separating it into real satoshis and micro-satoshis, without overflow from micro to real. But then where would micro-sats come from? The earliest point would be after the tenth halving, maybe in year 2048.

This looks too late. Another way is to introduce a new, smaller unit, decoupled from sats. Something like a built-in altcoin. It could be soft forked using one of the nops, i.e. <amount> OP_SEND OP_DROP.

On the other hand why one would need such small units on layer 1? Doesn't make sense.

[pooya87]

Something like this could be implemented in a backward compatible way but is a tremendous burden to both code correctly and for full nodes to keep a complicated database of the fraction amounts on top of what they have.
For example you don't have to use the amount field anymore, just use the witness part. A witness version X (like 3) could do it by assigning the first witness item to be the fraction amount. In case of two 1.9 and 1.9 inputs the fractions go in the witness item and become 0.9+0.9=1.8 and the old part (the amount in each txout) is still 1+1=2. Both nodes are happy.

The problem however is that the following statement is not correct:

In the future, sooner or later, introducing fractional satoshis would be needed.

[vjudeu]

Unfortunately it's not backward-compatible. Let the new amounts be 1.9 and 1.9, the old will be 1 and 1.

No. The old will be zero and zero.

[vjudeu]

i'd rather see hard-fork

Everyone would rather see hard-fork, but because of backward-compatibility, the only way for BTC is the soft-fork way, unless the old software will be totally broken (for example after breaking ECDSA or SHA-256). Of course, all such changes could be also applied to some second layers like Lightning Network and as long as there would be a way to never touch the mainnet, it would be de facto standard without any forks and users would be fine.

[pooya87]

Everyone would rather see hard-fork, but because of backward-compatibility, the only way for BTC is the soft-fork way,

The main reason why soft forks are chosen is because they don't require everyone to upgrade which is a side effect of being backward compatible, otherwise hard forks are a lot better. For example SegWit as a hard fork would have been so much better (no need for waste of space [flag, wrapped SegWit, extra field,...], no need for old script types that are equivalent to new ones).

as long as there would be a way to never touch the mainnet, i

That is impossible. Second layer is built on top of "first" layer and cannot exist without it.

[odolvlobo]

One problem with a floating-point representation is that the system will lose satoshis due to precision adjustment.

For example, lets assume a simple decimal system with 1 digit of precision. In this system, a transaction with 2 inputs of 0.9 satoshis each, can have a maximum output of 1 satoshi, for a permanent loss of 0.8 satoshis.

Of course, the precision is much higher in your system so the loss would be lower, but it would not be 0.

[PrimeNumber7]

When someone spends outputs that have a fraction of a satoshi, the transaction will appear to be invalid because it violates consensus rules. If you can send a fraction of a satoshi, you can also send 1.5 satoshi in an output.

Spending zero satoshi is backward-compatible. New amounts will be visible only by new clients, the old ones will see moving zero satoshis from some inputs to zero satoshis to some outputs. It is similar as in Segwit: if you run some old client, you see no signatures in Segwit inputs.

No. That is nonsense. If someone spent two 0.5 satoshi inputs and had a single output of 1 satoshi output, an old node would need to recognize the output as being valid

With SegWit, there were scripts that were previously "anyone can spend" that were changed to "only certain people can spend". This means transactions sent to SegWit addresses would appear valid to both old and new nodes, and that transactions that spend SegWit inputs would appear valid to both old and new nodes, but old nodes would not be able to validate if the transaction is valid under new rules.

A soft fork must restrict the transactions that are valid. Your proposal increases the transactions that are valid.

[vjudeu]

A soft fork must restrict the transactions that are valid. Your proposal increases the transactions that are valid.

How? Currently transactions sending from zero coins to zero coins have no restrictions at all (except matching signatures of course). In the new format, they would be valid only if new amounts would match.

I think that sending zero satoshis is the only option to completely skip amount validation. Using any other amount would mean that adding them would be necessary. Also, if going from this new format to the old one should be possible, then all fees from such zero satoshi outputs could be collected in some special output and splitted between old accounts when needed.

No. That is nonsense. If someone spent two 0.5 satoshi inputs and had a single output of 1 satoshi output, an old node would need to recognize the output as being valid

It will recognize them as valid. The old node would see two zero satoshi inputs and single zero satoshi output. Unless that new output should be in the old format, then it would be taken from previously accumulated coins (because if someone converted N old satoshis to new zero satoshis, all these coins were taken as fees and placed in a special coinbase output).

One problem with a floating-point representation is that the system will lose satoshis due to precision adjustment.

I think that 56 bits should be sufficient to express any amount precisely enough, and the first 8 bits just allow to shift them to the right and express smaller amounts in this way.

If more precision is needed, then more than one output should be used.

For example, lets assume a simple decimal system with 1 digit of precision. In this system, a transaction with 2 inputs of 0.9 satoshis each, can have a maximum output of 1 satoshi, for a permanent loss of 0.8 satoshis.

No, it can be saved by creating two outputs, one with 0.8 satoshis and one with single satoshi. And we talk here about 56 bits of precision, so such cases would be extremely rare.

[j2002ba2]

A soft fork must restrict the transactions that are valid. Your proposal increases the transactions that are valid.

How? Currently transactions sending from zero coins to zero coins have no restrictions at all (except matching signatures of course). In the new format, they would be valid only if new amounts would match.

There are no UTXOs containing zero coins. These are pruned, and cannot be used as an input.

The whole discussion is pointless. There's no need of sub-satoshi values on layer one.

[pooya87]

There are no UTXOs containing zero coins. These are pruned, and cannot be used as an input.

That's wrong. The only outputs that never enter the UTXO database are the ones that start with OP_RETURN otherwise any other output regardless of its amount value will enter the database (granted the transaction containing it is valid).
Here's an example tx with 2 outputs both with 0 amount
https://blockchair.com/bitcoin/transaction/2c3050b7eb9b0a659a93f72e701b2cb17224af03bb42978ca3b0d2b6ffadc3d8

Here is another one with the transaction spending it:
https://blockchair.com/bitcoin/transaction/84be9f9b56a4e824fe92311eba4075539313171084213275ed1b946dfb52e9f5
https://blockchair.com/bitcoin/transaction/349c5580262d0a4d640f70d82004daecba08bb83f068b6fb7370ad859d437138

The whole discussion is pointless. There's no need of sub-satoshi values on layer one.

That's true though.

[BlackHatCoiner]

Isn't it a little early to talk about fractional satoshis when the dust amount is 547? We have no need for extra digits, 8 are fine. Anything below the dust amount shows that you're unable of broadcasting it, to prevent any DDoS attacks. I've noticed that they dust amount goes analogously with the exchange rate to dollars. In the early 2011, it was 0.01 BTC (~= 1-20 cents). Now, in 2021, it's 0.00000547 BTC (~= 1-20 cents).

Assuming that 0.00000001 BTC becomes equal with a value within that range, then we'd still not need it. And that would make the price of 1 BTC ~= $1,000,000-$20,000,000. The market cap would be within $20,000,000,000,000 and $400,000,000,000,000.

Please correct me if I made a mistake anywhere.