Switch all units to micro-BTC by default #3862

Per mailing list discussion. http://sourceforge.net/p/bitcoin/mailman/message/31640769/

"Advantages are obvious:

1. having satoshi as 1/100 of the main unit is familiar to people like USD and cent
2. All existing financial software can deal/store big numbers but typically only 2 decimals.
3. Split could be linked with the introduction of the ISO code in one step."

It does not look like item 3 is feasible, but the first two are a strong rationale. Existing financial software trying to integrate bitcoin must convert decimal places, with all that entails (accounting and bitcoin numbers "look" different to outsider auditors).

Humans in general seem to deal with large numbers for small values (Yen) better than fractional ones (bitcoin).

Regarding 3 above, we could simply define 1 XBT = 100 Satoshi, which of course also means that 1 BTC = 1000000 XBT. This would lay the ground work later for an ISO 4217 standardization effort for 'XBT'.

Non-serious side note: The funny thing is people have started talking about the dorian where 1 dorian = 100 satoshi, which nicely gives us our decimal point with two digits after it.

But yes, 1 XBT = 100 satoshi might just be the way to define it.

It meshes perfectly with accounting software, fits into ISO 4217, solves the "too many zeros on the right side of the decimal" problem, and side-steps the whole BTC vs. mBTC vs. uBTC debate. I'm not sure I'd care for it to be the default for GUI display just yet, but it's possible to do the above and just make it a selectable option.

uBTC price: $0.00064693

I generally like this more than microbtc, but I think many people are preferring microbtc at the moment because both "typical values" and their reciprocals are attractive numbers. And as cozz points out (by showing how much usd a µBTC costs on the open market), the reciprocal is really not a nice number right now. Arguably it will be in the future if bitcoin grows in success, and we might as well design for that future— since if it doesn't the decision doesn't matter so much.

The other downside is that by keeping the point you guarantee that people will continue to write financial software using radix-2 floating point and getting bad and or surprising results. Just food for though.

@gmaxwell how its displayed and how its stored are two different things right ?

I think the reference client should display it the way that it is stored and not mutate it in any way. If people want to display a different way that is up to them. See I think by "dictating" this in the reference client is going to give people yet another reason to shout at the devs. I don't want that.

@int03h so we should send out uncooked raw binary data? Come on. It needs to do something reasonably friendly and if what it does is unsuitable for your use then feel free to convert it... The way it is stored is unusable as an external interface.

You're free to do what ever you want, if you're unhappy with what the software does I insist you do not use that software (or modify it).

@gmaxwell how is it uncooked ? What we are discussing here is a modification to cooked data and how it is displayed. Any deviation from the way things are in the GUi introduces risk. If this is something you feel we can live with then so be it. I am just saying why is this necessary ?

PS : you are sending out raw uncooked data via the blockchain hence the need for RPC's and reference clients etc to pull/manage that data. I believe the reference client should be a demonstration HOW its can be done not a mandate for how things SHOULD be done.

Uncooked data would be a 8-byte serialized 64-bit integer. No GUI should show that.

Whatever we're showing, it's always an interpretation that makes sense to humans. Whether it is BTC/mBTC/uBTC/satoshi in decimal, binary, hexadecimal, base Pi, ...

MicroBTC is too small - anything even somewhat expensive will cost like 1,000,000 uBTC or more right now, and it's just annoying to have to deal with numbers that large all the time.

NACK on changing the default right now. uBTC is pretty much unknown in the wider community, switching the default in the wallet from one release to the next seems like a recipe for a lot of confusion (also Bitcoin-Qt is only a small part of the wallet 'market' these days, will not make a big impact if only we switch).

If the goal is to push people in the direction of uBTC it should be introduced first in the ecosystem by pricing things in it, and generally bombarding people with the term and making them aware it can be configured in wallets. Only then it makes sense to discuss it as default.

(edit: this may sound overly negative, to be clear I'm in favor of moving to uBTC display eventually, but changing the default in bitcoin-qt should not be the first step)

As long as the backend is always calculating in Satoshis, the presentation layer should be free to show you the number in whatever format you choose.

That said, I think the argument for an ISO 4217 compatible denomination needs to be taken more seriously. If we care about the wider world being able to interact with bitcoin more easily, going to uBTC makes more sense in the long run, and it's best if we switch defaults just once.

I want to plan for the future. Switch to Satoshi now. Pull the bandaid all at once.

@hank Japan, and the international finance industry that deals with JPY, handles this just fine. Advertisements for cars and houses are sometimes written in a way that removes some of the excessive digits, but for finance and accounting they are always present. @coz Exchanges would adopt a standard USDXBT quote that will give you a sensible number and be in line with forex quoting.

Just my 0.00000002 millions of dollars.

+1 @boinggg - a proper plan with limited pain.

@tarix mBTC now, uBTC later.

It is not a matter of taste, red or blue paint. Major accounting softwares do not work with mBTC (or BTC!) due to the decimal point issue. There is a specific set of problems that uBTC/XBT addresses, that BTC/mBTC do not.

Apparently not everyone has the same issues. If the length of discussions on the subject matter prove anything it's that everyone has their own reasons to prefer a certain unit. From the looks of it this will become just another long-winded thread where everyone states their preference.

I suggest (say, ) Bitpay takes initiative by recommending/switching to uBTC. If enough of the ecosystem catches on, the default should be changed to what people are using. Not the other way around.

I'd love to switch to uBTC now because points 1,2,3 make a lot of sense. The sooner the better. But I think that some software/website out there already uses 1 XBT = 1 BTC so I see how that could be a source of confusion. How about XBU or XUB? The symbol is different enough from BTC to make the unaware user go the extra mile and google what a XUB is.

NACK

Lets stick to programming core functionality rather than UI's. Silly bickering like this over something that the general community is perfectly capable of coming to consensus to on its own just makes me think more about how Bitcoin Core would be better off without wallet functionality.

Long time lurker and whatnot on git, throwing in my 2 sats, but why not just add them all to the display options and let the end user choose how they want to display it? That way people can set it as the default view as needed and personally I would love to have the option to just display my wallet in satoshies rather than mBTC in Blockchain.info for example.

All existing financial software can deal/store big numbers but typically only 2 decimals.

This is silly, no proper financial software represents currency as a float

This issue can easily be handled by wallets / UX / UI imo

Long time lurker here too! Agreed with jgarzik, It is very important to enable Bitcoin to integrate more seamlessly with existing financial software, much of which is legacy 3GL (such as COBOL) and only supports 2 decimal places. Few financial systems support 8 dp and this convention is a barrier in the path of Bitcoin's growth.

Because XBT has already some momentum there is a case for another new ISO code, hence:

XBT = 1 Bitcoin XBU = 1 microbitcoin

If XBU is supported internally within Bitcoin Core then the benefits of 2dp can be realized. The GUI should probably default to BTC but allow XBT and XBU as user selectable options.

Note at @AndrewClifford and others: the alternative subdivisions have been available as user selectable options since the first version of Bitcoin-Qt. This thread is about changing the default for new installs (as well as possibly installs that use the current default of BTC)

I thought we already changed the default to mBTC accross the board? guess we want to drop down to µBTC now?

And setting that properly in all wallets would be a boon as Blockchain.info web lets you set up to mBTC only and the android app you cannot set a display preference atm so a UI standard is needed on that.

This is counter productive and short-sighted.

1BTC should be 1BTC, it's complex enough for neophytes to not add other default that will just cause people to do mistakes.

Also, if you change the default to mBTC or uBTC or whatever just to keep it in sync with USD, are you gonna mess with it again if the BTC value go up by x100 or down by x100 ?

Finally, who's using a financial software not able to deal with a 1/100 or more exchange rate ?! Cough CNY Cough JPY ...

Nonsense.

@Ira I don't think you understand the concern being expressed there. It has nothing to do with the exchange rate, it's that there is apparently a non-trivial amount of software which cannot handle money values smaller than 0.01 (because, e.g. it does all calculation with integers normalized by 100). CNY, JPY, etc. don't present this issue. I believe the highest currency base unit in use— other than BTC— is only a couple of times more valuable than the USD.

@laanwj very valid point about not changing the default to uBTC because it is pretty much unknown in the wider community: it made some of us try and go creative around the problem, hence the XUB/XBU idea. Please discard that part if OT in this thread. But also please consider that defaults do matter and the consensus on Reddit seems to be overwhermingly in favour of the change. Apologies for all the noise and thanks for the hard work.

I agree with the fundamental idea, 100%. uBTC ('bits') is the right final unit for a number of reasons. But unfortunately I don't think changing the default in a reference client will matter at all. What WOULD actually make a difference would be for BitStamp, Coinbase, Blockchain.Info, BitPay, Kraken, Coinsetter, itBit, BTC Foundation, etc. (as many as possible) to get together, agree on the plan, agree on a switch date, create unified marketing material, and then do a coordinated rollout and media blast. Unfortunately, all of these guys probably have way bigger fish to fry right now, so good luck with that.

Side note: Users may find it confusing if they cannot send a quantity of 1.

Why not a familiar BTC cent? Most currencies western or eastern have a cent. A BTC cent (still a xBTC or XBT?) could be 10 Satoshi or 100 Satoshi.

Cent is used in many currencies as 1/100th of the base unit. A BTC cent of 0.01 BTC would solve none of the problems mentioned here. A BTC cent with any other value, like 100 Satoshi (which is the only other definition of cent which makes sense given its Etymology), would cause more confusion than simply calling it a micro-BTC.

A whole lot of sites and software already use 1 XBT == 1 BTC. It's too late to redefine that.

The GUI already allows people to change to mBTC or uBTC if they prefer to use that. Why force mBTC on people? Bitcoinity currently forces mBTC (and they are alone in doing that) on people and it's just annoying to have to change it back to BTC to get a sane display.

Please don't force those using the "official" client to have to change this frequently too.

And this "financial software only supports only 2 decimals" story seems to be a myth. Please give some actual examples of this supposed software. It's 2014. Computers can handle more than 2 decimals just fine. This BS story sounds like the year 2000 problem. The world did not end when we went from 1999 to 2000. If some outdated financial software seriously can't handle more than 2 decimals then that's a bug in their software that they should fix.

I personally don't care too much what you do as long as Armory and the exchanges doesn't go along with this.

@oyvinds +1

Please dont change it to mBTC or uBTC. In your bank account you see also a balance of "0.01" if you only have one cent. And not "1 Cent", just because it looks more... i dont know what...

Why should µBTC be the "final" unit? The Japanese yen uses no decimal points at all. Wouldn't that be preferable? All integers. Satoshis should be the "final" unit. It's even a Japanese-sounding name, like yen. But we're not there yet in terms of value.

And I have to disapprove of the proposal for XBT to be defined differently than BTC. It's already been established that XBT is synonymous with BTC and even that it's "more correct" in some senses, as "BTC" would indicate some as-yet-undefined currency from the country of Bhutan. The imminently opening Coinfloor exchange in the UK uses "XBT" consistently throughout its site.

Finally, it doesn't make sense for Bitcoin to have two ISO currency codes, e.g., XBT and XBU. No other ISO currency in the world has separate codes for different multiples of the same currency. It would be a waste of the code space.

The default for your wallet app can be whatever the developer deems useful, but the fact will still remain that in financial software numbers will be handled in Satoshis, and in many cases won't be able to be displayed as anything larger than uBTC.

NACK

Agreed with @oyvinds. If accounting software is inept at accepting XBT into their workflow, it is their programming problem, not Bitcoin's. They should develop a good interface that can account for Bitcoin's particularities, not the other way around.

For each currency, ISO 4217 defines the numerical relationship between the major unit and the minor unit. For most currencies of the world, this relationship is 1:100, but this is not true of every currency. Some currencies have no minor unit, and some Middle Eastern currencies have minor units in a 1:1000 ratio. So financial software already has to deal with variable numbers of decimal points. It wouldn't be a big deal to define XBT with a major:minor ratio of 1:100,000,000.

@laanwj apologies and understood. So, the thrust of the OP could be considered in two parts: a) try to push the market convention to uBTC b) allow for easier interoperability with legacy financial and accounting systems using uBTC.

IMHO "b" is easier and better tackled first.

Example of the Bitcoin-qt transaction export csv "Confirmed","Date","Type","Label","Address","Amount","ID" It needs "Currency" appended and the column populated with an appropriate ISO or pseudo-ISO depending upon whether Amount is BTC or uBTC @whistlack: few non-Bitcoin systems can cope with a major:minor ratio of 1:100,000,000

@rcornea respectfully have to disagree - there is a ton of legacy software that is NOT going to be rewritten just because some new kid on the block wants integration.

A lot of people seem to think that this conversation is around exchanges and the like. That is simply not the case - software like that will already be capable of a large number of decimal places. This is more for something like an accounting package. Virtually all of the SME accounting packages out there support 2 decimal places. There are no bookkeeping transactions that require more. If you're charging interest on a late account you round up or round down to the nearest cent, and that final value is what is stored. No accounting software will bill a client $10.42 in interest but actually store it as 10.418394887439.

The same goes for point of sales systems (POS), such as at a bar or restaurant. Many of them support multiple currencies, but do not support more than 2 decimal places. If you have a table at a restaurant and you charge a % surcharge for 8+ seaters, the POS will calculate it and round to the nearest cent. That 2 decimal place value is what is presented on the bill, it is what is paid, and it is what is stored in the accounting backend.

