<unnamed>

Public Key

npub15te7jlfhpkequ3fk7uhwgw700y5ykn6x4llt68y09mejjvn7zfcqs4eg6q

Profile Code

nprofile1qqs29ulf05msmvswg5m0wthy808hj2ztfar2ll4arj8jauefxflpyuqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsdpqjys

Publishing to

relay.snort.social

nos.lol

relay.damus.io

Last Notes

2023-06-07 15:09:40 UTC

- reply

📅 Original date posted:2013-11-15
📝 Original message:Hi guys,
I've seen many many non-geeks be utterly intimidated and confused by
0.000XXXXX quantities and/or mBTC & uBTC notation
Yes, $10 being rougnly 10,000 Won in South Korean is a great example where
large amounts of units work very well in a major economy.
FWIW, I would prefer the entire switch-over be done *once* *and *at the
same time switching both BTC to XBT and using the following
Currency Code *: *XBT
Unit Definition *: *1 Bit = 100 Satoshis
Addition benefit is splitting the term Bitcoin/bitcoin (as in Network and
currency unit) into Bitcoin (network) and Bit (the unit).
Perhaps this project/process should have a name and be listed on a road map
somewhere
*BRCS: *Bitcoin Re-denomination and [Currency] Code Standardization project
Cheers ...
On Fri, Nov 15, 2013 at 1:23 AM, Eugen Leitl <eugen at leitl.org> wrote:
> On Thu, Nov 14, 2013 at 05:53:16PM -0500, Alan Reiner wrote:
> > I really like the XBT idea. It makes a lot of sense to match the ISO
>
> I really don't. Just use the SI prefixes.
>
> > currency symbol (though the ISO guys will have to adjust the way they've
> > defined the "XBT"). And I do agree that going right to uBTC and
> > skipping mBTC makes sense, too.
>
> The display units should be choosable by the user.
>
> > I'd prefer them not be called "micro bitcoins." I really want to call
> > them "microbes" ... but I'm not sure that has the right flavor for money
>
> Why on earth?
>
> > transfer :) "Please give me 872 microbes". Perhaps we just call them
> > "bits." Or even "micros" or "microbits". As I write this, I realize
> > there's probably 872 threads on the forums about this already...
> >
> > But we would want to promote a consistent term, to avoid further
> > confusion when people use different names for the new unit. It's not
> > guaranteed to be successful, but if we pick a good name, and build it
> > into the interface on the first release pushing the new unit, we have a
> > chance to make the transition even easier.
>
> The reason SI prefixes were invented is exactly to preven that case.
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Alex Kravets <http://www.linkedin.com/in/akravets> def redPill = '
Scala <http://www.scala-lang.org/>
[[ brutal honesty <http://goo.gl/vwydt> is the best policy ]]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131115/8eb4c3e6/attachment.html>

2023-06-07 15:04:01 UTC

- reply

📅 Original date posted:2013-06-27
📝 Original message:Perhaps there should be two different sections on the web page.
Nerds / Non-Nerds
With different recommendations for which clients to use.
On Thu, Jun 27, 2013 at 2:56 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> On Thu, Jun 27, 2013 at 5:12 PM, Alex Kravets <kravets at gmail.com> wrote:
> > What all the nerdy devs (and I am one so I know) seem unable to
> comprehend,
> > is that regular people out there don't wanna learn all this new stuff and
> > new terminology they simply have no attention span for it.
>
> Bitcoin Wallet for Android is a decentralized client w/ network sync,
> and it works just fine. Fast, easy to use.
>
> --
> Jeff Garzik
> Senior Software Engineer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
--
Alex Kravets <http://www.linkedin.com/in/akravets> def redPill = '
Scala <http://www.scala-lang.org/>
[[ brutal honesty <http://goo.gl/vwydt> is the best policy ]]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130627/b4e6d949/attachment.html>

2023-06-07 15:04:00 UTC

- reply

📅 Original date posted:2013-06-27
📝 Original message:Hi Jim,
On Thu, Jun 27, 2013 at 12:18 PM, Jim <jim618 at fastmail.co.uk> wrote:
>
> Alex: Yes I think most users migrate to blockchain.info or,
> more recently coinbase.com. They are both good wallets
> but I'd like to keep Bitcoin as P2P as possible.
>
Guys, being a late comer/outsider (I got into bitcoin in early 2012), I can
tell you that this particular asylum is definitely run by its inmates.
What all the nerdy devs (and I am one so I know) seem unable to comprehend,
is that regular people out there don't wanna learn all this new stuff and
new terminology they simply have no attention span for it.
Simply channelling them to a decent client that
1. Just works (no blockchain downloads and no re-sync)
2. Allows to retain control of the private keys
Would be HUGE for mass adoption.
Old tired argument about "Bitcoin needs your nodes", so we'll channel you
to get bitcoin-qt client is both manipulative and unnecessary (there's
plenty of nodes and NAT'ed home nodes which don't mine are mostly useless
anyways)
P.S. coinbase.com is just another trust-me setup takes your coins in
exchange for IOUs, whereas blockchain.info does let you to retain control
of your private keys.
P.P.S. The reason why coinbase has gotten so big is precisely because they
don't trouble regular lawyers and doctors with all the nonsense but simply
give them a
"buy" and a "sell" button.
> Luke-Jr
> I think you are right here on the number of full nodes versus
> SPV nodes.
> I don't think we even know yet what are the working ratios of
> full nodes to SPV nodes. I haven't seen anybody do any
> analysis on this.
>
> I doubt multibit will ever participate in the Bitcoin network
> other than as an SPV client. All the optimisation is to reduce
> data traffic - it is effectively a mobile wallet that happens to
> live on a desktop. It is not really intended to be more than
> "a wallet for regular people to store and spend their bitcoin".
>
> In English the nomenclature for direction of the transactions
> is: "Sent to" and "Received with". To be honest I
> haven't transliterated the localisation files to check other
> language packs but the localisers are pretty good in my
> experience.
>
>
>
>
>
> On Thu, Jun 27, 2013, at 07:41 PM, Gregory Maxwell wrote:
> > On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr <luke at dashjr.org> wrote:
> > > On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote:
> > >> * Very real possibility of an overall net reduction of full nodes on
> P2P
> > >> network
> > > Even a reduction of *nodes at all*, as I've never seen a listening
> bitcoinj or
> > > MultiBit node. :/
> > > Jim, will MultiBit be adding p2p listening support?
> >
> > Without validation listening isn't currently very useful. :( Maybe it
> > could be somewhat more with some protocol additions.
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Windows:
> >
> > Build for Windows Store.
> >
> > http://p.sf.net/sfu/windows-dev2dev
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> --
> https://multibit.org Money, reinvented
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Alex Kravets <http://www.linkedin.com/in/akravets> def redPill = '
Scala <http://www.scala-lang.org/>
[[ brutal honesty <http://goo.gl/vwydt> is the best policy ]]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130627/1571c8d1/attachment.html>