Bitcoin Forum
November 21, 2017, 10:00:31 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 4 5 »  All
  Print  
Author Topic: More divisibility required - move the decimal point  (Read 13819 times)
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
February 10, 2011, 06:12:56 PM
 #21

Complicating the payment UI would suck. Right now it's nice and simple. Destination + amount. Can't get easier to understand than that.

The payment UI should stay simple. Of course. Simplicity is essential if Bitcoin is to spread to less technical people.

A transaction fee field is already present in the UI (click "Settings | Options"). I don't know whether it has any effect in the current release.
1511301631
Hero Member
*
Offline Offline

Posts: 1511301631

View Profile Personal Message (Offline)

Ignore
1511301631
Reply with quote  #2

1511301631
Report to moderator
1511301631
Hero Member
*
Offline Offline

Posts: 1511301631

View Profile Personal Message (Offline)

Ignore
1511301631
Reply with quote  #2

1511301631
Report to moderator
Join ICO Now A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511301631
Hero Member
*
Offline Offline

Posts: 1511301631

View Profile Personal Message (Offline)

Ignore
1511301631
Reply with quote  #2

1511301631
Report to moderator
1511301631
Hero Member
*
Offline Offline

Posts: 1511301631

View Profile Personal Message (Offline)

Ignore
1511301631
Reply with quote  #2

1511301631
Report to moderator
nelisky
Legendary
*
Offline Offline

Activity: 1554


View Profile
February 10, 2011, 06:18:00 PM
 #22

I'm not saying we should complicate anything. Actually, all this should be transparent to the user, with at most a simple fee/priority option, and *maybe* a notice that 'maybe you should include a fee' when last block was topped up, or something.

What I am saying is that with the current implementation there is a chance a tx stays in limbo forever, by being back logged by miners consistently. Hence the proposal for a default 'allow X free tx in each block' structure. Of course I run my own version of bitcoin and can hardcode whatever I feel like, but most casual miners make up most of the network, I guess.
Hal
VIP
Sr. Member
*
expert
Offline Offline

Activity: 314



View Profile
February 10, 2011, 06:53:14 PM
 #23

Lots of good ideas here!

I like Gavin's idea to display full precision in the UI and allow it on payments.

I like ribuck's terminology: 100 bitcents in a bitcoin, 1000 millicents in a bitcent, 1000 microcents in a Millicent.

I like [mike]'s suggestion to allow miners to store information relating to costs and policies, and to adapt network behavior from that information. I'd suggest using it specifically to normalize the "anti-spam" limits: the 0.01 minimums for large-transaction fees and for free transactions. Clearly Bitcoin needs a way to adjust these values, and Mike's proposal seems like a good candidate.

I also wonder if the anti-spam rule shouldn't be changed, to trigger if the largest output is tiny, rather than for any output. In Gavin's example, outputs of 1.5 and 0.000001 change seem ok to me.

Hal Finney
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2856


View Profile
February 10, 2011, 08:30:07 PM
 #24

I like supporting full precision in the UI and fixing coin selection.

The fees for generators should reflect actual costs, but I don't like the idea of hard-coding this. It should be user-selectable, and relaying fee requirements should be removed (or reduced and also user-selectable).

0.001 BTC is a good default fee. Amazon S3 charges $0.140 per GB if storage and $0.100 per GB of bandwidth. Even 0.0001 BTC per KB would be significantly higher.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
February 10, 2011, 08:58:04 PM
 #25

I like supporting full precision in the UI and fixing coin selection.

Coin selection would be an awesome thing.
It would allow more privacy for BTC users.

Cusipzzz
Sr. Member
****
Offline Offline

Activity: 324



View Profile
February 10, 2011, 09:06:01 PM
 #26

I like supporting full precision in the UI and fixing coin selection.

The fees for generators should reflect actual costs, but I don't like the idea of hard-coding this. It should be user-selectable, and relaying fee requirements should be removed (or reduced and also user-selectable).

0.001 BTC is a good default fee. Amazon S3 charges $0.140 per GB if storage and $0.100 per GB of bandwidth. Even 0.0001 BTC per KB would be significantly higher.

agree with all of this, especially coin selection.
jon_smark
Member
**
Offline Offline

Activity: 90


View Profile
February 11, 2011, 07:12:48 PM
 #27

I suggest the following:

