Those are problems with decimal fractions in floats. Tonal fractions have no such problem, nor do integer values (which I was recommending). A floating-point implementation that cannot handle all possible BitCoin values as integers, is a buggy implementation.

No, you can use whatever you want. But at least don't oppress those who choose to use "9" to mean the quantity of 8+2. Actually, it should be a "", but "9" is tolerated and I didn't feel like having and extra "9" key somewhere for decimal. When teaching, I always make sure I do a proper "" (with a full 6-like loop) for the Tonal digit "ko".

Decimal is unnatural for humans. Finger count is irrelevant. Should we use base 20 because of our toes? If you really want to count on your fingers, base 5 is better than base 10-- you can read 55 (35 decimal) that way. Or binary, then you can hit 11111111 (255 deci) without trouble (due to finger dynamics, I find it difficult to use the ring finger). I personally use binary for finger counting, each hand representing a single Tonal digit.

I agree, it should be. However, right now, it isn't all (simply) binary underneath. It's an encoded floating-point Decimal BitCoin value at the RPC level. This creates problems for Decimal as well, since the common decimal number of 0.1 cannot be represented by floats. But that's another topic.

If you believe the "education" systems (in any country) are useful at all, you're quite frankly deluded. If anyone learns anything in them, it's because of the rare teacher who cares, or the rare student who seeks knowledge. The only real teachers are parents. I am one of those real teachers, and I am sticking to Tonal. Bitcoin is a useful to tonal users because it allows us to exchange currency in our native/preferred number system, rather than have to work in decimal for monetary exchanges (even with others who hate decimal).

Remember, Decimal BitCoin doesn't cease to exist because of Tonal BitCoin. Your irrational/fanatical oppression is not helpful. Use what you want, but let us use what we want. BitCoin can either gain the adoption of the Tonal community, or lose it by insisting we all switch to decimal (in which case, there is frankly no benefit over our local fiat currencies-- why switch at all when more people accept the fiat?). If BitCoin only appeals to the libertarian niche, it will never gain widespread adoption. You (and others) need to recognize that if you want BitCoin to succeed, you must be open to ideals that don't appeal to you personally.

Solution to buggy JSON libraries (with base unit amounts): append a ".0" to all amounts, even though fractions are not possible. This should force all libraries with these bugs to treat it as a floating-point type, which is capable of representing the entire range. Embedded systems where floating-point is a problem can still validly ignore the ".0" and use int64.

Unpatched, this gets me 124.5 MH/s on my Radeon HD 5850. With a patch from tcatm on IRC, I got up to 259.5 MH/s. Still short of m0m's 265 MH/s, but getting closer.

This "fix" seems wrong. Really, 'phexdigit' should be redefined to a 'signed char' array, and 'c'  a simple 'signed char'-- then none of this casting mess is necessary. The problem stems from the fact that the C standard allows 'char' to be either signed or unsigned: implementors can choose (and I've often see it signed). That means if you might need to use values above 127 or below 0, you must specify signed/unsigned explicitly for your variables. What (char)-1 does, is turn it into 0xff (255) on compilers that have an unsigned 'char', which might work, but it really depends a lot on how the compiler handles the constant "-1" stored in the  (undefined signedness) phexdigit array.

I thought we were going with autotools from jgarzik?

I'm not aware of any formal studies, if you mean that. The easy example I usually use is asking you, as a human, to fold a paper into 10 equal pieces without any tools to assist you in measurement; then try folding into 16 equal pieces. This demonstrates that even though you have (presumably) grown up with decimal, you can still work better with tonal in practice. If you don't want to waste 2 papers, http://www.intuitor.com/hex/switch.html has a Java applet demonstrating the same in software (but for hexadecimal, which shares this same benefit as tonal).

Yes, from a decimal perspective it is base sixteen. There is a learning curve for someone used to decimal, but given a fair comparison,  it is actually much easier in practice.

Decimal	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16
Tonal	0	1	2	3	4	5	6	7	8		9						10
Pronunciation	Noll	An	De	Ti	Go	Su	By	Ra	Me	Ni	Ko	Hu	Vy	La	Po	Fy	Ton
-
Decimal	96	97	98	99	100	101	102	103	104	105	106	107	108	109	110	111	112
Tonal	60	61	62	63	64	65	66	67	68	6	69	6	6	6	6	6	70
Pronunciation	By-ton	By-ton-an	By-ton-de	By-ton-ti	By-ton-go	By-ton-su	By-ton-by	By-ton-ra	By-ton-me	By-ton-ni	By-ton-ko	By-ton-hu	By-ton-vy	By-ton-la	By-ton-po	By-ton-fy	Ra-ton
-
Decimal	248	249	250	251	252	253	254	255	256	257	258	259	260	261	262	263	264
Tonal	8		9						100	101	102	103	104	105	106	107	108
Pronunciation	Fy-ton-me	Fy-ton-ni	Fy-ton-ko	Fy-ton-hu	Fy-ton-vy	Fy-ton-la	Fy-ton-po	Fy-ton-fy	San	San-an	San-de	San-ti	San-go	San-su	San-by	San-ra	San-me

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)

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 splitting the Tonal talk to another thread. It doesn't belong here.

Integer units don't break backward compatibility at all, if implemented using a RPC versioning mechanism (eg, bitcoin.<version>. prefix to methods, or--as MT suggested on IRC-- using a different URI path). This way, the old "RPC v0" can continue to function for as long as we care to maintain it, while new code can use RPC v1 with integer units. Given the fact that URIs are used, it might also be possible to simply use a query parameter (eg, "?precision=0", "?precision=1e8", "?precision=65536") to specify a division for all units explicitly (and default to "?precision=1e8" for backward compatibility for a while), while not forcing newer APIs to use base units.

Please, this is about program internals, nothing that should ever be visible to the end user.

Also, we already have plenty of decimal units, no need for more. A "COIN" (in the code), is defined as 0.01 BTC (1,000,000 base units aka centi-micro-bitcoin aka bitcoin-bong). "One bitcoin" is, regardless of anything discussed here, to remain at 10^8 base units for the short-term (long-term, it's too large to be viable). "An bitcoin" is also to remain at 16^4 for the foreseeable future. Please see https://en.bitcoin.it/wiki/Units

This thread already existed in https://www.bitcoin.org/smf/index.php?topic=3028.0

sipa's "Idea 2" sounds exactly like "RPC v1", while gavin's "counter-proposal" sounds like "RPC v0 without rounding".

Of the voters, 3 prefer to not fix the problem at all, while 6 want it fixed. Of those 6:
- 3 want RPC v1 (base bitcoin integers; aka sipa's "Idea 2")
- 2 want RPC v0 without rounding (gavin's "counter-proposal")
- 2 voted for another (unspecified) solution (maybe sipa's "Idea 1"?)

I personally prefer RPC v1/sipa's Idea 2. This is already written in a backward-compatible form in my "neutral" branch. This way, the old/current method of centi-BTC precision BTC values can be supported by default for another N months while new code is concurrently designed for the newer API, and old code ported gradually. After that time, the default can be changed to RPC v1. After more time, especially if someone is having problems porting the old code (I'm not sure what the deprecated functions did), the older RPC v0 can be removed so as to not clutter the code for future development.

vladimir: RPC v1/sipa's Idea 2 *is* moving all APIs to centi-micro-BTCs (the low-level cannot support nano-BTC precision).

No problem at all. TBC is an adaptation of the BitCoin currency to the Tonal number system, in the same way as a port of software is an adaptation to a new platform. The only problem is when people work against innovation and progress.

It doesn't work just fine. It is impossible to send values with sub-cent precision, and therefore also impossible to send almost any TBC coins. And just because you personally don't care about TBC is not an excuse to make life more difficult for those who do. It's no different than Windows developers trying to prevent a Linux (or Mac) port of their open source software simply by stating "it works fine for us on Windows" as an excuse to not merge patches that make it work on both platforms. The BitCoin community is growing, and not everyone is going to have the same ideals or even basic reasons for being part of the community; don't force your narrow subset of interests on everyone else whose interests might or might not overlap with yours.

OR, anyone using jansson would simply have to use (non-fractional) floats. As mentioned earlier, float types can represent the full range of base bitcoins fine, so long as they're not represented as decimal values.1e8 is a perfectly legal JSON number. 1 BTC shouldn't be 1e00, it should be 1e8. And no matter how it is written (0.001 or 1e-03), the fractional-floating-point issues remain.

This works fine with the neutral branch: ./bitcoind -rpcversion=1 sendtoaddress 1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo 1e8

Actually, JSON-RPC doesn't support integer nor floating-point. It supports "number", which is not necessarily either.

But so long as we are working in base units, there is no reason to use floating-point rather than a simple int64...

UPnP is only a "security" issue if you're treating hacks like NAT as some kind of a firewall (which it's not intended to be). NAT is a hack to allow multiple computers/devices to access the WAN from a single WAN address. It isn't supposed to block anything. Blocking incoming connections has merely been a bug in the NAT implementations. UPnP fixes this bug by giving endpoints the ability to tell the router what ports it expects a connection on, so the router can correctly pass that traffic through.

If you want a firewall, go ahead and get one (or install it as software). But that is unrelated to the bug that UPnP fixes.

IMO, without giving the user an informed choice in this, most people would probably consider it to be malware.