Bitcoin Forum
May 10, 2024, 06:31:24 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How difficult is it to increase Bitcoin divisibility?  (Read 3308 times)
rebuilder (OP)
Legendary
*
Offline Offline

Activity: 1615
Merit: 1000



View Profile
March 23, 2011, 09:53:01 AM
 #1

Currently, Bitcoins are divisible to 8 decimal places. It's conceivable that if Bitcoin gains real momentum, in the future that may not be enough granularity. It's not going to be a problem for a while, quite possibly ever,  but it may be in the future. So, some thinking on this follows:

I'll use the term "Satoshi", as previously coined by others, to mean the current smallest available Bitcoin unit.

-From what I understand, increasing the divisibility would require modifications to the protocol such that transfers of any sums below one Satoshi would not be compatible with clients lacking the modifications. Correct?

-I assume that transfers of sums up to 8 decimal places would still be possible between "new" clients and "old" ones, or at least the modifications could be done in such a way that this was the case.

Now, if it becomes necessary to add divisibility, how troublesome will this be? Let's say I'm selling nuts and bolts and I realize one Satoshi is too much for a bolt. I have a customer who really, really just wants to buy one bolt from me, but is only willing to pay .1 Satoshi for it, which I think is a fair price. So, I start using a modified client that allows for spending of sub-Satoshi amounts, and I tell my customer to do the same. Let's say I had 1000 Satoshi before, now I have 1000.1. I do many such transactions, until the smaller sums eventually form several Satoshi.

So, I suppose the client would be able to collate sub-Satoshi sums into Satoshis so that I can still send 1 Satoshi or more to someone not using a client capable of handling sub-Satoshi amounts. The other option is that sub-Satoshi transfers essentially "corrupt" my wallet in such a way that the BTC it contains are no longer compatible with legacy versions of the protocol. This is not the case, right?

Basically I'm wondering if there's any serious incompatibility that would result from an increase in divisibility, or if it's just a matter of needing to upgrade to a new client if one wishes to use sub-Satoshi amounts, without any added troubles if one does not. As far as I can tell, it should be pretty trouble-free, but is there something I'm missing? If increased divisibility amounted to forking the block chain, then maybe it should be done sooner rather than later.


Selling out to advertisers shows you respect neither yourself nor the rest of us.
---------------------------------------------------------------
Too many low-quality posts? Mods not keeping things clean enough? Self-moderated threads let you keep signature spammers and trolls out!
1715365884
Hero Member
*
Offline Offline

Posts: 1715365884

View Profile Personal Message (Offline)

Ignore
1715365884
Reply with quote  #2

1715365884
Report to moderator
1715365884
Hero Member
*
Offline Offline

Posts: 1715365884

View Profile Personal Message (Offline)

Ignore
1715365884
Reply with quote  #2

1715365884
Report to moderator
The Bitcoin software, network, and concept is called "Bitcoin" with a capitalized "B". Bitcoin currency units are called "bitcoins" with a lowercase "b" -- this is often abbreviated BTC.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715365884
Hero Member
*
Offline Offline

Posts: 1715365884

View Profile Personal Message (Offline)

Ignore
1715365884
Reply with quote  #2

1715365884
Report to moderator
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5194
Merit: 12982


View Profile
March 23, 2011, 05:24:50 PM
 #2

The change is pretty simple, I think: The transaction and block versions would increase, and the sign bit of nValue would be treated as a sort of "enhanced precision" flag.

This is totally incompatible with old clients, though. The two networks won't be able to interact, since old clients will view all enhanced-precision transactions as being invalid. I don't think there's any way to do it in a backward-compatible way. Like all changes of this sort, it'll be phased in. This has been done several times before. The new rule applies only after some block number is reached, so everyone moves to the new rule simultaneously. Here is a past backward-incompatible change that was phased in, for example:

Code:
if (nBestHeight > 84000)
{
    if (nKeysCount > 20)
        return false;
    nOpCount += nKeysCount;
    if (nOpCount > 201)
        return false;
}

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
stakhanov
Full Member
***
Offline Offline

Activity: 175
Merit: 101


View Profile
March 23, 2011, 06:24:02 PM
 #3

Shouldn't we make the change now, when it is still relatively simple?
genjix
Legendary
*
Offline Offline

Activity: 1232
Merit: 1076


View Profile
March 23, 2011, 06:35:58 PM
 #4

Shouldn't we make the change now, when it is still relatively simple?

I agree. Either variable length or INT128.

The beginning 13 bits are not even used and are always 0 even. Maybe they could be used as a flag to indicate another INT64 following the same format on the end.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!