Re: [Bitcoin-development] Economics of information propagation

2014-04-20 Thread Daniel Lidstrom
 Of course, in reality smaller miners can just mine on top of block headers
 and include no transactions and do no validation, but that is extremely
 harmful to the security of Bitcoin.


If it's only during the few seconds that it takes to to verify the block,
then would this really be that big of a deal?  E.g. even if all miners did
this, a 10 second delay would only yield an average of a couple blind/empty
blocks per day.


On Sun, Apr 20, 2014 at 10:06 PM, Peter Todd p...@petertodd.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 That is mistaken: you can't mine on top of just a block header, leaving
 small miners disadvantaged as they are earning no profit while they wait
 for the information to validate the block and update their UTXO sets. This
 results in the same problem as before, as the large pools who mine most
 blocks can validate either instantly - the self-mine case - or more quickly
 than the smaller miners.

 Of course, in reality smaller miners can just mine on top of block headers
 and include no transactions and do no validation, but that is extremely
 harmful to the security of Bitcoin.


 On 20 April 2014 23:58:58 GMT-04:00, Mark Friedenbach m...@monetize.io
 wrote:
 As soon as we switch to headers
 first - which will be soon - there will be no difference in propagation
 time no matter how large the block is. Only 80 bites will be required
 to
 propagate the block header which establishes priority for when the
 block is
 fully validated.
 On Apr 20, 2014 6:56 PM, Jonathan Levin
 jonathan.le...@sant.ox.ac.uk
 wrote:
 
  Hi all,
 
  I am a post-graduate economist writing a paper on the incentives of
  mining. Even though this issue has been debated in the forums, I
 think it
  is important to get a sense of the magnitude of the incentives at
 play and
  determine what implications this has for the transaction fee market.
 
  As it has been pointed out before the marginal cost for miners does
 not
  stem from the private cost of the miner validating the signature and
  including it in the list of transactions in the block but rather the
  increased probability that the block will be orphaned as a result of
 slower
  propagation. Gavin did some back of the envelope worst case
 calculations
  but these overstated the effect of propagation delay. The reason
 being the
  80ms additional time to reach 50% of the network is spread throughout
 the
  time that it takes to reach 50% of the network. During this time
 miners are
  notified about the block and treat it as the longest chain and hence
 are no
  longer mining with the aim to produce a competing block.
 
  I am looking to calculate the change in the curvature of the
 probability
  mass function that a block hears about my block in any given second
 as a
  function of the block size. Although there is likely to be
 significant
  noise here, there seems to be some stable linear relationships with
 the
  time that it takes to reach different quartiles. Has anyone done
 this? I
  have used some empirical data that I am happy to share but ideally I
 would
  like analytical solutions.
 
  Following Peter Todd, I also find the concerning result that
 propagation
  delays results in increasing returns to higher shares of the hashing
 power.
  Indeed it may well be in the interest of large pools to publish large
  blocks to increase propagation delays on the network which would
 increase
  orphan rates particularly for small miners and miners that have not
  invested in sufficient bandwidth / connectivity. If a small miner
 hears
  about a block after 4.5 seconds on average there is a 0.7% chance
 that
  there is already a block in circulation.  Large miners can increase
 the
  time that it takes for small miners to hear about blocks by
 increasing the
  size of their blocks. For example if the time that it takes for a
 small
  miner to hear about the block goes to 12 seconds there is a 2 percent
  chance there is already a block in circulation for the small miner.
 There
  is also a 1.2% chance that there will be a competing block published
 after
  a small miner propagates in the time that it gets to full
 propagation. Am I
  getting this right that the probability of a miner’s block being
 orphaned
  is comprised of the probability that the miner was not the first to
 find a
  valid block and the probability that given they are first, someone
 else in
  the absence of hearing about it finds a competing valid block.
 
  One question is: Are orphans probabilistic and only resolved after
 hearing
  about a new block that lengthens the chain or is there a way to know
 in
  advance? Is it frowned upon to mine on top of a block that you have
 just
  found even though it is very likely going to end up an orphan?
 
  Would be happy to share the draft form of the paper and receive any
  feedback.
 
  Finally, at coinometrics we are working on a modified client to
 capture
  information on network propagation and would invite any 

[Bitcoin-development] Identity protocol observation

2013-10-03 Thread Daniel Lidstrom
The location of a tx in the blockchain can be encoded in n=log2(h)+log2(t)
bits, where h is the block height, and t is the number of transactions in
the block.  Currently h~250,000 and t~500, so n~27.  A CVC phoneme encodes
~10.7 bits *, so a transaction today can be located in the blockchain with
3 of these, e.g. reb-mizvig.  This is reasonably short, readable and
memorable.

The identity protocol Jeff Garzik is working on will link a public key
fingerprint to a miner sacrifice transaction.  This tx could in turn be
uniquely described with a short name as above.  Associating this name with
the public key becomes secure once the tx is sufficiently buried in the
blockchain.  In the identity protocol, lightweight clients check the
validity of a sacrifice tx by checking that its merkle path is valid.  But
this path encodes, via the ordering of the hashes at each level, the
location of the transaction in the block, so the lightweight client can
verify the sacrifice tx's short name using only the information he already
has.

Some more random names:
vec-halhic
wom-vizpyd
guv-zussof
jog-copwug
seg-rizges
jyg-somgod
pax-synjem
zyg-zuxdyj
gid-mutdyj
rel-hyrdaj

Sources of inspiration:
urbit.org
https://en.bitcoin.it/wiki/Identity_protocol_v1

* This is somewhat restricted: I disallowed q for obvious reasons and k
because it conflicts with c, and c looks much softer and less like
Klingon.  H is allowed for the first consonant, but not the second, and x
is allowed for the last one, but not the first one.  Y is a vowel, but not
a consonant.  Maybe these weren't quite the right choices.  Paint away!
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Identity protocol observation

2013-10-03 Thread Daniel Lidstrom
A couple more thoughts on this:

1) Both c and k can be kept if c is pronounced 'ch', giving ~10.9 bits per
phoneme.
2) An extra phoneme (4 encode 43 bits total) gives room to put extra
information into the name, e.g. the first 5 bits could be input as the key
to a PRP that permutes the last 38 back to a standard encoding of a tx
location.  This would give the user 32 random names per sacrifice to choose
from, and 38 bits to encode its location in the blockchain, which is enough
for pretty large blocks.

Sample 4 phoneme names:
~milmoz-vyrnyx
~mypnoz-fojzas
~sawfex-bovlec
~fidhut-guvgis
~bobfej-jessuk
~furcos-diwhuw
~wokryx-wilrox
~bygbyl-caggos
~vewcyv-jyjsal
~daxsaf-cywkul

They're not that bad IMHO, especially if you get to pick a decent one from
a bunch.


On Thu, Oct 3, 2013 at 3:35 AM, Daniel Lidstrom lidstro...@gmail.comwrote:

 The location of a tx in the blockchain can be encoded in n=log2(h)+log2(t)
 bits, where h is the block height, and t is the number of transactions in
 the block.  Currently h~250,000 and t~500, so n~27.  A CVC phoneme encodes
 ~10.7 bits *, so a transaction today can be located in the blockchain with
 3 of these, e.g. reb-mizvig.  This is reasonably short, readable and
 memorable.

 The identity protocol Jeff Garzik is working on will link a public key
 fingerprint to a miner sacrifice transaction.  This tx could in turn be
 uniquely described with a short name as above.  Associating this name with
 the public key becomes secure once the tx is sufficiently buried in the
 blockchain.  In the identity protocol, lightweight clients check the
 validity of a sacrifice tx by checking that its merkle path is valid.  But
 this path encodes, via the ordering of the hashes at each level, the
 location of the transaction in the block, so the lightweight client can
 verify the sacrifice tx's short name using only the information he already
 has.

 Some more random names:
 vec-halhic
 wom-vizpyd
 guv-zussof
 jog-copwug
 seg-rizges
 jyg-somgod
 pax-synjem
 zyg-zuxdyj
 gid-mutdyj
 rel-hyrdaj

 Sources of inspiration:
 urbit.org
 https://en.bitcoin.it/wiki/Identity_protocol_v1

 * This is somewhat restricted: I disallowed q for obvious reasons and k
 because it conflicts with c, and c looks much softer and less like
 Klingon.  H is allowed for the first consonant, but not the second, and x
 is allowed for the last one, but not the first one.  Y is a vowel, but not
 a consonant.  Maybe these weren't quite the right choices.  Paint away!

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Identity protocol observation

