<unnamed>

Public Key

npub1qa67gm2kyrqt7sldhzeppu5hq2ajx80y8f5rs9z6f34pjce03lms4wrrvp

Profile Code

nprofile1qqsqwa0yd4tzps9lg0km3vss72ts9werrhjr56pcz3dyc6sevvhclacpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsyg4ewn

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:20:48 CEST

- reply

📅 Original date posted:2014-05-02
📝 Original message:Luke,
My point is that you never apply the prefixes to the currency unit itself.
We don't spend kilodollars or megadollars.
Ben
On Fri, May 2, 2014 at 7:38 PM, Luke Dashjr <luke at dashjr.org> wrote:
> On Saturday, May 03, 2014 12:54:37 AM Ben Davenport wrote:
> > My only addition is that I think we should all stop trying to attach SI
> > prefixes to the currency unit. Name me another world currency that uses
> SI
> > prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted standard
> at
> > least in the US is <currency-symbol><amount><modifier>, i.e. $63k or $3M.
> > That may not be accepted form everywhere, but in any case it's an
> informal
> > format, not a formal one. The important point is there should be one base
> > unit that is not modified with SI prefixes. And I think the arguments are
> > strong for that unit being = 100 satoshi.
>
> Huh? Your examples demonstrate the *opposite* of your point. 'k' and 'M'
> *are*
> the SI prefixes. People *do* use 63k USD, $63k, and $3M. I'll be the first
> one
> to admit SI is terrible, but I don't understand your argument here.
>
> Luke
>
> P.S. Note that SI units haven't actually ever been adopted, except by
> force of
> law. "Name me ... that uses SI" is a silly thing to say, since virtually
> all
> naturally-or-freely-adopted units of any measure have been based on a
> number
> that factor to twos and threes (not fives, like decimal).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140502/391c75c7/attachment.html>

2023-06-07 17:20:46 CEST

- reply