I think this makes complete sense - let's rip the band-aid and make it happen. If there are sites using 1 XBT == 1 BTC they are not common, and their developers will surely have no problem changing the nomenclature of the site back to BTC. We've discussed this around the dev team and nobody has even stumbled across a site actively using XBT in that manner (admittedly a small sample size and thus anecdotal, but nonetheless).

Realize that if you define 1 XBT == 100 satoshis, then no web site will be able to use "XBT" without a footnote clarifying that "1 XBT is equal to one millionth of a bitcoin." Without such a footnote, the site's use of "XBT" would be ambiguous, as it could be using the old definition of "XBT" or the new definition.

@whitslack fair enough - but that doesn't seem to be too much of an inconvenience, and nobody will remember the "old" definition in 10 years time. The whole point of phasing something out through a redefinition is that the old will eventually become meaningless. Agree with you 100% on not having two ISO codes.

I don't really have a horse in this race, but as an interested user, I think switching to two decimal places makes a lot of sense. Adoption is surely being hindered by the confusion that comes from having so many numbers to the right of the decimal.

Perception matters and having Bitcoins look a bit more familiar would go a long way towards driving adoption.

So a beer for @jgarzik for working through this. @changetip

@oyvinds BitPay worked on QuickBooks integration. We have already found these problems in the field. Other accounting packages we cannot name (NDA, under devel, etc.) also have the same problem.

It is no myth.

Bitcoin Core would be better off without wallet functionality.

:+1:

I like the idea of "switching to two decimal places" a lot!

@jgarzik is spot on -- µBTC as the standard with 2 decimals (as with every other common currency) makes sense.

To those who believe, for example, that spending 10 000 (~$6 USD) bits on a cup of coffee will hinder adoption, please reference the Dogecoin experiment. No such detriment has been recorded. To the contrary, Dogecoin has been one of the fastest growing cryptocurrencies ever created, due in large part to the psychological facet of "much coins".

In the wider world, people are familiar with currencies such as Yen or Hong Kong Dollar, which feature large numbers for US$1.00 levels of value.

In general humans are most familiar with money systems that do not exceed 2 decimal places.

No amount of software engineering will fix basic human learned behavior.

Why not simply use Satoshis as the base unit?

If you're already proposing to scale everything by 10^-6 , it's not a particularly large leap to instead scale by 10^-8 .

If I have one BTC, I have 100,000,000 satoshis. One mBTC? 100,000 satoshis. One uBTC? 100 satoshis

This addresses the psychological issue of people preferring big numbers over decimal places, while maintaining a nomenclature consistent with the core protocol.

@dougmercer; as jgarzik has suggested, people are already accustomed to a 2 decimal monetary system

@dougmercer exactly, 2 decimal points is the standard and most people is already used to it.

@sebicas @campassi I understand and agree with that observation. The trade-off here to consider is: is the addition of somewhat contrived verbiage worth introducing in order to have a two decimal place monetary system?

I see value in either side of that trade-off.

With that said, I slightly prefer the idea of using Satoshi's instead of microbits, as the primary individuals who would benefit most from this conversion are also the people least likely to be comfortable with SI-prefix conversions.

@kokojie It isn't based on fiat swings, it is based on what accounting software can deal with and what standards already exist for currencies.

@kokojie this has nothing to do with fiat swings. It's a change from an 8-decimal-place representation to a 2-decimal-place representation, which is more familiar to most.

@kokojie how many people needed Bitcoin to work in QuickBooks in 2012?

@dougmercer no contrived verbiage needed. We'll call it a "bit".

@kokojie the unit isn't changing. This is the default representation of the base unit - it's a visual change on the QT client only. Nothing underlying changes, nobody using Bitcoin Core needs to change their code to compensate for this.

NACK, for now. Will just aim to confuse new and intermediate users. @petertodd Agree that the wallet functionality should be removed or at least separated.

NACK

As things are, this will cause confusion specially when looking at the table with amounts, there's no specification there of what the current unit is. (next time you upgrade people could have a nice fake-surprise thinking they've suddenly become bitcoin millionaires... can you imagine)

I'd propose as a related fix, to add the current unit next to the "Amount" title, if the current unit is not BTC.

So you'd end up with:

• "Amount" (for BTC)
• "Amount (mBTC)"
• "Amount (µBTC)"

depending on the case.

Instead of changing the default, we could just make it more convenient to change units where it's relevant. For example, on the transactions table, a right click on the "Amount" column could show a dropdown with the available units, the current selection would have a checkmark.

On the "Overview" screen, clicking on the "BTC" text would make it cycle to the next unit...

Technically the change is trivial enough and only affects usability not stability so how about letting the users' community vote with their own coins on the matter? Let me expand, here's my idea. A target charity is chosen for donation. Maybe jgarzik to decide which one (just because he opened the issue on github first). He makes two addresses: one associated with the choice of switching defaults to micro-BTC and one with the choice of leaving defaults to BTC. A time limit is set for voting. The address that gets more coins is the most supported choice and gets implemented. All coins are sent to the chosen charity. Bonus effect is we get a lot of media attention because of the distributed voting experiment on a planetary scale.

Could it work? Would it be a fair compromise?

A fair idea, but I see many potential pitfalls. What exactly happens to the funds donated to addresses? If the total balance decides a "winner" then users will complain that the "rich" have influence. If a transaction counts as a vote, then someone could create thousands of wallets.

If I was tasked with solving this problem, I would have coin age determine a vote. Wallets created after the voting started would be ineligible to vote, and votes would be weighed by various factors.

In the end I don't think we need to create a rocketship for something like this.

If dropping from 8 decimal places to 2 is good, then wouldn't dropping to 0 decimal places be even better? Japanese yen don't use any decimal points at all. They set their prices like they score their pinball games: with lots of zeros. "A cup of coffee? That'll be §250,000, please."

Just rename Bitcoin to MegaBitcoin, but don't change the balance display. Once people are used to that for a year, they'll understand that 1 bitcoin = 100 satoshi. Only half kidding.

"All existing financial software can deal/store big numbers but typically only 2 decimals."

Al existing financial software can cope by using mBTC right now. Making the change does nothing.

Please consider naming the subdivision something that isn't confusing for the general public. Think about the 98% of the world that is not familiar with bitcoin and the difficulty for them to differentiate which is which from BTC, XBT, mBTC, uBTC etc.Try explaining to your next door neighbor the difference and see what happens.

As it was said before, choose something simple to remember, "bit" is a good idea (a bit from a coin). Or any other name that means something. The human mind remembers names that mean something. Please don't go for the BTC, XBT, mBTC, uBTC. That looks like is made for robots or borg people.

Also thing about the oral language, just saying microbitcoin or nanobitcoin is a mouthful.

OK I give it another try. At least there is agreement on the fact that a BTC as of today has too many decimals to be used by non-techies to pay for grocery. Also it seems that the ISO code for XBT = 1 BTC is already in use and no one is in favour of going to Bloomberg and ask them to change their charting. Then how about we use megasatoshis (e.g. megasats) and kilosatoshis (e.g. kilosats). 1 megasat = 1 hundredth of a BTC = 1000 kilosats = buys you at least one beer in most countries as of today. When/if megasats become grossly inadequate as a unit of measure for beers, then, in time, we can switch to kilosats. Or gigasats.

IMHO the reference QT bitcoin client matters and has to lead the way because it is the reference client.

@Future-me-FromFuture 98% of the world doesn't know how to download and/or can't download/maintain the blockchain. Nevermind use the QT client.

This has created so much noise its actually rather amusing.

EDIT: @super3 +1 --disable-wallet by default for the win. ( I know it wont happen .. but I am going to keep saying it )

EDIT2: as an aside - syncing the blockchain from 3 local peers to a forth with all of them addnode'd to each other takes 10 hours. I can copy it over in just under 20 minutes (on the slowest machine).

and @gubatron gets my vote for most appropriate approach. needs a bump and a look. just add the denomination to the wallet and be done with it. defaults remain as they are.

@EuroTrash2 you're right: is a reference client.. but it needs not be IMHO. @int03h +1

I find this discussion mildly amusing because there appears to be a consensus amongst developers that a successful (is no longer an experiment) bitcoin won't be used by normal people for daily transactions (cup of coffee, newspaper, etc.). This builds atop the fact that bitcoin is already unusable for micro transactions as it simply doesn't (and will never again) scale to transactions of hundredths of a US cent.

Instead, so their theory goes, bitcoin will become a settlement currency. It will be used to trade value amongst trusted systems or amongst contract participants (escrow, smart contracts, coloured coins etc.)

So it's a bit dishonest talking about the perceptions of the man in the street, if the man in the street is merely a vehicle to move bitcoin out of its experimental phase into its settlement-currency phase.

Also, if the programmers who are interfacing bitcoin with "financial systems" can't grok that bitcoin is an integer in the range 0 to 2,100,000,000,000,000 (approximately :-) then we're fucking doomed.

I wish Satoshi had defined more significant digits (at least 6 more) and I wish the developers didn't view the ultimate future as being that of a settlement-currency, i.e. that scalability to micro transactions was a goal.

But we're stuck with what we've got and the maths of scalability are hard to argue with. Within, say, 10 years bitcoin will be solely a settlement currency if it survives as a medium of exchange. Humans will be transacting in other currencies (pegged or floating, closed-trusted or open peer-to-peer) against bitcoin. Bitcoin the currency will disappear from plain sight in the same way as SWIFT or BACS.

So in my view, this is merely a middle-term user-interface problem - and it should be recognised as such. There is no future in which we get an extra 6 digits of precision, so there's no need to worry about whether we might have to "shift the decimal point again". There will never be micro transactions, because of scalability, so humans are going to stop transacting peer-to-peer in bitcoins eventually, anyway.

With all that understood, "bit" really does seem like the most human-friendly name for the middle term. "dorian" would be my close second vote.

Most people still don't know what a megabyte is and no, I don't mean that most people can't work out whether it's 1,000,000 bytes or 1,048,576 bytes. I mean that they don't know the scale, whether mega is a thousand or a million or something else.

Counting zeroes left of the decimal point is only mildly less painful than counting those right of it: a cup of tea that currently costs 0.0025 BTC would cost 2500 bits.

Counting fees in bits is definitely amusing: currently the suggested fee is 0.1 bits per byte :) And the proposed new fee is 100 bytes per bit.

Maybe dorians is the way to go after all.

Regardless, a commonly agreed unit corresponding with 100 satoshis appears to be a step forward in easing the adoption of bitcoin the currency.

tldr: dorian may be the least confusing name for 100 satoshis, for the period that humans are still transacting in bitcoin before (if) it becomes a settlement currency.

@JawedAshraf There is no such consensus. This github got linked to reddit and trolled, so many of the comments are from uninformed people who do not even use this software.

Further, bitcoin works for microtransactions just fine. You are able to make 1,000,000 bitcoin payments per second if you wish, as this software demo shows: https://bitcointalk.org/index.php?topic=244656.0

@jgarzik Maybe I should have been clearer, as I'm referring to the values and fees associated with on-blockchain micro transactions, not off-blockchain micro transactions. I'm familiar with the thread you linked and its technique to route around scalability issues presented by the blockchain itself. In fact that thread defines a use-case for bitcoin as a settlement currency :)

Off-blockchain transactions means there will be no pressure to add significant digits. And payment channels are a trust-less though very close neighbour of trusted payment services/channels (such as that offered by Coinbase, where customers of Coinbase can transact in bitcoin without hitting the blockchain). The currency seen by the user of the latter kind of channel is not necessarily bitcoin and it seems to me that trustless channels for micro transactions can be denominated in something else that's directly convertible to bitcoin, so that settlements are all that's needed on bitcoin's blockchain.

Anyway, I support a unit of 100 satoshis, for whatever timespan people individually interact with the blockchain.

I've been running the reference client (and mining) for nearly 3 years - thanks for your and others' hard work.

I think that for bitcoin to be adopted by the regular people, like we are intending, we must understand that the average joe remembers better short names.

I propose that we do a poll and ask the people to chose from xbt, mbtc, ubtc, bit and any other short 3 letter name that we should be using for the default denomination.

This naming discussion is completely pointless. There is always a difference between the 'formal' or 'scientific` name of something and the name used in the street (or community). In this case the formal names are the SI units. However, denominations of money get their own names over time which are easy to pronounce or witty, no need for any kind of poll or process. It's just not up to us.

