Drak [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-13 📝 Original message:I agree with you Jeff. The ...
📅 Original date posted:2014-03-13
📝 Original message:I agree with you Jeff. The unit switch needs to happen once and once only,
but that is exactly why I said the defaults really need to change in
Bitcoin-Qt since that is still the main reference implementation and it
will influence others.
Bitpay could also take the lead here and make the switch to their defaults.
That would greatly assist the uBTC movement.
Regardless of what anyone says, Bitcoin-Qt is still the main reference
implementation and the best way to encourage a change in the community at
large is for the default units to be changed here. Core devs can surely
garner enough consensus among themselves to accept and merge a PR to that
effect. That will send a message, more than anything else that can be done.
My two satoshi.
Drak
On 13 March 2014 16:29, Jeff Garzik <jgarzik at bitpay.com> wrote:
> On Thu, Mar 13, 2014 at 12:14 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> > Of course, as Mike said, this ship may have already sailed, but if
> > there's any way to revisit this, I'm there. We're just about to do
> > another Armory release and could support this very easily.
>
> mBTC now just means the issue -will- be revisited in the future. Just
> a question of when, not if.
>
> People and software in various nations handle big numbers for small
> values (e.g. Yen) just fine.
> People and software do -not- handle extra decimal places well, field
> experience shows.
>
> <vendor hat: on> To roll out QuickBooks support --without converting
> any numbers, a key financial attribute-- mBTC is simply insufficient
> today, not in the future.
>
> I also argue that it is a security risk, as follows: To support
> accounting packages limited to 2 decimal places, decimal point
> conversion must be performed. This produces a situation where your
> accounting system shows numbers that do not visually match the numbers
> in the bitcoin software. That, in turn, making auditing more
> difficult, particularly for outsiders.
>
> Shipping with mBTC defaults was decidedly unwise, considering that --
> like BTC -- it fails to solve existing, known problems that uBTC can
> solve, and considering the inevitable mBTC->uBTC switch.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/ed4f62d7/attachment.html>;
📝 Original message:I agree with you Jeff. The unit switch needs to happen once and once only,
but that is exactly why I said the defaults really need to change in
Bitcoin-Qt since that is still the main reference implementation and it
will influence others.
Bitpay could also take the lead here and make the switch to their defaults.
That would greatly assist the uBTC movement.
Regardless of what anyone says, Bitcoin-Qt is still the main reference
implementation and the best way to encourage a change in the community at
large is for the default units to be changed here. Core devs can surely
garner enough consensus among themselves to accept and merge a PR to that
effect. That will send a message, more than anything else that can be done.
My two satoshi.
Drak
On 13 March 2014 16:29, Jeff Garzik <jgarzik at bitpay.com> wrote:
> On Thu, Mar 13, 2014 at 12:14 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> > Of course, as Mike said, this ship may have already sailed, but if
> > there's any way to revisit this, I'm there. We're just about to do
> > another Armory release and could support this very easily.
>
> mBTC now just means the issue -will- be revisited in the future. Just
> a question of when, not if.
>
> People and software in various nations handle big numbers for small
> values (e.g. Yen) just fine.
> People and software do -not- handle extra decimal places well, field
> experience shows.
>
> <vendor hat: on> To roll out QuickBooks support --without converting
> any numbers, a key financial attribute-- mBTC is simply insufficient
> today, not in the future.
>
> I also argue that it is a security risk, as follows: To support
> accounting packages limited to 2 decimal places, decimal point
> conversion must be performed. This produces a situation where your
> accounting system shows numbers that do not visually match the numbers
> in the bitcoin software. That, in turn, making auditing more
> difficult, particularly for outsiders.
>
> Shipping with mBTC defaults was decidedly unwise, considering that --
> like BTC -- it fails to solve existing, known problems that uBTC can
> solve, and considering the inevitable mBTC->uBTC switch.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/ed4f62d7/attachment.html>;