📅 Original date posted:2014-05-02
📝 Original message:I fully support this (it's what I suggested over a year ago), but what it
comes down to is BitPay, Coinbase, Blockchain and Bitstamp getting
together, agreeing what they're going to use, and doing a little joint
customer education campaign around it. If there's community momentum around
"bits", great.
My only addition is that I think we should all stop trying to attach SI
prefixes to the currency unit. Name me another world currency that uses SI
prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted standard at
least in the US is <currency-symbol><amount><modifier>, i.e. $63k or $3M.
That may not be accepted form everywhere, but in any case it's an informal
format, not a formal one. The important point is there should be one base
unit that is not modified with SI prefixes. And I think the arguments are
strong for that unit being = 100 satoshi.
Ben
On Fri, May 2, 2014 at 12:17 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> <vendor hat: on>
>
> Related:
> http://blog.bitpay.com/2014/05/02/bitpay-bitcoin-and-where-to-put-that-decimal-point.html
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> 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/20140502/3dded3a2/attachment.html>

2023-06-07 17:15:39 CEST

- reply

📅 Original date posted:2014-03-13
📝 Original message:Another vote in support of uBTC. I made my position clear in May of last
year. Since then, Dogecoin has essentially PROVEN the psychological value
of a low-valued large-balance currency.
(From: https://bitcointalk.org/index.php?topic=220322.msg2334059#msg2334059)
"The whole unit change seems so disruptive and difficult to coordinate now
-- do we really want to have to deal with another one later when there are
way more people to try to coordinate? I really think we should look to the
endgame and figure out where we want to be.
"I'd propose moving to uB (micro-bitcoin = 1e-6) as the standard unit now
and forever. For now, it can be referred to as uB or uBTC, but over time,
once it's ubiquitous, it should just be called a bitcoin. Because the
smallest unit is the satoshi (1e-8), this means uB-denominated prices would
get 2 decimal places maximum, which is the most that any consumer wants to
deal with anyway.
"At the same time, I'd propose inverting the exchange rate, so instead of
quoting uB/USD = .00013, it would be quoted as USD/uB = 7692. This is
exactly the same way Yen are quoted relative to USD (USDJPY = 100.66), and
is also the same way other private virtual currencies such as WoW gold are
quoted."
On Thu, Mar 13, 2014 at 11:29 AM, Mike Hearn <mike at plan99.net> wrote:
> You would only need to change it if there was a sub-satoshi hardfork,
>> which doesn't seem necessary anytime soon.
>>
>
> +
>
> We shouldn't make any assumptions about the future price of bitcoin to
>> make the decision.
>>
>
> Hmmm ;) Didn't you just make an assumption about the future price?
>
>
>> This sounds very US-centric to me. Aren't you thinking in usd?
>>
>
> The currencies I'm familiar with are CHF, USD, EUR and GBP, which all have
> roughly similar values. I guess such currencies make up the bulk of the
> Bitcoin userbase at the moment.
>
>
>> "People seem to like mBTC" is just an ad populum fallacy: millions of
>> flies can actually be wrong. Also you haven't showed them micros,
>> maybe they like it too.
>
>
> Saying "it's already popular and would take work to change" is not really
> a fallacy now, is it?
>
> But anyway, this is getting silly. You don't have to convince me. Go visit
> all the services I listed above, plus all the ones I didn't find in my five
> minutes of searching, and convince them they're wrong like the flies and
> switching is the best use of their time :o
>
>
> ------------------------------------------------------------------------------
> 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/9a96164a/attachment.html>

2023-06-07 17:11:49 CEST

- reply

📅 Original date posted:2014-01-17
📝 Original message:Well, at least we don't have to worry about cache invalidation.
Ben
On Fri, Jan 17, 2014 at 6:46 AM, Peter Todd <pete at petertodd.org> wrote:
> On Fri, Jan 17, 2014 at 10:15:40AM +0100, Mike Hearn wrote:
> > I must say, this shed is mighty fine looking. It'd be a great place to
> > store our bikes. But, what colour should we paint it?
>
> I think we should paint it this colour:
>
> They had uncovered what seemed to be the side of a large coloured
> globule embedded in the substance. The colour, which resembled some
> of the bands in the meteor's strange spectrum, was almost impossible
> to describe; and it was only by analogy that they called it colour
> at all. Its texture was glossy, and upon tapping it appeared to
> promise both brittle ness and hollowness. One of the professors gave
> it a smart blow with a hammer, and it burst with a nervous little
> pop. Nothing was emitted, and all trace of the thing vanished with
> the puncturing. It left behind a hollow spherical space about three
> inches across, and all thought it probable that others would be
> discovered as the enclosing substance wasted away.
>
> I think it really gets to the core of my feelings about this naming
> discussion.
>
> > How about we split the difference and go with "privacy address"? As Peter
> > notes, that's what people actually like and want. The problem with
> stealth
> > is it's got strong connotations with American military hardware and
> perhaps
> > thieves sneaking around in the night:
> >
> > https://www.google.com/search?tbm=isch&q=stealth
>
> WOW! AWESOME KICK-ASS PICS!
>
> Come to think of it, I could have called it "incognito addresses" - a
> term nice enough that Google and Firefox use it in their browsers - but
> what's done is done and any further discussion about this is just going
> to confuse the public. Remember that in the long run all this stuff will
> be hidden behind payment protocols anyway, and users *won't even know*
> that under the hood a stealth address is being used, making the name
> just a technical detail. For now though, lets use the good PR and get
> some early adopters on board.
>
> However, the term 'incognito' probably would be a good one to use within
> wallet software itself to describe what it's doing when the user clicks
> the "I want my transactions to be private" setting - there are after all
> fundemental bandwidth-privacy trade-offs in the threat model supposed by
> both prefix and bloom filters. In this instance the term isn't going to
> go away.
>
>
> Anyway, back to work: For the actual address format I strongly think we
> need to ensure that it can be upgrading in a backwards compatible way.
> This means we have to be able to add new fields - for instance if
> Gregory's ideas for different ways of doing the SPV-bait came to
> fruition. Given that "addresses" aren't something that should stay
> user-visible forever, thoughts on just making the actual data a protocol
> buffers object?
>
> Second question: Any performance figures yet on how efficient scanning
> the blockchain for matching transactions actually is? I'd like to get an
> idea soon for both desktop and smartphone wallets so we can figure out
> what kind of trade-offs users might be forced into in terms of prefix
> length.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000001c9b372ed519ecc6d41c10b42a7457d1ca5acd560a535596b
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/20140117/f1767ee8/attachment.html>