public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
@ 2013-11-05 16:56 Ittay
  2013-11-05 17:05 ` Peter Todd
  2013-11-07 20:05 ` [Bitcoin-development] comments on selfish-mining model (Re: BIP proposal - patch to raise selfish mining threshold.) Adam Back
  0 siblings, 2 replies; 17+ messages in thread
From: Ittay @ 2013-11-05 16:56 UTC (permalink / raw)
  To: Bitcoin Dev; +Cc: Gavin Andresen, Emin Gün Sirer

[-- Attachment #1: Type: text/plain, Size: 2515 bytes --]

Hello,

Please see below our BIP for raising the selfish mining threshold.
Looking forward to your comments.

Best,
Ittay

---

Bitcoin Improvement Proposal

Owners: Ittay Eyal and Emin Gun Sirer

We suggest a change in the propagation and mining algorithm for chains of
the same difficulty, to raise the threshold on Selfish Mining attacks.

* Current situation:
When a miner is notified of a new chain of the same difficulty as the one
it is mining on, it will ignore it.

* Background:
The selfish mining attack and its implications were described in detail in
the following research paper:
http://arxiv.org/abs/1311.0243v1

* Proposal:
To thwart selfish mining attacks launched by less than 25% of the mining
power, we propose the following change to the protocol:
When a miner learns of more than one chain of the same difficulty, it
should propagate all of them, and choose one of them to mine on uniformly
at random among all chains of the same difficulty.

When hearing of a chain of maximal difficulty that it did not know of
before:
1. Add it to a local list of maximal difficulty chains.
2. Propagate it to its neighbors.
3. Choose a branch uniformly at random from the local list, and mine on it.

* Example:
t0: learn of chain A of difficulty x.
    propagate A to neighbors.
    start mining on A.
t1: learn of chain B of difficulty x.
    propagate B to neighbors.
    toss a coin between A and B; if B wins, switch to mining on B.
t2: learn of chain C of difficulty x.
    propagate C to neighbors.
    toss a 3 faced coin among A, B, and C; switch to mining on the winning
chain.

* Concerns and answers:
1. No harm to miners when all are honest.
Mining blocks is a random Poisson process, which is memoryless. Having
mined on the block in the past does not provide an advantage in locating a
solution in the future. Therefore, a miner is not harmed by switching the
chain on which it mines.

2. No new vulnerabilities introduced:
Currently the choice among equal-length chains is done arbitrarily,
depending on network topology. This arbitrariness is a source of
vulnerability. We replace it with explicit randomness, which is at the
control of the protocol. The change does not introduce executions that were
not possible with the old protocol.

3. Complete backward compatibility:
Any subset of the miners can switch to the proposed protocol.

4. Progressive improvement:
Each miner that adopts the change raises the threshold a little bit. The
threshold will reach 25% with universal adoption.

[-- Attachment #2: Type: text/html, Size: 3331 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

• * Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
    2013-11-05 16:56 [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold Ittay
  @ 2013-11-05 17:05 ` Peter Todd
    2013-11-05 17:14   ` Peter Todd
    2013-11-05 17:26   ` Ittay
    2013-11-07 20:05 ` [Bitcoin-development] comments on selfish-mining model (Re: BIP proposal - patch to raise selfish mining threshold.) Adam Back
    1 sibling, 2 replies; 17+ messages in thread
  From: Peter Todd @ 2013-11-05 17:05 UTC (permalink / raw)
    To: Ittay; +Cc: Bitcoin Dev, Gavin Andresen, Emin Gün Sirer
  
  [-- Attachment #1: Type: text/plain, Size: 1443 bytes --]
  
  On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
  > Hello,
  > 
  > Please see below our BIP for raising the selfish mining threshold.
  > Looking forward to your comments.
  
  <snip>
  
  > 2. No new vulnerabilities introduced:
  > Currently the choice among equal-length chains is done arbitrarily,
  > depending on network topology. This arbitrariness is a source of
  > vulnerability. We replace it with explicit randomness, which is at the
  > control of the protocol. The change does not introduce executions that were
  > not possible with the old protocol.
  
  Credit goes to Gregory Maxwell for pointing this out, but the random
  choice solution does in fact introduce a vulnerability in that it
  creates incentives for pools over a certain size to withhold blocks
  rather than immediately broadcasting all blocks found.
  
  The problem is that when the pool eventually choses to reveal the block
  they mined, 50% of the hashing power switches, thus splitting the
  network. Like the original attack this can be to their benefit. For
  pools over a certain size this strategy is profitable even without
  investing in a low-latency network; Maxwell or someone else can chime in
  with the details for deriving that threshold.
  
  I won't get a chance to for a few hours, but someone should do the
  analysis on a deterministic switching scheme.
  
  -- 
  'peter'[:-1]@petertodd.org
  0000000000000005e25ca9b9fe62bdd6e8a2b4527ad61753dd2113c268bec707
  
  [-- Attachment #2: Digital signature --]
  [-- Type: application/pgp-signature, Size: 490 bytes --]
  
  ^ permalink raw reply	[flat|nested] 17+ messages in thread

• • * Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
      2013-11-05 17:05 ` Peter Todd
    @ 2013-11-05 17:14   ` Peter Todd
      2013-11-05 17:43     ` Ittay
      2013-11-05 17:26   ` Ittay
      1 sibling, 1 reply; 17+ messages in thread
    From: Peter Todd @ 2013-11-05 17:14 UTC (permalink / raw)
      To: Ittay; +Cc: Bitcoin Dev, Gavin Andresen, Emin Gün Sirer
    
    [-- Attachment #1: Type: text/plain, Size: 2403 bytes --]
    
    On Tue, Nov 05, 2013 at 12:05:41PM -0500, Peter Todd wrote:
    > On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
    > > Hello,
    > > 
    > > Please see below our BIP for raising the selfish mining threshold.
    > > Looking forward to your comments.
    > 
    > <snip>
    > 
    > > 2. No new vulnerabilities introduced:
    > > Currently the choice among equal-length chains is done arbitrarily,
    > > depending on network topology. This arbitrariness is a source of
    > > vulnerability. We replace it with explicit randomness, which is at the
    > > control of the protocol. The change does not introduce executions that were
    > > not possible with the old protocol.
    > 
    > Credit goes to Gregory Maxwell for pointing this out, but the random
    > choice solution does in fact introduce a vulnerability in that it
    > creates incentives for pools over a certain size to withhold blocks
    > rather than immediately broadcasting all blocks found.
    > 
    > The problem is that when the pool eventually choses to reveal the block
    > they mined, 50% of the hashing power switches, thus splitting the
    > network. Like the original attack this can be to their benefit. For
    > pools over a certain size this strategy is profitable even without
    > investing in a low-latency network; Maxwell or someone else can chime in
    > with the details for deriving that threshold.
    > 
    > I won't get a chance to for a few hours, but someone should do the
    > analysis on a deterministic switching scheme.
    
    Oh, and I don't want to give the wrong impression: there's no need to
    rush to get this problem fixed. Even if someone wanted to launch an
    attack right now, with a fair amount of resources, there's a lot of
    counter-measures based on human intervention that can definitely stop
    the attack in the short-term; what's needed is at worst moderate-term,
    and much more likely a long-term approach. In addition, keep in mind
    that this attack is very easy to detect, so if one is actually launched
    we will know immediately and can start taking direct counter-measures at
    that time.
    
    That Gregory Maxwell so quickly identified a flaw in this proposed
    solution suggests we should proceed carefully.
    
    It'd be good to do a test of this attack, as well as possible solutions,
    on testnet to better explore it and possible counter-measures.
    
    -- 
    'peter'[:-1]@petertodd.org
    000000000000000a03ea8c90161a275ee63d077ec35c1b582c77934c0be12a02
    
    [-- Attachment #2: Digital signature --]
    [-- Type: application/pgp-signature, Size: 490 bytes --]
    
    ^ permalink raw reply	[flat|nested] 17+ messages in thread

  • • * Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
        2013-11-05 17:14   ` Peter Todd
      @ 2013-11-05 17:43     ` Ittay
        2013-11-05 17:54       ` Mike Hearn
        2013-11-05 19:56       ` Peter Todd
        0 siblings, 2 replies; 17+ messages in thread
      From: Ittay @ 2013-11-05 17:43 UTC (permalink / raw)
        To: Peter Todd; +Cc: Ittay, Gavin Andresen, Emin Gün Sirer, Bitcoin Dev
      
      [-- Attachment #1: Type: text/plain, Size: 1422 bytes --]
      
      On Tue, Nov 5, 2013 at 12:14 PM, Peter Todd <pete@petertodd•org> wrote:
      
      > On Tue, Nov 05, 2013 at 12:05:41PM -0500, Peter Todd wrote:
      > > On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
      >
      > Oh, and I don't want to give the wrong impression: there's no need to
      > rush to get this problem fixed. Even if someone wanted to launch an
      > attack right now, with a fair amount of resources, there's a lot of
      > counter-measures based on human intervention that can definitely stop
      > the attack in the short-term
      
      
      The attack can be easily hidden. And be sure that before today, today,
      and after today, very smart people are at their computer planning attacks
      on Bitcoin. Exploits must be published and fixed FAST.
      
      Nevertheless, I agree  that, as you say, we must not rush it. Look at the
      BIP, find if we missed anything, and let's discuss it.
      
      
      > In addition, keep in mind
      > that this attack is very easy to detect, so if one is actually launched
      > we will know immediately and can start taking direct counter-measures at
      > that time.
      >
      
      Not really. Please see the discussion section in our paper.
      
      
      > That Gregory Maxwell so quickly identified a flaw in this proposed
      > solution suggests we should proceed carefully.
      >
      
      There is no flaw. You were just reiterating that the solution does not give
      us the 51% percent security you thought you had before. We showed that
      we're not getting this back, I'm afraid.
      
      Best,
      Ittay
      
      [-- Attachment #2: Type: text/html, Size: 2276 bytes --]
      
      ^ permalink raw reply	[flat|nested] 17+ messages in thread

    • • * Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
          2013-11-05 17:43     ` Ittay
        @ 2013-11-05 17:54       ` Mike Hearn
          2013-11-05 18:07         ` Alessandro Parisi
          2013-11-05 19:56       ` Peter Todd
          1 sibling, 1 reply; 17+ messages in thread
        From: Mike Hearn @ 2013-11-05 17:54 UTC (permalink / raw)
          To: Ittay; +Cc: Bitcoin Dev, Gavin Andresen, Emin Gün Sirer
        
        [-- Attachment #1: Type: text/plain, Size: 475 bytes --]
        
        On Tue, Nov 5, 2013 at 6:43 PM, Ittay <ittay.eyal@cornell•edu> wrote:
        
        > The attack can be easily hidden. And be sure that before today, today,
        > and after today, very smart people are at their computer planning attacks
        > on Bitcoin. Exploits must be published and fixed FAST.
        >
        
        I think it would be helpful if you actually implemented and pulled off this
        attack, by becoming the dominant miner capable of reversing spends at will.
        Then we'd know how quickly it can be done.
        
        [-- Attachment #2: Type: text/html, Size: 1005 bytes --]
        
        ^ permalink raw reply	[flat|nested] 17+ messages in thread

      • • * Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
            2013-11-05 17:54       ` Mike Hearn
          @ 2013-11-05 18:07         ` Alessandro Parisi
            2013-11-05 18:37           ` Jeff Garzik
            0 siblings, 1 reply; 17+ messages in thread
          From: Alessandro Parisi @ 2013-11-05 18:07 UTC (permalink / raw)
            To: Mike Hearn; +Cc: Ittay, Gavin Andresen, Emin Gün Sirer, Bitcoin Dev
          
          [-- Attachment #1: Type: text/plain, Size: 1734 bytes --]
          
          I agree with Ittay: when bugs are found, they must be fixed ASAP,
          expecially when they affect a sensitive sw such as Bitcon; in IT security,
          every flaw that is exploitable in abstract, is going to be exploited in
          real, sooner or later, also taking into account the increasing parallel
          computing power; beware of false sense of security
          
          WebSite: http://www.startithub.com
          Per rimanere aggiornato in merito a Startup, Innovazione e Normativa di
          settore, sottoscrivi la nostra newsletter:
          http://www.startithub.com/blog/sottoscrivi-newsletter/
          
          
          2013/11/5 Mike Hearn <mike@plan99•net>
          
          > On Tue, Nov 5, 2013 at 6:43 PM, Ittay <ittay.eyal@cornell•edu> wrote:
          >
          >> The attack can be easily hidden. And be sure that before today, today,
          >> and after today, very smart people are at their computer planning attacks
          >> on Bitcoin. Exploits must be published and fixed FAST.
          >>
          >
          > I think it would be helpful if you actually implemented and pulled off
          > this attack, by becoming the dominant miner capable of reversing spends at
          > will. Then we'd know how quickly it can be done.
          >
          >
          >
          >
          >
          > ------------------------------------------------------------------------------
          > November Webinars for C, C++, Fortran Developers
          > Accelerate application performance with scalable programming models.
          > Explore
          > techniques for threading, error checking, porting, and tuning. Get the most
          > from the latest Intel processors and coprocessors. See abstracts and
          > register
          > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
          > _______________________________________________
          > Bitcoin-development mailing list
          > Bitcoin-development@lists•sourceforge.net
          > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
          >
          >
          
          [-- Attachment #2: Type: text/html, Size: 3069 bytes --]
          
          ^ permalink raw reply	[flat|nested] 17+ messages in thread

        • • * Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
              2013-11-05 18:07         ` Alessandro Parisi
            @ 2013-11-05 18:37           ` Jeff Garzik
              2013-11-05 18:55             ` Alessandro Parisi
              0 siblings, 1 reply; 17+ messages in thread
            From: Jeff Garzik @ 2013-11-05 18:37 UTC (permalink / raw)
              To: Alessandro Parisi; +Cc: Ittay, Bitcoin Dev, Emin Gün Sirer, Gavin Andresen
            
            On Tue, Nov 5, 2013 at 1:07 PM, Alessandro Parisi <startithub@gmail•com> wrote:
            > I agree with Ittay: when bugs are found, they must be fixed ASAP, expecially
            > when they affect a sensitive sw such as Bitcon; in IT security, every flaw
            > that is exploitable in abstract, is going to be exploited in real, sooner or
            > later, also taking into account the increasing parallel computing power;
            > beware of false sense of security
            
            That is quite ignorant.  Bitcoin is far more complex than standard IT
            security "fix ASAP" mantra.  Distributed consensus is a new field of
            computer science, and blindly applying standard logic to bitcoin will
            quickly result in large problems.
            
            Every fix has the chance of changing the game theory or economics of
            bitcoin.  A change to the core consensus protocol within bitcoin --
            mining -- is even more game-theory- and economically-critical to the
            core system.  Changes thus have more impact, where any change
            potentially reduces bitcoin's value to zero in the worst case.
            
            Bitcoin is akin to medical device or avionics software.  We cannot
            just change at will, without significant research, analysis and
            testing.   "It is a bug, it must be fixed ASAP" is ignorant and
            dangerous.
            
            Further, this is at present a THEORETICAL problem, and the solution
            presented has some obvious flaws, that would make our current, WORKING
            SYSTEM more fragile, and less secure.
            
            -- 
            Jeff Garzik
            Senior Software Engineer and open source evangelist
            BitPay, Inc.      https://bitpay.com/
            
            
            
            ^ permalink raw reply	[flat|nested] 17+ messages in thread

          • • * Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
                2013-11-05 18:37           ` Jeff Garzik
              @ 2013-11-05 18:55             ` Alessandro Parisi
                2013-11-05 18:58               ` Jeff Garzik
                0 siblings, 1 reply; 17+ messages in thread
              From: Alessandro Parisi @ 2013-11-05 18:55 UTC (permalink / raw)
                To: Jeff Garzik; +Cc: Bitcoin Dev
              
              [-- Attachment #1: Type: text/plain, Size: 1775 bytes --]
              
              Thank you very much for your fair response, Sir;
              this means that anytime a bug is found in Bitcoin protocol, chances are
              that it would take a lot more time to get fixed
              
              
              2013/11/5 Jeff Garzik <jgarzik@bitpay•com>
              
              > On Tue, Nov 5, 2013 at 1:07 PM, Alessandro Parisi <startithub@gmail•com>
              > wrote:
              > > I agree with Ittay: when bugs are found, they must be fixed ASAP,
              > expecially
              > > when they affect a sensitive sw such as Bitcon; in IT security, every
              > flaw
              > > that is exploitable in abstract, is going to be exploited in real,
              > sooner or
              > > later, also taking into account the increasing parallel computing power;
              > > beware of false sense of security
              >
              > That is quite ignorant.  Bitcoin is far more complex than standard IT
              > security "fix ASAP" mantra.  Distributed consensus is a new field of
              > computer science, and blindly applying standard logic to bitcoin will
              > quickly result in large problems.
              >
              > Every fix has the chance of changing the game theory or economics of
              > bitcoin.  A change to the core consensus protocol within bitcoin --
              > mining -- is even more game-theory- and economically-critical to the
              > core system.  Changes thus have more impact, where any change
              > potentially reduces bitcoin's value to zero in the worst case.
              >
              > Bitcoin is akin to medical device or avionics software.  We cannot
              > just change at will, without significant research, analysis and
              > testing.   "It is a bug, it must be fixed ASAP" is ignorant and
              > dangerous.
              >
              > Further, this is at present a THEORETICAL problem, and the solution
              > presented has some obvious flaws, that would make our current, WORKING
              > SYSTEM more fragile, and less secure.
              >
              > --
              > Jeff Garzik
              > Senior Software Engineer and open source evangelist
              > BitPay, Inc.      https://bitpay.com/
              >
              
              [-- Attachment #2: Type: text/html, Size: 2397 bytes --]
              
              ^ permalink raw reply	[flat|nested] 17+ messages in thread

            • • * Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
                  2013-11-05 18:55             ` Alessandro Parisi
                @ 2013-11-05 18:58               ` Jeff Garzik
                  2013-11-05 19:33                 ` Jameson Lopp
                  0 siblings, 1 reply; 17+ messages in thread
                From: Jeff Garzik @ 2013-11-05 18:58 UTC (permalink / raw)
                  To: Alessandro Parisi; +Cc: Bitcoin Dev
                
                On Tue, Nov 5, 2013 at 1:55 PM, Alessandro Parisi <startithub@gmail•com> wrote:
                > this means that anytime a bug is found in Bitcoin protocol, chances are that
                > it would take a lot more time to get fixed
                
                Correct.  There is significant potential that a fix can create other
                problems...   and any major mistake could instantly destroy > $2
                billion worth of value.
                
                -- 
                Jeff Garzik
                Senior Software Engineer and open source evangelist
                BitPay, Inc.      https://bitpay.com/
                
                
                
                ^ permalink raw reply	[flat|nested] 17+ messages in thread

              • • * Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
                    2013-11-05 18:58               ` Jeff Garzik
                  @ 2013-11-05 19:33                 ` Jameson Lopp
                    0 siblings, 0 replies; 17+ messages in thread
                  From: Jameson Lopp @ 2013-11-05 19:33 UTC (permalink / raw)
                    To: bitcoin-development
                  
                  The conversations that spawned from this paper have been fascinating to 
                  read, but I have a problem with the conclusions. To quote the paper:
                  
                  "The Bitcoin ecosystem is open to manipulation, and potential takeover, 
                  by miners seeking to maximize their rewards. This paper presented 
                  Selfish-Mine, a mining strategy that enables pools of colluding miners
                  that adopt it to earn revenues in excess of their mining power. Higher 
                  revenues can lead new rational miners to join sel\fsh miner pools, 
                  leading to a collapse of the decentralized currency."
                  
                  Please explain to me why any rational miner would collude to earn 
                  slightly higher short term profits at the expense of then wiping out the 
                  value of all their bitcoins in the long term.
                  
                  Also, if you felt that this vulnerability is an immediate danger to the 
                  Bitcoin network, why publish the vulnerability publicly rather than 
                  first disclosing it privately to the core developers? Apologies if you 
                  did disclose it privately in the past; I've seen no mention of it.
                  --
                  Jameson Lopp
                  Software Engineer
                  Bronto Software
                  
                  On 11/05/2013 01:58 PM, Jeff Garzik wrote:
                  > On Tue, Nov 5, 2013 at 1:55 PM, Alessandro Parisi <startithub@gmail•com> wrote:
                  >> this means that anytime a bug is found in Bitcoin protocol, chances are that
                  >> it would take a lot more time to get fixed
                  >
                  > Correct.  There is significant potential that a fix can create other
                  > problems...   and any major mistake could instantly destroy > $2
                  > billion worth of value.
                  >
                  
                  
                  
                  ^ permalink raw reply	[flat|nested] 17+ messages in thread

      • * Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
          2013-11-05 17:43     ` Ittay
          2013-11-05 17:54       ` Mike Hearn
        @ 2013-11-05 19:56       ` Peter Todd
          1 sibling, 0 replies; 17+ messages in thread
        From: Peter Todd @ 2013-11-05 19:56 UTC (permalink / raw)
          To: Ittay; +Cc: Bitcoin Dev, Gavin Andresen, Emin Gün Sirer
        
        [-- Attachment #1: Type: text/plain, Size: 8779 bytes --]
        
        On Tue, Nov 05, 2013 at 12:43:15PM -0500, Ittay wrote:
        > On Tue, Nov 5, 2013 at 12:14 PM, Peter Todd <pete@petertodd•org> wrote:
        > 
        > > On Tue, Nov 05, 2013 at 12:05:41PM -0500, Peter Todd wrote:
        > > > On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
        > >
        > > Oh, and I don't want to give the wrong impression: there's no need to
        > > rush to get this problem fixed. Even if someone wanted to launch an
        > > attack right now, with a fair amount of resources, there's a lot of
        > > counter-measures based on human intervention that can definitely stop
        > > the attack in the short-term
        > 
        > 
        > The attack can be easily hidden. And be sure that before today, today,
        > and after today, very smart people are at their computer planning attacks
        > on Bitcoin. Exploits must be published and fixed FAST.
        
        Not this exploit.
        
        Here's a perfectly plausible worst-case scenario, that could be
        happening right now: RAND High Frequency Trading Corp (a subsidiary of
        General Evil) has a globe-spanning low-latency network of fiber,
        line-of-sight microwave, and some experimental line-of-site neutrino
        links criss-crossing the globe. They can get data to and from any point
        on this planet faster than anyone else. Of course, in addition to their
        spectacular network they have an immense amount of computing power, as
        well as exotic overclocked liquid nitrogen bathed CPU's that run at
        clockspeeds double what commercial hardware can do; in short, they have
        access to scalar performance no-one else has. Of course, they like to
        keep a healthy reserve so, 99% of all this fancy gear is constantly
        idle. Whatever, they can afford it.
        
        RAND just hired a bunch of fresh MIT graduates, the best of the best.
        Problem is the best of the best tends to make not so best mistakes, so
        RAND figures a Training Exercise is in order. Fortunately for them the NSA (a
        subsidiary of General Evil) slipped a rootkit into my keyboard a week or
        so ago - probably that time when I woke up in that farmers field with a
        *splitting* headache - and are reading what I'm typing right now.
        
        I go on to explain how an excellent training exercise for these fresh
        MIT graduates would be to implement this nifty attack some Cornell
        researchers came up with. It's really simple, elegant even, but to do it
        best what you really want is the kind of low-latency network a
        high-frequency-trading corporation would have. I then point out how a
        good training exercise ideally is done in a scenario where there is
        genuine risk and reward, but where the worst-case consequences are
        manageable - new hires to tend to screw up. (I then go on to explain my
        analog electronics background, and squeeze in some forced anecdote about
        how I blew up something worth a lot of money owned by my employers at
        some point in the distant past)
        
        Unfortunately for the operators of BTC Guild, one of these new MIT grads
        happens to have a: passed General Evil's psych screening with flying
        colors, and b: have spent too much time around the MIT Kidnappng Club.
        He decides it'd be easier to just kidnap the guy running BTC Guild than
        fill out the paperwork to borrow RAND's FPGA cluster, so he does.
        
        As expected the attack runs smoothly: with 30% of the hashing power,
        neutrino burst generator/encoders's rigged around the globe to fire the
        moment another pool gets a block, and the odd DoS attack for fun, they
        quickly make a mockery of the Bitcoin network, reducing every other
        miners profitability to zero in minutes. The other miners don't have a
        hope: they're blocks have to travel the long way, along the surface of
        the earth, while RAND's blocks shave off important milliseconds by
        taking the direct route.
        
        
        Of course, this doesn't go unnoticed, er, eventualy: 12 hours later the
        operators of GHash.IO, Eligius, slush, Bitminter, Eclipse and ASICMiner
        open their groggy eyes and mutter something about how that simulcast
        Tuesday party really shouldn't have had an open bar... or so much coke.
        
        They don't even notice that the team from BTC Guild has vanished, but
        they do notice a YouTube video of Gavin right on bitcoin.org doing his
        best Spock impression, er, I mean appealing for calm and promising that
        Top Men are working on the issue of empty blocks as we speak. Meanwhile
        CNN's top headline reads "IS THIS THE END OF BITCOIN?!?!"
        
        It takes another hour for the Aspirin's to finally kick in, but
        eventually get all get on IRC and start trying to resolve the issue -
        seems that whenever any of them produce a block, somehow by incredible
        coincidence someone else finds another block first. After a few rounds
        of this they're getting suspicious. (if they weren't all so hung-over
        they might have also found suspicious the fact that whenever they found
        a block they saw a sudden blue flash - Cherenkov radiation emitted when
        those neutrino's interacted with the vitreous humour in their eyeballs)
        
        It's quickly realized that "somehow" BTC Guild isn't affected...
        GHash.IO and Eligius, 22% and 13% of the hashing power respectively,
        decide to try a little experiment: they peer to each other and only each
        other through an encrypted tunnel and... hey, no more lucky blocks!
        slush, 7% of the hashing power is invited to the peering group next,
        followed by Bitminter, 6%, and Eclipse, 2%, and finally ASICMiner, 1%,
        for a grand total of... 51% of the hashing power!
        
        Of course, just creating blocks isn't useful for users, they need to be
        distributed too, so someone quickly writes up a "one-way firewall" patch
        that allows the group's blocks to propagate to the rest of the network.
        Blocks created by anyone else are ignored.
        
        It takes a few more hours, but eventually the attacker seems to run out
        of blocks, and transaction processing returns to normal, albeit a little
        slow. (20 min block average) Of course, soon there's a 3,000 post thread
        on bitcointalk complaining about the "centralized pool cartel", but
        somehow life goes on.
        
        The next day Gavin goes on CNN, and gives a lovely interview about how
        the past two days events show how the strength of the Bitcoin network is
        in the community. For balance they interview this annoying "Peter Todd"
        guy from "Keep Bitcoin Free!" who blathers on about how relying on
        altruism or something will doom the Bitcoin network in the long run.
        After the interview Gavin respectfully points out that maybe next time
        they find a so called "developer" with a ratio of bitcointalk posts to
        actual lines of code in the Bitcoin git repository better than one
        hundred to one. The producer just wishes that "Mike Hearn" guy was
        available; at least he's got a sense of fashion, sheesh!
        
        
        Anyway, I'm out of space for my little story, but yeah, the ending
        involves a group of now-rich pool operators who decide to start a large
        financial services and data networking company, oh, and time-travel...
        
        
        > Nevertheless, I agree  that, as you say, we must not rush it. Look at the
        > BIP, find if we missed anything, and let's discuss it.
        
        Indeed.
        
        Quite seriously, your attack is a serious long-term risk, but in the
        short term the social dynamics of Bitcoin are such that it's just not a
        show-stopping risk. At worst some miners will lose a bunch of money -
        that's something that's happened before with the March chain fork, and
        sure enough Bitcoin survived just fine.
        
        > > In addition, keep in mind
        > > that this attack is very easy to detect, so if one is actually launched
        > > we will know immediately and can start taking direct counter-measures at
        > > that time.
        > >
        > 
        > Not really. Please see the discussion section in our paper.
        
        You can hide *who* is the attacker - you can't hide the fact that an
        attack is happening if done on a meaningful scale.
        
        > > That Gregory Maxwell so quickly identified a flaw in this proposed
        > > solution suggests we should proceed carefully.
        > >
        > 
        > There is no flaw. You were just reiterating that the solution does not give
        > us the 51% percent security you thought you had before. We showed that
        > we're not getting this back, I'm afraid.
        
        That's not what we're concerned about - what we're concerned about is
        that your BIP doesn't discuss the issue, and you didn't seem to be aware
        of it. That suggests that the analysis is incomplete. There's no
        pressing need to rush changes, as explained above by example, so we're
        best off understanding the issue thoroughly first.
        
        There's a whole spectrum of potential solutions that haven't been
        discussed - I myself have two approaches I'm working on that may solve
        this problem in ways you haven't (publicly) considered. I'm sure there
        are many others out there.
        
        -- 
        'peter'[:-1]@petertodd.org
        00000000000000005144f6a7109b9f8543880a0a5f85a054ec53966bc2daa24c
        
        [-- Attachment #2: Digital signature --]
        [-- Type: application/pgp-signature, Size: 490 bytes --]
        
        ^ permalink raw reply	[flat|nested] 17+ messages in thread

  • * Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
      2013-11-05 17:05 ` Peter Todd
      2013-11-05 17:14   ` Peter Todd
    @ 2013-11-05 17:26   ` Ittay
      2013-11-05 17:37     ` Patrick
      2013-11-05 18:57     ` Jeremy Spilman
      1 sibling, 2 replies; 17+ messages in thread
    From: Ittay @ 2013-11-05 17:26 UTC (permalink / raw)
      To: Peter Todd; +Cc: Ittay, Gavin Andresen, Emin Gün Sirer, Bitcoin Dev
    
    [-- Attachment #1: Type: text/plain, Size: 1747 bytes --]
    
    That sounds like selfish mining, and the magic number is 25%. That's the
    minimal pool size.
    Today the threshold is 0% with good connectivity.
    
    If I misunderstood your point, please elaborate.
    
    Ittay
    
    
    
    On Tue, Nov 5, 2013 at 12:05 PM, Peter Todd <pete@petertodd•org> wrote:
    
    > On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
    > > Hello,
    > >
    > > Please see below our BIP for raising the selfish mining threshold.
    > > Looking forward to your comments.
    >
    > <snip>
    >
    > > 2. No new vulnerabilities introduced:
    > > Currently the choice among equal-length chains is done arbitrarily,
    > > depending on network topology. This arbitrariness is a source of
    > > vulnerability. We replace it with explicit randomness, which is at the
    > > control of the protocol. The change does not introduce executions that
    > were
    > > not possible with the old protocol.
    >
    > Credit goes to Gregory Maxwell for pointing this out, but the random
    > choice solution does in fact introduce a vulnerability in that it
    > creates incentives for pools over a certain size to withhold blocks
    > rather than immediately broadcasting all blocks found.
    >
    > The problem is that when the pool eventually choses to reveal the block
    > they mined, 50% of the hashing power switches, thus splitting the
    > network. Like the original attack this can be to their benefit. For
    > pools over a certain size this strategy is profitable even without
    > investing in a low-latency network; Maxwell or someone else can chime in
    > with the details for deriving that threshold.
    >
    > I won't get a chance to for a few hours, but someone should do the
    > analysis on a deterministic switching scheme.
    >
    > --
    > 'peter'[:-1]@petertodd.org
    > 0000000000000005e25ca9b9fe62bdd6e8a2b4527ad61753dd2113c268bec707
    >
    
    [-- Attachment #2: Type: text/html, Size: 2432 bytes --]
    
    ^ permalink raw reply	[flat|nested] 17+ messages in thread

  • • * Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
        2013-11-05 17:26   ` Ittay
      @ 2013-11-05 17:37     ` Patrick
        2013-11-05 18:18       ` Alessandro Parisi
        2013-11-05 18:57     ` Jeremy Spilman
        1 sibling, 1 reply; 17+ messages in thread
      From: Patrick @ 2013-11-05 17:37 UTC (permalink / raw)
        To: bitcoin-development
      
      [-- Attachment #1: Type: text/plain, Size: 2862 bytes --]
      
      The ratio of honest miners that mine the first block they see is > 0.5
      
      Your proposed solution would reduce that ratio to 0.5
      
      In other words your proposed change would make the attack you describe
      easier not harder.
      
      On 11/05/2013 09:26 AM, Ittay wrote:
      > That sounds like selfish mining, and the magic number is 25%. That's
      > the minimal pool size. 
      > Today the threshold is 0% with good connectivity. 
      >
      > If I misunderstood your point, please elaborate. 
      >
      > Ittay 
      >
      >
      >
      > On Tue, Nov 5, 2013 at 12:05 PM, Peter Todd <pete@petertodd•org
      > <mailto:pete@petertodd•org>> wrote:
      >
      >     On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
      >     > Hello,
      >     >
      >     > Please see below our BIP for raising the selfish mining threshold.
      >     > Looking forward to your comments.
      >
      >     <snip>
      >
      >     > 2. No new vulnerabilities introduced:
      >     > Currently the choice among equal-length chains is done arbitrarily,
      >     > depending on network topology. This arbitrariness is a source of
      >     > vulnerability. We replace it with explicit randomness, which is
      >     at the
      >     > control of the protocol. The change does not introduce
      >     executions that were
      >     > not possible with the old protocol.
      >
      >     Credit goes to Gregory Maxwell for pointing this out, but the random
      >     choice solution does in fact introduce a vulnerability in that it
      >     creates incentives for pools over a certain size to withhold blocks
      >     rather than immediately broadcasting all blocks found.
      >
      >     The problem is that when the pool eventually choses to reveal the
      >     block
      >     they mined, 50% of the hashing power switches, thus splitting the
      >     network. Like the original attack this can be to their benefit. For
      >     pools over a certain size this strategy is profitable even without
      >     investing in a low-latency network; Maxwell or someone else can
      >     chime in
      >     with the details for deriving that threshold.
      >
      >     I won't get a chance to for a few hours, but someone should do the
      >     analysis on a deterministic switching scheme.
      >
      >     --
      >     'peter'[:-1]@petertodd.org <http://petertodd.org>
      >     0000000000000005e25ca9b9fe62bdd6e8a2b4527ad61753dd2113c268bec707
      >
      >
      >
      >
      > ------------------------------------------------------------------------------
      > November Webinars for C, C++, Fortran Developers
      > Accelerate application performance with scalable programming models. Explore
      > techniques for threading, error checking, porting, and tuning. Get the most 
      > from the latest Intel processors and coprocessors. See abstracts and register
      > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
      >
      >
      > _______________________________________________
      > Bitcoin-development mailing list
      > Bitcoin-development@lists•sourceforge.net
      > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
      
      
      [-- Attachment #2: Type: text/html, Size: 5169 bytes --]
      
      ^ permalink raw reply	[flat|nested] 17+ messages in thread

    • • * Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
          2013-11-05 17:37     ` Patrick
        @ 2013-11-05 18:18       ` Alessandro Parisi
          0 siblings, 0 replies; 17+ messages in thread
        From: Alessandro Parisi @ 2013-11-05 18:18 UTC (permalink / raw)
          To: Patrick; +Cc: Bitcoin Dev
        
        [-- Attachment #1: Type: text/plain, Size: 3578 bytes --]
        
        Patrick, could you please explain us why the solution proposed by Ittay
        would drop the actual honest miners ratio, becoming so backfire? Thanks a
        lot
        
        
        2013/11/5 Patrick <patrick@intersango•com>
        
        >  The ratio of honest miners that mine the first block they see is > 0.5
        >
        > Your proposed solution would reduce that ratio to 0.5
        >
        > In other words your proposed change would make the attack you describe
        > easier not harder.
        >
        >
        > On 11/05/2013 09:26 AM, Ittay wrote:
        >
        > That sounds like selfish mining, and the magic number is 25%. That's the
        > minimal pool size.
        > Today the threshold is 0% with good connectivity.
        >
        >  If I misunderstood your point, please elaborate.
        >
        >  Ittay
        >
        >
        >
        > On Tue, Nov 5, 2013 at 12:05 PM, Peter Todd <pete@petertodd•org> wrote:
        >
        >> On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
        >> > Hello,
        >> >
        >> > Please see below our BIP for raising the selfish mining threshold.
        >> > Looking forward to your comments.
        >>
        >>  <snip>
        >>
        >> > 2. No new vulnerabilities introduced:
        >> > Currently the choice among equal-length chains is done arbitrarily,
        >> > depending on network topology. This arbitrariness is a source of
        >> > vulnerability. We replace it with explicit randomness, which is at the
        >> > control of the protocol. The change does not introduce executions that
        >> were
        >> > not possible with the old protocol.
        >>
        >>  Credit goes to Gregory Maxwell for pointing this out, but the random
        >> choice solution does in fact introduce a vulnerability in that it
        >> creates incentives for pools over a certain size to withhold blocks
        >> rather than immediately broadcasting all blocks found.
        >>
        >> The problem is that when the pool eventually choses to reveal the block
        >> they mined, 50% of the hashing power switches, thus splitting the
        >> network. Like the original attack this can be to their benefit. For
        >> pools over a certain size this strategy is profitable even without
        >> investing in a low-latency network; Maxwell or someone else can chime in
        >> with the details for deriving that threshold.
        >>
        >> I won't get a chance to for a few hours, but someone should do the
        >> analysis on a deterministic switching scheme.
        >>
        >> --
        >> 'peter'[:-1]@petertodd.org
        >> 0000000000000005e25ca9b9fe62bdd6e8a2b4527ad61753dd2113c268bec707
        >>
        >
        >
        >
        > ------------------------------------------------------------------------------
        > November Webinars for C, C++, Fortran Developers
        > Accelerate application performance with scalable programming models. Explore
        > techniques for threading, error checking, porting, and tuning. Get the most
        > from the latest Intel processors and coprocessors. See abstracts and registerhttp://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
        >
        >
        >
        > _______________________________________________
        > Bitcoin-development mailing listBitcoin-development@lists•sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
        >
        >
        >
        >
        > ------------------------------------------------------------------------------
        > November Webinars for C, C++, Fortran Developers
        > Accelerate application performance with scalable programming models.
        > Explore
        > techniques for threading, error checking, porting, and tuning. Get the most
        > from the latest Intel processors and coprocessors. See abstracts and
        > register
        > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
        > _______________________________________________
        > Bitcoin-development mailing list
        > Bitcoin-development@lists•sourceforge.net
        > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
        >
        >
        
        [-- Attachment #2: Type: text/html, Size: 6383 bytes --]
        
        ^ permalink raw reply	[flat|nested] 17+ messages in thread

    • * Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
        2013-11-05 17:26   ` Ittay
        2013-11-05 17:37     ` Patrick
      @ 2013-11-05 18:57     ` Jeremy Spilman
        2013-11-05 22:49       ` Ittay
        1 sibling, 1 reply; 17+ messages in thread
      From: Jeremy Spilman @ 2013-11-05 18:57 UTC (permalink / raw)
        To: Peter Todd, Ittay; +Cc: Bitcoin Dev, Gavin Andresen, Emin Gün Sirer
      
      [-- Attachment #1: Type: text/plain, Size: 2920 bytes --]
      
      Great paper Ittay, thanks for all your work on this.
      
      > Today the threshold is 0% with good connectivity.
      
      Fig. 2 captures this well, the threshold is only zero if 'y' is 1. In  
      Section 6 and 6.1 you argue y -> 1 but the sybil attack you describe,  
      isn't that more like how *all* sophisticated miners would want to ensure  
      their blocks are widely propagated? I think you can't assume only the  
      selfish miner is doing it.
      
      Based on the current  'first seen' algorithm, as you say, competing  
      longest chains happen about every 60 blocks.  The rest of the time, a  
      single block propagates through the vast majority of the network  
      'uncontested'.  If there are multiple valid longest blocks being  
      simultaneously propagated, then  propagation pattern of the competing  
      blocks will determine hash rate on each.
      
      Selfish mining requires exploiting the race condition between learning  
      about a competing block, and publishing your own. Usually we talk about  
      minimizing publishing latency so that your block ends up uncontested 59/60  
      times, and in the 1/60 times, even then your block has the best chance of  
      winning.
      
      Selfish mining forgoes the 59/60 chance of your block being uncontested,  
      and instead chooses to 'race the network' every time. You start 'one step  
      behind' the competing block (since of course you only learn about it after  
      it starts propagating), so you must rely on being able to outrace  
      propagation of the competing block through a private low-latency  
      side-network which can inject your block at multiple points throughout the  
      bitcoin p2p network to outrace the competitor.
      
      I think it's a stretch to say 'y' is 0 with good connectivity. Even the  
      best connected mining pools today are concerned with this 'y' factor.
      
      Here's a probably very dumb idea... to throw out one possible "solution"...
      
      You want a way to fake-out the 'selfish miner' into disclosing their  
      blocks -- how can your force their hand to prevent them from accumulating  
      longer private chains?
      
      What if you propagate (and relay) an encrypted block header which honest  
      miners will timestamp when they receive it, then 10 seconds later  
      propagate the decryption key to unblind it. But here's the catch - maybe  
      the decryption results in junk, maybe it results a new longer block. If  
      it's a real block then it gets priority based on when the ciphertext was  
      received instead of when the decryption key was received. Now 'selfish  
      miner' can't race the network anymore, because they are always in state 0'  
      and can't tell if they are up against a ghost, or a real competing block.  
      If they wait for the decryption key to check, it's too late, and they are  
      guaranteed to lose unless they can out-race the network, e.g. back at  
      t=50%. Of course there would need to be some way to anti-DDoS this which  
      allows for some amount of these fake-outs without letting them get out of  
      hand.
      
      Thanks,
      Jeremy
      
      [-- Attachment #2.1: Type: text/html, Size: 3441 bytes --]
      
      ^ permalink raw reply	[flat|nested] 17+ messages in thread

    • • * Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
          2013-11-05 18:57     ` Jeremy Spilman
        @ 2013-11-05 22:49       ` Ittay
          0 siblings, 0 replies; 17+ messages in thread
        From: Ittay @ 2013-11-05 22:49 UTC (permalink / raw)
          To: Jeremy Spilman; +Cc: Ittay, Gavin Andresen, Emin Gün Sirer, Bitcoin Dev
        
        [-- Attachment #1: Type: text/plain, Size: 1883 bytes --]
        
        On Tue, Nov 5, 2013 at 1:57 PM, Jeremy Spilman <jeremy@taplink•co> wrote:
        
        
        > I think it's a stretch to say 'y' is 0 with good connectivity. Even the
        > best connected mining pools today are concerned with this 'y' factor.
        >
        
        Check out the following paper for the effect a single node can have on
        propagation, and on the relation between block size and propagation speed.
        This strongly supports our assumption.
        http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf
        
        
        >
        > Here's a probably very dumb idea... to throw out one possible "solution"...
        >
        > You want a way to fake-out the 'selfish miner' into disclosing their
        > blocks -- how can your force their hand to prevent them from accumulating
        > longer private chains?
        >
        > What if you propagate (and relay) an encrypted block header which honest
        > miners will timestamp when they receive it, then 10 seconds later propagate
        > the decryption key to unblind it. But here's the catch - maybe the
        > decryption results in junk, maybe it results a new longer block. If it's a
        > real block then it gets priority based on when the ciphertext was received
        > instead of when the decryption key was received. Now 'selfish miner' can't
        > race the network anymore, because they are always in state 0' and can't
        > tell if they are up against a ghost, or a real competing block. If they
        > wait for the decryption key to check, it's too late, and they are
        > guaranteed to lose unless they can out-race the network, e.g. back at
        > t=50%. Of course there would need to be some way to anti-DDoS this which
        > allows for some amount of these fake-outs without letting them get out of
        > hand.
        >
        
        That's a dangerous way to go, opening the door to DoS attacks, as you
        mention. Besides, it makes a simple algorithm complicated, and doing such
        changes may lead to different vulnerabilities that are difficult to cover.
        
        Best,
        Ittay
        
        [-- Attachment #2: Type: text/html, Size: 2885 bytes --]
        
        ^ permalink raw reply	[flat|nested] 17+ messages in thread

• * [Bitcoin-development] comments on selfish-mining model (Re: BIP proposal - patch to raise selfish mining threshold.)
    2013-11-05 16:56 [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold Ittay
    2013-11-05 17:05 ` Peter Todd
  @ 2013-11-07 20:05 ` Adam Back
    1 sibling, 0 replies; 17+ messages in thread
  From: Adam Back @ 2013-11-07 20:05 UTC (permalink / raw)
    To: Ittay; +Cc: Bitcoin Dev, Gavin Andresen, Emin Gün Sirer
  
  (Talking about the paper, not the BIP).  With regard to racing the other
  winner which catches up when private pool length=1:
  
  i) the model does not appear to take into account that when another pool
  goes on to mine a block, and the attacker publishes their selfishly-withheld
  block, the selfish pool will not be able to change the existing winners
  mind.  This is not insignificant as the pools have 30%, 20%, 15%, 7% etc. 
  
  ii) The miners already have an incentive, as other big bitcoin processors,
  to maintain fast, secure and redundant links to other significant miners. 
  
  The attacker is giving up a large proportion of their winnings from the
  times that they win at all.  Say the attacker IS the 30% pool, when he wins
  and waits for someone else to win, > 80% of the network is pool mined, so
  there is a good chance that the other winner individually represents a
  non-negligible proportion of the network or a sufficiently well connected
  portion of the network that the attacker will be unable to race them to
  publication with a useful proportion of the network.
  
  iii) Also broadcast is not instantaneous, lets say network propagation takes
  10 seconds; a big proportion of the time, the actual mining times will be
  more than 5 seconds apart so that by the time the selfish miner learns of
  the block, much of the network will already have accepted it block as first.
  
  iv) Even within the 10 seconds ambiguity period, the more powerful miner
  will tend statistically to come first, and so reach a bigger portion of the
  network, as well as having a stronger incentive to maintain links as in ii).
  
  These four factors erode the achievable \gamma parameter.  I suspect it
  unlikely \gamma>0.5 would be achievable, putting the profitable threshold
  \alpha in 25% - 33%.  (And assuming whatever techniques to reduce latency
  are used by the selfish pools can be used by other pools.)
  
  
  Your main result that even with \gamma=0 (if you dont win any races) that
  you still win once the selfish pool reaches 33% is an important new
  indication, which needs further consideration.  (And you could expect to win
  some percentage \gamma>0 even with the factors I mention, and full
  implementation of the same latency reduction techniques in all moderate
  sized miners, selfish and normal).
  
  It is also not clear what will happen if multiple selfish miners compete
  with each other.  A selfish miner cooperating as a peer to increase
  percentage runs risk of mutual sabotage - he has to announce his private
  block to his co-conspirator, and the co-conspirator may publish, or collude
  with another non-selfish miner.  
  
  Your supposition is there is a profit motive to collude.  However there are
  other profit motives in bitcoin that are not exercised - for example there
  were for sometime 2 pools that had excess of 50% power, and yet this was not
  abused for double spending.  Of course increasing profit by a new mining
  strategy is not theft as double spending which has a clear loser.  Miners
  even exercised restraint and volutarily avoided growing over 50%.
  
  
  As others have I think said by now analysis is welcome.  It seems that Peter
  Todd may have observed the same or something similar wrt miner incentives
  some months ago, though it wasnt as widely read nor formally verified.  
  
  It might be useful to release the source for your simulator if that is open
  to you.
  
  
  In my opinion a constructive direction for reducing centralization risks is
  to try to reduce the use of and motivation for pools.  Even at <51% per pool
  there is (probabilistic) miner risk in double-spends.  And there is risk
  that the large miners evolve to become a defacto policy enforcement point
  for policies not aligned with user interests, or with fungibility of bitcoin
  which itself presents another kind of risk (defacto reduced fungibility
  should this arise would also be bad for bitcoin).
  
  Also without even having mining power, there is scope to network hacking (eg
  of routers in front of miners) to influence the mining profit, and even
  double spend.  As I mentioned large miners have an incentive to maintain
  secure redudant links (probably some links using Tor for blocks) as a
  counter-measure. 
  
  Adam
  
  On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
  >   Hello,
  >   Please see below our BIP for raising the selfish mining threshold.
  >   Looking forward to your comments.
  
  
  
  ^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2013-11-07 20:05 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-05 16:56 [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold Ittay
2013-11-05 17:05 ` Peter Todd
2013-11-05 17:14   ` Peter Todd
2013-11-05 17:43     ` Ittay
2013-11-05 17:54       ` Mike Hearn
2013-11-05 18:07         ` Alessandro Parisi
2013-11-05 18:37           ` Jeff Garzik
2013-11-05 18:55             ` Alessandro Parisi
2013-11-05 18:58               ` Jeff Garzik
2013-11-05 19:33                 ` Jameson Lopp
2013-11-05 19:56       ` Peter Todd
2013-11-05 17:26   ` Ittay
2013-11-05 17:37     ` Patrick
2013-11-05 18:18       ` Alessandro Parisi
2013-11-05 18:57     ` Jeremy Spilman
2013-11-05 22:49       ` Ittay
2013-11-07 20:05 ` [Bitcoin-development] comments on selfish-mining model (Re: BIP proposal - patch to raise selfish mining threshold.) Adam Back

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox