qt: Switch unit to πBTC by default #3870

laanwj commented at 11:09 AM on March 14, 2014: member

After a long and deep discussion on the mailing list it was decided to switch the default unit to πBTC (base Pi Bitcoin) by default.

This pull adds the functionality to enter as well as show Bitcoin amounts in proper πBTC. All the other units are deprecated and will be removed in next release.

The only possible drawback of πBTC is that it takes a lot of screen space, so widen the amount column in the transaction table. This does make Bitcoin much better suited for microdonations as small amounts look so much longer.

A patch to switch the RPC units to πBTC should be part of JSON API v2.

qt: Switch unit to πBTC by default

After a long and deep discussion on the mailing list it was decided to
switch the default unit to πBTC (PiBitcoin) by default.

This pull adds the functionality to enter as well as show
Bitcoin amounts in proper πBTC. All the other units are deprecated
and will be removed in next release.

The only possible drawback of πBTC is that it takes a lot of
screen space, so widen the amount column in the transaction table.

A patch to switch the RPC units to πBTC should be part of JSON API v2.

ee81b03a0b

bf0d7998-81ec-48d1-b236-076ed3c77581 commented at 12:25 PM on March 14, 2014: none

NOP

This pull request is far too irrational for my liking.

Have the developers considered enforcing that all Bitcoin transaction output sizes be Mersenne primes? Values could then be represented as an index along the known list, reducing transaction size considerably. This would absolve the need for units, as only the first 40 Merseene primes would fit within the coin limit.

mikehearn commented at 1:01 PM on March 14, 2014: contributor

Unsure about π - representing prices in multiples of 58 would be more Satoshi-ish. But I fully approve of the NSA-style address label generator you have there. Very convenient. The switch to doubles for extra financial safety is also welcome.

int03h commented at 1:28 PM on March 14, 2014: none

I personally like this proposal. ACK. ;)

shemnon commented at 1:28 PM on March 14, 2014: none

My objection is political instead of technical. It may slow down adoption in a few states in the US since the value of π may be subject to local legislative laws. (http://en.wikipedia.org/wiki/Indiana_Pi_Bill)

int03h commented at 1:50 PM on March 14, 2014: none

The π is a lie…Happy Half Tau Day! http://halftauday.com/

finway-china commented at 2:11 PM on March 14, 2014: none

π is still wrong.

gavinandresen commented at 2:26 PM on March 14, 2014: contributor

NACK. I might reconsider if the display is switched to base eleven.

bf0d7998-81ec-48d1-b236-076ed3c77581 commented at 2:28 PM on March 14, 2014: none

@gavinandresen 11 is prime, we can work with this.

super3 commented at 4:38 PM on March 14, 2014: contributor

The GUI should add functionality so I can see my coins displayed in different bases. Octal should be default.

cozz commented at 5:05 PM on March 14, 2014: contributor

I tend to favor this because it would also solve part of bitcoins malleability issues, due to the properties of pi being transcendental and irrational.

sipa commented at 5:50 PM on March 14, 2014: member

I think this discussion is going in circles.

instagibbs commented at 6:02 PM on March 14, 2014: member

exp() or bust who doesn't think in natural log space anyways

petertodd commented at 10:18 PM on March 14, 2014: contributor

ACK

int03h commented at 11:01 PM on March 14, 2014: none

ACK. 2 requires commit . I believe. Happy Pi Day.

roybadami commented at 12:49 AM on March 15, 2014: contributor

By all means offer πBTC but please make eBTC the default, if you must use real numbers. If nothing else, eBTC is getting far more current, real world, usage in wallets than πBTC (not least because e is an ASCII character and π isn't).

Although I question the need for any real multipliers when iBTC is clearly the end game. IMHO we should move to imaginary bitcoins now, to avoid any misconception that bitcoins are real.

roy

sipa commented at 12:59 AM on March 15, 2014: member

Where can I buy -i iBTC?

roybadami commented at 1:03 AM on March 15, 2014: contributor

Hmm, negative imaginary bitcoins might get a bit notationally inconvenient, it's true. We need a concise way to notate a unit that equals (-i)BTC so that we can work in positive imaginary space.

sipa commented at 1:06 AM on March 15, 2014: member

ACK.

This move towards πBTC will also encourage rolling out integration with the RADIUS protocol, despite many being diametrically opposed to it.

roybadami commented at 1:11 AM on March 15, 2014: contributor

Re (-i)BTC, I propose we call it a MIB (for Minus Imaginary Bitcoin). Inter alia, we really should raise the priority of the project to migrate all protocol elements to ASN.1.

RADIUS integration is an interesting suggestion; it could become particularly important as dial-up access to Bitcoin services increases in popularity (which is highly likely given the interest in integrating Bitcoin with telephones).

We will probably need to propose new cryptographic protocols, though, to replace the current symmetric encryption in RADIUS.

roybadami commented at 1:17 AM on March 15, 2014: contributor

((By the way, DIAMETER really is the proposed IETF standards track successor to RADIUS. I'm not sure anyone is seriously using it in anger, though.))

jtimon commented at 1:37 AM on March 15, 2014: contributor

NACK No, really, pi is wrong...

http://tauday.com/ http://tauday.com/tau-manifesto

int03h commented at 4:14 AM on March 15, 2014: none

And to round up PI day : recommended viewing http://thepiratebay.se/torrent/9494720/Pi.1998.720p.BluRay.x264.anoXmous

in src/qt/bitcoinunits.cpp:None in ee81b03a0b

 111 |  }
 112 |  
 113 | +/* Use doubles for financial amounts for extra safety,
 114 | + * it's better than floats!
 115 | + */
 116 | +const double pi = 3.1415926535897932384626433;

luke-jr commented at 5:19 AM on March 15, 2014:

wtf is this? pi must be defined exactly please!

petertodd commented at 6:14 AM on March 15, 2014:

@luke-jr That's more than good enough for MtGox.

luke-jr commented at 6:20 AM on March 15, 2014:

@petertodd Are you insuring my MtGox bitcoins?

petertodd commented at 7:12 AM on March 15, 2014:

@luke-jr Depends on your definition of 'insurance', or for that matter, 'Bitcoins'.

laanwj commented at 7:34 AM on March 15, 2014: member

Closing this. I found some difficulties with accounting software that only supports two decimals. This causes them to draw sloppy and incomplete circles, but if it was good enough for ancient Greece it's good enough for us.

I also want to avoid the kind of legal issues mentioned by @shemnon, Bitcoin already has a bad enough name, violating the Indiana Pi Bill will likely provoke politicians into a full scale war on math. @sipa The suggestion about moving to complex numbers for monetary values sounds great. This allows more accurate price discovery for pricing imaginary as well as real items. An early draft of altcoin 'capitalism 2.0' skips the obvious next step of quaternions and proposes turing-complete monetary values. But I think that's overkill. @mikehearn, @gavinandresen From the other alternative bases I like base-58 best. This integrates the great user experience for addresses with that for numbers, bravo.

laanwj closed this on Mar 15, 2014

DrahtBot locked this on Sep 8, 2021