Re: [Bitcoin-development] moving the default display to mbtc

2014-05-02 Thread Ben Davenport
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-symbolamountmodifier, 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 jgar...@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@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] moving the default display to mbtc

2014-05-02 Thread Ben Davenport
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 l...@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-symbolamountmodifier, 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).

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] moving the default display to mbtc

2014-03-13 Thread Ben Davenport
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 m...@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@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Stealth Addresses

2014-01-17 Thread Ben Davenport
Well, at least we don't have to worry about cache invalidation.

Ben


On Fri, Jan 17, 2014 at 6:46 AM, Peter Todd p...@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=ischq=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
 0001c9b372ed519ecc6d41c10b42a7457d1ca5acd560a535596b


 --
 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=119420431iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
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=119420431iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Suggestion: allow receivers to pay optional fee for transactions without fees

2014-01-16 Thread Ben Davenport
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 frag...@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=119420431iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
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=119420431iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development