Re: [Bitcoin-development] moving the default display to mbtc
the SI prefixes. People *do* use 63k USD, $63k, and $3M. I'll be the first one As a counter argument, many sources (including the BBC) abbreviate million to 'm' (and billion to 'bn'), e.g. $3m, $3bn. I think any similarity with SI units here is coincidental. 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] bits: Unit of account
Context as a disambiguator works fine when the interlocutors understand the topics they're talking about. Not a day goes by without me seeing neurotypical people get horribly confused between RAM and Hard Drive sizes, because they share the same units (not that that can be helped, as the units are supposed to be the same, base 1000 vs 1024 notwithstanding). Bit (as a unit) is already really confusing for anyone who doesn't deal with it on a regular basis. I think people who don't see an issue are making an assumption based on their own lack of confusion. We understand computer science AND Bitcoin. Most people have zero understanding of either. Bitcoin already has a ton of issues with terrible names for things: - Mining (for transaction validation). - Addresses (which are meant to be one-time use, and don't even really exist at the network level). - Wallets (which don't hold your bitcoins, can be copied, and all backups can be stolen from equally). I end up having to make the distinctions obvious every time I explain Bitcoin to someone new to it. There's an acceptable tradeoff here, because there were arguably no better words to assign to these concepts (although I'd argue mining is a really awful metaphor, and is the one that prompts the most questions from people). Then add to the pile a bunch of third parties naming themselves after parts of the protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've definitiely seen average people get confused between the blockchain and blockchain.info (not so much Coinbase, because that name doesn't come up in beginner explanations). It seems downright masochistic to add yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile for no reason other than aesthetics. Are we actively trying to confuse people? On Sat, May 3, 2014 at 1:41 AM, Aaron Voisine vois...@gmail.com wrote: 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:
Re: [Bitcoin-development] bits: Unit of account
Excellent points Christophe! Although moving to 1e-6 units is fine for me and I see advantages of doing this, I don't get that people on this mailing list are fine with calling such unit bit. It's geeky as hell, ambiguous and confusing. slush On Sat, May 3, 2014 at 5:48 PM, Christophe Biocca christophe.bio...@gmail.com wrote: Context as a disambiguator works fine when the interlocutors understand the topics they're talking about. Not a day goes by without me seeing neurotypical people get horribly confused between RAM and Hard Drive sizes, because they share the same units (not that that can be helped, as the units are supposed to be the same, base 1000 vs 1024 notwithstanding). Bit (as a unit) is already really confusing for anyone who doesn't deal with it on a regular basis. I think people who don't see an issue are making an assumption based on their own lack of confusion. We understand computer science AND Bitcoin. Most people have zero understanding of either. Bitcoin already has a ton of issues with terrible names for things: - Mining (for transaction validation). - Addresses (which are meant to be one-time use, and don't even really exist at the network level). - Wallets (which don't hold your bitcoins, can be copied, and all backups can be stolen from equally). I end up having to make the distinctions obvious every time I explain Bitcoin to someone new to it. There's an acceptable tradeoff here, because there were arguably no better words to assign to these concepts (although I'd argue mining is a really awful metaphor, and is the one that prompts the most questions from people). Then add to the pile a bunch of third parties naming themselves after parts of the protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've definitiely seen average people get confused between the blockchain and blockchain.info (not so much Coinbase, because that name doesn't come up in beginner explanations). It seems downright masochistic to add yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile for no reason other than aesthetics. Are we actively trying to confuse people? On Sat, May 3, 2014 at 1:41 AM, Aaron Voisine vois...@gmail.com wrote: 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
Re: [Bitcoin-development] bits: Unit of account
bit has a lot of meanings to geeks, so what. bit means for average people: - something very small, that 100 satoshi is. - part of the name Bitcoin - easy to get conversion 1 coin = 1 million bits = 1 Bitcoin Regards, Tamas Blummer Founder, CEO http://bitsofproof.com On 03.05.2014, at 18:02, slush sl...@centrum.cz wrote: Excellent points Christophe! Although moving to 1e-6 units is fine for me and I see advantages of doing this, I don't get that people on this mailing list are fine with calling such unit bit. It's geeky as hell, ambiguous and confusing. slush On Sat, May 3, 2014 at 5:48 PM, Christophe Biocca christophe.bio...@gmail.com wrote: Context as a disambiguator works fine when the interlocutors understand the topics they're talking about. Not a day goes by without me seeing neurotypical people get horribly confused between RAM and Hard Drive sizes, because they share the same units (not that that can be helped, as the units are supposed to be the same, base 1000 vs 1024 notwithstanding). Bit (as a unit) is already really confusing for anyone who doesn't deal with it on a regular basis. I think people who don't see an issue are making an assumption based on their own lack of confusion. We understand computer science AND Bitcoin. Most people have zero understanding of either. Bitcoin already has a ton of issues with terrible names for things: - Mining (for transaction validation). - Addresses (which are meant to be one-time use, and don't even really exist at the network level). - Wallets (which don't hold your bitcoins, can be copied, and all backups can be stolen from equally). I end up having to make the distinctions obvious every time I explain Bitcoin to someone new to it. There's an acceptable tradeoff here, because there were arguably no better words to assign to these concepts (although I'd argue mining is a really awful metaphor, and is the one that prompts the most questions from people). Then add to the pile a bunch of third parties naming themselves after parts of the protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've definitiely seen average people get confused between the blockchain and blockchain.info (not so much Coinbase, because that name doesn't come up in beginner explanations). It seems downright masochistic to add yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile for no reason other than aesthetics. Are we actively trying to confuse people? On Sat, May 3, 2014 at 1:41 AM, Aaron Voisine vois...@gmail.com wrote: 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
Re: [Bitcoin-development] bits: Unit of account
I agree with the sentiment that most people don't understand either computer science or Bitcoin. The goal of getting people to understand enough about Bitcoin to use it is achievable and a goal that is in scope of our efforts. Getting them to understand computer science at large at the same time, less so. The fact that people routinely confuse RAM and hard drive sizes has much to do with the fact that the average lay person has little need to prioritize this as something to keep in the forefront. They don't get horribly confused, they just simply don't get worked up over what looks to them like a rounding error, much to the dismay of anyone who believes that everyone should be an expert at computer science. The average joe may assess (accurately from his perspective) that the distinction isn't important enough to merit significant mental resources and he is justified in not expending them that way even if someone else thinks he should. Poor understanding is precisely what a proper effort to name this would be to avoid. It is not frill or aesthetics, it is a planned targeting of language to achieve the clearest communication to the widest possible target audience using the language most likely to be understood by them in light of our objectives. It's marketing. Mike Sent from my iPhone On May 3, 2014, at 9:49 AM, Christophe Biocca christophe.bio...@gmail.com wrote: Context as a disambiguator works fine when the interlocutors understand the topics they're talking about. Not a day goes by without me seeing neurotypical people get horribly confused between RAM and Hard Drive sizes, because they share the same units (not that that can be helped, as the units are supposed to be the same, base 1000 vs 1024 notwithstanding). Bit (as a unit) is already really confusing for anyone who doesn't deal with it on a regular basis. I think people who don't see an issue are making an assumption based on their own lack of confusion. We understand computer science AND Bitcoin. Most people have zero understanding of either. Bitcoin already has a ton of issues with terrible names for things: - Mining (for transaction validation). - Addresses (which are meant to be one-time use, and don't even really exist at the network level). - Wallets (which don't hold your bitcoins, can be copied, and all backups can be stolen from equally). I end up having to make the distinctions obvious every time I explain Bitcoin to someone new to it. There's an acceptable tradeoff here, because there were arguably no better words to assign to these concepts (although I'd argue mining is a really awful metaphor, and is the one that prompts the most questions from people). Then add to the pile a bunch of third parties naming themselves after parts of the protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've definitiely seen average people get confused between the blockchain and blockchain.info (not so much Coinbase, because that name doesn't come up in beginner explanations). It seems downright masochistic to add yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile for no reason other than aesthetics. Are we actively trying to confuse people? -- 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
[Bitcoin-development] Bug with handing of OP_RETURN?
Can someone enlighten me on why the following transaction is being rejected
by Bitcoind 0.9.1 with error code -22 on Mainnet.
0100015594a8c1f84b926e84d70c3a3d5e517e0c12dc07cb1a774b587121fef08f91b86b48304502202f534407f6dee4d8932ec22491cbc15a2d31af2bade4e8d417e4b1955de57f5902210086e2f0210c169b85074429b1b1c2f32e19509d7ed19f7804ab7212bd183a012102add59262e234c0045d1f6a3d40a144b47ea0b4214916f55fb6029a079cc0b3cb0358021976a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac0a6a054f4101000102753d60861976a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac
Debug.log shows the following:
ERROR: AcceptToMemoryPool : nonstandard transaction: scriptpubkey
Here is the decoded transaction:
{
lock_time:0,
inputs:[
{
prev_out:{
index:0,
hash:b8918ff0fe2171584b771acb07dc120c7e515e3d3a0cd7846e924bf8c1a89455
},
script:48304502202f534407f6dee4d8932ec22491cbc15a2d31af2bade4e8d417e4b1955de57f5902210086e2f0210c169b85074429b1b1c2f32e19509d7ed19f7804ab7212bd183a012102add59262e234c0045d1f6a3d40a144b47ea0b4214916f55fb6029a079cc0b3cb
}
],
vout_sz:3,
hash:44130e812fa15f411c6accb739082eb81ecf074470cefb8e617ecf105690f6e1,
vin_sz:1,
out:[
{
address:12QkihKUyE1hAkv7wmaMj6V3QiN8FfMvpv,
script_string:OP_DUP OP_HASH160
0f763005e063382f8f4138f75cdc64d14f8ec16f OP_EQUALVERIFY OP_CHECKSIG,
value:600,
script:76a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac
},
{
script_string:OP_RETURN 4f41010001 753d,
value:0,
script:6a054f4101000102753d
},
{
address:12QkihKUyE1hAkv7wmaMj6V3QiN8FfMvpv,
script_string:OP_DUP OP_HASH160
0f763005e063382f8f4138f75cdc64d14f8ec16f OP_EQUALVERIFY OP_CHECKSIG,
value:34400,
script:76a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac
}
],
size:245,
version:1
}
Outputs are above dust, inputs are not spent. OP_RETURN is supposed to be
standard in 0.9.1 and the data is well below 40 bytes, so why is this being
rejected?
Thanks,
Flavien
--
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] Bug with handing of OP_RETURN?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The standard format ended up being exactly:
OP_RETURN 0 to 40-byte PUSHDATA
You've split the data across two PUSHDATA's. The standard should have let the
data be split up like that; pull requests accepted.
On 3 May 2014 13:04:52 GMT-05:00, Flavien Charlon
flavien.char...@coinprism.com wrote:
Can someone enlighten me on why the following transaction is being
rejected
by Bitcoind 0.9.1 with error code -22 on Mainnet.
0100015594a8c1f84b926e84d70c3a3d5e517e0c12dc07cb1a774b587121fef08f91b86b48304502202f534407f6dee4d8932ec22491cbc15a2d31af2bade4e8d417e4b1955de57f5902210086e2f0210c169b85074429b1b1c2f32e19509d7ed19f7804ab7212bd183a012102add59262e234c0045d1f6a3d40a144b47ea0b4214916f55fb6029a079cc0b3cb0358021976a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac0a6a054f4101000102753d60861976a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac
Debug.log shows the following:
ERROR: AcceptToMemoryPool : nonstandard transaction: scriptpubkey
Here is the decoded transaction:
{
lock_time:0,
inputs:[
{
prev_out:{
index:0,
hash:b8918ff0fe2171584b771acb07dc120c7e515e3d3a0cd7846e924bf8c1a89455
},
script:48304502202f534407f6dee4d8932ec22491cbc15a2d31af2bade4e8d417e4b1955de57f5902210086e2f0210c169b85074429b1b1c2f32e19509d7ed19f7804ab7212bd183a012102add59262e234c0045d1f6a3d40a144b47ea0b4214916f55fb6029a079cc0b3cb
}
],
vout_sz:3,
hash:44130e812fa15f411c6accb739082eb81ecf074470cefb8e617ecf105690f6e1,
vin_sz:1,
out:[
{
address:12QkihKUyE1hAkv7wmaMj6V3QiN8FfMvpv,
script_string:OP_DUP OP_HASH160
0f763005e063382f8f4138f75cdc64d14f8ec16f OP_EQUALVERIFY OP_CHECKSIG,
value:600,
script:76a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac
},
{
script_string:OP_RETURN 4f41010001 753d,
value:0,
script:6a054f4101000102753d
},
{
address:12QkihKUyE1hAkv7wmaMj6V3QiN8FfMvpv,
script_string:OP_DUP OP_HASH160
0f763005e063382f8f4138f75cdc64d14f8ec16f OP_EQUALVERIFY OP_CHECKSIG,
value:34400,
script:76a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac
}
],
size:245,
version:1
}
Outputs are above dust, inputs are not spent. OP_RETURN is supposed to
be
standard in 0.9.1 and the data is well below 40 bytes, so why is this
being
rejected?
Thanks,
Flavien
--
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
-BEGIN PGP SIGNATURE-
Version: APG v1.1.1
iQFQBAEBCAA6BQJTZTfsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhQHmCADIcIs8w0FCDslGpbg1
audI1fAg/XnZ2J/862egYLtV2P0ooQnQz6g4kA0YIQGJI5tqyr9NEB6q/FVeKT61
3ecs3YsRtUkXmum6Wnq7QUGjvyMQo5nwLx2b3kDYEvb9v+aAKoBNKdz1xmp7jxE3
6bCx9eBeRBmhDWp1Xrr3VQI7KEUx4BfUxaLioYnCvaSuPsU+QQfXPFc+9ypRRclc
ymAj0VRGRPe2LQMNjerG4DMH8MRd5LOXjUxYV3XO3LyKSKvM18Lte+16w/uU3uBV
msIMbWEgm/DXI5fLWL7MFuLIsFrPs9BzjZSSZA7zQvntLtlQWCMnGeXsozjK14ol
lUl8
=0kuQ
-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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.05.2014 02:54, Ben Davenport wrote: 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. As you said, that's in the US, and I strongly suspect the sole reason is that in the US the currency symbol is written in front of the amount. I often pronounce $10k as ten kilodollar, using it exactly like a SI-prefix. The much better argument against SI prefixes is that the prefixes for values less than 1 tend to be much less well known: Most people know that kilo means 1000, many know that mega means 1,000,000, but few know that micro means 0.001, and those that do tend to confuse micro and nano. Jannis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIbBAEBAgAGBQJTZTmNAAoJEBrvn3PsoRcmrzYP9R0cch42wV+I21MNVbWEEhfw GjuCqE2Vz7QtI4nhRZ0Eas+MOY6iZD1c2A7cr4BjWx+MdQQwJSMKg/UKruE3j9xs 4QAFQtjvQ69Yd5ztq3ISWM/DpGfPXRvRdIf02ldz0Sf4HMxvqHCcYov3/laOrFnF 3ECpd+JLrU/Wq/HWwuFFXbfyQnpn+9LHx5gcfhV/pW7PwAjwzeaKhY1neQRHhQWq pD8iv2dikqs30nO6bhnrCv/u0N+2iwV4e+J0E+kpBwrCZLeG8MirRRdnLruJ5mnT nGyRNdfPKl5n0Gm4AFkBC3a4VIYwOxAzxdfA55Hn27yxll0GFEQNqR9OCNblGUbQ RWa3Nywa22aYHOTi7evmuP6dVFjF4T8dl8LzDBmeawBsbOeHAUYJgLoHezdwEoto Dt01ML4CmCINnPIFiuab17gpUYg7OXKomOQPrdyaVnP2abgvQCV5bYhMnKKVa25U mW5PK02stxKcTEyHBsz0BG8zmdx5+7A5ySaUHrXs+l3YNBp3idlDUeYIsEBKFAtR vNEGLbV2ZvteOb+tflxuPSjgIaMHD9w6vX2l7+VgkRTms743s/wbQuLb2fXq7osM zws5D/L74zG1ZwsNM04Ygs2GJoJhkb1QXxY9EuoIeiuK3nVeJEWeRGHBEmqCXOPx FB/2U/d69fUTbvUzOXA= =Qo8z -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] Bug with handing of OP_RETURN?
I don't think such a pull request would be accepted. The point was to minimize impact to the block chain. Each extras txout adds 9 bytes minimum, with zero benefit over serializing the data together in a single OP_RETURN. On 05/03/2014 11:39 AM, Peter Todd wrote: The standard format ended up being exactly: OP_RETURN 0 to 40-byte PUSHDATA You've split the data across two PUSHDATA's. The standard should have let the data be split up like that; pull requests accepted. -- 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] Bug with handing of OP_RETURN?
On Sat, May 3, 2014 at 11:55 AM, Mark Friedenbach m...@monetize.io wrote: I don't think such a pull request would be accepted. The point was to minimize impact to the block chain. Each extras txout adds 9 bytes minimum, with zero benefit over serializing the data together in a single OP_RETURN. In this case it's not a question extra txouts, its a question of additional pushes. Assuming you didn't get the push overhead for free, the only issue I see with that off the cuff is extra complexity in the IsStandard rule... but really, why? Your application already needs to define the meaning of the data— what point is there in making your hash commitment less uniform with the rest of the network? -- 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] Bug with handing of OP_RETURN?
Is it more complex? The current implementation using template matching seems more complex than `if script.vch[0] == OP_RETURN script.vch.size() 42` On 05/03/2014 12:08 PM, Gregory Maxwell wrote: On Sat, May 3, 2014 at 11:55 AM, Mark Friedenbach m...@monetize.io wrote: I don't think such a pull request would be accepted. The point was to minimize impact to the block chain. Each extras txout adds 9 bytes minimum, with zero benefit over serializing the data together in a single OP_RETURN. In this case it's not a question extra txouts, its a question of additional pushes. Assuming you didn't get the push overhead for free, the only issue I see with that off the cuff is extra complexity in the IsStandard rule... but really, why? Your application already needs to define the meaning of the data— what point is there in making your hash commitment less uniform with the rest of the network? -- 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
[Bitcoin-development] A statistical consensus rule for reducing 0-conf double-spend risk
This idea was suggested by Joe on 2011-02-14 https://bitcointalk.org/index.php?topic=3441.msg48484#msg48484 . It deserves another look. Nodes today make a judgment regarding which of several conflicting spends to accept, and which is a double-spend. But there is no incorporation of these collective judgments into the blockchain. So today, it's the wild west, right up until the next block. To address this: - Using its own clock, node associates a timestamp with every transaction upon first seeing its tx hash (at inv, in a block, or when created) - Node relays respend attempts (subject to anti-DOS rules, see github PR #3883) - Eventually, node adds a consensus rule: Do not accept blocks containing a transaction tx2 where - tx2 respends an output spent by another locally accepted transaction tx1, and - timestamp(tx2) - timestamp(tx1) T What is T? According to http://bitcoinstats.com/network/propagation/ recent tx propagation has a median of 1.3 seconds. If double-spender introduces both transactions from the same node, assuming propagation times distributed exponentially with median 1.3 seconds, the above consensus rule with reject threshold T = 7.4 seconds would result in mis-identification of the second-spend by less than 1% of nodes.* If tx1 and tx2 are introduced in mutually time-distant parts of the network, a population of nodes in between would be able to accept either transaction, as they can today. But the attacker still has to introduce them at close to the same time, or the majority of the network will confirm the one introduced earlier. Merchant is watching also, and these dynamics mean he will not have to watch for very long to gain confidence if he was going to get double-spent, he would have learned it by now. The consensus rule also makes mining a never-broadcast double-spend quite difficult, because the network assigns it very late timestamps. Miner has to get lucky and find the block very quickly. In other words, it converges to a Finney attack. This would be the first consensus rule that anticipated less than 100% agreement. But the parameters could be chosen so that it was still extremely conservative. Joe also suggested a fail-safe condition: drop this rule if block has 6 confirmations, to prevent a fork in unusual network circumstances. We can't move toward this, or any, solution without more data. Today, the network is not transparent to double-spend attempts, so we mostly have to guess what the quantitative effects would be. The first step is to share the data broadly by relaying first double-spend attempts as in github PR #3883. *Calcs: For Exp(lambda), median ln(2)/lambda = 1.3 == lambda = .533 Laplace(0,1/lambda) .01 == T = 7.34 seconds -- 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
Absent a concerted effort to move to something else other than 'bits', I would be willing to bet the nomenclature moves in that direction anyway. 'Bits' is just a shorten word for 'millibits' (or microbits, if you will). It's easier to say and my guess is people would tend to use it naturally own their own. Kind of like 'bucks' for dollars. The other synergies are: -bit is part of the word Bitcoin. The currency unit bit is part of a whole bitcoin. -bit symbolically represents the tech nature of the bitcoin. -bit used to be a unit of money way back when. This largely reclaims it. -when used as money bit when in references to a precession metal coin. The name 'bitcoin' references that as well as the mimicking of the gold standard in the protocol rules. All around I don't think there is a better fit. I doubt people will get confused by it. The context it's used in will distinguish it from other uses of the word. On 05/03/2014 12:27 PM, Mike Caldwell wrote: I agree with the sentiment that most people don't understand either computer science or Bitcoin. The goal of getting people to understand enough about Bitcoin to use it is achievable and a goal that is in scope of our efforts. Getting them to understand computer science at large at the same time, less so. The fact that people routinely confuse RAM and hard drive sizes has much to do with the fact that the average lay person has little need to prioritize this as something to keep in the forefront. They don't get horribly confused, they just simply don't get worked up over what looks to them like a rounding error, much to the dismay of anyone who believes that everyone should be an expert at computer science. The average joe may assess (accurately from his perspective) that the distinction isn't important enough to merit significant mental resources and he is justified in not expending them that way even if someone else thinks he should. Poor understanding is precisely what a proper effort to name this would be to avoid. It is not frill or aesthetics, it is a planned targeting of language to achieve the clearest communication to the widest possible target audience using the language most likely to be understood by them in light of our objectives. It's marketing. Mike Sent from my iPhone On May 3, 2014, at 9:49 AM, Christophe Biocca christophe.bio...@gmail.com wrote: Context as a disambiguator works fine when the interlocutors understand the topics they're talking about. Not a day goes by without me seeing neurotypical people get horribly confused between RAM and Hard Drive sizes, because they share the same units (not that that can be helped, as the units are supposed to be the same, base 1000 vs 1024 notwithstanding). Bit (as a unit) is already really confusing for anyone who doesn't deal with it on a regular basis. I think people who don't see an issue are making an assumption based on their own lack of confusion. We understand computer science AND Bitcoin. Most people have zero understanding of either. Bitcoin already has a ton of issues with terrible names for things: - Mining (for transaction validation). - Addresses (which are meant to be one-time use, and don't even really exist at the network level). - Wallets (which don't hold your bitcoins, can be copied, and all backups can be stolen from equally). I end up having to make the distinctions obvious every time I explain Bitcoin to someone new to it. There's an acceptable tradeoff here, because there were arguably no better words to assign to these concepts (although I'd argue mining is a really awful metaphor, and is the one that prompts the most questions from people). Then add to the pile a bunch of third parties naming themselves after parts of the protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've definitiely seen average people get confused between the blockchain and blockchain.info (not so much Coinbase, because that name doesn't come up in beginner explanations). It seems downright masochistic to add yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile for no reason other than aesthetics. Are we actively trying to confuse people? -- 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
[Bitcoin-development] (no subject)
losew...@gmail.com losew...@gmail.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] A statistical consensus rule for reducing 0-conf double-spend risk
Unfortunately this could fork the network permanently, which is much worse than a double spend. There's no magic way to have a consensus, so it becomes trivial with a few tries to split the network into two halves: (tx1 before tx2, tx2 before tx1). Some nodes in the middle will accept either block, but you've still forked off some non-zero number of nodes. At a minimum, you'd need a way to reconcile the split (Accept the offending block once it's 2+ deep). The problem is that since the rule isn't enforceable, no miner will wait before mining on the longest chain (which is the rational move), and you're back to where we are now. On Sat, May 3, 2014 at 8:29 PM, Tom Harding t...@thinlink.com wrote: This idea was suggested by Joe on 2011-02-14 https://bitcointalk.org/index.php?topic=3441.msg48484#msg48484 . It deserves another look. Nodes today make a judgment regarding which of several conflicting spends to accept, and which is a double-spend. But there is no incorporation of these collective judgments into the blockchain. So today, it's the wild west, right up until the next block. To address this: - Using its own clock, node associates a timestamp with every transaction upon first seeing its tx hash (at inv, in a block, or when created) - Node relays respend attempts (subject to anti-DOS rules, see github PR #3883) - Eventually, node adds a consensus rule: Do not accept blocks containing a transaction tx2 where - tx2 respends an output spent by another locally accepted transaction tx1, and - timestamp(tx2) - timestamp(tx1) T What is T? According to http://bitcoinstats.com/network/propagation/ recent tx propagation has a median of 1.3 seconds. If double-spender introduces both transactions from the same node, assuming propagation times distributed exponentially with median 1.3 seconds, the above consensus rule with reject threshold T = 7.4 seconds would result in mis-identification of the second-spend by less than 1% of nodes.* If tx1 and tx2 are introduced in mutually time-distant parts of the network, a population of nodes in between would be able to accept either transaction, as they can today. But the attacker still has to introduce them at close to the same time, or the majority of the network will confirm the one introduced earlier. Merchant is watching also, and these dynamics mean he will not have to watch for very long to gain confidence if he was going to get double-spent, he would have learned it by now. The consensus rule also makes mining a never-broadcast double-spend quite difficult, because the network assigns it very late timestamps. Miner has to get lucky and find the block very quickly. In other words, it converges to a Finney attack. This would be the first consensus rule that anticipated less than 100% agreement. But the parameters could be chosen so that it was still extremely conservative. Joe also suggested a fail-safe condition: drop this rule if block has 6 confirmations, to prevent a fork in unusual network circumstances. We can't move toward this, or any, solution without more data. Today, the network is not transparent to double-spend attempts, so we mostly have to guess what the quantitative effects would be. The first step is to share the data broadly by relaying first double-spend attempts as in github PR #3883. *Calcs: For Exp(lambda), median ln(2)/lambda = 1.3 == lambda = .533 Laplace(0,1/lambda) .01 == T = 7.34 seconds -- 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] Bug with handing of OP_RETURN?
On Sat, May 3, 2014 at 2:04 PM, Flavien Charlon flavien.char...@coinprism.com wrote: Outputs are above dust, inputs are not spent. OP_RETURN is supposed to be standard in 0.9.1 and the data is well below 40 bytes, so why is this being rejected? The carried data must all be contained within one pushdata. -- 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] bits: Unit of account
+1 On 4 May 2014 02:06, Chris Pacia ctpa...@gmail.com wrote: Absent a concerted effort to move to something else other than 'bits', I would be willing to bet the nomenclature moves in that direction anyway. 'Bits' is just a shorten word for 'millibits' (or microbits, if you will). It's easier to say and my guess is people would tend to use it naturally own their own. Kind of like 'bucks' for dollars. The other synergies are: -bit is part of the word Bitcoin. The currency unit bit is part of a whole bitcoin. -bit symbolically represents the tech nature of the bitcoin. -bit used to be a unit of money way back when. This largely reclaims it. -when used as money bit when in references to a precession metal coin. The name 'bitcoin' references that as well as the mimicking of the gold standard in the protocol rules. All around I don't think there is a better fit. I doubt people will get confused by it. The context it's used in will distinguish it from other uses of the word. On 05/03/2014 12:27 PM, Mike Caldwell wrote: I agree with the sentiment that most people don't understand either computer science or Bitcoin. The goal of getting people to understand enough about Bitcoin to use it is achievable and a goal that is in scope of our efforts. Getting them to understand computer science at large at the same time, less so. The fact that people routinely confuse RAM and hard drive sizes has much to do with the fact that the average lay person has little need to prioritize this as something to keep in the forefront. They don't get horribly confused, they just simply don't get worked up over what looks to them like a rounding error, much to the dismay of anyone who believes that everyone should be an expert at computer science. The average joe may assess (accurately from his perspective) that the distinction isn't important enough to merit significant mental resources and he is justified in not expending them that way even if someone else thinks he should. Poor understanding is precisely what a proper effort to name this would be to avoid. It is not frill or aesthetics, it is a planned targeting of language to achieve the clearest communication to the widest possible target audience using the language most likely to be understood by them in light of our objectives. It's marketing. Mike Sent from my iPhone On May 3, 2014, at 9:49 AM, Christophe Biocca christophe.bio...@gmail.com wrote: Context as a disambiguator works fine when the interlocutors understand the topics they're talking about. Not a day goes by without me seeing neurotypical people get horribly confused between RAM and Hard Drive sizes, because they share the same units (not that that can be helped, as the units are supposed to be the same, base 1000 vs 1024 notwithstanding). Bit (as a unit) is already really confusing for anyone who doesn't deal with it on a regular basis. I think people who don't see an issue are making an assumption based on their own lack of confusion. We understand computer science AND Bitcoin. Most people have zero understanding of either. Bitcoin already has a ton of issues with terrible names for things: - Mining (for transaction validation). - Addresses (which are meant to be one-time use, and don't even really exist at the network level). - Wallets (which don't hold your bitcoins, can be copied, and all backups can be stolen from equally). I end up having to make the distinctions obvious every time I explain Bitcoin to someone new to it. There's an acceptable tradeoff here, because there were arguably no better words to assign to these concepts (although I'd argue mining is a really awful metaphor, and is the one that prompts the most questions from people). Then add to the pile a bunch of third parties naming themselves after parts of the protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've definitiely seen average people get confused between the blockchain and blockchain.info (not so much Coinbase, because that name doesn't come up in beginner explanations). It seems downright masochistic to add yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile for no reason other than aesthetics. Are we actively trying to confuse people? -- 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
