Ben Davenport [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-01-15 to 2014-05-03
💬 Posted a total of 6 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:20:48

- 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 15:20:46

- 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 15:20:46

- reply

2023-06-07 15:15:39

- 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 15:15:39

- reply

2023-06-07 15:12:19

- reply

📅 Original date posted:2014-01-16
📝 Original message:You can create a transaction which spends the output to yourself, attaching
a fee to that transaction. In order for miners to grab the transaction fee
on that transaction, they would have to also mine the original transaction.
Likely, you'd have to do this by hand, but software could be written to
simplify doing it. No protocol changes needed.
Ben
On Thu, Jan 16, 2014 at 5:39 PM, Dâniel Fraga <fragabr at gmail.com> wrote:
> Someone sent me a very small donation (0.00121 BTC) without
> paying fees. I don't know who sent it and I know this type of
> transaction are usually rejected by miners. Take a look at it below:
>
> https://imageshack.com/i/ngv5g8j
>
> Even with the a low probability of confirmation, I
> was hoping that after a few days it could be included in a block, but
> Blockchain.info simply removed it (I know the sender sent from a
> Blockchain.info wallet, because he added a note):
>
>
> https://blockchain.info/pt/tx/3cde47ee3979a46b36bd61bdb0caf9c11dea58ac99f17fb17b95728766de70e0
>
> As you can see now it shows as "Transaction not found".
>
> My suggestion is: it would be nice if the receiver could have a
> chance to pay the fee when the sender didn't pay any fee. For example,
> I could pay a fee of 0.0001 BTC and receive 0.00121 BTC. In the end I'd
> have 0.00111 BTC. Better than nothing.
>
> Would it be technically possible to do that or it would be too
> much trouble to change the protocol to allow the receiver to pay an
> optional fee?
>
> Ps: I'm not a programmer, but if the receiver could
> optionally "attach" some fee to the transaction, even if he/she didn't
> sent the transaction, this could be solved. Bitcoin-qt could even warn
> the receiver he received a transaction without fee and if he wants
> faster confirmation he could pay a fee.
>
> Ps2: if this is a silly suggestion, just ignore it. I tried on
> Bitcointalk, but nobody answered.
>
> --
> Linux 3.12.0: One Giant Leap for Frogkind
> http://www.youtube.com/DanielFragaBR
> http://mcxnow.com
> Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL
>
>
>
>
> ------------------------------------------------------------------------------
> 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/20140116/8f21db5d/attachment.html>

2023-06-07 15:11:49

- 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>

2023-06-07 15:11:41

- reply

📅 Original date posted:2014-01-15
📝 Original message:Love what's happening here, and how quickly things are moving, from initial
concept, to first implementation, to first transaction.
But may I suggest we consider changing the name "stealth address" to
something more neutral?
Already, many people on Reddit and elsewhere are misinterpreting the
purpose of such addresses, whether for tax evasion, criminal activity, or
who knows what. Bitcoin already has plenty of political hurdles based
sheerly on the technology. We don't need to make life harder for ourselves.
Even forgetting about politics, the "stealth" association just seems to
imply something secretive going on. Is a Fortune 500 company or worldwide
charity going to want to use something called a "stealth address"?
I'd propose the alternate term "routing address".
- It's a descriptive, neutral term
- It accurately describes what the address is: it's a way to route payment
to a recipient, but not the actual final address
- It can be analogized to a bank's routing number: It is uniquely, publicly
and persistently tied to the receiving institution. The payor and payee
knows when payment is made using it, but it's not publicly visible.
That's the best I've got, but here are some alternate terms in case that
doesn't work:
- reusable public address
- permanent public address
- permanent address
- static address
I don't like these quite as much because they're not as clear. Normal
addresses are all reusable, permanent and static -- they just _shouldn't_
be used that way.
Ben
On Tue, Jan 14, 2014 at 4:19 PM, Drak <drak at zikula.org> wrote:
> Sorry this is possibly OT, but someone posted this thread to r/bitcoin and
> it's gone straight to position 1. People are really enthusiastic about this
> feature.
>
> Drak
>
>
> ------------------------------------------------------------------------------
> 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/20140115/4e4a71a9/attachment.html>