One bitcoin equals 100 bitcents
One bitcent equals one thousand millicents
One bitcent equals one million microcents

By subdividing the bitcent rather than the bitcoin, we neatly end up with a name for the tiniest piece of bitdust, i.e. 1/100000000 of a bitcoin.

No doubt in time nicknames would arise for these small units. I like "austrian" and "satoshi" as possible nicknames

That's an interesting proposal, but I have one strong argument against it: the mixing of a three-order of magnitude scale (1 bitcent = 10^3 millicents = 10^6 microcents) with a two-order scale (1 bitcoin = 100 bitcent) is almost guaranteed to lead to confusion down the road.  Moreover, the fixation on cents is largely an artifact derived from the current versions of the Bitcoin GUI using by default two decimal places.  Should a future version switch to a three decimal default (a move I think is wise) then this anchoring on cents will go away.

We should pick a scale that uses a uniform jump in orders of magnitude all the way from the tiniest amount to the largest. And the number of orders of magnitude should be three, since it's the one most familiar to people. Granted, speaking of millicoins and microcoins could get tiresome, so choosing nicknames for the multiples and submultiples is a good idea.  I agree that "Satoshi" is a good candidate, but I'll have to disagree with you on the "Austrian"... :-)

My suggestions:

1 satoshi = 1000 BTC
1 BTC = 1000 koishi  ('koishi' being Japanese for 'pebble')
1 koishi = 1000 suna  ('suna' being japanese for 'sand')
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
February 11, 2011, 07:35:04 PM
 #28

That's an interesting proposal, but I have one strong argument against it: the mixing of a three-order of magnitude scale (1 bitcent = 10^3 millicents = 10^6 microcents) with a two-order scale (1 bitcoin = 100 bitcent) is almost guaranteed to lead to confusion down the road.

Well, i had other proposals.

Code:
1 BTCX0 = 1 BTC
1 BTCX1 = 0.1 BTC
1 BTCX2 = 0.01 BTC
1 BTCX3 = 0.001 BTC
1 BTCX4 = 0.0001 BTC

or

Code:
1 BTCA = 0.1 BTC
1 BTCB = 0.01 BTC
1 BTCC = 0.001 BTC
1 BTCD = 0.0001 BTC

or

Code:
1 BTC-0 = 1 BTC
1 BTC-1 = 0.1 BTC
1 BTC-2 = 0.01 BTC
1 BTC-3 = 0.001 BTC
1 BTC-4 = 0.0001 BTC


...and variations of above.

Yeah i agree - it's not very good looking, but I think it's the most intuitive and probably one of the most logical solutions.
Using it we can avoid a lot of mess.

grondilu
Legendary
*
Offline Offline

Activity: 1134


View Profile
February 11, 2011, 07:42:30 PM
 #29


Will satoshi be back to sign the tarball if gavin increases the decimal precision?

I'd feel much more comfortable if it's satoshi who stays in charge for this.
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
February 11, 2011, 08:02:42 PM
 #30

Will satoshi be back to sign the tarball if gavin increases the decimal precision?

satoshi never signed any tarballs.  He posted SHA1 signatures, but anyone can do that.

Ideally, gavin or satoshi or whomever will post SHA1 signatures of 0.3.20 release inside a PGP-signed message.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
LZ
Staff
Legendary
*
Offline Offline

Activity: 1652


P2P Cryptocurrency


View Profile
February 11, 2011, 09:02:17 PM
 #31

I do not think that we really need values less then 0.01 BTC right now.
But on the other hand, of course, if you got 0.001 - UI should show it.

Почему мои сатоши не выводятся?  Планету я купила

 

My OpenPGP fingerprint: 5099EB8C0F2E68C63B4ECBB9A9D0993E04143362
FatherMcGruder
Sr. Member
****
Offline Offline

Activity: 322



View Profile WWW
February 11, 2011, 09:14:17 PM
 #32

I think it would be nice if the client would calculate the probability of a transaction going through in the next block for a given transaction fee, as specified by the user. The user would then have the necessary information to select a suitable fee.

Use my Trade Hill referral code: TH-R11519

Check out bitcoinity.org and Ripple.

Shameless display of my bitcoin address:
1Hio4bqPUZnhr2SWi4WgsnVU1ph3EkusvH
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
February 11, 2011, 11:08:24 PM
 #33

Here's how I think small amounts could be shown on the user interface, to minimise confusion:



