I wrote a patch to give JSON-RPC connections their own threads. However, it still has some issues that I can't seem to figure out. If anyone can advise on how to fix it, this would be a nice feature.

• Occasional crashes (SIGABRT)
• Segfault if -DUSE_SSL
• Timed out connections aren't closed

http://luke.dashjr.org/programs/bitcoin/w/bitcoind/luke-jr.git/commitdiff/355e162fba35810978742f6f1e6f2e413cdc78e9

Would appreciate beta-testing of Spesmilo, the next generation Bitcoin client that welcomes diversity. Additional translations and patches welcome! Live support available on FreeNode #bitcoin-dev.

• Windows installer -- Requires Administrator to install or you will get an error
• Source code
• Gitorious project (including git repository)

Gentoo install:

• layman -o https://gitorious.org/bitcoin/gentoo/blobs/raw/master/overlay.xml -f -a bitcoin
• emerge -a spesmilo #(you may need to keyword some packages)

Quick start (from source):

• # Dependencies: PySide, ImageMagick
  
• make local
• make
• ./spesmilo

To install:

• make install

To install with bitcoin: URI support for KDE:

• make install KDESERVICEDIR="/usr/share/kde4/services"

[Please note that even if hexadecimal is supported, nobody is required to use it. It remains the user's choice which number system they use. Even if you open a URI encoded in hexadecimal, you will see the Decimal/BTC equivalent in your client (unless you configure it for TBC). In other words, a vote for decimal-only is a vote to force humans who want to use tonal to switch to decimal.]

Should Bitcoin: URIs be allowed to contain only decimal bitcoins (BTC), or tolerate the human's choice of BTC or TBC (converted first to hexadecimal)?

Please note that even if hexadecimal is supported, nobody is required to use it. It remains the user's choice which number system they use. Even if you open a URI encoded in hexadecimal, you will see the Decimal/BTC equivalent in your client (unless you configure it for TBC). In other words, a vote for decimal-only is a vote to force humans who want to use tonal to switch to decimal.

If you want to request/bill for 10.25 BTC, you (or your shopping cart) would write:

• Decimal only: bitcoin:youraddress?amount=10.25
• Decimal or hexadecimal: bitcoin:youraddress?amount=10.25
• Decimal or duodeci or hexadeci: bitcoin:youraddress?amount=10.25

If you want to request/bill for 1.5 mBTC (milli-BTC), you (or your shopping cart) would write:

• Decimal only: bitcoin:youraddress?amount=0.0015
• Decimal or hexadecimal: bitcoin:youraddress?amount=0.0015
• Decimal or duodeci or hexadeci: bitcoin:youraddress?amount=0.0015

If you want to request/bill for 10.2 TBC (TonalBitcoin), you (or your shopping cart) would write:

• Decimal only: bitcoin:youraddress?amount=0.01056768
• Decimal or hexadecimal: bitcoin:youraddress?amount=x10.2
• Decimal or duodeci or hexadeci: bitcoin:youraddress?amount=x10.2

If you want to request/bill for 1 ᵐTBC (mill-TonalBitcoin), you (or your shopping cart) would write:

• Decimal only: bitcoin:youraddress?amount=2.68435456
• Decimal or hexadecimal: bitcoin:youraddress?amount=x1000
• Decimal or duodeci or hexadeci: bitcoin:youraddress?amount=x1000

[Assuming they use high-level amounts]

Assuming they use high-level amounts, should Bitcoin: URIs support only present-day common-use BTC quantities, or should people be able to adapt it over time to different sizes?

Should Bitcoin: URIs use low-level or high-level units?

If you want to request/bill for 10.25 BTC, you (or your shopping cart) would write:

• Only support present-day standard units: bitcoin:youraddress?amount=10.25
• Optionally support specifying exponent: bitcoin:youraddress?amount=10.25 or bitcoin:youraddress?amount=10.25e8
• Require specifying exponent: bitcoin:youraddress?amount=10.25e8

If you want to request/bill for 1.5 mBTC (milli-BTC), you (or your shopping cart) would write:

• Only support present-day standard units: bitcoin:youraddress?amount=0.0015
• Optionally support specifying exponent: bitcoin:youraddress?amount=0.0015 or bitcoin:youraddress?amount=1.5e5
• Require specifying exponent: bitcoin:youraddress?amount=1.5e5

If you want to request/bill for 10.2 TBC (TonalBitcoin), you (or your shopping cart) would write:

• With hex support:
• Only support present-day standard units: bitcoin:youraddress?amount=x10.2
• Optionally support specifying exponent: bitcoin:youraddress?amount=x10.2 or bitcoin:youraddress?amount=x10.2x4
• Require specifying exponent: bitcoin:youraddress?amount=x10.2x4
• Without hex support:
• Only support present-day standard units: bitcoin:youraddress?amount=0.01056768
• Optionally support specifying exponent: bitcoin:youraddress?amount=0.01056768 or bitcoin:youraddress?amount=1056768e0
• Require specifying exponent: bitcoin:youraddress?amount=1056768e0

If you want to request/bill for 1 ᵐTBC (mill-TonalBitcoin), you (or your shopping cart) would write:

• With hex support:
• Only support present-day standard units: bitcoin:youraddress?amount=x1000
• Optionally support specifying exponent: bitcoin:youraddress?amount=x1000 or bitcoin:youraddress?amount=x1x7
• Require specifying exponent: bitcoin:youraddress?amount=x1x7
• Without hex support:
• Only support present-day standard units: bitcoin:youraddress?amount=2.68435456
• Optionally support specifying exponent: bitcoin:youraddress?amount=2.68435456 or bitcoin:youraddress?amount=268435456e0
• Require specifying exponent: bitcoin:youraddress?amount=268435456e0

[100000000]

Should Bitcoin: URIs use low-level or high-level units?

If you want to request/bill for 1 BTC, you (or your shopping cart) would write:

• Low-level: bitcoin:youraddress?amount=100000000
• High-level: bitcoin:youraddress?amount=1

If you want to request/bill for 1 mBTC (milli-BTC), you (or your shopping cart) would write:

• Low-level: bitcoin:youraddress?amount=100000
• High-level: bitcoin:youraddress?amount=0.001

If you want to request/bill for 1 TBC (TonalBitcoin), you (or your shopping cart) would write:

• Low-level: bitcoin:youraddress?amount=65536
• High-level (without hexadecimal support): bitcoin:youraddress?amount=0.00065536
• High-level (with hexadecimal support): bitcoin:youraddress?amount=x1

If you want to request/bill for 1 ᵐTBC (mill-TonalBitcoin), you (or your shopping cart) would write:

• Low-level: bitcoin:youraddress?amount=268435456
• High-level (without hexadecimal support): bitcoin:youraddress?amount=2.68435456
• High-level (with hexadecimal support): bitcoin:youraddress?amount=x1000

Does this wording satisfy everyone?

For Python, python-jsonrpc is the official JSON-RPC implementation. It automatically generates Python methods for RPC calls. However, due to its design for supporting old versions of Python, it is also rather inefficient. jgarzik has forked it as Python-BitcoinRPC and optimized it for current versions (at least Python 2.6+, though not 3.x). Generally, this version is recommended.

While BitcoinRPC lacks a few obscure features from jsonrpc, software using only the ServiceProxy class can be written the same to work with either version the user might choose to install:

Someone in #bitcoin-discussion was having problems with JSON-RPC and it turned out to be related to their timezone overflowing the rfc1123Time function's buffer. My 'rfc1123Time_localefix' branch addresses the problem by forcing the locale and timezone to POSIX and UTC for its purposes (and resetting it back later).

git fetch git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git rfc1123Time_localefix && git diff 454bc8..FETCH_HEAD && git merge FETCH_HEAD

I suspect the JSON-RPC has other locale problems as well, in case someone wants to look into it further.

As of now, my miner is only accepting transactions with a simple 1 TBC per Bˢ (that's 0.00065536 BTC per 512 bytes) fee minimum. That means you can send amounts less than 0.01 BTC for much less than most miners charge (0.01 BTC)! I am also allowing non-standard transactions, so you can get those in too. The only catch is, ordinary peers will silently discard your transaction, so you need to connect directly to me. You can do that with the original client by specifying -addnode=nat.router.dashjr.org on the command line. Please note you will still need to hack your bitcoin[d] to actually create the transactions. Enjoy!

Pull request: https://github.com/bitcoin/bitcoin/pull/85

Starting a thread here, since it's not possible to comment on GitHub without agreeing to finance a legal battle when they get sued.

Looks good at first glance. Can we brainstorm test cases that we think might cause problems?
E.g. Wallet with (only) available transactions of +1 +2.0001 +3 : Send 6 bitcoins; what happens?
Same wallet, send 2 (I think you'll get a 2.0001+1 spend with 1.0001 change)...
Any other tricky edge cases?

In your first case, it should send 6 with a 0.0001 fee (this one is UNavoidable).

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_protocol

The 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.

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)

[PLEASE NOTE]

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

This "Tonal Bitcoin" stuff is just stupid. "Bong-BitCoin" indeed!

Just as "stupid" as Spanish is to the ignorant American who thinks everyone should speak English. In reality, if you actually took the time to learn Tonal, you'd realize that it is in fact Decimal and SI that is truly stupid. (Yet I'm not demanding everyone drop Decimal BitCoin support just because I don't like it)

The Nystrom representation itself isn't stupid, but using it for Bitcoin is. It brings absolutely nothing worthwhile to Bitcoin.

One bitcoin is 100000000 units of bitdust, and the maximum number of bitcoins is 21000000, both of which are convenient decimal numbers. What's the point of having one Bong-Bitcoin equal to 42.94967296 BTC?

If you do want to count bitcoins in hexadecimal, you should simply use the equivalent number in base 16. For example, 255 BTC = 0xFF BTC.

More like, it brings BitCoin to the Tonal system. The Tonal system itself is also worthwhile-- but admittedly, TBC does nothing for people who are content just continuing to use Decimal (except developers, who get a method to ensure their code is properly abstracted).

One decimal BitCoin is 100,000,000 units of "bitdust", because it is a decimal unit system. The maximum number of bitcoins in decimal is in fact 20,999,999.9769, which is only convenient to round to 21 million. On the other hand, each tonal bitcoin is 1,0000 (65,536 decimal) units of "bitdust" (aka TBCᵇ), which is convenient because it is a tonal unit. The maximum tonal bitcoins is 7,750,54.00, which actually has an ending 0 unlike the decimal equivalent.

There are numerous reasons making 1 BTC = 1 TBC would be confusing and in general a bad idea:

• It would lead people to think 10 TBC = 10 BTC, when it is in fact 16 BTC
• It would be impossible to determine what unit system the value was intended to be used with. As defined today, there is a simple mathematical test to determine if any given number of "bitdust" represents a BTC or TBC value.
• 1 BTC only allows for 21 million "normal" units. There are almost 7 billion people. If BitCoin ever gains widespread adoption, the present size of TBC will be much better suited for everyday spending/trading. BTC, on the other hand, will need to re-base (or else everyone will just be using μBTC instead).
• 1 BTC is, as you stated, based on 100,000,000 base units. This is the awkward number of 55,100 base units in Tonal, and not very sensible for a Tonal unit (which are calculated in a useful way).
• 1 BTC can only be divided into 100 Tonal units. This would make it completely unworkable when/if BitCoin reaches critical mass to require rebasing.

I'm creating this thread to discuss two branches I have, titled RPCv0SubcentInputs and 'neutral'.

RPCv0SubcentInputs merely removes the code which rounds RPC inputs to centi-BitCoins. This breaks compatibility slightly, specifically with any code that assumes the RPC inputs will be rounded. There is also a possibility that if the system's FPU cannot accurately represent the fraction, the input might be interpreted slightly differently than it should be. For example, 0.1 BTC cannot be represented as a binary floating-point number.

"Neutral" bumps the BitCoin RPC version from 0 to 1, prepending (over-the-wire only) methods with "bitcoin.<version number>.", and removes (in principle) all the methods which were marked as "deprecated" in the source. Instead of using floating-point Decimal BitCoin values (BTC), int64 raw/base Bitcoin values are used for all inputs/outputs. This achieves 1) better efficiency, especially on systems without a FPU, 2) no possible floating point precision issues, and 3) low-level is now unit-neutral (BTC vs TBC vs etc). By default, for backward compatibility, the command line arguments default to version 0. To make version 1 calls, prepend the commandline with -rpcversion=1