Support for Tonal Bitcoin units (ᵇTBC, ˢTBC, and TBC) #929
Conversation
Only available on dropdowns when a Tonal-compatible font is installed
|
I even don't know, what Tonal means, never heard of it ... guess Google is my friend. |
|
http://books.google.com/books?id=aNYGAAAAYAAJ&printsec=frontcover Tonal Bitcoins provides another use-case for Bitcoin. Right now, Bitcoin appeals to libertarians, anarchists, and some other groups. By supporting more languages, Bitcoin extends to people who don't speak English. By supporting non-decimal numbers, Bitcoin can extend to those who use or prefer those numbers too. No modern fiat currency can be used effectively with Tonal, so for those who prefer it, this is a "killer feature". |
|
Okay, I propose this should be opt-in somehow, as I would not like it to be shown as a default. I think it would scare "normal decimal users" and make the GUI unnecessarily complex, which is bad for everyday users. If "Only available on dropdowns when a Tonal-compatible font is installed" means I wont see it, I'm fine with it ^^. |
|
I still don't understand why anyone would prefer it. Surely one unit is sufficient - should it start supporting binary, hexadecimal, pi-base, etc too? I think there needs to be a rationale for introducing this base over any others that also exist. |
|
As I said in the summary, TBC units are only available on dropdowns when a Tonal-compatible font is installed. Most (all?) operating systems don't include Tonal-compatible fonts by default, so likely only Tonal users would see it as an option. rebroad, the book explains how decimal is flawed and why tonal is much better and easier for humans. I don't think decimal vs tonal makes sense in this forum. |
|
As I said, if it don't bothers me or everyday users I'm fine with it from the technical side. |
|
decimal vs tonal makes perfect sense in this forum, which is a forum discussing this change, which is a change directly related to decimal vs tonal. To avoid a discussion on decimal vs tonal is to avoid discussing this change, isn't it? I've read the wikipedia article on tonal, which seems to be the same as hexadecimal, which I am familiar with, having used it on a BBC Micro for a good decade or so. I see why it's useful to use hexadecimal with things such as network masks, as they are already based on base 2. Bitcoin numbers are not, and therefore I see no logic in introducing a new base, based on 16, pi, or any other number when there is already one (base 10) established and in use. I also don't see why 1 BTC doesn't equal 1 TBC. Why was it decided that 0.0001 TBC = .00000001 BTC? Seems a bit arbitrary to me. The problem I have with this change is that it sets a precedent, where the end result is not clear. If we add this, do we then add any other base anyone else fancies adding, and if not, what argument would there be not to? It's clear to me there needs to be a strong reason for this base (and a rationale for why it's fixed 0.0001 to 0.00000001 as suggested) over any other base that could be added in order to avoid an unhealthy precedent. |
|
The change isn't about forcing anyone to use either decimal or tonal, just extending the diversity to more people who already use tonal. Would you argue against using Spanish on a pullreq to add the Spanish translation? You clearly haven't read the Tonal System book, or else you would know that it isn't the same as hexadecimal (though the radix is common), and how it is more useful to human for general everyday numbers than decimal. English is established and in use, but does that mean software shouldn't be translated into other languages? The world is a big place. Also, USD and Euro are established and in use. Why use Bitcoin? |
|
To compare "tonal vs decimal" to "english vs all other languages" is I suspect a vacuous truth. Of course other languages need to be supported - they are already in use. Bitcoin is worthwhile despite USD and Euro existing as it provides needed advantages. What advantages does this change provide? It's a simple question. Can you give a simple answer? Preferably a shorter answer than a book written centuries ago which no one has heard of. |
|
Tonal and Dozenal are also already in use. Bitcoin is worthwhile to me because of its fitness for a tonal adaptation. The simple key advantage to Tonal over Decimal, is that Tonal is easier for humans to work with, since it is based on just 2s rather than 2 and 5 (which is unnatural to the human mind). |
|
Ok, I should have said "of course, other languages are needed, not everyone speaks English". Do you know anyone who doesn't understand decimal? 2 hands. 5 fingers. Very natural to the human mind. Is there something you're not telling us, Luke?! And a better language analogy to this change would be to suggest translation for Klingon was necessary. Actually, that sounds kinda cool - I'd support that change :) |
|
I know plenty of currencies that work with decimal. If I wanted to use a decimal currency, I'd just use those. How many (adult) humans use their fingers for numbers generally? Usually you do numbers in your mind, where fingers are of no relevance. The human mind does not work well with 5s. This is why almost every unit of measurement humans have naturally come up with have been binary, dozenal, or tonal. The modern metric system (SI/decimal) has only ever been adopted by force, and even to this day has notable resistance under persecution in countries that enforce it (except on the decimal clock and calendar, which most everyone has given up on). Also, note that even when finger-counting is helpful, it's much better suited to tonal since you can do a full digit on each hand (ie, 0 through (15 deci) on one hand, or up to (255 deci) on both). |
|
I disagree 2 and 5 is less natural. I do agree using only 2 as a prime base may have advantages, and I'm a huge fan of using other number bases for fun. That said, in my opinion changing the number base people count in, is harder than changing how people count dates, count time, expect red to mean stop in traffic, the language they use in daily life and which food they eat, all at once. In your private life you do as you please, but it is unrealistic to assume you'll ever be able to use anything but decimal when communicating with a stranger - the critical mass of people using decimal is just too overwhelming. For all those not accustomed to using tonal, just adding support for it is a burden: more options people will need to learn the meaning of, more code that needs to be maintained, while it doesn't add or improve anything. |
|
It does add/improve the "reasons people use Bitcoin instead of USD" list, at the very least. I could just as well argue that any of the pulls trying to increase anonymity are more of a burden with no legitimate improvement. |
|
Luke, so far this change seems to be based on a number of untruths. The bitcoin wiki article on tonal had a number of inaccuracies, which I have edited to correct. e.g. it's not infinitely divisible, as bitcoins txs have limited decimal places, and it's not easier to use than decimal for most people I know. How many people are going to remember that 1 BTC = 1525.87890625 TBC? It just introduces confusion for no apparent benefit. Take this article, for example : https://en.bitcoin.it/wiki/Units - there are two rows both called Bitcoin, but with different values. It almost seems that this tonal proposal borders on sabotaging bitcoin by introducing such ambiguity. I don't only think it's not a healthy change, but actually an unhealthy one. I can't imagine any exchanges referring to TBCs either as it would mess up all their exchange rates unless the currency being exchanged was in base 16 also. I'm fairly certain that base 10 has not been "forced on us by governments", rather, it's existed as far as history can remember because we have 10 fingers, and it's the most obvious and easiest to use for humans. You've still not explained why 1 BTC doesn't equal 1 TBC or why it was decided that it would be 0.0001 TBCs that equals 0.00000001 BTC. This are important considerations, and you seem to be avoiding answering queries about them, and instead basing your arguments on falsehoods. Why? |
|
Tonal numbers do support infinite binary division, though Bitcoin does not. This was clear in context, though I have added a note to be explicit about it. Tonal is objectively easier than decimal. Conversion can be, and often is, done approximately: do you remember that 1 centimeter = 0.393700787 inches? Decimal may not have been forced lately (though it arguably was originally when introduced to Europe in the 10th century), but decimal units - the SI metric system - were and still are forced by governments in every case that they have been adopted. Even once a decimal unit is adopted, people who have adopted it continue to use binary divisions despite their awkwardness in the decimal system (eg, US quarters). BTC is a decimal multiple unit, not part of the protocol. The protocol is based on a "satoshi" unit which is 0.00000001 BTC. When choosing the size of the base TBC unit, the primary consideration was what size would be reasonable in the long run. It makes no sense to define 1 TBC = 55,100 (1 BTC). Given the total 2.1 quintillion raw bitcoin elements and reasonable Earth population in the near future, 1,0000 (65,536 deci) satoshis was the most logical quantity to set the base Tonal unit to. Given Bitcoin's current market valuations, it makes more sense to work in ˢTBC (0.16777216 BTC, or about 0.80 USD). I didn't answer those questions because they were not asked. None of the arguments put forward are false. |
|
Tonal numbers support infinite binary division. Decimal numbers support infinite decimal division. Does this surprise anyone? If we choose to change the protocol to more digits, we could divide the value of the base unit by a power of 2, or by a power of 10. You may argue that BTC is not a part of the protocol, and I agree, but it is part of the system: the bitcoin economy is built around the monetary unit BTC, and not TBC (though you're free to create one that does). Given that fact, if the precision is increased, the only viable option seems dividing the base unit it by a power of 10, and this new unit will not be expressible as a finite hexadecimal expansion anymore. I'm willing to accept that people living and raised in a tonal-only world may have some advantage for counting things over those in a decimal world (though I'm not certain either). Who knows? We don't. It may be your dream, but you have to stay realistic. And in a realistic setting, no I don't believe this is a practical advantage to any significant amount of potential users. I won't comment anymore on this. NACK |
|
The only sensible change to the Bitcoin amount protocol would be to make them a proper fraction instead of an integer, not to simply buy a few more years by multiplying by ten or a hundred. Given that, Bitcoin would be infinitely divisible in both decimal and tonal, and people could trade sizes like 1/3 or 1/7 which are completely impossible right now. If Tonal users alone aren't considered "significant", then I could try adding Dozenal support too... DSA at least seems to have a more organized online presence. |
|
NACK - I understand its a nice feature, but until we atleast get more than one person who wants to see this merged, maintained, etc I really, really dont think it should be merged. |
|
Fair enough. How about I just keep it in next-test until I can convince more Tonal users to switch to Bitcoin? ;) |
|
@TheBlueMatt I would also like to see this get merged, maintained, etc. |
|
@rebroad It's being maintained in Knots now. The lack of need to update it has proven it is extremely low maintenance, but with it in Knots, I don't think it's very important to have it in Core also. People who want to use TBC can just use Knots. |
|
No chance. |
c447aec [Net] Update hard-coded seeds (Fuzzbawls) Pull request description: Updated hard-coded seeds based on uptime and availability from primary DNS seeder. ACKs for commit c447ae: Tree-SHA512: 4ca56e41e277092093eead76fbc229a130bb786790c784a91e0d78a724f35a6e6594c4daa82a9dda88f7ed2eae441bc371fa2b4ab3d50d203d518d667ecbd2a9
Only available on dropdowns when a Tonal-compatible font is installed