Bitcoin decimals. Is 1.00000000 Bitcoin the same as 1.000000000000 Bitcoin?

[o_e_l_e_o]

please please pelase go look at the transactions and coin rewards of 2009 in actual byte form data. (true data form) and realise that a coin reward was never 50.00
it was always 5,000,000,000 units. it was just the GUI front end graphic display for human eye interpreted as 50.00.. but that was not the actual hard code rule

I mean, as DooMAD has pointed out, I literally said that a satoshi has always been the base unit in the very post you quoted, but feel free to create more strawmen at which to direct your rage.

My math tells that no matter how many zeroes are after the decimal point, if they're all zero it's the same number.

Absolutely. Take a meter. It does not matter if you divide that in to 100 centimeters, or 1,000 millimeters, or 1,000,000,000 nanometers. You will never have more than 1 meter.

If it were the case that dividing bitcoin in to millisats was effectively creating more bitcoin, then why is Lightning bitcoin the same value as on-chain bitcoin? It should be that Lightning bitcoin is 1/1000th the price of on-chain bitcoin, since there are 1000 times more units in the form of millisats. This is obviously not the case, because dividing a fixed supply in to smaller units is not the same as increasing the supply.

[1714583533]

1714583533

[1714583533]

1714583533

[1714583533]

1714583533

[franky1]

oeleo you also said

"Satoshi had no issue with further subdivision"
and
"No one complained then that suddenly there were a million times more bitcoin, and the cap of 21 million had suddenly become 21 trillion because of 6 more places after the decimal point."

where you were trying to make it sound like more subunits were created in the past and bitcoin had more shareable bitcoin due to a change in the past and no one cared.. yes you made it sound as if its not a problem to break the rules now to add more units...



i clarified that satoshi was not talking about the hard rule of subunits(sats)... he was just talking about the GUI display of representation outside of the rule.. where it does not even change the rules or subunits.
but just a lazy basket display

stop trying to use references about graphic display translations to think it infers acceptance to break hard code rules

[uneng]

As long as bitcoin has 100,000,000 satoshis there won't be any issues. It just shouldn't be created more decimal "satoshis" houses, so instead of the currently amount we would say bitcoin is composed by 1,000,000,000 satoshis or more. 1 btc must always equal to 100,000,000 satoshis. If people want to create decimal houses they should divide the satoshi unit in more parts, but never changing the currently structure.

If they want to transact 1,37158304 satoshi it's ok.

[NotATether]

Side note, you don't need a hardfork to add (a few) extra decimal places. There is some parameter in Bitcoin Core which lets you configure the minimum transaction fee of tx's your node will relay (-minrelaytx?). It's default value is 1000 sats/kB (kilobyte). You can change this to as low as 1, and get 3 extra decimal places used, for a total of 11 decimals.

[serjent05]

I also believe any decimal added on the right won't change the value of a whole number 1 is always equal to 1.000000000.  It can be proven mathematically unless one value on the decimal became 1  .  Since the number of Bitcoin in circulation is not impacted or changed by adding several zeros on the decimal, I believe the scarcity and value will stay the same.  What changes is the divisibility since Bitcoin can have a smaller fraction than its current original state.

[o_e_l_e_o]

Side note, you don't need a hardfork to add (a few) extra decimal places. There is some parameter in Bitcoin Core which lets you configure the minimum transaction fee of tx's your node will relay (-minrelaytx?). It's default value is 1000 sats/kB (kilobyte). You can change this to as low as 1, and get 3 extra decimal places used, for a total of 11 decimals.

That's not how it works.

