ribuck
Donator
Hero Member
Offline
Activity: 826
Merit: 1060
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 10, 2011, 06:12:56 PM |
|
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.
|
|
|
|
nelisky
Legendary
Offline
Activity: 1540
Merit: 1002
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 10, 2011, 06:18:00 PM |
|
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
Offline
Activity: 314
Merit: 4041
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 10, 2011, 06:53:14 PM |
|
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
Offline
Activity: 5306
Merit: 13296
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 10, 2011, 08:30:07 PM |
|
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
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 10, 2011, 08:58:04 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 10, 2011, 09:06:01 PM |
|
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
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 90
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2011, 07:12:48 PM |
|
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
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2011, 07:35:04 PM |
|
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. 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 1 BTCA = 0.1 BTC 1 BTCB = 0.01 BTC 1 BTCC = 0.001 BTC 1 BTCD = 0.0001 BTC
or 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
Activity: 1288
Merit: 1080
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2011, 07:42:30 PM |
|
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
Offline
Activity: 1596
Merit: 1099
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2011, 08:02:42 PM |
|
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, Bloq CEO, former bitcoin core dev team; opinions are my own. Visit bloq.com / metronome.io Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
|
|
|
LZ
Legendary
Offline
Activity: 1722
Merit: 1072
P2P Cryptocurrency
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2011, 09:02:17 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2011, 09:14:17 PM |
|
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
Hero Member
Offline
Activity: 826
Merit: 1060
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2011, 11:08:24 PM |
|
Here's how I think small amounts could be shown on the user interface, to minimise confusion: ![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fi55.tinypic.com%2F9t06sp.png&t=665&c=C5JcX90mg7vVzw) 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
Activity: 3920
Merit: 2349
Eadem mutata resurgo
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2011, 12:06:22 AM |
|
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#provisionpricesIn 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
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 109
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2011, 06:59:33 AM |
|
Here's how I think small amounts could be shown on the user interface, to minimise confusion: ![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fi55.tinypic.com%2F9t06sp.png&t=665&c=C5JcX90mg7vVzw) 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
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2011, 08:25:37 AM |
|
Here's how I think small amounts could be shown on the user interface, to minimise confusion: ![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fi55.tinypic.com%2F9t06sp.png&t=665&c=C5JcX90mg7vVzw) 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
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2011, 03:53:08 PM Last edit: February 12, 2011, 04:09:52 PM by Luke-Jr |
|
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
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2011, 04:00:25 PM |
|
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 ? 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
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2011, 04:12:12 PM |
|
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](https://bitcointalk.org/Smileys/default/tongue.gif) (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 ? 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
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2011, 04:52:57 PM |
|
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.
|
|
|
|
|