How divisible are bitcoins - the technical side
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?
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.
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… 😊
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.
Quote from: FreeMoney on September 23, 2010, 6:01:27 PM UTCWon’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.
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.
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.