I am proposing the bitcoin development community work together on creating a specification for a new wallet-access protocol. The present bitcoind JSON-RPC has numerous problems (primarily polling requirements and precision issues) which make it unsuitable for efficient usage in a client. Please feel free to edit https://en.bitcoin.it/wiki/Wallet_protocolThe first task, IMO, should be to define requirements for the protocol. Once those are relatively stable, we can begin on actual specification of the protocol constructs. |
|
|
|
If the ".0" workaround is not desired, it should be easy to back out just that one commit. However, it should have no negative effects, and avoids money-handling problems with buggy JSON implementations (which there seem to be plenty of).
Can you be more specific? I know of jansson, which has problems because the author arbitrarily declared all integers in his API to be 32-bit. What other problematic implementation exist? I'm no expert on all the JSON libraries out there, but the one embedded in BitCoin had such a bug-- if a JSON number looks float-ish, it will error if the code tries to access it as an integer. This bug is out of necessity fixed in the ".0"-adding commit. 1. I agree with a proposal to change RPC to showing native int64 values for monetary amounts, in JSON output. No special tricks like $coin.0.
2. I disagree that this issue, alone, requires a breaking change to RPC. It's "nice to have" but not a driver for inclusion.
3. I strongly disagree with multi-version code at this early stage in bitcoin's life. We should just pick an RPC version and stick with it. "This" issue? There are numerous issues being addressed by this solution... Note: According to the JSON standard, N and N.0 are the exact same number. (not intending to argue with your points here, just making a point of fact). |
|
|
|
Comments: - We should not support multiple RPC versions in the same binary. We are at 0.3.x, early in bitcoin's life. If we need to change the API, we just change it. Adding a 'version' arg to many functions pointlessly increases complexity.
- However, I don't see a driving need to change the API just for this issue.
- It is strange that SelectCoinsMinConf() needs any change at all.
- In general, I understand the desire to avoid faux-floating point in JSON output, as is currently done, but "$nanocoin.0" seems like an absurd attempt to avoid weird implementation issues, when those issues should instead be confronted directly.
Good catch with SelectCoinsMinConf-- that bit is part of a bugfix that should (AIUI) already be included in the 0.3.21 tree. Apparently it's not, so got grouped in. I remade the diff and updated the link in the original post. If the ".0" workaround is not desired, it should be easy to back out just that one commit. However, it should have no negative effects, and avoids money-handling problems with buggy JSON implementations (which there seem to be plenty of). P.S. even though I know what you mean, probably best not to use the word "nano" for what is not in any way a SI-nano division. might confuse someone. |
|
|
|
I would gather that Luke, the proponent of Tonal Bitcoins, is deaf to the concern that unnecessary complication is bad. Someone who has no problem persistently telling us we need to switch to using the character "9" to mean ten because it's "easier for humans" would have no reservations about doubling the complexity of the API to support the same agenda. This is a simplification and correction, it doesn't add complexity. While proper precision is indeed a requirement of sending TBC, it is by no means TBC-specific. |
|
|
|
Can you post examples of requests/responses with the "old" JSON-RPC and your new JSON-RPC? RPCv0: {"params":[],"method":"bitcoin.0.getbalance","id":"jsonrpc"} => {"result":351.10259079,"error":null,"id":"jsonrpc"}RPCv1: {"params":[],"method":"bitcoin.1.getbalance","id":"jsonrpc"} => {"result":35110259079.0,"error":null,"id":"jsonrpc"}RPCv0: {"params":["1DMNJcDoqeLcEyCD3KRZ49MT4PKFcoafKU",1.00000000],"method":"bitcoin.0.sendtoaddress","id":"jsonrpc"} => {"result":"d51e53e9a50aac1856c68ad619f6c19bb7d5791670a57c1f4e3131b10965938f","error":null,"id":"jsonrpc"}RPCv1: {"params":["1DMNJcDoqeLcEyCD3KRZ49MT4PKFcoafKU",100000000.0],"method":"bitcoin.1.sendtoaddress","id":"jsonrpc"} => {"result":"d51e53e9a50aac1856c68ad619f6c19bb7d5791670a57c1f4e3131b10965938f","error":null,"id":"jsonrpc"}RPCv0: (impossible to do)RPCv1: {"params":["1DMNJcDoqeLcEyCD3KRZ49MT4PKFcoafKU",1048576.0],"method":"bitcoin.1.sendtoaddress","id":"jsonrpc"} => {"result":"d51e53e9a50aac1856c68ad619f6c19bb7d5791670a57c1f4e3131b10965938f","error":null,"id":"jsonrpc"}I'm still firmly against this change-- it seems to me you are "solving" a non-problem. The problems addressed have been discussed in the 3 other threads, as well as the majority expressing a desire to use base units for internals/protocols. |
|
|
|
There have been 3 threads about the 1000000 base unit rounding problem now, and all 3 have had a general consensus that base units should be used by all protocols and internals. Gavin made a valid point about a buggy JSON-RPC library that would try to fit anything integer-looking into a int32_t, and that can easily be solved by appending ".0" to all amounts, triggering any such oversimplified implementation to use a floating-point type (which can represent all valid base unit bitcoin values without precision errors). I have completed a working implementation of this in the Gitorious 'neutral' branch ( http://gitorious.org/bitcoin/bitcoin/commits/neutral ). The only "bug" remaining, in my experience, is that when operating in JSON-RPC client (not server) mode, the pretty-formatting code turns the ".0" into ".00000000"; since this mode is mainly useful for testing, and even then defaults to the old RPCv0 mode, it should not be in my opinion considered a blocker issue. Currently, to use RPCv1, methods must be prefixed by 'bitcoin.1.'; RPCv0 can be explicitly selected with 'bitcoin.0.'. MagicalTux had suggested using instead a different URI, but the changes required in bitcoind to support this would be non-trivial. Testing and constructive criticism requested; Let's try to get this fix in for 0.3.21! Edit: To see a diff of all the changes, run: git fetch git://gitorious.org/bitcoin/bitcoin.git neutral && git diff -r b1a657a..FETCH_HEAD Edit: Pretty diff of everything changed: http://paste.factorcode.org/paste?id=2182 (please use git pull, don't apply patch manually) |
|
|
|
Some points: Are you using Windows or Linux? Also gavin accepted the patch, so we should expect the bitcoind to have that patch in the next release. Let's use the accepted Python coding style: http://www.python.org/dev/peps/pep-0008/Why do you run bitcoin --help? The file core_interface.py is preferrable since we want to have the option to later switch to other cores (QBitcoin  I'm working on wallet backup atm so I'll message you on irc once that's done to guide you through pulling in my changes. I only use Linux. Patch or not, I just wanted to use it with a 24/7 remote RPC server. When working on others' code, I try to simply mimic their coding style. Python annoys me enough without trying to follow a long list of additional nonsensical rules. What don't you like? :p It runs 'bitcoind --help' to ensure bitcoind is available. If it isn't, the "Internal" option is disabled. Perhaps using an internal-core subclass in core_interface.py would be a good idea, but then *all* invocation/control of bitcoind should be moved into it (right now you have this in main.py) |
|
|
|
We all know here that there's a maximum number of bitcoin which is 21 million. 20,999,999.9769 BTC actually. Who needs an infinite number of bitcoins anyway? There are a finite number of potential bitcoin users. An infinite currency is a worthless currency. There are an infinite number of potential bitcoin users, until the end of the world. Currently, the world population is a mere 6.7 billion, and there is more than enough land in Texas for every last one of us to have our own house. If BitCoin succeeds long-term, we will need much more base units. But that's so far off, it's not worth bothering with now. |
|
|
|
I want to use TBC, not BTC. So when TBC reaches $1 parity, I will celebrate *that* day.  |
|
|
|
or possibly it might be better to just stick with the existing SI units and use mBTC (milli-bitcoin; 0.001 BTC) or μBTC (nano-bitcoin; 0.000001 BTC). This creates another problem. You have mili-btc, which is easy enough, but what about 0.0001 BTC and 0.00001 BTC ? Oh well, yet another reason decimal/SI sucks I guess. Switch to Tonal, or suffer with mdBTC (milli-deci-)?  (or just use 100 μBTC or 0.1 mBTC) Reminder that we already have a URI specification that defines a format for safely representing any BTC (or TBC) value in a human-readable way. 100 BTC is represented as 100X8 (for 8 places beyond the decimal point). It could just as well be used for 1X4 (for 0.0001 BTC) or even 1X0 (for a single base unit). You mean something like this but kind of - reversed ? 1 BTCX0 = 1 BTC
1 BTCX1 = 0.1 BTC
1 BTCX2 = 0.01 BTC
1 BTCX3 = 0.001 BTC
1 BTCX4 = 0.0001 BTC Right. Introducing a new "BTCXn" would totally confuse things with the existing URI scheme probably. |
|
|
|
Reminder that we already have a URI specification that defines a format for safely representing any BTC (or TBC) value in a human-readable way. 100 BTC is represented as 100X8 (for 8 places beyond the decimal point). It could just as well be used for 1X4 (for 0.0001 BTC) or even 1X0 (for a single base unit). That being said, more human-friendly names/units are still appropriate. Base unit / 10000 could be named "DBC" (but then how would you pronounce it?), or possibly it might be better to just stick with the existing SI units and use mBTC (milli-bitcoin; 0.001 BTC) or μBTC (micro-bitcoin; 0.000001 BTC). |
|
|
|
Even though I think "TBC" is silly, if the RPC accepted strings and could either be decimal ones (1234.567) as well as hexadecimal (0x1234.567) then he'd have his Tonal Bitcoins. It would be up to him to fork it to put those silly 19th-century Mormon Deseret Alphabet looking digits in instead of the hexadecimal the rest of us understand, but anyone who shared the legitimate concern about bitcoins being strictly divisible by ten would have it solved, this could be used to represent exact amounts from IEEE floating point as well. 1 BTC != 1 TBC. 0x1234.567 BTC is 6816.287 TBC (6C81C6.E9287 in hexadecimal; it is also impossible, given it contains a fractional 0.7 (Tonal/hex; 0.4375 decimal) base units) In any case, I don't want RPC to use TBC. I want it to use base units, like all internals/protocols should. Adding a ".0" to the end is only to workaround a known buggy JSON implementation. |
|
|
|
|
Someone care to explain how precision even could be increased? It doesn't seem possible from what i know of the Bitcoin network.
|
|
|
|
Or do you mean you just want your client to warn you before wasting .009 BTC?
IF sub-cent-transactions are implemented, this is a must. the average newbie won't even notice that he's losing sub-cents, when he can only see 2digits in his GUI. also a bad idea to tell people, they first have to configure stuff right to not lose any coins. why not stick with amounts that you are able to send without a loss? Sub-cents are already possible, including invisible loss of it. Just because *you* aren't able to spend it without a loss (due to a bug in your client) doesn't mean *nobody* can... |
|
|
|
say i got a balance of 0btc.
i receive 1.009btc from mining on a pool.
now i wanna buy a coffee for my first 1btc, but i can't without losing .009btc.
my vote:
as long as it's possible to lose sub-cents, one shouldn't be able to send them. Configure your pool account not to send anything but multiples of 0.01. Or do you mean you just want your client to warn you before wasting .009 BTC? |
|
|
|
|
If it was a lot, and this all seems like a lot of work, you might offer a bounty for someone to do it for you. Be sure you trust them.
|
|
|
|
|
This thread is a poll to determine how needed sub-cent transaction precision is.
PLEASE NOTE: This is not about sending a transactions smaller than 0.01 BTC, but rather about sending transactions of (for example) 1.00000001 BTC
|
|
|
|
If it's just the JSON api then why not fix it when it becomes a problem? Upgrading an API to a new one is not a problem as much as upgrading a protocol. It is a problem now. The real question is whether the precision should be made larger from int64 to int128 It is technically impossible for more than 21 million bitcoins to ever exist. int64 holds the entire quantity of base units. int128 makes no sense on a technical level. Besides, JSON only has "numbers", not int-sizes or floats. Buggy JSON implementations might try to read number-without-a-decimal-point as an int32, which is why the JSON API should require a ".0" after every number. Base units should be used because 1) valid JSON implementations might try making an imprecise float (all are, for 0.1) even when precision is needed, 2) human-readable values should be kept on the GUI, not in low-level internals like APIs, and 3) Not all Bitcoin users want to use the Decimal BitCoin (BTC) divisions. |
|
|
|
actually in bitcoin it's an int
in ur os it's binary (or hex in ass)
in ur cpu it's binary I was referring to the RPC layer, which is internals. |
|
|
|
|
Show Posts
