coinlatte (OP)
Newbie
Offline
Activity: 21
Merit: 16
|
|
April 12, 2021, 01:35:45 PM |
|
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: 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.
|
|
|
|
sheenshane
Legendary
Offline
Activity: 2478
Merit: 1231
|
|
April 12, 2021, 01:56:44 PM Merited by JayJuanGee (1) |
|
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
Legendary
Offline
Activity: 1736
Merit: 7281
In memory of o_e_l_e_o
|
|
April 12, 2021, 02:33:33 PM Merited by JayJuanGee (1) |
|
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
Copper Member
Legendary
Offline
Activity: 1652
Merit: 1900
Amazon Prime Member #7
|
|
April 12, 2021, 03:04:44 PM |
|
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
|
|
April 12, 2021, 04:31:48 PM Merited by JayJuanGee (1) |
|
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
Copper Member
Legendary
Offline
Activity: 1652
Merit: 1900
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.
|
|
|
|
vjudeu
|
|
April 12, 2021, 06:21:35 PM |
|
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
Legendary
Offline
Activity: 1736
Merit: 7281
In memory of o_e_l_e_o
|
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
Legendary
Offline
Activity: 1456
Merit: 1174
Always remember the cause!
|
|
April 12, 2021, 08:23:10 PM Last edit: April 12, 2021, 08:35:10 PM by 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
|
|
April 12, 2021, 10:56:32 PM Merited by JayJuanGee (1) |
|
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
Legendary
Offline
Activity: 3584
Merit: 10902
|
|
April 13, 2021, 03:41:05 AM Merited by JayJuanGee (1) |
|
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
|
|
April 13, 2021, 06:07:44 AM |
|
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
|
|
April 13, 2021, 12:30:53 PM |
|
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
Legendary
Offline
Activity: 3584
Merit: 10902
|
|
April 14, 2021, 02:59:40 AM |
|
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
Legendary
Offline
Activity: 4438
Merit: 3388
|
|
April 14, 2021, 12:24:10 PM |
|
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.
|
Join an anti-signature campaign: Click ignore on the members of signature campaigns. PGP Fingerprint: 6B6BC26599EC24EF7E29A405EAF050539D0B2925 Signing address: 13GAVJo8YaAuenj6keiEykwxWUZ7jMoSLt
|
|
|
PrimeNumber7
Copper Member
Legendary
Offline
Activity: 1652
Merit: 1900
Amazon Prime Member #7
|
|
April 14, 2021, 01:47:10 PM |
|
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
|
|
April 15, 2021, 05:40:25 AM |
|
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
|
|
April 15, 2021, 04:49:32 PM |
|
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.
|
|
|
|
|
BlackHatCoiner
Legendary
Offline
Activity: 1652
Merit: 8149
Bitcoin is a royal fork
|
|
June 27, 2021, 06:33:58 PM |
|
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.
|
|
|
|
|