Re: [Bitcoin-development] moving the default display to mbtc
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 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 , 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
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 , 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 wrote: > > > 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
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 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
Well, at least we don't have to worry about cache invalidation. Ben On Fri, Jan 17, 2014 at 6:46 AM, Peter Todd 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 > 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=119420431&iu=/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=119420431&iu=/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
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 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@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=119420431&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
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 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@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=119420431&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
