[Bitcoin-development] BIP70 implementation guidance
A bunch of different people either have implemented or are implementing BIP70 at the moment. Here's a bunch of things I've been telling people in response to questions. At some point I'll submit a pull req with this stuff in but for now it's just an email. *Error handling during signature checking* I've had queries around the right behaviour here. BIP 70 is underspecified and we should fix it IMO. If PKI checking fails you should just treat the request as if it's unsigned. The reason is that there is no incentive for an attacker to break the signature instead of just removing it entirely, so an attacker would never trigger any error flows you put in. However, someone who is signing their request with an unknown CA or using an upgraded version of the protocol that isn't entirely backwards compatible *could* trigger signature checking failure. Therefore, in order to make introducing new (possibly community run) CA's or new variations on signing possible, please treat any errors as if there was no signature at all. This is not what browsers do, but browsers have an advantage - they were already given an identity and told to expect a secure protocol when the user typed in the web address with an https://prefix (or clicked a link). Unfortunately a Bitcoin wallet has no context like this. One person asked me whether this makes the whole scheme pointless because a MITM can just delete the signature. The answer is no - downgrade attacks are always possible on systems that start out insecure. The solution is to train users to expect the upgrade and refuse to go ahead if it's not there. Training users to expect signed payment requests will be a big task similar to the way the browser industry trained users to look for the padlock when typing in credit card details, but it must be done. Because wallets lack context there's no equivalent to HSTS for us either. So in your GUI's try to train the user - when showing a signed payment request, tell them to expect the recipient name to appear in future and that they should not proceed if it doesn't. This gives us a kind of mental HSTS. *Extended validation certs* When a business is accepting payment, showing the name of the business is usually better than showing just the domain name, for a few reasons: 1. Unless your domain name *is* your business name like blockchain.info, it looks better and gives more info. 2. Domain names are more phishable than EV names, e.g. is the right name bitpay.com or bit-pay.com or bitpay.co.uk? 3. More important: Someone who hacks your web server or DNS provider can silently get themselves a domain name SSL cert issued, probably without you noticing. Certificate transparency will eventually fix that but it's years away from full deployment. It's much harder for a hacker to get a bogus EV cert issued to them because there's a lot more checking involved. EV certs still have the domain name in the CN field, but they also have the business name in the OU field. In theory we are supposed to have extra code to check that a certificate really was subject to extended validation before showing the contents of this field. In practice either bitcoinj nor Bitcoin Core actually do, they just always trust it. It'd be nice to fix that in future. You should show the organisation data instead of the domain name if you find it, for EV certs. *pki=none* Signing is optional in BIP 70 for good reasons. One implementor told me they were considering rejecting unsigned payment requests. Do not do this! A MITM can easily rewrite the bitcoin URI to look as if BIP70 isn't in use at all. Even though today most (all?) payment requests you'll encounter are signed, it's important that signing is optional because in future we need individual people to start generating payment requests too, and many of them won't have any kind of memorisable digital identity. Plus other people just won't want to do it. BIP70 is about lots of features, signing is only one. *S/MIME certs* Email address certs look a bit different to SSL certs. You can get one for free from here https://comodo.com/home/email-security/free-email-certificate.php In these certs the display name can be found in the Subject Alternative Name field with a type code of 1. Example code: https://github.com/bitcoinj/bitcoinj/commit/feecc8f48641cd02cafc42150abba4e4841ea33d You won't encounter many of these today except on Gavin's test site, but in future people may wish to start creating and signing their own payment requests for individual purposes using these certs (especially as they are free). So please try to handle them correctly. *Broadcast vs upload* Please upload transactions and commit them to your wallet when the server responds with 200 OK, but expect the merchant to broadcast them. Don't give the user an option to pick - it's pointless as there's no obvious right answer. *Testing* You can find a test site here:
Re: [Bitcoin-development] Compatibility Bitcoin-Qt with Tails
On 04/30/2014 03:02 AM, Wladimir wrote: On Sat, Apr 26, 2014 at 7:29 PM, Kristov Atlas aut...@anonymousbitcoinbook.com wrote: Hey Wladimir, Thanks for building this binary. The initial problem with Qt was resolved, and I was able to load the GUI that chooses my datadir. After choosing the default datadir, however, it segfaulted. I've fixed the issue; at least on Debian 6 - which is a lot more conductive to development than tails :-). See https://github.com/bitcoin/bitcoin/pull/4094 for the gory details. New test build available: https://download.visucore.com/bitcoin/linux-gitian-3cbabfa.tar.gz (sigs: https://download.visucore.com/bitcoin/linux-gitian-3cbabfa.tar.gz.sig ) Wladimir Nice work! I can confirm that this dev binary runs smoothly in the latest version of Tails, v1.0. Screenshot proof here [1]. When this is incorporated into the next release of Bitcoin Core, will this make the usual Linux binary compatible, or will there be a special binary just for systems running the older Qt? -Kristov [1] http://postimg.org/image/p3ycwai9d/ -- 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] Compatibility Bitcoin-Qt with Tails
On Fri, May 2, 2014 at 7:46 PM, Kristov Atlas aut...@anonymousbitcoinbook.com wrote: Nice work! I can confirm that this dev binary runs smoothly in the latest Thanks for testing! version of Tails, v1.0. Screenshot proof here [1]. When this is incorporated into the next release of Bitcoin Core, will this make the usual Linux binary compatible, or will there be a special binary just for systems running the older Qt? The normal binary will be compatible. At some point we may add a binary that is linked to Qt 5.x as well for newer distributions, but compatibility is most important. Wladimir -- 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
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
Re: [Bitcoin-development] BIP70 implementation guidance
At the moment BIP70 specifically requires that a request be rejected if validation fails, so that should be fixed that sooner rather than later: The recipient must verify the certificate chain according to [RFC5280] and reject the PaymentRequest if any validation failure occurs. Aaron There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers On Fri, May 2, 2014 at 8:39 AM, Mike Hearn m...@plan99.net wrote: A bunch of different people either have implemented or are implementing BIP70 at the moment. Here's a bunch of things I've been telling people in response to questions. At some point I'll submit a pull req with this stuff in but for now it's just an email. Error handling during signature checking I've had queries around the right behaviour here. BIP 70 is underspecified and we should fix it IMO. If PKI checking fails you should just treat the request as if it's unsigned. The reason is that there is no incentive for an attacker to break the signature instead of just removing it entirely, so an attacker would never trigger any error flows you put in. However, someone who is signing their request with an unknown CA or using an upgraded version of the protocol that isn't entirely backwards compatible could trigger signature checking failure. Therefore, in order to make introducing new (possibly community run) CA's or new variations on signing possible, please treat any errors as if there was no signature at all. This is not what browsers do, but browsers have an advantage - they were already given an identity and told to expect a secure protocol when the user typed in the web address with an https:// prefix (or clicked a link). Unfortunately a Bitcoin wallet has no context like this. One person asked me whether this makes the whole scheme pointless because a MITM can just delete the signature. The answer is no - downgrade attacks are always possible on systems that start out insecure. The solution is to train users to expect the upgrade and refuse to go ahead if it's not there. Training users to expect signed payment requests will be a big task similar to the way the browser industry trained users to look for the padlock when typing in credit card details, but it must be done. Because wallets lack context there's no equivalent to HSTS for us either. So in your GUI's try to train the user - when showing a signed payment request, tell them to expect the recipient name to appear in future and that they should not proceed if it doesn't. This gives us a kind of mental HSTS. Extended validation certs When a business is accepting payment, showing the name of the business is usually better than showing just the domain name, for a few reasons: Unless your domain name is your business name like blockchain.info, it looks better and gives more info. Domain names are more phishable than EV names, e.g. is the right name bitpay.com or bit-pay.com or bitpay.co.uk? More important: Someone who hacks your web server or DNS provider can silently get themselves a domain name SSL cert issued, probably without you noticing. Certificate transparency will eventually fix that but it's years away from full deployment. It's much harder for a hacker to get a bogus EV cert issued to them because there's a lot more checking involved. EV certs still have the domain name in the CN field, but they also have the business name in the OU field. In theory we are supposed to have extra code to check that a certificate really was subject to extended validation before showing the contents of this field. In practice either bitcoinj nor Bitcoin Core actually do, they just always trust it. It'd be nice to fix that in future. You should show the organisation data instead of the domain name if you find it, for EV certs. pki=none Signing is optional in BIP 70 for good reasons. One implementor told me they were considering rejecting unsigned payment requests. Do not do this! A MITM can easily rewrite the bitcoin URI to look as if BIP70 isn't in use at all. Even though today most (all?) payment requests you'll encounter are signed, it's important that signing is optional because in future we need individual people to start generating payment requests too, and many of them won't have any kind of memorisable digital identity. Plus other people just won't want to do it. BIP70 is about lots of features, signing is only one. S/MIME certs Email address certs look a bit different to SSL certs. You can get one for free from here https://comodo.com/home/email-security/free-email-certificate.php In these certs the display name can be found in the Subject Alternative Name field with a type code of 1. Example code: https://github.com/bitcoinj/bitcoinj/commit/feecc8f48641cd02cafc42150abba4e4841ea33d You won't encounter many of these today except on Gavin's test site, but in future people may wish to start creating and
Re: [Bitcoin-development] BIP70 implementation guidance
*Extended validation certs* When a business is accepting payment, showing the name of the business is usually better than showing just the domain name, for a few reasons: 1. Unless your domain name *is* your business name like blockchain.info, it looks better and gives more info. 2. Domain names are more phishable than EV names, e.g. is the right name bitpay.com or bit-pay.com or bitpay.co.uk? 3. More important: Someone who hacks your web server or DNS provider can silently get themselves a domain name SSL cert issued, probably without you noticing. Certificate transparency will eventually fix that but it's years away from full deployment. It's much harder for a hacker to get a bogus EV cert issued to them because there's a lot more checking involved. EV certs still have the domain name in the CN field, but they also have the business name in the OU field. Well, many certs have something in the O field. That has nothing to do with EV - EV just mandates a particular set of validation requirements. In theory we are supposed to have extra code to check that a certificate really was subject to extended validation before showing the contents of this field. In practice either bitcoinj nor Bitcoin Core actually do, they just always trust it. It'd be nice to fix that in future. I agree that blindly showing the O field may not be ideal - there *may* conceivably be some CAs that include it without validation on their cheap certs (although most cheap certs simply don't include it). But it's not clear that EV or not is the right criterion here - there are certainly non-EV certs out there that are organisation validated. You should show the organisation data instead of the domain name if you find it, for EV certs. I have really mixed feelings about giving this privileged treatment exclusively to EV certs, for the simple reason that the rules around EV certs are iniquitous and some businesses are excluded. e.g. in the UK sole traders (that is, unincorporated businesses) can't get EV certs because the UK doesn't maintain a trade register of such businesses and therefore such businesses are incapable of satisfying the EV rules. That said, EV certs are here, now, and (sadly) supporting them is better than doing nothing... roy -- 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 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
It will also be important to chose the currency symbol for bits at the same time. Lowercase stroke b I think is the obvious choice. Unicode U+0180 Aaron On Friday, May 2, 2014, Alan Reiner etothe...@gmail.com wrote: I've been a strong supporter of the 1e-6 unit switch since the beginning and ready to do whatever I can with Armory to help ease that transition. I'm happy to prioritize a release that updates the Armory interface to make bits the default unit, when the time is right. I think it makes sense to get as many apps and services to upgrade nearly simultaneously. My plan is to have a popup on the first load of the new version that briefly introduces the change, and mentions that they can go back to the old way in the settings, but make them work to do it. For the transient period (6 months?) all input boxes will auto-update nearby labels with the converted-to-BTC value as they type, so that they don't have to do any math in their head. Similarly, all displayed BTC values will show both. But the 1e-6 unit will always be default or first unless they explicitly change it in the interface. On 5/2/2014 8:54 PM, Ben Davenport wrote: 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.comjavascript:_e(%7B%7D,'cvml','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.netjavascript:_e(%7B%7D,'cvml','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 listbitcoin-developm...@lists.sourceforge.net javascript:_e(%7B%7D,'cvml','Bitcoin-development@lists.sourceforge.net');https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers -- 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] bits: Unit of account
[resend - apologies if duplicate] Microbitcoin is a good-sized unit, workable for everyday transaction values, with room-to-grow, and a nice relationship to satoshis as 'cents'. But bits has problems as a unit name. Bits will be especially problematic whenever people try to graduate from informal use to understanding the system internals - that is, when the real bits of key sizes, hash sizes, and storage/bandwidth needs become important. The bit as binary digit was important enough that Satoshi named the system after it; that homage gets lost if the word is muddied with a new retconned meaning that's quite different. Some examples of possible problems: * If bit equals 100 satoshis, then the natural-language unpacking of bit-coin is 100 satoshi coin, which runs against all prior usage. * If people are informed that a 256-bit private key is what ultimately controls their balances, it could prompt confusion like, if each key has 256-bits, will I need 40 keys to hold 10,000.00 bits? * When people learn that there are 8 bits to a byte, they may think, OK, my wallet holding my 80,000.00 bits will then take up 10 kilobytes. * When people naturally extend bit into kilobits to mean 1000 bits, then the new coinage kilobits will mean the exact same amount (100,000 satoshi) as many have already been calling millibits. I believe it'd be best to pick a new made-up single-syllable word as a synonym for microbitcoin, and I've laid out the case for zib as that word at http://zibcoin.org. 'Zib' also lends itself to an expressive unicode symbol, 'Ƶ' (Z-with-stroke), that remains distinctive even if it loses its stroke or gets case-reversed. (Comparatively, all 'b'-derived symbols for data-bits, bitcoins, or '100 satoshi bits' risk collision in contexts where subtleties of casing/stroking are lost.) (There's summary of more problems with bit in the zibcoin.org FAQ at: http://zibcoin.org/faq#why-not-bits-to-mean-microbitcoins.) - Gordon On 5/1/14, 3:35 PM, Aaron Voisine wrote: I'm also a big fan of standardizing on microBTC as the standard unit. I didn't like the name bits at first, but the more I think about it, the more I like it. The main thing going for it is the fact that it's part of the name bitcoin. If Bitcoin is the protocol and network, bits are an obvious choice for the currency unit. I would like to propose using Unicode character U+0180, lowercase b with stroke, as the symbol to represent the microBTC denomination, whether we call bits or something else: http://www.fileformat.info/info/unicode/char/0180/index.htm Another candidate is Unicode character U+2422, the blank symbol, but I prefer stroke b. http://www.fileformat.info/info/unicode/char/2422/index.htm Aaron There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers On Apr 21, 2014 5:41 AM, Pieter Wuille pieter.wuille@gm... wrote: On Apr 21, 2014 3:37 AM, Un Ix slashdevnull@... wrote: Something tells me this would be reduced to a single syllable in common usage I.e. bit. What units will be called colloquially is not something developers will determine. It will vary, depend on language and culture, and is not relevant to this discussion in my opinion. It may well be that people in some geographic or language area will end up (or for a while) calling 1e-06 BTC bits. That's fine, but using that as official name in software would be very strange and potentially confusing in my opinion. As mentioned by others, that would seem to me like calling dollars bucks in bank software. Nobody seems to have a problem with having colloquial names, but US dollar or euro are far less ambiguous than bit. I think we need a more distinctive name. -- Pieter -- 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
I live in Argentina. Here, 1BTC is around half of a monthly average wage (net), so, as you can imagine, the value of 1 BTC is *very* inconvenient for everyday transactions. Also it presents an important entry barrier for new adopters: It would be easier to accept buying thousands of bits than buying a tiny fraction of a Bitcoin, for the same amount of pesos. Changing to 1e-6 bits will solve both problems. Changing to 1e-6 microbitcoins will solve the first one, but not sure about the second one. Buying (or earning) mili or micro something isn't that sexy either. Finally, against micro and in favor of bits, micro is noted μ, which is also inconvenient (I had to copy and paste it from an other site). Many different notations will be used like: μBTC, uBTC, microBTC and even mBTC. Please prevent that. These arguments also applies to many places in the world (Argentina is 40 out of 72 listed countries in http://en.wikipedia.org/wiki/List_of_countries_by_average_wage). matías On Fri, May 2, 2014 at 10:13 PM, Alan Reiner etothe...@gmail.com wrote: I've been a strong supporter of the 1e-6 unit switch since the beginning and ready to do whatever I can with Armory to help ease that transition. I'm happy to prioritize a release that updates the Armory interface to make bits the default unit, when the time is right. I think it makes sense to get as many apps and services to upgrade nearly simultaneously. My plan is to have a popup on the first load of the new version that briefly introduces the change, and mentions that they can go back to the old way in the settings, but make them work to do it. For the transient period (6 months?) all input boxes will auto-update nearby labels with the converted-to-BTC value as they type, so that they don't have to do any math in their head. Similarly, all displayed BTC values will show both. But the 1e-6 unit will always be default or first unless they explicitly change it in the interface. On 5/2/2014 8:54 PM, Ben Davenport wrote: 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 -- 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 -- Matías Alejo
Re: [Bitcoin-development] moving the default display to mbtc
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
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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Huh? Your examples demonstrate the *opposite* of your point. 'k' and 'M' *are* the SI prefixes. People *do* use 63k USD, $63k, and $3M. Excellent point. Also, I frequently hear statements referring to mili-bitcoins, mBTC, pronounced as mili-bits or m-bits; the term bits is very much already in use and not to refer to uBTC. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQFQBAEBCAA6BQJTZFfuMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhRSfB/434bom68YyzgW0rPek wrkjBHtxK7BgrPvkpMsBpAIWQ+NbKZBNTIZfp78rbUlGdj+3mXc5e+QXSnKHJn6V azUtn4PsvL/iNAIZ91vdMYKRvFkAPfS+XBxR0J3JiAzQb6dshyUm9X6UQyJHGs8O EOS2sQ/c2ZY6hFVE5JfA3jH8ykQy36MNfehbT290kppkcRq24JAVLYz66444CHA1 iMHCfnlcR9hMUVQmzds4QLIPHLLjEqkMxJUe5yxFVeW0MFxu2sG3jfYcOwoqQbBY N+hLHOKuH5mOm6mfJ3/IHVj2dM9jok+JKG0GytZA1kKGbh/KGIhxIxE/06dNakfW QzfS =666/ -END PGP SIGNATURE- -- 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
Think your example is not quite valid ... People say or write $88M or $45k I.e. use SI prefix as a suffix, else it would be more, not less, clear on what amount is being referred to. For me, bits are easy to say and one million as a factor is simple to understand. M-bits, kilobits, millibits, etc are never going to be used by folk in everyday transactions, IMHO Gavin On 3/05/2014, at 10:40 am, 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 -- 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
Excellent move Jeff. Best would now be to establish XBT as the ISO code for bits. Regards, Tamas Blummer http://bitsofproof.com On 02.05.2014, at 21:17, 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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] bits: Unit of account
I have to agree with Mike. Human language is surprisingly tolerant of overloading and inference from context. Neurotypical people have no problem with it and perceive a software engineer's aversion to it as being pedantic and strange. Note that bits was a term for a unit of money long before the invention of digital computers. Aaron There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers On Fri, May 2, 2014 at 7:06 PM, Gordon Mohr goj...@gmail.com wrote: [resend - apologies if duplicate] Microbitcoin is a good-sized unit, workable for everyday transaction values, with room-to-grow, and a nice relationship to satoshis as 'cents'. But bits has problems as a unit name. Bits will be especially problematic whenever people try to graduate from informal use to understanding the system internals - that is, when the real bits of key sizes, hash sizes, and storage/bandwidth needs become important. The bit as binary digit was important enough that Satoshi named the system after it; that homage gets lost if the word is muddied with a new retconned meaning that's quite different. Some examples of possible problems: * If bit equals 100 satoshis, then the natural-language unpacking of bit-coin is 100 satoshi coin, which runs against all prior usage. * If people are informed that a 256-bit private key is what ultimately controls their balances, it could prompt confusion like, if each key has 256-bits, will I need 40 keys to hold 10,000.00 bits? * When people learn that there are 8 bits to a byte, they may think, OK, my wallet holding my 80,000.00 bits will then take up 10 kilobytes. * When people naturally extend bit into kilobits to mean 1000 bits, then the new coinage kilobits will mean the exact same amount (100,000 satoshi) as many have already been calling millibits. I believe it'd be best to pick a new made-up single-syllable word as a synonym for microbitcoin, and I've laid out the case for zib as that word at http://zibcoin.org. 'Zib' also lends itself to an expressive unicode symbol, 'Ƶ' (Z-with-stroke), that remains distinctive even if it loses its stroke or gets case-reversed. (Comparatively, all 'b'-derived symbols for data-bits, bitcoins, or '100 satoshi bits' risk collision in contexts where subtleties of casing/stroking are lost.) (There's summary of more problems with bit in the zibcoin.org FAQ at: http://zibcoin.org/faq#why-not-bits-to-mean-microbitcoins.) - Gordon On 5/1/14, 3:35 PM, Aaron Voisine wrote: I'm also a big fan of standardizing on microBTC as the standard unit. I didn't like the name bits at first, but the more I think about it, the more I like it. The main thing going for it is the fact that it's part of the name bitcoin. If Bitcoin is the protocol and network, bits are an obvious choice for the currency unit. I would like to propose using Unicode character U+0180, lowercase b with stroke, as the symbol to represent the microBTC denomination, whether we call bits or something else: http://www.fileformat.info/info/unicode/char/0180/index.htm Another candidate is Unicode character U+2422, the blank symbol, but I prefer stroke b. http://www.fileformat.info/info/unicode/char/2422/index.htm Aaron There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers On Apr 21, 2014 5:41 AM, Pieter Wuille pieter.wuille@gm... wrote: On Apr 21, 2014 3:37 AM, Un Ix slashdevnull@... wrote: Something tells me this would be reduced to a single syllable in common usage I.e. bit. What units will be called colloquially is not something developers will determine. It will vary, depend on language and culture, and is not relevant to this discussion in my opinion. It may well be that people in some geographic or language area will end up (or for a while) calling 1e-06 BTC bits. That's fine, but using that as official name in software would be very strange and potentially confusing in my opinion. As mentioned by others, that would seem to me like calling dollars bucks in bank software. Nobody seems to have a problem with having colloquial names, but US dollar or euro are far less ambiguous than bit. I think we need a more distinctive name. -- Pieter -- 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