@laanwj while it's true in theory, I think at this stage, decision made by devs could help community a lot. You guys are still the most respectable source in this community, and if you decide we should name things one way or another, it will likely stick. Even within this discussion you can see how coining the term satoshi for the smallest unit helped a lot. But it was easier when community was smaller.

I know you have a lot of cooler and more important stuff to care about in the core. But just as you think about how core changes may influence future scalability, it may be helpful to think how they may influence future widespread adoption. It's not up to you, but it can be.

Most people just don't know SI units. It's a fact that seems weird when you are surrounded by tech/science people. Even for for those who do, 0.00005 requires a bit longer to process than 500 000. Use of small fractions is so unpopular, that we don't even have any standard way to separate these zeroes.

And I'm sorry for dropping in without code here, I do believe that this decision should be based on devs rational thinking and not some community polls, because a single person voice (who takes time to think things through) is much more valuable than 50 other people who just act like a swarm. Keep up the good work.

@comboy I'm probably the one dev around here who can chime in with some authority, as I've got a fine arts degree and spent about a third of that degree in design.... and I'll say wholeheartedly that I don't believe for a second that we can do effective top-down design for something as organic as humans figuring out what to name things. It just doesn't work - we're inevitably going to come up with something 90% of the actual Bitcoin-using population thinks is awkward or even ridiculous just by the fact that we're not them and don't understand their worldview. If users feel the need to talk about uBTC they will switch - it's just an option. If they don't, they don't. Trying to figure out what's right with anything less than a top-tier advertising/design firm is bound to fail - this stuff is legitimately hard and those consultants genuinely earn their money. (at least the good ones...)

On the bright side, at least we're sane enough that we're not discussing a proposal as utterly mad as ethereum's made up series of names for its denominations...

+1 @laanwj , @petertodd informal names will be organic,

US pennies, are named after british pennige (penny-yuh), commonly known as "pence". Dimes from french "disme", latin "decimus". Spanish old 5 coin pesetas were called "Duros" (The hard ones, I suppose because the coins were the hardest ones)... Bolivares -> Bolos, Fuertes (Strong ones).

Regular people or people with much richer linguistic backgrounds could come up with much cooler, friendlier names that make sense for average people.

Also until the price of Bitcoin isn't stable people will keep finding the amounts (however many decimal points they have to use) irrelevant, at this point in time, the mental value of things is still based on local fiat.

@petertodd if not forcing some name, then at least a default option would be nice, because regarding this

If users feel the need to talk about uBTC they will switch - it's just an option.

I very strongly believe that for most users, defaults are what they will ever use.

If I may .. and I am in a fighting mood .. so forgive me. This is not a blog folks. Your OPINIONS are not relevant. The fact that 99% of those that probably added 0.00001 uBTC to this convo dont even run the client means its all empty barrels making noise.

Jeff as the one that opened the discussion may seem to be bearing the brunt of the criticism and I regret that a lot because it was well meant and he deserves no flames.

I am going to say it again.. this is why you guys need to move away from end user experience to more fundamental elements. Let the chips fall where they may on this nonsense.

This is just an opinion .. it is not relevant.

@int03h some of us want to contribute precisely to that aspect, a better user experience.

@gubatron then the wallet should be forked. I don't see how the end-to-end experience can be controlled by any single group of people.

... made better. Plenty of people to focus on both core and ux.

but a wedge I see .. ( said in yoda voice )

@petertodd @int03h Yes, we should definitely get out of the wallet business, I've been saying that for a while. I personally can't wait to move the wallet to another project. Let others fork and innovate there. The -disable-wallet mode in 0.9 is a step towards that. Headers-first download will be another step towards SPV mode.

What's the problem with leaving bitcoin as it is? This whole argument is somewhat USA-centric. Here (in Indonesia), 1 USD = 10,000 in the local currency, and I don't see anyone here wanting to change that.

修改默认单位为mBTC是有好处的 比如说我要发送 0.0001 个BTC给别人 这样的很容易输入错误 但是如果修改成mBTC就可以降低这个错误的概率，因为只要知道输入 0.1mBTC 就行了

另外一个原因是整数位都有相应的单位名称，比如 300 就“百”作为单位 3000有“千”作为单位，这样就能说“几百”“几千”，但是小数点后的位置就没有相应的单位0.0005 只能说“零点零零零x”~~

OMG ~~

I vote for 'bits' (microbits). It has a nice correlation to the word bitcoin and has the two decimal places. I don't see any problem with paying 6,000 bits for a coffee especially if deflation continues and it becomes 600