The digits are grouped into milli-cents and micro-cents, and are shown smaller than the usual "bitcoins and bitcents".

The advantages of this scheme are that it preserves the familiar "dollar-and-cents" type notation with two digits after the decimal point, yet allows for all of the available precision to be displayed when needed. The groups of three digits help to make these amounts easier to read.
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2436



View Profile
February 12, 2011, 12:06:22 AM
 #34


Around the mid-1800's in San Fran mining town you could get a clam chowder for 5 cents
http://www.foodtimeline.org/foodpioneer.html#provisionprices

In Zimbabwe recently they were trading trillions for pints of milk (before it collapsed completely) ...
... decimal divisions are arbitrary ... people will pay X number of something's if that is what is familiar.

Local
Member
**
Offline Offline

Activity: 109



View Profile
February 12, 2011, 06:59:33 AM
 #35

Here's how I think small amounts could be shown on the user interface, to minimise confusion:



The digits are grouped into milli-cents and micro-cents, and are shown smaller than the usual "bitcoins and bitcents".

I like it.
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
February 12, 2011, 08:25:37 AM
 #36

Here's how I think small amounts could be shown on the user interface, to minimise confusion:



The digits are grouped into milli-cents and micro-cents, and are shown smaller than the usual "bitcoins and bitcents".

I like it.

+1

Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2268



View Profile
February 12, 2011, 03:53:08 PM
 #37

Reminder that we already have a URI specification that defines a format for safely representing any BTC (or TBC) value in a human-readable way. 100 BTC is represented as 100X8 (for 8 places beyond the decimal point). It could just as well be used for 1X4 (for 0.0001 BTC) or even 1X0 (for a single base unit).

That being said, more human-friendly names/units are still appropriate. Base unit / 10000 could be named "DBC" (but then how would you pronounce it?), or possibly it might be better to just stick with the existing SI units and use mBTC (milli-bitcoin; 0.001 BTC) or μBTC (micro-bitcoin; 0.000001 BTC).

ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
February 12, 2011, 04:00:25 PM
 #38

or possibly it might be better to just stick with the existing SI units and use mBTC (milli-bitcoin; 0.001 BTC) or μBTC (nano-bitcoin; 0.000001 BTC).

This creates another problem. You have mili-btc, which is easy enough, but what about 0.0001 BTC and 0.00001 BTC ?

Reminder that we already have a URI specification that defines a format for safely representing any BTC (or TBC) value in a human-readable way. 100 BTC is represented as 100X8 (for 8 places beyond the decimal point). It could just as well be used for 1X4 (for 0.0001 BTC) or even 1X0 (for a single base unit).

You mean something like this but kind of - reversed ?

Quote
1 BTCX0 = 1 BTC
1 BTCX1 = 0.1 BTC
1 BTCX2 = 0.01 BTC
1 BTCX3 = 0.001 BTC
1 BTCX4 = 0.0001 BTC

Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2268



View Profile
February 12, 2011, 04:12:12 PM
 #39

or possibly it might be better to just stick with the existing SI units and use mBTC (milli-bitcoin; 0.001 BTC) or μBTC (nano-bitcoin; 0.000001 BTC).
This creates another problem. You have mili-btc, which is easy enough, but what about 0.0001 BTC and 0.00001 BTC ?
Oh well, yet another reason decimal/SI sucks I guess. Switch to Tonal, or suffer with mdBTC (milli-deci-)? Tongue
(or just use 100 μBTC or 0.1 mBTC)

Reminder that we already have a URI specification that defines a format for safely representing any BTC (or TBC) value in a human-readable way. 100 BTC is represented as 100X8 (for 8 places beyond the decimal point). It could just as well be used for 1X4 (for 0.0001 BTC) or even 1X0 (for a single base unit).
You mean something like this but kind of - reversed ?
Quote
1 BTCX0 = 1 BTC
1 BTCX1 = 0.1 BTC
1 BTCX2 = 0.01 BTC
1 BTCX3 = 0.001 BTC
1 BTCX4 = 0.0001 BTC
Right. Introducing a new "BTCXn" would totally confuse things with the existing URI scheme probably.

ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
February 12, 2011, 04:52:57 PM
 #40

Right. Introducing a new "BTCXn" would totally confuse things with the existing URI scheme probably.

That would be not for the URI scheme, but just for general use.

Pages: « 1 [2] 3 4 5 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!