Pages:
Author

Topic: Representing fractional satoshis in difficulty-like format (Read 347 times)

legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
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.

I don't see any problem with mere discussion about fractional satoshi, it could be used as reference in future. But it become controversial if people are serious to implement it today. Aside from the fact we don't need extra digit, it waste everyone's time since it potential require hard-fork or soft-fork which add another technical debt/complexity.
legendary
Activity: 4270
Merit: 4534
Quote
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.

as you say
just having old nodes forget anything below a satoshi wont work.  
leading to old nodes not relay these tx's as they are breaking the transaction value audit

but also
the 'change'(tx fee) which then turns into coinbase reward would also be unauditable
the auditing of all the change wont tally to the same amount as the coinbase fee reward and would void the whole block

which means it involves alot more cludgy code to redefine consensus than just having a new tx format that measures value in sub satoshi units.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
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.
legendary
Activity: 3472
Merit: 10611
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

Quote
The whole discussion is pointless. There's no need of sub-satoshi values on layer one.
That's true though.
full member
Activity: 206
Merit: 447
Quote
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.

hero member
Activity: 813
Merit: 1944
Quote
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.

Quote
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).

Quote
One problem with a floating-point representation is that the system will lose satoshis due to precision adjustment.
Quote
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.

Quote
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.
copper member
Activity: 1652
Merit: 1901
Amazon Prime Member #7
Quote
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.
legendary
Activity: 4466
Merit: 3391
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.
legendary
Activity: 3472
Merit: 10611
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).

Quote
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.
hero member
Activity: 813
Merit: 1944
Quote
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.
hero member
Activity: 813
Merit: 1944
Quote
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.
legendary
Activity: 3472
Merit: 10611
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.
full member
Activity: 206
Merit: 447
Quote
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. OP_SEND OP_DROP.

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

legendary
Activity: 1456
Merit: 1175
Always remember the cause!
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.
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
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?
hero member
Activity: 813
Merit: 1944
Quote
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.
copper member
Activity: 1652
Merit: 1901
Amazon Prime Member #7
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.
hero member
Activity: 813
Merit: 1944
Quote
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.
copper member
Activity: 1652
Merit: 1901
Amazon Prime Member #7
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.
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
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.
Pages:
Jump to: