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

* [bitcoin-dev] Selfish Mining Prevention
@ 2018-09-01  0:11 Andrew
  2018-09-13 23:19 ` Andrew
  0 siblings, 1 reply; 14+ messages in thread
From: Andrew @ 2018-09-01  0:11 UTC (permalink / raw)
  To: Bitcoin Dev

As I understand, selfish mining is an attack where miners collude to
mine at a lower hashrate then with all miners working independently.
What are the current strategies used to prevent this and what are the
future plans?

One idea I have is to let the block reward get "modulated" according
to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)
consisting of 144 blocks, h is the hashrate of the last 144 block (1
day) period, and r is the base subsidy (12.5 BTC currently). You can
then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
peak you get the full reward. Otherwise you get less, down to a min of
0.5 r.

If miners were to collude to mine at a lower than peak hashrate, then
they may be able to do it profitably for 144 blocks, but after that,
the reward would get modulated and it wouldn't be so much in their
interest to continue mining at the lower hashrate.

What flaws are there with this? I know it could be controversial due
to easier mining present for early miners, so maybe it would have to
be done in combination with a new more dynamic difficulty adjustment
algorithm. But I don't see how hashrate can continue rising
indefinitely, so a solution should be made for selfish mining.

Also when subsidies stop and a fee market is needed, I guess a portion
of the fees can be withheld for later if hashrate is not at peak.


-- 
PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647


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

• * Re: [bitcoin-dev] Selfish Mining Prevention
    2018-09-01  0:11 [bitcoin-dev] Selfish Mining Prevention Andrew
  @ 2018-09-13 23:19 ` Andrew
    2018-09-14 14:49   ` Moral Agent
    2018-09-15  5:29   ` Damian Williamson
    0 siblings, 2 replies; 14+ messages in thread
  From: Andrew @ 2018-09-13 23:19 UTC (permalink / raw)
    To: Bitcoin Dev
  
  I discussed this more at bitcointalk:
  https://bitcointalk.org/index.php?topic=4998410.0
  
  The attacks I'm interested in preventing are not only selfish mining
  and collusion, but also more subtle attacks like block withholding,
  and in general anything that aims to drive out the competition in
  order to increase hashrate fraction. I also scrapped the idea of
  changing the block subsidies, and I am only focuses on fees.
  
  You can read more about the motivation and details in the bitcointalk
  thread, but my proposal in short would be to add the concept of
  "reserve fees". When a user makes a transaction, for each txout
  script, they can add parameters that specify the fraction of the total
  fee that is held in "reserve" and the time it is held in "reserve"
  (can set a limit of 2016 blocks). This "reserve" part of the fee will
  be paid to miners if the hashrate rises. So if hashrate is currently h
  and peak hashrate (from past year) is p, then for each period (1 day),
  a new hashrate is calculated h1, and if h1 > h, then the fraction
  (h1-h)/p from the reserve fees created in the past 2016 blocks will be
  released to miners for that period (spread out over the 144 blocks in
  that period). And this will keep happening as long as hashrate keeps
  rising, until the "contract" expires, and the leftover part can be
  used by the owner of the unspent output, but it can only be used for
  paying fees, not as inputs for future transactions (to save on block
  space).
  
  This should incentivize miners to not drive out the competition, since
  if they do, there will be less of these reserve fees given to miners.
  Yes in the end the miners will get all the fees, but with rising
  hashrate they get an unconditional subsidy that does not require
  transactions, thus more space for transactions with fees.
  
  I can make a formal BIP and pull request, but I need to know if there
  is interest in this. Now fees don't play such a large part of the
  block reward, but they will get more important, and this change
  wouldn't force anything (would be voluntary by each user), just miners
  have to agree to it with a soft fork (so they don't spend from the
  anyone-can-spend outputs used for reserve fees). Resource requirements
  for validation are quite small I believe.
  
  On Sat, Sep 1, 2018 at 12:11 AM, Andrew <onelineproof@gmail•com> wrote:
  > As I understand, selfish mining is an attack where miners collude to
  > mine at a lower hashrate then with all miners working independently.
  > What are the current strategies used to prevent this and what are the
  > future plans?
  >
  > One idea I have is to let the block reward get "modulated" according
  > to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)
  > consisting of 144 blocks, h is the hashrate of the last 144 block (1
  > day) period, and r is the base subsidy (12.5 BTC currently). You can
  > then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
  > peak you get the full reward. Otherwise you get less, down to a min of
  > 0.5 r.
  >
  > If miners were to collude to mine at a lower than peak hashrate, then
  > they may be able to do it profitably for 144 blocks, but after that,
  > the reward would get modulated and it wouldn't be so much in their
  > interest to continue mining at the lower hashrate.
  >
  > What flaws are there with this? I know it could be controversial due
  > to easier mining present for early miners, so maybe it would have to
  > be done in combination with a new more dynamic difficulty adjustment
  > algorithm. But I don't see how hashrate can continue rising
  > indefinitely, so a solution should be made for selfish mining.
  >
  > Also when subsidies stop and a fee market is needed, I guess a portion
  > of the fees can be withheld for later if hashrate is not at peak.
  >
  >
  > --
  > PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
  
  
  
  -- 
  PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
  
  
  ^ permalink raw reply	[flat|nested] 14+ messages in thread