2013-10-03 Thread Daniel Lidstrom
Fair enough, though people still manage okay with phone numbers.  And a
decentralized naming system seems to come at great cost - with namecoin you
need the whole blockchain to resolve names without trust.  Strip out a bell
and whistle - meaningfulness and transferability of names - and you get a
simple, rudimentary (spam killing!) system that scales on any device.  I'll
only argue that it seems to be Good Enough *for the types of people who
might care about decentralized names*.  Probably a very small set :)


On Thu, Oct 3, 2013 at 8:00 AM, Mike Hearn m...@plan99.net wrote:

 Interesting observation, thanks.

 I'd think any competent implementation of such an identity scheme would
 not involve end users directly handling randomized nonsense words, however.
 I always imagined a sacrifice as being a file that you make with a GUI tool
 and load into a browser extension.


 On Thu, Oct 3, 2013 at 3:35 PM, Daniel Lidstrom lidstro...@gmail.comwrote:

 A couple more thoughts on this:

 1) Both c and k can be kept if c is pronounced 'ch', giving ~10.9 bits
 per phoneme.
 2) An extra phoneme (4 encode 43 bits total) gives room to put extra
 information into the name, e.g. the first 5 bits could be input as the key
 to a PRP that permutes the last 38 back to a standard encoding of a tx
 location.  This would give the user 32 random names per sacrifice to choose
 from, and 38 bits to encode its location in the blockchain, which is enough
 for pretty large blocks.

 Sample 4 phoneme names:
 ~milmoz-vyrnyx
 ~mypnoz-fojzas
 ~sawfex-bovlec
 ~fidhut-guvgis
 ~bobfej-jessuk
 ~furcos-diwhuw
 ~wokryx-wilrox
 ~bygbyl-caggos
 ~vewcyv-jyjsal
 ~daxsaf-cywkul

 They're not that bad IMHO, especially if you get to pick a decent one
 from a bunch.


 On Thu, Oct 3, 2013 at 3:35 AM, Daniel Lidstrom lidstro...@gmail.comwrote:

 The location of a tx in the blockchain can be encoded in
 n=log2(h)+log2(t) bits, where h is the block height, and t is the number of
 transactions in the block.  Currently h~250,000 and t~500, so n~27.  A CVC
 phoneme encodes ~10.7 bits *, so a transaction today can be located in the
 blockchain with 3 of these, e.g. reb-mizvig.  This is reasonably short,
 readable and memorable.

 The identity protocol Jeff Garzik is working on will link a public key
 fingerprint to a miner sacrifice transaction.  This tx could in turn be
 uniquely described with a short name as above.  Associating this name with
 the public key becomes secure once the tx is sufficiently buried in the
 blockchain.  In the identity protocol, lightweight clients check the
 validity of a sacrifice tx by checking that its merkle path is valid.  But
 this path encodes, via the ordering of the hashes at each level, the
 location of the transaction in the block, so the lightweight client can
 verify the sacrifice tx's short name using only the information he already
 has.

 Some more random names:
 vec-halhic
 wom-vizpyd
 guv-zussof
 jog-copwug
 seg-rizges
 jyg-somgod
 pax-synjem
 zyg-zuxdyj
 gid-mutdyj
 rel-hyrdaj

 Sources of inspiration:
 urbit.org
 https://en.bitcoin.it/wiki/Identity_protocol_v1

 * This is somewhat restricted: I disallowed q for obvious reasons and k
 because it conflicts with c, and c looks much softer and less like
 Klingon.  H is allowed for the first consonant, but not the second, and x
 is allowed for the last one, but not the first one.  Y is a vowel, but not
 a consonant.  Maybe these weren't quite the right choices.  Paint away!




 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
 from
 the latest Intel processors and coprocessors. See abstracts and register 

 http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Identity protocol observation

2013-10-03 Thread Daniel Lidstrom
Names clearly solve a different problem than that, but we still use them,
so they must be solving _some_ problem :p  In this case they're a unique
identifier humans can remember after a bit of use and easily communicate to
each other with little room for error.  Securely mapping them to public
keys would make key verification simpler.  Simpler than checking a much
larger key fingerprint, at least.  Like I said, it's probably a niche
product ;)

I used to remember dozens of phone numbers before my phone did it for me,
but maybe I was just weird.


On Thu, Oct 3, 2013 at 9:22 AM, Mike Hearn m...@plan99.net wrote:

 1) Generate sacrifice proof file using an app
 2) Load file into browser
 3) Surf

 Where are the names in that design? I'm not sure where NameCoin comes into
 this. The point of a sacrifice is it's an anonymous identity, there's no
 point attaching a name to it.

 BTW I keep phone numbers in an address book ;)




 On Thu, Oct 3, 2013 at 5:16 PM, Daniel Lidstrom lidstro...@gmail.comwrote:

 Fair enough, though people still manage okay with phone numbers.  And a
 decentralized naming system seems to come at great cost - with namecoin you
 need the whole blockchain to resolve names without trust.  Strip out a bell
 and whistle - meaningfulness and transferability of names - and you get a
 simple, rudimentary (spam killing!) system that scales on any device.  I'll
 only argue that it seems to be Good Enough *for the types of people who
 might care about decentralized names*.  Probably a very small set :)


 On Thu, Oct 3, 2013 at 8:00 AM, Mike Hearn m...@plan99.net wrote:

 Interesting observation, thanks.

 I'd think any competent implementation of such an identity scheme would
 not involve end users directly handling randomized nonsense words, however.
 I always imagined a sacrifice as being a file that you make with a GUI tool
 and load into a browser extension.


 On Thu, Oct 3, 2013 at 3:35 PM, Daniel Lidstrom lidstro...@gmail.comwrote:

 A couple more thoughts on this:

 1) Both c and k can be kept if c is pronounced 'ch', giving ~10.9 bits
 per phoneme.
 2) An extra phoneme (4 encode 43 bits total) gives room to put extra
 information into the name, e.g. the first 5 bits could be input as the key
 to a PRP that permutes the last 38 back to a standard encoding of a tx
 location.  This would give the user 32 random names per sacrifice to choose
 from, and 38 bits to encode its location in the blockchain, which is enough
 for pretty large blocks.

 Sample 4 phoneme names:
 ~milmoz-vyrnyx
 ~mypnoz-fojzas
 ~sawfex-bovlec
 ~fidhut-guvgis
 ~bobfej-jessuk
 ~furcos-diwhuw
 ~wokryx-wilrox
 ~bygbyl-caggos
 ~vewcyv-jyjsal
 ~daxsaf-cywkul

 They're not that bad IMHO, especially if you get to pick a decent one
 from a bunch.


 On Thu, Oct 3, 2013 at 3:35 AM, Daniel Lidstrom 
 lidstro...@gmail.comwrote:

 The location of a tx in the blockchain can be encoded in
 n=log2(h)+log2(t) bits, where h is the block height, and t is the number 
 of
 transactions in the block.  Currently h~250,000 and t~500, so n~27.  A CVC
 phoneme encodes ~10.7 bits *, so a transaction today can be located in the
 blockchain with 3 of these, e.g. reb-mizvig.  This is reasonably short,
 readable and memorable.

 The identity protocol Jeff Garzik is working on will link a public key
 fingerprint to a miner sacrifice transaction.  This tx could in turn be
 uniquely described with a short name as above.  Associating this name with
 the public key becomes secure once the tx is sufficiently buried in the
 blockchain.  In the identity protocol, lightweight clients check the
 validity of a sacrifice tx by checking that its merkle path is valid.  But
 this path encodes, via the ordering of the hashes at each level, the
 location of the transaction in the block, so the lightweight client can
 verify the sacrifice tx's short name using only the information he already
 has.

 Some more random names:
 vec-halhic
 wom-vizpyd
 guv-zussof
 jog-copwug
 seg-rizges
 jyg-somgod
 pax-synjem
 zyg-zuxdyj
 gid-mutdyj
 rel-hyrdaj

 Sources of inspiration:
 urbit.org
 https://en.bitcoin.it/wiki/Identity_protocol_v1

 * This is somewhat restricted: I disallowed q for obvious reasons and
 k because it conflicts with c, and c looks much softer and less like
 Klingon.  H is allowed for the first consonant, but not the second, and x
 is allowed for the last one, but not the first one.  Y is a vowel, but not
 a consonant.  Maybe these weren't quite the right choices.  Paint away!




 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
 most from
 the latest Intel processors and coprocessors. See abstracts and
 register 

 http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
 ___
 Bitcoin

Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting

2013-06-10 Thread Daniel Lidstrom
Reserving my judgement until I've though about it more (design by committee
scares me, and this voting sounds expensive), I think the SPV-verifiable
moving median can be done by binning the space of block size limits, and
for each node in the UTXO tree, a value for each bin is stored which is the
sum of the corresponding bins of each of the children.  The childless nodes
- which correspond to the individual UTXOs - increment the appropriate bin
of their parents according to the rules you mentioned.  The bin values in
the root node of the UTXO tree would then be added to those, weighted
appropriately, of the previous N blocks.

The hash of a node would be that of the bin values, concatenated with the
child nodes' hashes.  In this way, any step of the calculation of the
median would produce a localized error in the UTXO tree that's easily
verified.

The number of bins would have to be kept relatively small in order to keep
this from adding too much data to the UTXO tree branches though.


On Mon, Jun 10, 2013 at 2:30 AM, Peter Todd p...@petertodd.org wrote:

 On Mon, Jun 10, 2013 at 04:09:26AM +, John Dillon wrote:

 My general comments on the idea are that while it's hard to say if a
 vote by proof-of-stake is really representative, it's likely the closest
 thing we'll ever get to a fair vote. Proof-of-stake is certainely better
 than just letting miners choose; as you point out miners can always
 choose to decrease the blocksize anyway so we only need a vote on
 allowable increases. Proof-of-stake also clearly favors those who
 actually have invested in Bitcoin over those who only talk about
 Bitcoin.

 I'll also say that while I know people will complain about putting
 politics into a technical problem, as I keep saying, is *is* a political
 issue. The limitations may be technical, but the ultimate issue is a
 very political decision about what we want Bitcoin to be. Yes, there
 will be people campaigning left and right to get users to vote for
 various limits with their coins, deal with it. Democracy is messy.

 Voting would take a lot of the nastier politics out of the situation,
 perhaps somewhat ironically. It would quite clearly take control away
 from the core development team, and the Bitcoin Foundation, and put it
 back in the hands of the community; you can't argue conspiracy theories
 that the Foundation is trying to control Bitcoin when there is a
 completely transparent voting system in place. People will complain that
 big Bitcoin players are throwing their weight around, but the blockchain
 itself is a voting mechanism that is anything but 1 person = 1 vote.

 Of course I wouldn't be the slightest bit surprised if users happily
 vote themselves into something looking like a centralized PayPal
 replacement in the long run, but at least if that happens the process by
 which they get there will be transparent and relatively democratic.


  A vote will consist of a txout with a scriptPubKey of the following form:
 
  OP_RETURN magic vote_id txid vout vote scriptSig
 
  Where scriptSig is a valid signature for a transaction with nLockTime
  500,000,000-1 spending txid:vout to scriptPubKey:
 
  OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL

 I just wanted to point out how general this mechanism is. Regardless of
 what the scriptPubKey form is, standard, P2SH, multisig, whatever to
 vote is to simply prove you could have spent the txout.

  vote_id is the ID of the specific vote being made, and magic is included
 to
  allow UTXO proof implementations a as yet unspecified way of identifying
 votes
  and including the weighted median as part of the UTXO tree sums. (it also
  allows SPV clients to verify the vote if the UTXO set is a Patricia tree
 of
  scriptPubKeys) vote is just the numerical vote itself.

 Ah, you're assuming a direct Patricia tree. Keep in mind that
 scriptPubKey's can be up to 10,000 bytes long, and an attacker can use
 that (with 10,000 other txouts) to create some extremely deep trees. I
 said on IRC a few days ago about how skeptical I am of implementing
 consensus critical systems with such huge differences in average and
 worst case, but I'll admit this is a decent use-case.

 Having said that, proof to SPV clients leaves open the interesting
 possibility that a third-party holding Bitcoins on your behalf can prove
 that they voted according to your wishes, or even prove they voted
 according to all their users wishes. Basically we'd add a rule for the
 UTXO tree where a specific OP_RETURN form is included in the UTXO tree,
 even though it is unspendable, and is removed from the tree if the
 master txout is spent. Note that in this case by prove they voted we
 mean the service actually taking the step of ensuring their vote was
 recorded in the blockchain.

  The vote must compute
  the median, rather than the mean, so as to not allow someone to skew the
 vote
  by simply setting their value extremely high. Someone who still
 remembers their
  

Re: [Bitcoin-development] Large-blocks and censorship

2013-03-07 Thread Daniel Lidstrom
My views on censorship resistance in the face of scaling:

1) I expect if I'm not careful about preserving my privacy with the way I
use Bitcoin, then I will always run the risk of being censored by miners.
This means connecting to the network anonymously, not reusing addresses,
and perhaps even mixing my coins.  The onus is on me here to avoid
censorship, but I'm optimistic that this privacy preservation can be made
pretty automatic.

2) I expect anonymity systems to scale to accommodate Bitcoin full nodes,
not Bitcoin to stay small to avoid putting pressure on anonymity systems to
scale.

3) If 2 is too tall an order, then mining in a pool is always an option.
There should always be some countries in the world free enough to allow
mining pools to operate, and miners in countries that ban Bitcoin can
simply connect to these anonymously.  If not, then Bitcoin is toast anyway,
is it not?  If these miners are really interested in avoiding censoring
transactions, then they will do their due diligence and choose a pool that
doesn't do this.  But even if they don't, censorship can be personally
avoided by following 1.

On Thu, Mar 7, 2013 at 2:19 PM, Mike Hearn m...@plan99.net wrote:

 As an aside, there's a paper coming out in perhaps a few months that
 describes a new way to provide Chaum-style privacy integrated with
 Bitcoin, but without the use of blinding and without any need for
 banks. It's quite smart, I was reviewing the paper this week.
 Unfortunately the technique is too slow and too complicated to
 actually integrate, but you'd probably get a kick out of it. It's
 based on zero knowledge proofs. You can talk to Ian Miers if you like,
 perhaps he'll send you a copy for review.

 Back on topic.

 This idea is not new. I proposed the idea of regulating miners to
 freeze certain outputs two years ago:

