How divisible are bitcoins - the technical side

[nelisky]

Hey,

So there is another thread asking about bc and decimal places. It is stated that the client(s) only show 2 decimal places, but there are 8 in total. Now, working on stuff, I find that it would be nice if I could transfer at least 4 decimals precision, but the full 8 would be great.

Looking at the code it seems simple enough to remove the rounding from bitcoind, but what about the receiving side? If it's a non UI client, then it will show everything, but would I be making things overly confusing for GUI clients?

Is there any shortcoming in me patching my client to handle full precision?

[FreeMoney]

Won't transaction fees make that pointless?

If you are trying to give accurate payouts from the sportsbook I don't think anyone will mind having it rounded off at .01 for now. That is only $0.0006 after all.

[nelisky]

Won't transaction fees make that pointless?

If you are trying to give accurate payouts from the sportsbook I don't think anyone will mind having it rounded off at .01 for now. That is only $0.0006 after all.

Will transaction fees be applied to transfers above 0.01, but with more precision? I wasn't aware of it being that way.

And yes, I am rounding for now, but I like things clean, and I can either allow withdrawal of higher precision amounts, or I can round to 2 decimals the prize handout, I just rather do the former, that's all.

And no, it's not *only* for the sportsbook. I have plans...

[satoshi]

I would not encourage using the extra decimal places.  They're only intended for future use.

You are correct that above 0.01 can still have additional precision, but the recipient won't be able to see it.  The UI will show it rounded down.

[FreeMoney]

Won't transaction fees make that pointless?

If you are trying to give accurate payouts from the sportsbook I don't think anyone will mind having it rounded off at .01 for now. That is only $0.0006 after all.

Will transaction fees be applied to transfers above 0.01, but with more precision? I wasn't aware of it being that way.

And yes, I am rounding for now, but I like things clean, and I can either allow withdrawal of higher precision amounts, or I can round to 2 decimals the prize handout, I just rather do the former, that's all.

And no, it's not *only* for the sportsbook. I have plans...

You are a busy dude!

Did I hear something about the change being charged a fee? Oh oh, that was the block with the tiny fee in it. So 50.00001 sending 50 had a change of .00001 and therefore a fee, but usually no fee because 70.00001 = 50 + 20.00001 change = no fee. But this was fixed to only charge the tiny bit as fee anyhow.

[theymos]

If you wanted to do that, it'd probably be best to modify rpc.cpp and deal with nValue directly.

The recipient doesn't need to do anything special to receive the coins, though they'll probably end up throwing away most of the additional (sub-0.01) bitcoins. You'll also be throwing away coins, but probably more frequently -- you might lose a lot of them this way.

You could eliminate losses from dealing in sub-0.01 bitcoins (for yourself) by improving the way Bitcoin chooses which coins to send. It currently doesn't try to avoid the "dust change" situation, so it happens randomly.

[purplezky]

Can anyone confirm that in the existing client it still is a bad idea to do transaction with more than 2 decimals precision ?
Does this "dust change" situation still happen when the transaction is less than 0.01 bitcoins ?
Because it's ease to change rpc.cpp to round to 4 decimals precision, and i imagine a lot of people would like this to be the case.

[theymos]

Does this "dust change" situation still happen when the transaction is less than 0.01 bitcoins ?

It does.

Another decimal of allowed precision might be added soon.

[BitterTea]

It does.

Another decimal of allowed precision might be added soon.

Why do it incrementally instead of allowing the client to handle the full 8 decimals of precision?

[Gavin Andresen]

Why do it incrementally instead of allowing the client to handle the full 8 decimals of precision?

As of version 0.3.20, the GUI and JSON-RPC both allow full-precision values for sends.  So you can send 1.00123456 BTC if you like.

And the GUI will display full-precision wallet balances/etc (it truncates trailing zeros past .00, so you won't notice unless you have sub-cent BTC in your wallet).

The 'dust spam' rules are still in, so you're expected to pay a fee if you are sending less than 0.01 BTC-- that is, if you try to send 0.00001 BTC it will trigger the fee (sending 1.00001 would not trigger the fee).

[khal]

Version 32002 allow full precision in RPC, but not the GUI (0.3.20.2 BETA). Linux version, 64bits.

[edit]
Transaction amount has been rounded... (with RPC)

Code:

~/bitcoin/bitcoin-0.3.20.2/bin/64/bitcoind sendtoaddress 1B3Lbed1DdthF1LEoPrAoJvbX2SqXY1TGx 1.00123456
801cb30169228441d1a8632a5b3d6b7880947c71e7db696818ac74d26edd3734

Code:

    {
        "account" : "",
        "address" : "1B3Lbed1DdthF1LEoPrAoJvbX2SqXY1TGx",
        "category" : "send",
        "amount" : -1.00000000,
        "fee" : 0.00000000,
        "confirmations" : 0,
        "txid" : "801cb30169228441d1a8632a5b3d6b7880947c71e7db696818ac74d26edd3734",
        "time" : 1302885826
    }

[Gavin Andresen]

You're right-- full-precision is in git-head, but wasn't in 0.3.20.  It will be in 0.3.21.

[khal]

Thanks, i prefer this rather than a bug.

[purplezky]

Which Git branch is supposed to be 0.3.21