• • * Re: [bitcoin-dev] Selfish Mining Prevention
      2018-09-13 23:19 ` Andrew
    @ 2018-09-14 14:49   ` Moral Agent
      2018-09-14 17:30     ` Andrew
      2018-09-15  5:29   ` Damian Williamson
      1 sibling, 1 reply; 14+ messages in thread
    From: Moral Agent @ 2018-09-14 14:49 UTC (permalink / raw)
      To: onelineproof, Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 5070 bytes --]
    
    You might be interested in an idea I wrote about that is in a similar
    spirit here:
    
    https://medium.com/coinmonks/taming-large-miners-with-helper-blocks-6ae67ac242f6
    
    From the article:
    
    When a block is solved, it randomly selects one satoshi from the utxo set
    and gives whomever controls that satoshi the power to generate a “Helper
    Block”. The Helper Block commits to a subset of transactions for inclusion
    in the next block. A miner can accept the Helper Block by including the
    suggested transactions and giving the associated transaction fees to a
    payment address specified in the Helper Block. Miners who do not use a
    Helper Block must satisfy a 25% higher difficulty.
    
    On Fri, Sep 14, 2018 at 9:56 AM Andrew via bitcoin-dev <
    bitcoin-dev@lists•linuxfoundation.org> wrote:
    
    > I discussed this more at bitcointalk:
    > https://bitcointalk.org/index.php?topic=4998410.0
    >
    > The attacks I'm interested in preventing are not only selfish mining
    > and collusion, but also more subtle attacks like block withholding,
    > and in general anything that aims to drive out the competition in
    > order to increase hashrate fraction. I also scrapped the idea of
    > changing the block subsidies, and I am only focuses on fees.
    >
    > You can read more about the motivation and details in the bitcointalk
    > thread, but my proposal in short would be to add the concept of
    > "reserve fees". When a user makes a transaction, for each txout
    > script, they can add parameters that specify the fraction of the total
    > fee that is held in "reserve" and the time it is held in "reserve"
    > (can set a limit of 2016 blocks). This "reserve" part of the fee will
    > be paid to miners if the hashrate rises. So if hashrate is currently h
    > and peak hashrate (from past year) is p, then for each period (1 day),
    > a new hashrate is calculated h1, and if h1 > h, then the fraction
    > (h1-h)/p from the reserve fees created in the past 2016 blocks will be
    > released to miners for that period (spread out over the 144 blocks in
    > that period). And this will keep happening as long as hashrate keeps
    > rising, until the "contract" expires, and the leftover part can be
    > used by the owner of the unspent output, but it can only be used for
    > paying fees, not as inputs for future transactions (to save on block
    > space).
    >
    > This should incentivize miners to not drive out the competition, since
    > if they do, there will be less of these reserve fees given to miners.
    > Yes in the end the miners will get all the fees, but with rising
    > hashrate they get an unconditional subsidy that does not require
    > transactions, thus more space for transactions with fees.
    >
    > I can make a formal BIP and pull request, but I need to know if there
    > is interest in this. Now fees don't play such a large part of the
    > block reward, but they will get more important, and this change
    > wouldn't force anything (would be voluntary by each user), just miners
    > have to agree to it with a soft fork (so they don't spend from the
    > anyone-can-spend outputs used for reserve fees). Resource requirements
    > for validation are quite small I believe.
    >
    > On Sat, Sep 1, 2018 at 12:11 AM, Andrew <onelineproof@gmail•com> wrote:
    > > As I understand, selfish mining is an attack where miners collude to
    > > mine at a lower hashrate then with all miners working independently.
    > > What are the current strategies used to prevent this and what are the
    > > future plans?
    > >
    > > One idea I have is to let the block reward get "modulated" according
    > > to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)
    > > consisting of 144 blocks, h is the hashrate of the last 144 block (1
    > > day) period, and r is the base subsidy (12.5 BTC currently). You can
    > > then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
    > > peak you get the full reward. Otherwise you get less, down to a min of
    > > 0.5 r.
    > >
    > > If miners were to collude to mine at a lower than peak hashrate, then
    > > they may be able to do it profitably for 144 blocks, but after that,
    > > the reward would get modulated and it wouldn't be so much in their
    > > interest to continue mining at the lower hashrate.
    > >
    > > What flaws are there with this? I know it could be controversial due
    > > to easier mining present for early miners, so maybe it would have to
    > > be done in combination with a new more dynamic difficulty adjustment
    > > algorithm. But I don't see how hashrate can continue rising
    > > indefinitely, so a solution should be made for selfish mining.
    > >
    > > Also when subsidies stop and a fee market is needed, I guess a portion
    > > of the fees can be withheld for later if hashrate is not at peak.
    > >
    > >
    > > --
    > > PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
    >
    >
    >
    > --
    > PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
    > _______________________________________________
    > bitcoin-dev mailing list
    > bitcoin-dev@lists•linuxfoundation.org
    > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
    >
    
    [-- Attachment #2: Type: text/html, Size: 6202 bytes --]
    
    ^ permalink raw reply	[flat|nested] 14+ messages in thread

  • • * Re: [bitcoin-dev] Selfish Mining Prevention
        2018-09-14 14:49   ` Moral Agent
      @ 2018-09-14 17:30     ` Andrew
        2018-09-14 18:00       ` Moral Agent
        0 siblings, 1 reply; 14+ messages in thread
      From: Andrew @ 2018-09-14 17:30 UTC (permalink / raw)
        To: Moral Agent; +Cc: Bitcoin Protocol Discussion
      
      (reposting to whole list instead of just him) @Moral Agent:
      Interesting proposal though it introduces some elements
      of proof of stake so it would be more controversial in my view. Also,
      something needs to be explained about how this would not create an
      attack where difficulty is frequently dropping by 25%, and suddenly we
      find ourselves with a very low difficulty and PoW attacks can easily
      happen. I need to analyse your proposal more, but I prefer to discuss
      it on your blog instead of here just to limit the side topics and
      focus only on my proposal.
      
      No one has yet given me a good reason for why not to support my proposal...
      
      On Fri, Sep 14, 2018 at 2:49 PM, Moral Agent <ethan.scruples@gmail•com> wrote:
      > You might be interested in an idea I wrote about that is in a similar spirit
      > here:
      >
      > https://medium.com/coinmonks/taming-large-miners-with-helper-blocks-6ae67ac242f6
      >
      > From the article:
      >
      > When a block is solved, it randomly selects one satoshi from the utxo set
      > and gives whomever controls that satoshi the power to generate a “Helper
      > Block”. The Helper Block commits to a subset of transactions for inclusion
      > in the next block. A miner can accept the Helper Block by including the
      > suggested transactions and giving the associated transaction fees to a
      > payment address specified in the Helper Block. Miners who do not use a
      > Helper Block must satisfy a 25% higher difficulty.
      >
      > On Fri, Sep 14, 2018 at 9:56 AM Andrew via bitcoin-dev
      > <bitcoin-dev@lists•linuxfoundation.org> wrote:
      >>
      >> I discussed this more at bitcointalk:
      >> https://bitcointalk.org/index.php?topic=4998410.0
      >>
      >> The attacks I'm interested in preventing are not only selfish mining
      >> and collusion, but also more subtle attacks like block withholding,
      >> and in general anything that aims to drive out the competition in
      >> order to increase hashrate fraction. I also scrapped the idea of
      >> changing the block subsidies, and I am only focuses on fees.
      >>
      >> You can read more about the motivation and details in the bitcointalk
      >> thread, but my proposal in short would be to add the concept of
      >> "reserve fees". When a user makes a transaction, for each txout
      >> script, they can add parameters that specify the fraction of the total
      >> fee that is held in "reserve" and the time it is held in "reserve"
      >> (can set a limit of 2016 blocks). This "reserve" part of the fee will
      >> be paid to miners if the hashrate rises. So if hashrate is currently h
      >> and peak hashrate (from past year) is p, then for each period (1 day),
      >> a new hashrate is calculated h1, and if h1 > h, then the fraction
      >> (h1-h)/p from the reserve fees created in the past 2016 blocks will be
      >> released to miners for that period (spread out over the 144 blocks in
      >> that period). And this will keep happening as long as hashrate keeps
      >> rising, until the "contract" expires, and the leftover part can be
      >> used by the owner of the unspent output, but it can only be used for
      >> paying fees, not as inputs for future transactions (to save on block
      >> space).
      >>
      >> This should incentivize miners to not drive out the competition, since
      >> if they do, there will be less of these reserve fees given to miners.
      >> Yes in the end the miners will get all the fees, but with rising
      >> hashrate they get an unconditional subsidy that does not require
      >> transactions, thus more space for transactions with fees.
      >>
      >> I can make a formal BIP and pull request, but I need to know if there
      >> is interest in this. Now fees don't play such a large part of the
      >> block reward, but they will get more important, and this change
      >> wouldn't force anything (would be voluntary by each user), just miners
      >> have to agree to it with a soft fork (so they don't spend from the
      >> anyone-can-spend outputs used for reserve fees). Resource requirements
      >> for validation are quite small I believe.
      >>
      >> On Sat, Sep 1, 2018 at 12:11 AM, Andrew <onelineproof@gmail•com> wrote:
      >> > As I understand, selfish mining is an attack where miners collude to
      >> > mine at a lower hashrate then with all miners working independently.
      >> > What are the current strategies used to prevent this and what are the
      >> > future plans?
      >> >
      >> > One idea I have is to let the block reward get "modulated" according
      >> > to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)
      >> > consisting of 144 blocks, h is the hashrate of the last 144 block (1
      >> > day) period, and r is the base subsidy (12.5 BTC currently). You can
      >> > then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
      >> > peak you get the full reward. Otherwise you get less, down to a min of
      >> > 0.5 r.
      >> >
      >> > If miners were to collude to mine at a lower than peak hashrate, then
      >> > they may be able to do it profitably for 144 blocks, but after that,
      >> > the reward would get modulated and it wouldn't be so much in their
      >> > interest to continue mining at the lower hashrate.
      >> >
      >> > What flaws are there with this? I know it could be controversial due
      >> > to easier mining present for early miners, so maybe it would have to
      >> > be done in combination with a new more dynamic difficulty adjustment
      >> > algorithm. But I don't see how hashrate can continue rising
      >> > indefinitely, so a solution should be made for selfish mining.
      >> >
      >> > Also when subsidies stop and a fee market is needed, I guess a portion
      >> > of the fees can be withheld for later if hashrate is not at peak.
      >> >
      >> >
      >> > --
      >> > PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
      >>
      >>
      >>
      >> --
      >> PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
      >> _______________________________________________
      >> bitcoin-dev mailing list
      >> bitcoin-dev@lists•linuxfoundation.org
      >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      
      
      
      -- 
      PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
      
      
      ^ permalink raw reply	[flat|nested] 14+ messages in thread

    • • * Re: [bitcoin-dev] Selfish Mining Prevention
          2018-09-14 17:30     ` Andrew
        @ 2018-09-14 18:00       ` Moral Agent
          0 siblings, 0 replies; 14+ messages in thread
        From: Moral Agent @ 2018-09-14 18:00 UTC (permalink / raw)
          To: Andrew K; +Cc: Bitcoin Protocol Discussion
        
        [-- Attachment #1: Type: text/plain, Size: 6389 bytes --]
        
        Thank you, and my apologies. I should have sent that link just to you and
        not put everyone on cc.
        
        On Fri, Sep 14, 2018 at 1:30 PM Andrew <onelineproof@gmail•com> wrote:
        
        > (reposting to whole list instead of just him) @Moral Agent:
        > Interesting proposal though it introduces some elements
        > of proof of stake so it would be more controversial in my view. Also,
        > something needs to be explained about how this would not create an
        > attack where difficulty is frequently dropping by 25%, and suddenly we
        > find ourselves with a very low difficulty and PoW attacks can easily
        > happen. I need to analyse your proposal more, but I prefer to discuss
        > it on your blog instead of here just to limit the side topics and
        > focus only on my proposal.
        >
        > No one has yet given me a good reason for why not to support my proposal...
        >
        > On Fri, Sep 14, 2018 at 2:49 PM, Moral Agent <ethan.scruples@gmail•com>
        > wrote:
        > > You might be interested in an idea I wrote about that is in a similar
        > spirit
        > > here:
        > >
        > >
        > https://medium.com/coinmonks/taming-large-miners-with-helper-blocks-6ae67ac242f6
        > >
        > > From the article:
        > >
        > > When a block is solved, it randomly selects one satoshi from the utxo set
        > > and gives whomever controls that satoshi the power to generate a “Helper
        > > Block”. The Helper Block commits to a subset of transactions for
        > inclusion
        > > in the next block. A miner can accept the Helper Block by including the
        > > suggested transactions and giving the associated transaction fees to a
        > > payment address specified in the Helper Block. Miners who do not use a
        > > Helper Block must satisfy a 25% higher difficulty.
        > >
        > > On Fri, Sep 14, 2018 at 9:56 AM Andrew via bitcoin-dev
        > > <bitcoin-dev@lists•linuxfoundation.org> wrote:
        > >>
        > >> I discussed this more at bitcointalk:
        > >> https://bitcointalk.org/index.php?topic=4998410.0
        > >>
        > >> The attacks I'm interested in preventing are not only selfish mining
        > >> and collusion, but also more subtle attacks like block withholding,
        > >> and in general anything that aims to drive out the competition in
        > >> order to increase hashrate fraction. I also scrapped the idea of
        > >> changing the block subsidies, and I am only focuses on fees.
        > >>
        > >> You can read more about the motivation and details in the bitcointalk
        > >> thread, but my proposal in short would be to add the concept of
        > >> "reserve fees". When a user makes a transaction, for each txout
        > >> script, they can add parameters that specify the fraction of the total
        > >> fee that is held in "reserve" and the time it is held in "reserve"
        > >> (can set a limit of 2016 blocks). This "reserve" part of the fee will
        > >> be paid to miners if the hashrate rises. So if hashrate is currently h
        > >> and peak hashrate (from past year) is p, then for each period (1 day),
        > >> a new hashrate is calculated h1, and if h1 > h, then the fraction
        > >> (h1-h)/p from the reserve fees created in the past 2016 blocks will be
        > >> released to miners for that period (spread out over the 144 blocks in
        > >> that period). And this will keep happening as long as hashrate keeps
        > >> rising, until the "contract" expires, and the leftover part can be
        > >> used by the owner of the unspent output, but it can only be used for
        > >> paying fees, not as inputs for future transactions (to save on block
        > >> space).
        > >>
        > >> This should incentivize miners to not drive out the competition, since
        > >> if they do, there will be less of these reserve fees given to miners.
        > >> Yes in the end the miners will get all the fees, but with rising
        > >> hashrate they get an unconditional subsidy that does not require
        > >> transactions, thus more space for transactions with fees.
        > >>
        > >> I can make a formal BIP and pull request, but I need to know if there
        > >> is interest in this. Now fees don't play such a large part of the
        > >> block reward, but they will get more important, and this change
        > >> wouldn't force anything (would be voluntary by each user), just miners
        > >> have to agree to it with a soft fork (so they don't spend from the
        > >> anyone-can-spend outputs used for reserve fees). Resource requirements
        > >> for validation are quite small I believe.
        > >>
        > >> On Sat, Sep 1, 2018 at 12:11 AM, Andrew <onelineproof@gmail•com> wrote:
        > >> > As I understand, selfish mining is an attack where miners collude to
        > >> > mine at a lower hashrate then with all miners working independently.
        > >> > What are the current strategies used to prevent this and what are the
        > >> > future plans?
        > >> >
        > >> > One idea I have is to let the block reward get "modulated" according
        > >> > to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)
        > >> > consisting of 144 blocks, h is the hashrate of the last 144 block (1
        > >> > day) period, and r is the base subsidy (12.5 BTC currently). You can
        > >> > then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
        > >> > peak you get the full reward. Otherwise you get less, down to a min of
        > >> > 0.5 r.
        > >> >
        > >> > If miners were to collude to mine at a lower than peak hashrate, then
        > >> > they may be able to do it profitably for 144 blocks, but after that,
        > >> > the reward would get modulated and it wouldn't be so much in their
        > >> > interest to continue mining at the lower hashrate.
        > >> >
        > >> > What flaws are there with this? I know it could be controversial due
        > >> > to easier mining present for early miners, so maybe it would have to
        > >> > be done in combination with a new more dynamic difficulty adjustment
        > >> > algorithm. But I don't see how hashrate can continue rising
        > >> > indefinitely, so a solution should be made for selfish mining.
        > >> >
        > >> > Also when subsidies stop and a fee market is needed, I guess a portion
        > >> > of the fees can be withheld for later if hashrate is not at peak.
        > >> >
        > >> >
        > >> > --
        > >> > PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
        > >>
        > >>
        > >>
        > >> --
        > >> PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
        > >> _______________________________________________
        > >> bitcoin-dev mailing list
        > >> bitcoin-dev@lists•linuxfoundation.org
        > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        >
        >
        >
        > --
        > PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
        >
        
        [-- Attachment #2: Type: text/html, Size: 8193 bytes --]
        
        ^ permalink raw reply	[flat|nested] 14+ messages in thread

  • * Re: [bitcoin-dev] Selfish Mining Prevention
      2018-09-13 23:19 ` Andrew
      2018-09-14 14:49   ` Moral Agent
    @ 2018-09-15  5:29   ` Damian Williamson
      2018-09-15 16:01     ` Andrew
      1 sibling, 1 reply; 14+ messages in thread
    From: Damian Williamson @ 2018-09-15  5:29 UTC (permalink / raw)
      To: Andrew, Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 4916 bytes --]
    
    >This "reserve" part of the fee will be paid to miners if the hashrate rises.
    
    
    Anticipating ongoing hashrate rise shows that you have not yet thought about moving outside of the current greed model, a model wherein mining will consume all available resources within the colony's objective just to spread as far as possible with each new miner bringing diminishing individual returns and shortening the life of Earth for no additional gain. Greed model := bacteria.
    
    ________________________________
    From: bitcoin-dev-bounces@lists•linuxfoundation.org <bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of Andrew via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
    Sent: Friday, 14 September 2018 9:19:37 AM
    To: Bitcoin Dev
    Subject: Re: [bitcoin-dev] Selfish Mining Prevention
    
    I discussed this more at bitcointalk:
    https://bitcointalk.org/index.php?topic=4998410.0
    
    The attacks I'm interested in preventing are not only selfish mining
    and collusion, but also more subtle attacks like block withholding,
    and in general anything that aims to drive out the competition in
    order to increase hashrate fraction. I also scrapped the idea of
    changing the block subsidies, and I am only focuses on fees.
    
    You can read more about the motivation and details in the bitcointalk
    thread, but my proposal in short would be to add the concept of
    "reserve fees". When a user makes a transaction, for each txout
    script, they can add parameters that specify the fraction of the total
    fee that is held in "reserve" and the time it is held in "reserve"
    (can set a limit of 2016 blocks). This "reserve" part of the fee will
    be paid to miners if the hashrate rises. So if hashrate is currently h
    and peak hashrate (from past year) is p, then for each period (1 day),
    a new hashrate is calculated h1, and if h1 > h, then the fraction
    (h1-h)/p from the reserve fees created in the past 2016 blocks will be
    released to miners for that period (spread out over the 144 blocks in
    that period). And this will keep happening as long as hashrate keeps
    rising, until the "contract" expires, and the leftover part can be
    used by the owner of the unspent output, but it can only be used for
    paying fees, not as inputs for future transactions (to save on block
    space).
    
    This should incentivize miners to not drive out the competition, since
    if they do, there will be less of these reserve fees given to miners.
    Yes in the end the miners will get all the fees, but with rising
    hashrate they get an unconditional subsidy that does not require
    transactions, thus more space for transactions with fees.
    
    I can make a formal BIP and pull request, but I need to know if there
    is interest in this. Now fees don't play such a large part of the
    block reward, but they will get more important, and this change
    wouldn't force anything (would be voluntary by each user), just miners
    have to agree to it with a soft fork (so they don't spend from the
    anyone-can-spend outputs used for reserve fees). Resource requirements
    for validation are quite small I believe.
    
    On Sat, Sep 1, 2018 at 12:11 AM, Andrew <onelineproof@gmail•com> wrote:
    > As I understand, selfish mining is an attack where miners collude to
    > mine at a lower hashrate then with all miners working independently.
    > What are the current strategies used to prevent this and what are the
    > future plans?
    >
    > One idea I have is to let the block reward get "modulated" according
    > to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)
    > consisting of 144 blocks, h is the hashrate of the last 144 block (1
    > day) period, and r is the base subsidy (12.5 BTC currently). You can
    > then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
    > peak you get the full reward. Otherwise you get less, down to a min of
    > 0.5 r.
    >
    > If miners were to collude to mine at a lower than peak hashrate, then
    > they may be able to do it profitably for 144 blocks, but after that,
    > the reward would get modulated and it wouldn't be so much in their
    > interest to continue mining at the lower hashrate.
    >
    > What flaws are there with this? I know it could be controversial due
    > to easier mining present for early miners, so maybe it would have to
    > be done in combination with a new more dynamic difficulty adjustment
    > algorithm. But I don't see how hashrate can continue rising
    > indefinitely, so a solution should be made for selfish mining.
    >
    > Also when subsidies stop and a fee market is needed, I guess a portion
    > of the fees can be withheld for later if hashrate is not at peak.
    >
    >
    > --
    > PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
    
    
    
    --
    PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
    _______________________________________________
    bitcoin-dev mailing list
    bitcoin-dev@lists•linuxfoundation.org
    https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
    
    [-- Attachment #2: Type: text/html, Size: 6466 bytes --]
    
    ^ permalink raw reply	[flat|nested] 14+ messages in thread

  • • * Re: [bitcoin-dev] Selfish Mining Prevention
        2018-09-15  5:29   ` Damian Williamson
      @ 2018-09-15 16:01     ` Andrew
        2018-09-15 22:45       ` Damian Williamson
        0 siblings, 1 reply; 14+ messages in thread
      From: Andrew @ 2018-09-15 16:01 UTC (permalink / raw)
        To: Damian Williamson; +Cc: Bitcoin Protocol Discussion
      
      @Moral Agent: No problem. I did ask in the first post what the current
      plans are for selfish miner prevention. So if anyone has any other
      relevant ideas (not just for selfish mining but for making mining more
      decentralized and competetive), then please post it, but I just prefer
      to focus on my proposal more than others.
      
      @Damian: I think you are concerned that this will incentivize more
      global resource consumption and will be detrimental to our
      environment? Personally, I believe centralization of energy does more
      harm to the environment rather than total energy consumption. If
      Bitcoin helps "power" to become more decentralized, then I wouldn't be
      surprised if total (global) energy consumption actually decreases. The
      debt based economy is forcing us to continuously grow and use up more
      resources, and collectivism is turning individuals into
      super-organisms capable of doing much more harm to the environment
      than can be done by one or a just a few individuals working
      independently. In my proposal, I actually allow for changing
      environmental conditions by measuring only the peak hashrate of the
      past year, and not the full history of blocks.
      
      On Sat, Sep 15, 2018 at 5:29 AM, Damian Williamson <willtech@live•com.au> wrote:
      >>This "reserve" part of the fee will be paid to miners if the hashrate
      >> rises.
      >
      >
      > Anticipating ongoing hashrate rise shows that you have not yet thought about
      > moving outside of the current greed model, a model wherein mining will
      > consume all available resources within the colony's objective just to spread
      > as far as possible with each new miner bringing diminishing individual
      > returns and shortening the life of Earth for no additional gain. Greed model
      > := bacteria.
      >
      > ________________________________
      > From: bitcoin-dev-bounces@lists•linuxfoundation.org
      > <bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of Andrew via
      > bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
      > Sent: Friday, 14 September 2018 9:19:37 AM
      > To: Bitcoin Dev
      > Subject: Re: [bitcoin-dev] Selfish Mining Prevention
      >
      > I discussed this more at bitcointalk:
      > https://bitcointalk.org/index.php?topic=4998410.0
      >
      > The attacks I'm interested in preventing are not only selfish mining
      > and collusion, but also more subtle attacks like block withholding,
      > and in general anything that aims to drive out the competition in
      > order to increase hashrate fraction. I also scrapped the idea of
      > changing the block subsidies, and I am only focuses on fees.
      >
      > You can read more about the motivation and details in the bitcointalk
      > thread, but my proposal in short would be to add the concept of
      > "reserve fees". When a user makes a transaction, for each txout
      > script, they can add parameters that specify the fraction of the total
      > fee that is held in "reserve" and the time it is held in "reserve"
      > (can set a limit of 2016 blocks). This "reserve" part of the fee will
      > be paid to miners if the hashrate rises. So if hashrate is currently h
      > and peak hashrate (from past year) is p, then for each period (1 day),
      > a new hashrate is calculated h1, and if h1 > h, then the fraction
      > (h1-h)/p from the reserve fees created in the past 2016 blocks will be
      > released to miners for that period (spread out over the 144 blocks in
      > that period). And this will keep happening as long as hashrate keeps
      > rising, until the "contract" expires, and the leftover part can be
      > used by the owner of the unspent output, but it can only be used for
      > paying fees, not as inputs for future transactions (to save on block
      > space).
      >
      > This should incentivize miners to not drive out the competition, since
      > if they do, there will be less of these reserve fees given to miners.
      > Yes in the end the miners will get all the fees, but with rising
      > hashrate they get an unconditional subsidy that does not require
      > transactions, thus more space for transactions with fees.
      >
      > I can make a formal BIP and pull request, but I need to know if there
      > is interest in this. Now fees don't play such a large part of the
      > block reward, but they will get more important, and this change
      > wouldn't force anything (would be voluntary by each user), just miners
      > have to agree to it with a soft fork (so they don't spend from the
      > anyone-can-spend outputs used for reserve fees). Resource requirements
      > for validation are quite small I believe.
      >
      > On Sat, Sep 1, 2018 at 12:11 AM, Andrew <onelineproof@gmail•com> wrote:
      >> As I understand, selfish mining is an attack where miners collude to
      >> mine at a lower hashrate then with all miners working independently.
      >> What are the current strategies used to prevent this and what are the
      >> future plans?
      >>
      >> One idea I have is to let the block reward get "modulated" according
      >> to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)
      >> consisting of 144 blocks, h is the hashrate of the last 144 block (1
      >> day) period, and r is the base subsidy (12.5 BTC currently). You can
      >> then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
      >> peak you get the full reward. Otherwise you get less, down to a min of
      >> 0.5 r.
      >>
      >> If miners were to collude to mine at a lower than peak hashrate, then
      >> they may be able to do it profitably for 144 blocks, but after that,
      >> the reward would get modulated and it wouldn't be so much in their
      >> interest to continue mining at the lower hashrate.
      >>
      >> What flaws are there with this? I know it could be controversial due
      >> to easier mining present for early miners, so maybe it would have to
      >> be done in combination with a new more dynamic difficulty adjustment
      >> algorithm. But I don't see how hashrate can continue rising
      >> indefinitely, so a solution should be made for selfish mining.
      >>
      >> Also when subsidies stop and a fee market is needed, I guess a portion
      >> of the fees can be withheld for later if hashrate is not at peak.
      >>
      >>
      >> --
      >> PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
      >
      >
      >
      > --
      > PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
      > _______________________________________________
      > bitcoin-dev mailing list
      > bitcoin-dev@lists•linuxfoundation.org
      > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      
      
      
      -- 
      PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
      
      
      ^ permalink raw reply	[flat|nested] 14+ messages in thread

    • • * Re: [bitcoin-dev] Selfish Mining Prevention
          2018-09-15 16:01     ` Andrew
        @ 2018-09-15 22:45       ` Damian Williamson
          2018-09-16 23:20         ` Eric Voskuil
          0 siblings, 1 reply; 14+ messages in thread
        From: Damian Williamson @ 2018-09-15 22:45 UTC (permalink / raw)
          To: Andrew; +Cc: Bitcoin Protocol Discussion
        
        [-- Attachment #1: Type: text/plain, Size: 7744 bytes --]
        
        I see what you say, however, since the proposal as I have read it says "And this will keep happening as long as hashrate keeps rising," - what actually happens in the case hashrate stagnates or falls?
        
        
        I would prefer to see (not only with your proposal) greater bias toward hashrate being exponentially more uneconomical the more it rises to stifle greed. The current level of mining already greatly exceeds that necessary for the stability of the network and far lower hashrates are completely acceptible provided the network is protected from large switch-ons, which I say is achievable.
        
        
        I do have other thoughts to approach greed that I have not yet made formal on this list, much unrelated to your proposal, but, I see freedom of use of Bitcoin needing to be censorship resistant but not necessarily mining provided it is protected enough or free or flexible enough to allow for, say, 50k globally distributed standard mining hardware units to exist operating at any one time profitably. That said, I am PoW only and not PoS orientated.
        
        ________________________________
        From: akaramaoun@gmail•com <akaramaoun@gmail•com> on behalf of Andrew <onelineproof@gmail•com>
        Sent: Sunday, 16 September 2018 2:01:19 AM
        To: Damian Williamson
        Cc: Bitcoin Protocol Discussion
        Subject: Re: [bitcoin-dev] Selfish Mining Prevention
        
        @Moral Agent: No problem. I did ask in the first post what the current
        plans are for selfish miner prevention. So if anyone has any other
        relevant ideas (not just for selfish mining but for making mining more
        decentralized and competetive), then please post it, but I just prefer
        to focus on my proposal more than others.
        
        @Damian: I think you are concerned that this will incentivize more
        global resource consumption and will be detrimental to our
        environment? Personally, I believe centralization of energy does more
        harm to the environment rather than total energy consumption. If
        Bitcoin helps "power" to become more decentralized, then I wouldn't be
        surprised if total (global) energy consumption actually decreases. The
        debt based economy is forcing us to continuously grow and use up more
        resources, and collectivism is turning individuals into
        super-organisms capable of doing much more harm to the environment
        than can be done by one or a just a few individuals working
        independently. In my proposal, I actually allow for changing
        environmental conditions by measuring only the peak hashrate of the
        past year, and not the full history of blocks.
        
        On Sat, Sep 15, 2018 at 5:29 AM, Damian Williamson <willtech@live•com.au> wrote:
        >>This "reserve" part of the fee will be paid to miners if the hashrate
        >> rises.
        >
        >
        > Anticipating ongoing hashrate rise shows that you have not yet thought about
        > moving outside of the current greed model, a model wherein mining will
        > consume all available resources within the colony's objective just to spread
        > as far as possible with each new miner bringing diminishing individual
        > returns and shortening the life of Earth for no additional gain. Greed model
        > := bacteria.
        >
        > ________________________________
        > From: bitcoin-dev-bounces@lists•linuxfoundation.org
        > <bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of Andrew via
        > bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
        > Sent: Friday, 14 September 2018 9:19:37 AM
        > To: Bitcoin Dev
        > Subject: Re: [bitcoin-dev] Selfish Mining Prevention
        >
        > I discussed this more at bitcointalk:
        > https://bitcointalk.org/index.php?topic=4998410.0
        >
        > The attacks I'm interested in preventing are not only selfish mining
        > and collusion, but also more subtle attacks like block withholding,
        > and in general anything that aims to drive out the competition in
        > order to increase hashrate fraction. I also scrapped the idea of
        > changing the block subsidies, and I am only focuses on fees.
        >
        > You can read more about the motivation and details in the bitcointalk
        > thread, but my proposal in short would be to add the concept of
        > "reserve fees". When a user makes a transaction, for each txout
        > script, they can add parameters that specify the fraction of the total
        > fee that is held in "reserve" and the time it is held in "reserve"
        > (can set a limit of 2016 blocks). This "reserve" part of the fee will
        > be paid to miners if the hashrate rises. So if hashrate is currently h
        > and peak hashrate (from past year) is p, then for each period (1 day),
        > a new hashrate is calculated h1, and if h1 > h, then the fraction
        > (h1-h)/p from the reserve fees created in the past 2016 blocks will be
        > released to miners for that period (spread out over the 144 blocks in
        > that period). And this will keep happening as long as hashrate keeps
        > rising, until the "contract" expires, and the leftover part can be
        > used by the owner of the unspent output, but it can only be used for
        > paying fees, not as inputs for future transactions (to save on block
        > space).
        >
        > This should incentivize miners to not drive out the competition, since
        > if they do, there will be less of these reserve fees given to miners.
        > Yes in the end the miners will get all the fees, but with rising
        > hashrate they get an unconditional subsidy that does not require
        > transactions, thus more space for transactions with fees.
        >
        > I can make a formal BIP and pull request, but I need to know if there
        > is interest in this. Now fees don't play such a large part of the
        > block reward, but they will get more important, and this change
        > wouldn't force anything (would be voluntary by each user), just miners
        > have to agree to it with a soft fork (so they don't spend from the
        > anyone-can-spend outputs used for reserve fees). Resource requirements
        > for validation are quite small I believe.
        >
        > On Sat, Sep 1, 2018 at 12:11 AM, Andrew <onelineproof@gmail•com> wrote:
        >> As I understand, selfish mining is an attack where miners collude to
        >> mine at a lower hashrate then with all miners working independently.
        >> What are the current strategies used to prevent this and what are the
        >> future plans?
        >>
        >> One idea I have is to let the block reward get "modulated" according
        >> to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)
        >> consisting of 144 blocks, h is the hashrate of the last 144 block (1
        >> day) period, and r is the base subsidy (12.5 BTC currently). You can
        >> then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
        >> peak you get the full reward. Otherwise you get less, down to a min of
        >> 0.5 r.
        >>
        >> If miners were to collude to mine at a lower than peak hashrate, then
        >> they may be able to do it profitably for 144 blocks, but after that,
        >> the reward would get modulated and it wouldn't be so much in their
        >> interest to continue mining at the lower hashrate.
        >>
        >> What flaws are there with this? I know it could be controversial due
        >> to easier mining present for early miners, so maybe it would have to
        >> be done in combination with a new more dynamic difficulty adjustment
        >> algorithm. But I don't see how hashrate can continue rising
        >> indefinitely, so a solution should be made for selfish mining.
        >>
        >> Also when subsidies stop and a fee market is needed, I guess a portion
        >> of the fees can be withheld for later if hashrate is not at peak.
        >>
        >>
        >> --
        >> PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
        >
        >
        >
        > --
        > PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
        > _______________________________________________
        > bitcoin-dev mailing list
        > bitcoin-dev@lists•linuxfoundation.org
        > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        
        
        
        --
        PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
        
        [-- Attachment #2: Type: text/html, Size: 10174 bytes --]
        
        ^ permalink raw reply	[flat|nested] 14+ messages in thread

      • • * Re: [bitcoin-dev] Selfish Mining Prevention
            2018-09-15 22:45       ` Damian Williamson
          @ 2018-09-16 23:20         ` Eric Voskuil
            2018-09-17 13:18           ` Andrew
            0 siblings, 1 reply; 14+ messages in thread
          From: Eric Voskuil @ 2018-09-16 23:20 UTC (permalink / raw)
            To: Damian Williamson, Bitcoin Protocol Discussion
          
          [-- Attachment #1: Type: text/plain, Size: 8889 bytes --]
          
          Hash rate cannot get “more uneconomical”. Mining will always seek a return equal to the cost of capital, as does all production, and the energy expended will always be fundamentally a function of the fee level and energy price. Fee level is determined by variable demand for a fixed supply of confirmation.
          
          When you say greed you are simply referring to economically-rational behavior. It canny be eliminated, nor would that be a benefit.
          
          WRT energy consumption, there is nothing that can be done to reduce it except for people to stop using Bitcoin or for energy to get more expensive.
          
          e
          
          > On Sep 15, 2018, at 15:45, Damian Williamson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
          > 
          > I see what you say, however, since the proposal as I have read it says "And this will keep happening as long as hashrate keeps rising," - what actually happens in the case hashrate stagnates or falls?
          > 
          > I would prefer to see (not only with your proposal) greater bias toward hashrate being exponentially more uneconomical the more it rises to stifle greed. The current level of mining already greatly exceeds that necessary for the stability of the network and far lower hashrates are completely acceptible provided the network is protected from large switch-ons, which I say is achievable.
          > 
          > I do have other thoughts to approach greed that I have not yet made formal on this list, much unrelated to your proposal, but, I see freedom of use of Bitcoin needing to be censorship resistant but not necessarily mining provided it is protected enough or free or flexible enough to allow for, say, 50k globally distributed standard mining hardware units to exist operating at any one time profitably. That said, I am PoW only and not PoS orientated.
          >  
          > From: akaramaoun@gmail•com <akaramaoun@gmail•com> on behalf of Andrew <onelineproof@gmail•com>
          > Sent: Sunday, 16 September 2018 2:01:19 AM
          > To: Damian Williamson
          > Cc: Bitcoin Protocol Discussion
          > Subject: Re: [bitcoin-dev] Selfish Mining Prevention
          >  
          > @Moral Agent: No problem. I did ask in the first post what the current
          > plans are for selfish miner prevention. So if anyone has any other
          > relevant ideas (not just for selfish mining but for making mining more
          > decentralized and competetive), then please post it, but I just prefer
          > to focus on my proposal more than others.
          > 
          > @Damian: I think you are concerned that this will incentivize more
          > global resource consumption and will be detrimental to our
          > environment? Personally, I believe centralization of energy does more
          > harm to the environment rather than total energy consumption. If
          > Bitcoin helps "power" to become more decentralized, then I wouldn't be
          > surprised if total (global) energy consumption actually decreases. The
          > debt based economy is forcing us to continuously grow and use up more
          > resources, and collectivism is turning individuals into
          > super-organisms capable of doing much more harm to the environment
          > than can be done by one or a just a few individuals working
          > independently. In my proposal, I actually allow for changing
          > environmental conditions by measuring only the peak hashrate of the
          > past year, and not the full history of blocks.
          > 
          > On Sat, Sep 15, 2018 at 5:29 AM, Damian Williamson <willtech@live•com.au> wrote:
          > >>This "reserve" part of the fee will be paid to miners if the hashrate
          > >> rises.
          > >
          > >
          > > Anticipating ongoing hashrate rise shows that you have not yet thought about
          > > moving outside of the current greed model, a model wherein mining will
          > > consume all available resources within the colony's objective just to spread
          > > as far as possible with each new miner bringing diminishing individual
          > > returns and shortening the life of Earth for no additional gain. Greed model
          > > := bacteria.
          > >
          > > ________________________________
          > > From: bitcoin-dev-bounces@lists•linuxfoundation.org
          > > <bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of Andrew via
          > > bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
          > > Sent: Friday, 14 September 2018 9:19:37 AM
          > > To: Bitcoin Dev
          > > Subject: Re: [bitcoin-dev] Selfish Mining Prevention
          > >
          > > I discussed this more at bitcointalk:
          > > https://bitcointalk.org/index.php?topic=4998410.0
          > >
          > > The attacks I'm interested in preventing are not only selfish mining
          > > and collusion, but also more subtle attacks like block withholding,
          > > and in general anything that aims to drive out the competition in
          > > order to increase hashrate fraction. I also scrapped the idea of
          > > changing the block subsidies, and I am only focuses on fees.
          > >
          > > You can read more about the motivation and details in the bitcointalk
          > > thread, but my proposal in short would be to add the concept of
          > > "reserve fees". When a user makes a transaction, for each txout
          > > script, they can add parameters that specify the fraction of the total
          > > fee that is held in "reserve" and the time it is held in "reserve"
          > > (can set a limit of 2016 blocks). This "reserve" part of the fee will
          > > be paid to miners if the hashrate rises. So if hashrate is currently h
          > > and peak hashrate (from past year) is p, then for each period (1 day),
          > > a new hashrate is calculated h1, and if h1 > h, then the fraction
          > > (h1-h)/p from the reserve fees created in the past 2016 blocks will be
          > > released to miners for that period (spread out over the 144 blocks in
          > > that period). And this will keep happening as long as hashrate keeps
          > > rising, until the "contract" expires, and the leftover part can be
          > > used by the owner of the unspent output, but it can only be used for
          > > paying fees, not as inputs for future transactions (to save on block
          > > space).
          > >
          > > This should incentivize miners to not drive out the competition, since
          > > if they do, there will be less of these reserve fees given to miners.
          > > Yes in the end the miners will get all the fees, but with rising
          > > hashrate they get an unconditional subsidy that does not require
          > > transactions, thus more space for transactions with fees.
          > >
          > > I can make a formal BIP and pull request, but I need to know if there
          > > is interest in this. Now fees don't play such a large part of the
          > > block reward, but they will get more important, and this change
          > > wouldn't force anything (would be voluntary by each user), just miners
          > > have to agree to it with a soft fork (so they don't spend from the
          > > anyone-can-spend outputs used for reserve fees). Resource requirements
          > > for validation are quite small I believe.
          > >
          > > On Sat, Sep 1, 2018 at 12:11 AM, Andrew <onelineproof@gmail•com> wrote:
          > >> As I understand, selfish mining is an attack where miners collude to
          > >> mine at a lower hashrate then with all miners working independently.
          > >> What are the current strategies used to prevent this and what are the
          > >> future plans?
          > >>
          > >> One idea I have is to let the block reward get "modulated" according
          > >> to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)
          > >> consisting of 144 blocks, h is the hashrate of the last 144 block (1
          > >> day) period, and r is the base subsidy (12.5 BTC currently). You can
          > >> then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
          > >> peak you get the full reward. Otherwise you get less, down to a min of
          > >> 0.5 r.
          > >>
          > >> If miners were to collude to mine at a lower than peak hashrate, then
          > >> they may be able to do it profitably for 144 blocks, but after that,
          > >> the reward would get modulated and it wouldn't be so much in their
          > >> interest to continue mining at the lower hashrate.
          > >>
          > >> What flaws are there with this? I know it could be controversial due
          > >> to easier mining present for early miners, so maybe it would have to
          > >> be done in combination with a new more dynamic difficulty adjustment
          > >> algorithm. But I don't see how hashrate can continue rising
          > >> indefinitely, so a solution should be made for selfish mining.
          > >>
          > >> Also when subsidies stop and a fee market is needed, I guess a portion
          > >> of the fees can be withheld for later if hashrate is not at peak.
          > >>
          > >>
          > >> --
          > >> PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
          > >
          > >
          > >
          > > --
          > > PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
          > > _______________________________________________
          > > bitcoin-dev mailing list
          > > bitcoin-dev@lists•linuxfoundation.org
          > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
          > 
          > 
          > 
          > -- 
          > PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
          > _______________________________________________
          > bitcoin-dev mailing list
          > bitcoin-dev@lists•linuxfoundation.org
          > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
          
          [-- Attachment #2: Type: text/html, Size: 11873 bytes --]
          
          ^ permalink raw reply	[flat|nested] 14+ messages in thread

        • • * Re: [bitcoin-dev] Selfish Mining Prevention
              2018-09-16 23:20         ` Eric Voskuil
            @ 2018-09-17 13:18           ` Andrew
              2018-09-17 15:40             ` Eric Voskuil
              2018-09-17 19:36             ` Eric Voskuil
              0 siblings, 2 replies; 14+ messages in thread
            From: Andrew @ 2018-09-17 13:18 UTC (permalink / raw)
              To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion
            
            > I see what you say, however, since the proposal as I have read it says "And this will keep happening as long as hashrate keeps rising," - what actually happens in the case hashrate stagnates or falls?
            
            In general, a target hashrate can be set by users (can be less or more
            than the peak hashrate). As long as hashrate is rising and still
            didn't reach the target, miners will incrementally get the reserve
            fees. Once the "contract" times out, the remaining part can be used as
            fees by the users who created the reserve fee "contract". So if
            hashrate remains the same or falls, then users get the reserve fees
            back.
            
            I agree that we can't stop people from being greedy. If they are not
            Bitcoin mining, they will try to put their energy to earn in some
            other way...The hashrate is related the demand for Bitcoin (price) and
            the amount of fees/subsidies the miners will get paid. For every level
            of mining rewards (based on demand) there exists a limit on the
            hashrate. Once hashrate gets large enough, no new miners (additional
            hashrate) will want to join since their share of the hashrate is too
            small to make a profit.
            
            Also with merge mining and proof of space we can be quite efficient in
            the future. But of course I sympathize with the "don't be greedy"
            philosophy, and it can be good to educate people to use less resources
            than they need, just I think it's a bit outside of the scope of what
            the Bitcoin software protocol does.
            
            
            ^ permalink raw reply	[flat|nested] 14+ messages in thread

          • • * Re: [bitcoin-dev] Selfish Mining Prevention
                2018-09-17 13:18           ` Andrew
              @ 2018-09-17 15:40             ` Eric Voskuil
                2018-09-17 19:36             ` Eric Voskuil
                1 sibling, 0 replies; 14+ messages in thread
              From: Eric Voskuil @ 2018-09-17 15:40 UTC (permalink / raw)
                To: Andrew; +Cc: Bitcoin Protocol Discussion
              
              [-- Attachment #1: Type: text/plain, Size: 2042 bytes --]
              
              > Also with merge mining and proof of space we can be quite efficient in the future.
              
              Proof of memory (space) is just proof of work with extra steps. It does not reduce energy consumption.
              
              https://github.com/libbitcoin/libbitcoin/wiki/Proof-of-Memory-Facade
              
              Merge mining is non-dedicated cost, so also does not improve energy efficiency. The irreducible *cost* is what matters.
              
              https://github.com/libbitcoin/libbitcoin/wiki/Dedicated-Cost-Principle
              
              e
              
              On Sep 17, 2018, at 06:18, Andrew <onelineproof@gmail•com> wrote:
              
              >> I see what you say, however, since the proposal as I have read it says "And this will keep happening as long as hashrate keeps rising," - what actually happens in the case hashrate stagnates or falls?
              > 
              > In general, a target hashrate can be set by users (can be less or more
              > than the peak hashrate). As long as hashrate is rising and still
              > didn't reach the target, miners will incrementally get the reserve
              > fees. Once the "contract" times out, the remaining part can be used as
              > fees by the users who created the reserve fee "contract". So if
              > hashrate remains the same or falls, then users get the reserve fees
              > back.
              > 
              > I agree that we can't stop people from being greedy. If they are not
              > Bitcoin mining, they will try to put their energy to earn in some
              > other way...The hashrate is related the demand for Bitcoin (price) and
              > the amount of fees/subsidies the miners will get paid. For every level
              > of mining rewards (based on demand) there exists a limit on the
              > hashrate. Once hashrate gets large enough, no new miners (additional
              > hashrate) will want to join since their share of the hashrate is too
              > small to make a profit.
              > 
              > Also with merge mining and proof of space we can be quite efficient in
              > the future. But of course I sympathize with the "don't be greedy"
              > philosophy, and it can be good to educate people to use less resources
              > than they need, just I think it's a bit outside of the scope of what
              > the Bitcoin software protocol does.
              
              [-- Attachment #2: Type: text/html, Size: 3243 bytes --]
              
              ^ permalink raw reply	[flat|nested] 14+ messages in thread

            • * Re: [bitcoin-dev] Selfish Mining Prevention
                2018-09-17 13:18           ` Andrew
                2018-09-17 15:40             ` Eric Voskuil
              @ 2018-09-17 19:36             ` Eric Voskuil
                1 sibling, 0 replies; 14+ messages in thread
              From: Eric Voskuil @ 2018-09-17 19:36 UTC (permalink / raw)
                To: Andrew; +Cc: Bitcoin Protocol Discussion
              
              > Once hashrate gets large enough, no new miners (additional
              hashrate) will want to join since their share of the hashrate is too
              small to make a profit.
              
              The share (hash power) of a miner is proportional to capital investment, not the newness of that investment. The efficiency of a new mine (inclusive of pooling pressures) can certainly be sufficient to outperform other miners, resulting in the departure of the latter, thus not preventing the entry of the former.
              
              The point you should be making here is that energy consumption is regulated by the cost of capital (in addition to reward value and the cost of energy).
              
              Note that higher efficiency mining does not reduce energy consumption, nor does variation in the necessary cost of mining hardware. The total energy cost is the control, not the hash rate. This is of course why proof-of-memory (space) is pointless. It simply shifts most of the energy cost to hardware manufacture, shipment, etc.
              
              e
              
              On Sep 17, 2018, at 06:18, Andrew <onelineproof@gmail•com> wrote:
              
              >> I see what you say, however, since the proposal as I have read it says "And this will keep happening as long as hashrate keeps rising," - what actually happens in the case hashrate stagnates or falls?
              > 
              > In general, a target hashrate can be set by users (can be less or more
              > than the peak hashrate). As long as hashrate is rising and still
              > didn't reach the target, miners will incrementally get the reserve
              > fees. Once the "contract" times out, the remaining part can be used as
              > fees by the users who created the reserve fee "contract". So if
              > hashrate remains the same or falls, then users get the reserve fees
              > back.
              > 
              > I agree that we can't stop people from being greedy. If they are not
              > Bitcoin mining, they will try to put their energy to earn in some
              > other way...The hashrate is related the demand for Bitcoin (price) and
              > the amount of fees/subsidies the miners will get paid. For every level
              > of mining rewards (based on demand) there exists a limit on the
              > hashrate. Once hashrate gets large enough, no new miners (additional
              > hashrate) will want to join since their share of the hashrate is too
              > small to make a profit.
              > 
              > Also with merge mining and proof of space we can be quite efficient in
              > the future. But of course I sympathize with the "don't be greedy"
              > philosophy, and it can be good to educate people to use less resources
              > than they need, just I think it's a bit outside of the scope of what
              > the Bitcoin software protocol does.
              
              
              ^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [bitcoin-dev] Selfish Mining Prevention
@ 2018-09-17 14:09 Zawy
  2018-09-18 20:26 ` Andrew
  0 siblings, 1 reply; 14+ messages in thread
From: Zawy @ 2018-09-17 14:09 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

The 51% problem is deep. Any discussion of a solution to it should
begin with a link to an article that shows a profound discovery has
been made. Selfish mining prevention and pollution should be on
bitcoin-discussion, but it appears that list is not active.

The problem with Andrew's idea below is that it is a positive feedback
loop that amplifies oscillations. If h goes up or down due to price
changes or random solvetime variation, then the net reward goes in the
same direction, which motivates miners to cause h to go even further
in the same direction, which is a positive feedback loop until some
limit is reached. To make matters worse, miner profit motivation in
choosing which coin to mine is a non-linear function: a 30% drop in
difficulty (or 30% increase in this reward function) in an alt coin
can cause a 300% increase in hashrate.

Average of 144 past blocks to determine h are needed so that it does
not vary too much.  A selfish mine of 72 blocks would result in only a
12.5% loss compared to not using this pro-oscillation function. I've
tried similar reward functions in trying to reduce on-off mining.

There may also be a problem of issuing too many or too few coins,
depending on how fast h rises in the long term.

An alternative is to increase difficulty with this or a similar
function instead of reward. From a miner's perspective, there is not a
difference (they are only interested in the (price+fees)/difficulty
ratio. This would have the same problems.

The problem has been solved to the best of our ability by the Nakamoto
consensus. The math is straightforward, so you can't get around it's
failings unless it's a profound solution or we shift trust to some
place else. Currently we have to choose and trust a small group of
coins (or 1) to be the best choice(s), and to trust that the reward
plus fees we pay for mining (compared to coin value) is enough to
prevent a 51% attack.

> Say p is the peak hashrate for 365 periods (1 year)
> consisting of 144 blocks, h is the hashrate of the last 144 block (1
> day) period, and r is the base subsidy (12.5 BTC currently). You can
> then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
> peak you get the full reward. Otherwise you get less, down to a min of


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

• * Re: [bitcoin-dev] Selfish Mining Prevention
    2018-09-17 14:09 Zawy
  @ 2018-09-18 20:26 ` Andrew
    0 siblings, 0 replies; 14+ messages in thread
  From: Andrew @ 2018-09-18 20:26 UTC (permalink / raw)
    To: Zawy, Bitcoin Protocol Discussion
  
  @ Eric: Yes I forgot to mention that cost (in addition to price) also
  determines the profitability of mining and thus the total hashpower. I
  disagree with your assessment of merge mining as really what matters
  is opportunity cost of honestly mining vs attacking, and one reason we
  are currently safe from other networks attacking is that SHA256 is
  ASIC friendly and currently the main network utilising this (the
  ASICs) is Bitcoin mining. It would be hard for people computing prime
  numbers to quickly switch to Bitcoin mining, since they would need the
  ASICs. But if you really want to discuss this then I suggest opening a
  new thread here or bitcointalk since this is off-topic from my thread.
  Also there is a discussion about merge mining here:
  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/003981.html
  
  On Mon, Sep 17, 2018 at 2:09 PM, Zawy via bitcoin-dev
  <bitcoin-dev@lists•linuxfoundation.org> wrote:
  > The 51% problem is deep. Any discussion of a solution to it should
  > begin with a link to an article that shows a profound discovery has
  > been made. Selfish mining prevention and pollution should be on
  > bitcoin-discussion, but it appears that list is not active.
  >
  > The problem with Andrew's idea below is that it is a positive feedback
  > loop that amplifies oscillations. If h goes up or down due to price
  > changes or random solvetime variation, then the net reward goes in the
  > same direction, which motivates miners to cause h to go even further
  > in the same direction, which is a positive feedback loop until some
  > limit is reached. To make matters worse, miner profit motivation in
  > choosing which coin to mine is a non-linear function: a 30% drop in
  > difficulty (or 30% increase in this reward function) in an alt coin
  > can cause a 300% increase in hashrate.
  >
  > Average of 144 past blocks to determine h are needed so that it does
  > not vary too much.  A selfish mine of 72 blocks would result in only a
  > 12.5% loss compared to not using this pro-oscillation function. I've
  > tried similar reward functions in trying to reduce on-off mining.
  >
  > There may also be a problem of issuing too many or too few coins,
  > depending on how fast h rises in the long term.
  >
  > An alternative is to increase difficulty with this or a similar
  > function instead of reward. From a miner's perspective, there is not a
  > difference (they are only interested in the (price+fees)/difficulty
  > ratio. This would have the same problems.
  
  @Zawy: Are you talking about my proposal to modulate the subsidies?
  Because if you read my second post you see that I scrapped that part
  as it can be disruptive, and I am only proposing to let users have
  more control over how their fees are spent. A certain portion of fees
  is put in reserve and gets allocated to miners based on hashrate
  conditions, and once the "contract" expires, the remaining part goes
  back to the user for future fee payments. I understand it is unclear
  whether this will cause a significant benefit (I can work on
  simulations if I have time), but what could possibly go wrong with
  giving users more choice over how their fees are spent?
  
  Also if you see my post, I am not just trying to prevent Selfish
  Mining (33%) or 51% attacks, but in general any types of attacks that
  try to drive away mining competition (like block withholding attacks,
  networking attacks, etc).
  
  Someone on bitcointalk was also worried about a positive feedback
  loop, and I think my answer remains valid:
  "First, I think a price drop will be slightly offset by the lower rate
  of coins being mined. Also, confirmation times will get longer: Both
  the time to get a block will increase and the number of confirmations
  needed to have enough work done on the chain so that your transaction
  is considered safe. The fees would likely rise and this would increase
  rewards to miners, especially in a fee-market dominated future." Merge
  mining can also help to smooth hashrate so it doesn't depend so much
  on price, but even without merge mining it is not so clear that a
  there would be a destructive feedback loop and that's where
  simulations / math equations would help.
  
  Your idea of increasing difficulty, I haven't thought about much, but
  I don't think it's the same effect. When you increase the difficulty,
  the reward per block remains the same, only reward per real time
  falls, but it could also have the negative effect of incentivizing
  selfish mining or timestamp attacks to reverse the increased
  difficulty. Though actually timestamp attacks would sort of be
  dis-incentivized if underestimates of hashrate led to lower rewards.
  
  Obviously I will not work on a pull request if there is no strong
  interest for this. I think it is a harmless addition, so if I have
  time I can work on simulations to try to prove that there is a
  significant benefit with doing this.
  
  
  -- 
  PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
  
  
  ^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2018-09-18 20:26 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-01  0:11 [bitcoin-dev] Selfish Mining Prevention Andrew
2018-09-13 23:19 ` Andrew
2018-09-14 14:49   ` Moral Agent
2018-09-14 17:30     ` Andrew
2018-09-14 18:00       ` Moral Agent
2018-09-15  5:29   ` Damian Williamson
2018-09-15 16:01     ` Andrew
2018-09-15 22:45       ` Damian Williamson
2018-09-16 23:20         ` Eric Voskuil
2018-09-17 13:18           ` Andrew
2018-09-17 15:40             ` Eric Voskuil
2018-09-17 19:36             ` Eric Voskuil
2018-09-17 14:09 Zawy
2018-09-18 20:26 ` Andrew

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