https://bitcointalk.org/index.php?action=printpage;topic=5979.0

 I concluded that it was not a real risk because both mining and
 transactions can be done anonymously.

 Your argument rests on the assumption that you can't mine large blocks
 anonymously because Tor doesn't scale. Even if we go along with the
 idea that Tor is the only way to escape regulation (it's not), you
 should maybe take up its inability to move data sufficiently fast with
 the developers. Given that they routinely push two gigabits/second
 today, with an entirely volunteer run network, I think they'll be
 surprised to learn that their project is doomed to never be usable by
 miners.


 --
 Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
 Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the
 endpoint security space. For insight on selecting the right partner to
 tackle endpoint security challenges, access the full report.
 http://p.sf.net/sfu/symantec-dev2dev
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Enforcing inflation rules for SPV clients

2012-06-25 Thread Daniel Lidstrom

  
  
Here's the conversation I had with Mike that Gregory requested a
link to:


Thanks!
  
  
  Bad or hacked client devs is indeed a huge, worrying problem.
The official client is addressing this with a system called
gitian, where multiple developers all compile the same source to
the same binary and then sign the results. Multi-signatures
raise the bar for releasing hacked clients a lot. We're starting
to investigate this with bitcoinj too, but it's a lot of work.
  
  
  Generally, the more people you have to involve in a
conspiracy, the less likely it is to succeed. If a few miners
started to dominate the system they have strong financial
incentives to cheat, alternatively, they may be subjected to
government pressure. Having to get the client developers
involved too makes it much harder, especially as users have to
actually upgrade.
  
  
  I started a thread on the development mailing list with your
suggestion, by the way.

On Mon, Jun 25, 2012 at 1:00 AM, Daniel
  Lidstrom lidstro...@gmail.com
  wrote:
  
 Hey Mike,
  
  I put our conversation in the email for easy reference.
  
  In the unlikely event of a miner conspiracy to print
  money, is it really so much of a further stretch to think
  the developers of a widely used client could also be
  involved? (Well, maybe, since miners are unaccountable
  and developers are not. OTOH if most users are
  apathetic...) Also, isn't the advantage for lightweight
  clients of SPV over the server-client model that you don't
  have to trust any operator? Maybe I'm being too much of a
  purist here...
  
  Regarding errors being cheap to send and expensive to
  verify, compartmentalizing them the way I suggested before
  would make them individually cheaper to verify. Just
  throwing around ideas: requiring the error message be
  received by a quorum of peers before checking, and
  dropping misbehaving or unreliable peers could help.
  Also, not verifying error messages unless the peers
  relaying them are willing to send all the data necessary
  to do so would help. Hashcash could also be used to
  balance the costs to send and to verify a given type of
  error message. I like your idea to only check errors in
  blocks that are split points, and the length of the split
  could also be a consideration.
  
  Can we move further conversations
to email please? SMF kind of sucks as an inbox.

Anyway, yes, your proposal makes a lot of sense,
although I think in practice this is unlikely to be an
issue. If a majority of miners did start mining on a
chain with new rules, even if SPV clients couldn't
detect the switch automatically it's very likely the
developers of those clients would notify the users out
of band in some way. For example, by pushing an update
to users that explains the new rules to them and tells
them how they can cash out of the Bitcoin economy if
they disagree with the new consensus.

If users are on the losing side of a rule change and
want to stay there (eg, maybe most non-miners want to
stay on the slower chain), then the client can just
checkpoint the first block after the rule change
occurred. Now even though there's a harder chain with
the new rules, the client will stay with the old rules
despite being blind to them. There's nothing that says
checkpoints have to be hard coded - clients could poll
the client developers every day to get new ones. So as
long as the SPV devs are on the ball, most users would
stay on the old rules even if the software can't do it
by itself.

All that said, broadcasting messages proving a block
broke the rules is a nice backstop if it can be done
without excessive complexity. There are some details to
think about. These messages would be cheap to create and
expensive to verify. There has to be something that
stops me claiming to SPV clients that every single block
is invalid and forcing them to do tons of useless work.
Perhaps only blocks