The value you are thinking of is the MIN_RELAY_TX_FEE (https://github.com/bitcoin/bitcoin/blob/e9262ea32a6e1d364fb7974844fadc36f931f8c6/src/policy/policy.h#L57), which is indeed set at 1000 sats/kvB (which is equivalent to 1 sat/vB). However, this only applies to the fee paid for a transaction. Sure, you can change it to 1 sat/kvB if you want, meaning that a 250 vB transaction would only have to pay at least 2.5 sats in fees, which would in reality mean it had to pay a minimum of 3 sats. However, none of that allows you to send fractions of a satoshi as a fee or to create outputs which include fractions of a satoshi. It simply sets a lower limit for what your fee can be.

Because transactions are actually measured in weight units, we already have transactions which are fractions of a vbyte in size. For example, here is one I just pulled from my mempool: https://mempool.space/tx/5cf1d3b06cdb4dcd4513a42d6d3b19691558326af4ca11b961d852e39d9ed402. It has a virtual size of 172.25 vB, meaning the minimum fee required for this transaction would be 172.25 sats. But of course we cannot pay a fee of 172.25 sats, so the minimum fee would be 173 sats.

[NotATether]

The value you are thinking of is the MIN_RELAY_TX_FEE (https://github.com/bitcoin/bitcoin/blob/e9262ea32a6e1d364fb7974844fadc36f931f8c6/src/policy/policy.h#L57), which is indeed set at 1000 sats/kvB (which is equivalent to 1 sat/vB). However, this only applies to the fee paid for a transaction. Sure, you can change it to 1 sat/kvB if you want, meaning that a 250 vB transaction would only have to pay at least 2.5 sats in fees, which would in reality mean it had to pay a minimum of 3 sats. However, none of that allows you to send fractions of a satoshi as a fee or to create outputs which include fractions of a satoshi. It simply sets a lower limit for what your fee can be.

In that case, since the verification process does not explicitly check that amounts are within 8 decimals (its an implicit check, owing to the fact that every 8-decimal value can be represented in Core's custom integer type), a soft fork adding a second byte field for sub-fractional amounts (as garlonicon explained to me somewhere) should still work.

[franky1]

Side note, you don't need a hardfork to add (a few) extra decimal places. There is some parameter in Bitcoin Core which lets you configure the minimum transaction fee of tx's your node will relay (-minrelaytx?). It's default value is 1000 sats/kB (kilobyte). You can change this to as low as 1, and get 3 extra decimal places used, for a total of 11 decimals.

That's not how it works.

Because transactions are actually measured in weight units, we already have transactions which are fractions of a vbyte in size.

no we do not
stop playing user display cludgy math games to pretend proposals to break bitcoin code rules and data structures is a nothing burger..
look at actual bitcoin raw transaction data, there are no fractions
and no a hard drive does not see #'vbyte'
hard drives count data in actual bytes.

again you arw talking about human cludgy math, of the human GUI display of how bad math wants to calculate a fee based on data it ignores "for discount" or pretends is 4x bigger than actual bytes for legacy

try to stick to what actually exists in the real blockchain physical data, not what you see on a GUI display or in comments of code (comments are not rules, especially when the comments are badly worded to misrepresent what is actually happening in real world math terms
oh and take your own advice from another topic

That's true, but the important distinction is that people can understand the technical side of bitcoin if they want to. They can verify everything themselves, from the genesis block to the latest broadcasted transaction,

so try it once in a while instead of setting yup your social ping pong games to try to make people think its ok to break bitcoin rules because a comment told them so


you are again trying to set up a narrative that we actually do have sub units of sats on bitcoin to pretend that breaking the actual blockchain data format and value of bitcoin is a nothingburger because in your view the GUI, comments of code and your misrepresentations of what satoshi said is a more important  decider (in your view) than actual code and data and actual satoshi quotes references


i know you then try to redeem yourself by then saying

But of course we cannot pay a fee of 172.25 sats, so the minimum fee would be 173 sats.

but you had already entered the subtle implicit idea into peoples heads.. that bitcoin does have fractions of sats by what you said at the start of the paragraph

stop playing ping pong games to try to sway readers into thinking that breaking bitcoin is not a problem

its funny how your buddy group of malicious intent to break bitcoin. pretend that when someone proposes a new fee mechanism you lot say "there is no fee mechanism, miningpools can pick and choose what is a relevant fee to them, ignoring the reason someone paid X instead of y"

but as soon as it fits your narrative, you then say that there is a fee policy that the network treats as a rule "Because transactions are actually measured in weight units"

[LoyceV]

Say inflation was so crazy 1 Satoshi became $1 and a Hard Fork took place through which we add more decimals to Bitcoin.

By the time that happens, $1 is worth nothing and 1 sat will still be small enough not to need smaller denominations.

It currently has 8.  If we add 4 more decimals, is 1 Bitcoin still just as scarce or do you consider it artificial injection of supply?

Nothing changes.

[o_e_l_e_o]

no we do not
stop playing user display cludgy math games to pretend proposals to break bitcoin code rules and data structures is a nothing burger..
look at actual bitcoin raw transaction data, there are no fractions
and no a hard drive does not see #'vbyte'
hard drives count data in actual bytes.

again you arw talking about human cludgy math, of the human GUI display of how bad math wants to calculate a fee based on data it ignores "for discount" or pretends is 4x bigger than actual bytes for legacy

Another excellent strawman. You should try arguing against things that are actually said, instead of just inventing points which weren't made to argue against.

Obviously there is no fraction of raw bytes, and I never claimed that there was. There is however, undeniably, fractions of virtual bytes. BIP 141 is quite clear that transactions are measured in weight units, and that virtual bytes are equal to weight units divided by 4, which leaves us with fractions of virtual bytes, which are then rounded up to the nearest whole byte for the purpose of calculating the fee.

you are again trying to set up a narrative that we actually do have sub units of sats on bitcoin

That's the exact opposite of what I said, when I pointed out that a minimum fee of 1000 sats/kvB obviously does not allow you to pay 172.25 sats for a transaction which weighs 689 weight units / 172.25 vbytes since fractions of a satoshi do not exist on the main chain, and so the minimum fee must be 173 sats.

Try actually pausing and reading what people are writing before launching in to another tirade.

[Smartprofit]

While answering in another thread, this debate came up in my mind about Bitcoin and decimals.  Curious to know what the general user thinks.

Say inflation was so crazy 1 Satoshi became $1 and a Hard Fork took place through which we add more decimals to Bitcoin.  It currently has 8.  If we add 4 more decimals, is 1 Bitcoin still just as scarce or do you consider it artificial injection of supply?

-
Regards,
PrivacyG

Of course, such measures will not lead to a change in the essence of Bitcoin and will not have any effect on its price. 

The number of Bitcoins in the world will not increase, and its deflationary supply model will not suffer.

In addition, such a change in the Bitcoin code is largely meaningless, since this measure will still not allow the poor to buy 1 satoshi cheaply.  This is due to the fact that all Bitcoin transactions are made on a reimbursable basis. 

The income is received by miners.  At the same time, the commissions in the Bitcoin network are quite large.

[AGD]

Even ChatGPT knows the answer:


Question about Bitcoin. What will the impact be, when we add 4 zeros after the decimal, so that there will be 12 zeros instead of now 8 zeros?


#Adding four additional decimal places to the representation of Bitcoin would not change the value or underlying properties of the cryptocurrency. It would simply allow for greater precision in the representation of small amounts of Bitcoin.

For example, currently the smallest unit of Bitcoin that can be represented is 0.00000001 BTC, which is called a "satoshi" in honor of Bitcoin's creator, Satoshi Nakamoto. If four more decimal places were added, the smallest unit of Bitcoin that could be represented would be 0.000000000001 BTC.

It's important to note that this change would not affect the underlying value of Bitcoin or the amount of Bitcoin that exists. It would simply allow for the representation of smaller amounts of Bitcoin in a more precise way.

[franky1]

oeleo
i do read what you write and i have seen tactics many times, you are not new,..  you many times have subtle hints of mentioning thing in a way that has two meaning so that you can play ping pong games to irritate people and then recruit idiots to believe the other narrative you and your buddies try MANY times to push, while trying to play inocent about not pushing it by reciting other parts of the same paragraphs where you hint at the opposite. just so you can be wishy washy and hide from your narrative

you have many times been subtly pushing that satoshi and the community dont care about adding units because i know your buddies want to break bitcoin further to make it emulate LN. you have tried it before your crew of malcontents have also at times tried to change the meaning of what a full node is your crew have tried to say that pruning is safe to do and pretend it still protects the network and still distributes the ledger and all that crap, when pruning does not help distribute the ledger nor allow peers to seed from a pruned node for IBD, and other things.

your chums of malcontents do not understand consent and abstinence in regards to consensus. heck you lot are trying to redefine consensus to say that abstinence is consent, where you lot also think vetoing a feature is evil and not consenting is evil while thinking that ignoring non-consent and abstinence is something that should be allowed.. pretending both non consent and abstinence are equal to consent means performing an act on the community should still go forward even without majority readiness to even validate a new rule..

your crew love things that hinder bitcoin scaling and you hate people that want onchain scaling, pretending no one wants it bar one person is absolutely stupid narrative played.. you lot are soo narrow minded stuck in trying to break bitcoin just to populate your crummy sub network that you cant even see that bitcoiners want bitcoin to remain secure. you think everyone wants to break bitcoin and move to your crummy network so you continue these ping pong games of promoting that breaking bitcoin can happen without harm when it literally requires breaking bitcoin(harm) to do so.

you pretend sometimes your on the side of bitcoin by ending a paragraph to sound like your all for protecting bitcoin but you start paragraphs with you hinting that it can be broke easily without controversy.

oh and if you are going to now suggest that im wrong because [insert any excuse] to try distancing yourself from your chummy narrative of malcontents and say that you are not like them or you dont believe in their narrative.. atleast stop sounding like them first by avoiding copying their narrative, then maybe one day i wont keep mentioning you in the same regard as them


mnow i dare you to actually go and look at a raw transaction get the real binary data, and then see what that transaction value becomes if you changed a rule where the hard data subunit of a 50btc coin reward from 2009 was represented in your dream delusion of a LN emulating 11 decimal system

ill give you a hint 50 becomes 0.05
it also breaks the halving cycles ru;le where instead of finishing in 2142 it finishes in 2180 if it was imposed at the next halving to emulate LN digits
and he total coins mined so far (19m) will be diluted in representation to look like 190k bitcoin where the remaining new coin by 2180 will look like only 1.3m coins.
go try and look at data, code, rules, and do some math. and stop relying on comments you find as your source bases to break bitcoin. because no satoshi did not say he wanted to break bitcoins sub unit rule

[DooMAD]

crew of malcontents

Only in the delusional mind of franky1 could anyone other than himself be portrayed as the malcontent here.  I don't see anyone else disrupting every topic they can find to whine about "fake consensus" and the supposed perils of millisats.  Notice how it's only franky1 with the firework permanently lodged up their arse about such things.   

For what must be the hundredth time, we've got what we want.  We're perfectly happy (aside from having an unhinged lunatic to contend with every time we say something, that part is definitely wearing thin).  We don't require a "narrative" to change things.  The change has already been made.  You are simply unable to come to terms with the change.  You are the one who despises everything and everyone.  This is very much a you problem.  You are the malcontent.

[NeuroticFish]

ill give you a hint 50 becomes 0.05

You had better days with your answers, really.

And no, 50 would not become 0.05. 50 would become 50.0000.
The question is about replacing 1 satoshi with 1.0000 satoshi, not with 0.0001 satoshi.
Your "math" would work only if such a change would be done by monkeys instead of programmers. And it's not the case.

[NotATether]

look at actual bitcoin raw transaction data, there are no fractions
and no a hard drive does not see #'vbyte'
hard drives count data in actual bytes.

I don't know why Core developers decided to invent a new size metric "vbytes", considering that only the scriptSig and some other fields are excluded from the byte calculation. IMO it would've been better to use the terms "transaction fee (legacy)" and "transaction fee (segwit)" and then keep the byte metric, but I guess it's much too late for that now.

[franky1]

I don't know why Core developers decided to invent a new size metric "vbytes", considering that only the scriptSig and some other fields are excluded from the byte calculation. IMO it would've been better to use the terms "transaction fee (legacy)" and "transaction fee (segwit)" and then keep the byte metric, but I guess it's much too late for that now.

the reason is simple.. dev politics

the scaling bitcoin was about increasing transaction count..
the debate then became named "blocksize" debate

one side wanted more transaction utility on the blockchain.
the other side wanted to make it look like the first side just wanted more data bloat without more transaction utility

hence throwing around useless names like "big blocker" rather than calling the desires what they were.. more transactions on chain

so core used the cludgy math of miscounting bytes to "break outside the 1mb blocksize" without actually truly giving any increase in transaction count potential.,
because in their view saying they are offering "4mb blocksize" aka bigger blocks.. which in their mind was what the community wanted.., same tx count but more "block size" even if it was not what is actually been requested.

yea they been saying "look blocks are now 4 instead of 1.. while the actual tx count is not 4x
.. all thats been done was multiply the legacy bytes by 4x

very shady manipulative crap was done to pretend they were offering what the community wanted but in the end not giving the community 4x tx capacity. and instead just some unfinished txformat that is just used as a gateway to other networks (its true intent) while faking legacy as being 4x to "give the community the 4x they wanted"


its the simple analogy of
"we have 1 wife of 120lb we would like 4 wives of 120lb"
and core devs decided lets give then 1 wife of 480lb as it sounds like what they want

[seoincorporation]

Adding more zeros to bitcoin will not change anything, the total amount of bitcoin will be 21 million... And seeing 1 satoshi in $1 is an impossible scenario.

But is important to mention that some services already added more zeros on bitcoin for practical proposes. Here is a good example, go to coinmarketcap and look at the dogecoin prize, there you will see:

1 doge = 0.000004113

That's right, 9 digits after the dot... For trading and markets, this is a good option for better manipulation.

[franky1]

Adding more zeros to bitcoin will not change anything,

read some code. look at blockchain data..
look at how things need to change to get the "extra decimals"

dont just think from the prospective of the GUI

actually learn what is actual happening at the real rule and data level
breaking the rules to have more units at data level changes ALOT

it changes the number of halving events
it dilutes the 19m 'btc' to appear as 190k btc
meaning the "new btc" mined ends up as about 1.3m(1,332,187) btc at the end of all halvings in 2180

please do some maths and look at the data

check this post..
then read some code. check block data. and see how it actually changes..
.. surprise yourself by learning something

[BlackHatCoiner]

Say inflation was so crazy 1 Satoshi became $1 and a Hard Fork took place through which we add more decimals to Bitcoin.  It currently has 8.  If we add 4 more decimals, is 1 Bitcoin still just as scarce or do you consider it artificial injection of supply?

Yes. The 8 decimals isn't a strict protocol rule that affects monetary policy. Nobody ever promised there will be 8 forever. The only thing that's being said is that there won't be more than 21 million coins. Whether we have 8, 12 or infinite decimals, the 21 million rule is enforced. The fact that we'd have a few more coins in each decimal increase doesn't violate that rule.

it also breaks the halving cycles ru;le

Take a breath, calm down, sit and hear this: there is no halving cycle rule.