Re: [Bitcoin-development] "bits": Unit of account

[Tamas Blummer]

Wladimir,

what is missing is a decision to pull for the reference client. 
Or did I missed that bit?


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

[Wladimir]

On Sun, May 4, 2014 at 8:15 AM, Aaron Voisine  wrote:
> Bit by bit, it's become clear that it's a bit much to worry even a
> little bit that overloading the word "bit" would be every bit as bad
> as a two bit horse with the bit between it's teeth that bit the hand
> that feeds it, or a drill bit broken to bits after just a bit of use.

+1 good summary

And I think that's a good conclusion to this discussion about unit
names on the development mailing list. Everything has been said now.

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] "bits": Unit of account

[Un Ix]

+1(bit) for your bit on bits.

> On 4/05/2014, at 2:18 pm, "Aaron Voisine"  wrote:
> 
> Bit by bit, it's become clear that it's a bit much to worry even a
> little bit that overloading the word "bit" would be every bit as bad
> as a two bit horse with the bit between it's teeth that bit the hand
> that feeds it, or a drill bit broken to bits after just a bit of use.
> 
> Aaron
> 
> There's no trick to being a humorist when you have the whole
> government working for you -- Will Rodgers
> 
> 
>> On Sat, May 3, 2014 at 10:18 PM, Drak  wrote:
>> +1
>> 
>>> On 4 May 2014 02:06, "Chris Pacia"  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"
>  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 ex

Re: [Bitcoin-development] "bits": Unit of account

[Aaron Voisine]

Bit by bit, it's become clear that it's a bit much to worry even a
little bit that overloading the word "bit" would be every bit as bad
as a two bit horse with the bit between it's teeth that bit the hand
that feeds it, or a drill bit broken to bits after just a bit of use.

Aaron

There's no trick to being a humorist when you have the whole
government working for you -- Will Rodgers


On Sat, May 3, 2014 at 10:18 PM, Drak  wrote:
> +1
>
> On 4 May 2014 02:06, "Chris Pacia"  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"
>> >>  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

Re: [Bitcoin-development] "bits": Unit of account

[Drak]

+1
On 4 May 2014 02:06, "Chris Pacia"  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
> > ___
> > 

Re: [Bitcoin-development] Bug with handing of OP_RETURN?

[Jeff Garzik]

On Sat, May 3, 2014 at 2:04 PM, Flavien Charlon
 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] A statistical consensus rule for reducing 0-conf double-spend risk

[Christophe Biocca]

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

[Bitcoin-development] (no subject)

[losew...@gmail.com]

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] "bits": Unit of account

[Chris Pacia]

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" 
>>  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] A statistical consensus rule for reducing 0-conf double-spend risk

[Tom Harding]

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] Bug with handing of OP_RETURN?

[Mark Friedenbach]

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

[Gregory Maxwell]

On Sat, May 3, 2014 at 11:55 AM, Mark Friedenbach  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?

[Mark Friedenbach]

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] moving the default display to mbtc

[Jannis Froese]

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

[Peter Todd]

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

[Bitcoin-development] Bug with handing of OP_RETURN?

[Flavien Charlon]

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] "bits": Unit of account

[Mike Caldwell]

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

Re: [Bitcoin-development] "bits": Unit of account

[Tamas Blummer]

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  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 
>  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  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  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 .
> >>
> >> 'Zib' also lends itself to an expressive unicode symbol, 'Ƶ'
> >> (Z-with-stroke), that remains distinctive even if it loses its stroke or
> >> gets case-r

Re: [Bitcoin-development] "bits": Unit of account

[slush]

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  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  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 .
> >>
> >> '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:
> >> 

Re: [Bitcoin-development] "bits": Unit of account

[Christophe Biocca]

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  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  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 .
>>
>> '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:
>> .)
>>
>> - 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,

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

[Roy Badami]

> 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