Bitcoin Forum
October 31, 2024, 12:04:12 PM *
News: Bitcoin Pumpkin Carving Contest
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How difficult is it to increase Bitcoin divisibility?  (Read 3332 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!
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5362
Merit: 13348


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!