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

* [Bitcoin-development] User vote in blocksize through fees
@ 2015-06-12 18:11 Peter Todd
  2015-06-12 18:20 ` Mark Friedenbach
                   ` (4 more replies)
  0 siblings, 5 replies; 42+ messages in thread
From: Peter Todd @ 2015-06-12 18:11 UTC (permalink / raw)
  To: bitcoin-development

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

Jeff Garzik recently proposed that the upper blocksize limit be removed
entirely, with a "soft" limit being enforced via miner vote, recorded by
hashing power.

This mechanism within the protocol for users to have any influence over
the miner vote. We can add that back by providing a way for transactions
themselves to set a flag determining whether or not they can be included
in a block casting a specific vote.

We can simplify Garzik's vote to say that one of the nVersion bits
either votes for the blocksize to be increased, or decreased, by some
fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
nVersion bit in transactions themselves, also voting for an increase or
decrease. Transactions may only be included in blocks with an
indentical vote, thus providing miners with a monetary incentive via
fees to vote according to user wishes.

Of course, to cast a "don't care" vote we can either define an
additional bit, or sign the transaction with both versions. Equally we
can even have different versions with different fees, broadcast via a
mechanism such as replace-by-fee.


See also John Dillon's proposal for proof-of-stake blocksize voting:

https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html

-- 
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

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

• * Re: [Bitcoin-development] User vote in blocksize through fees
    2015-06-12 18:11 [Bitcoin-development] User vote in blocksize through fees Peter Todd
  @ 2015-06-12 18:20 ` Mark Friedenbach
    2015-06-12 18:26   ` Matt Whitlock
    2015-06-12 18:22 ` Matt Whitlock
                     ` (3 subsequent siblings)
    4 siblings, 1 reply; 42+ messages in thread
  From: Mark Friedenbach @ 2015-06-12 18:20 UTC (permalink / raw)
    To: Peter Todd; +Cc: Bitcoin Development
  
  [-- Attachment #1: Type: text/plain, Size: 2432 bytes --]
  
  Peter it's not clear to me that your described protocol is free of miner
  influence over the vote, by artificially generating transactions which they
  claim in their own blocks, or conforming incentives among voters by opting
  to be with the (slight) majority in order to minimize fees.
  
  Wouldn't it in fact be simpler to use the dynamic block size adjustment
  algorithm presented to the list a few weeks back, where the miner opts for
  a larger block by sacrificing fees? In that way the users "vote" for larger
  blocks by including sufficient fees to offset subsidy, but as it is an
  economic incentives miners gain nothing by inflating the fees in their own
  blocks.
  
  On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd <pete@petertodd•org> wrote:
  
  > Jeff Garzik recently proposed that the upper blocksize limit be removed
  > entirely, with a "soft" limit being enforced via miner vote, recorded by
  > hashing power.
  >
  > This mechanism within the protocol for users to have any influence over
  > the miner vote. We can add that back by providing a way for transactions
  > themselves to set a flag determining whether or not they can be included
  > in a block casting a specific vote.
  >
  > We can simplify Garzik's vote to say that one of the nVersion bits
  > either votes for the blocksize to be increased, or decreased, by some
  > fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
  > nVersion bit in transactions themselves, also voting for an increase or
  > decrease. Transactions may only be included in blocks with an
  > indentical vote, thus providing miners with a monetary incentive via
  > fees to vote according to user wishes.
  >
  > Of course, to cast a "don't care" vote we can either define an
  > additional bit, or sign the transaction with both versions. Equally we
  > can even have different versions with different fees, broadcast via a
  > mechanism such as replace-by-fee.
  >
  >
  > See also John Dillon's proposal for proof-of-stake blocksize voting:
  >
  >
  > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
  >
  > --
  > 'peter'[:-1]@petertodd.org
  > 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
  >
  >
  > ------------------------------------------------------------------------------
  >
  > _______________________________________________
  > Bitcoin-development mailing list
  > Bitcoin-development@lists•sourceforge.net
  > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  >
  >
  
  [-- Attachment #2: Type: text/html, Size: 3348 bytes --]
  
  ^ permalink raw reply	[flat|nested] 42+ messages in thread

• • * Re: [Bitcoin-development] User vote in blocksize through fees
      2015-06-12 18:20 ` Mark Friedenbach
    @ 2015-06-12 18:26   ` Matt Whitlock
      2015-06-12 18:36     ` Peter Todd
      2015-06-12 18:56     ` Jannes Faber
      0 siblings, 2 replies; 42+ messages in thread
    From: Matt Whitlock @ 2015-06-12 18:26 UTC (permalink / raw)
      To: Mark Friedenbach; +Cc: bitcoin-development
    
    On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
    > Peter it's not clear to me that your described protocol is free of miner
    > influence over the vote, by artificially generating transactions which they
    > claim in their own blocks
    
    Miners could fill their blocks with garbage transactions that agree with their vote, but this wouldn't bring them any real income, as they'd be paying their own money as fees to themselves. To get real income, miners would have to vote in accordance with real users.
    
    
    
    ^ permalink raw reply	[flat|nested] 42+ messages in thread

  • • * Re: [Bitcoin-development] User vote in blocksize through fees
        2015-06-12 18:26   ` Matt Whitlock
      @ 2015-06-12 18:36     ` Peter Todd
        2015-06-12 18:56     ` Jannes Faber
        1 sibling, 0 replies; 42+ messages in thread
      From: Peter Todd @ 2015-06-12 18:36 UTC (permalink / raw)
        To: Matt Whitlock; +Cc: bitcoin-development
      
      [-- Attachment #1: Type: text/plain, Size: 852 bytes --]
      
      On Fri, Jun 12, 2015 at 02:26:20PM -0400, Matt Whitlock wrote:
      > On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
      > > Peter it's not clear to me that your described protocol is free of miner
      > > influence over the vote, by artificially generating transactions which they
      > > claim in their own blocks
      > 
      > Miners could fill their blocks with garbage transactions that agree with their vote, but this wouldn't bring them any real income, as they'd be paying their own money as fees to themselves. To get real income, miners would have to vote in accordance with real users.
      
      Exactly. I very explicitly am proposing that we consider giving users a
      mechanism to pay for votes to give them a way to directly influence the
      outcome.
      
      -- 
      'peter'[:-1]@petertodd.org
      0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
      
      [-- Attachment #2: Digital signature --]
      [-- Type: application/pgp-signature, Size: 650 bytes --]
      
      ^ permalink raw reply	[flat|nested] 42+ messages in thread

    • * Re: [Bitcoin-development] User vote in blocksize through fees
        2015-06-12 18:26   ` Matt Whitlock
        2015-06-12 18:36     ` Peter Todd
      @ 2015-06-12 18:56     ` Jannes Faber
             [not found]       ` <CABr1YTfowMqgDZoWhDXiM0Bd3dwhVo6++FOvLntGc2HkApEbGw@mail.gmail.com>
        1 sibling, 1 reply; 42+ messages in thread
      From: Jannes Faber @ 2015-06-12 18:56 UTC (permalink / raw)
        To: Matt Whitlock, Mark Friedenbach; +Cc: bitcoin-development
      
      [-- Attachment #1: Type: text/plain, Size: 1296 bytes --]
      
      I'm imagining in Peter's proposal it's not the transaction votes that are
      counted but only the votes in the blocks? So miners get to vote but they
      risk losing money by having to exclude counter voting transactions. But
      garbage transactions are no problem at all.
      
      Note that users that want to cast a vote "pay" for that by increased
      confirmation time (on average, hopefully slightly depending on the trend).
      
      On Fri, Jun 12, 2015, 20:27 Matt Whitlock <bip@mattwhitlock•name> wrote:
      
      > On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
      > > Peter it's not clear to me that your described protocol is free of miner
      > > influence over the vote, by artificially generating transactions which
      > they
      > > claim in their own blocks
      >
      > Miners could fill their blocks with garbage transactions that agree with
      > their vote, but this wouldn't bring them any real income, as they'd be
      > paying their own money as fees to themselves. To get real income, miners
      > would have to vote in accordance with real users.
      >
      >
      > ------------------------------------------------------------------------------
      > _______________________________________________
      > Bitcoin-development mailing list
      > Bitcoin-development@lists•sourceforge.net
      > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
      >
      
      [-- Attachment #2: Type: text/html, Size: 1833 bytes --]
      
      ^ permalink raw reply	[flat|nested] 42+ messages in thread

    • • [parent not found: <CABr1YTfowMqgDZoWhDXiM0Bd3dwhVo6++FOvLntGc2HkApEbGw@mail.gmail.com>]

      • • * Re: [Bitcoin-development] User vote in blocksize through fees
                 [not found]       ` <CABr1YTfowMqgDZoWhDXiM0Bd3dwhVo6++FOvLntGc2HkApEbGw@mail.gmail.com>
          @ 2015-06-12 20:04         ` Eric Lombrozo
            2015-06-12 23:01           ` Vincent Truong
            2015-06-12 23:23           ` Aaron Gustafson
            0 siblings, 2 replies; 42+ messages in thread
          From: Eric Lombrozo @ 2015-06-12 20:04 UTC (permalink / raw)
            To: Jannes Faber; +Cc: Bitcoin Dev
          
          [-- Attachment #1: Type: text/plain, Size: 2278 bytes --]
          
          Miners currently only collect an almost negligible portion of their revenue
          from fees. While I certainly welcome any proposals that move us in the
          direction of defining a smooth metaconsensus process, I think with the
          curent economics, miners (and especially those with significant hashing
          power) have more of an incentive to block txs/spam their votes than to
          adapt to tx sender preferences...unless people increase their tx fees
          significantly. But without wallets that can make decent suggestions in this
          regard, this feature will be almost inaccessible to most regular users. And
          the economics still aren't entirely clear.
          
          - Eric Lombrozo
          On Jun 12, 2015 12:30 PM, "Jannes Faber" <j.faber@elevate•nl> wrote:
          
          I'm imagining in Peter's proposal it's not the transaction votes that are
          counted but only the votes in the blocks? So miners get to vote but they
          risk losing money by having to exclude counter voting transactions. But
          garbage transactions are no problem at all.
          
          Note that users that want to cast a vote "pay" for that by increased
          confirmation time (on average, hopefully slightly depending on the trend).
          
          On Fri, Jun 12, 2015, 20:27 Matt Whitlock <bip@mattwhitlock•name> wrote:
          
          > On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
          > > Peter it's not clear to me that your described protocol is free of miner
          > > influence over the vote, by artificially generating transactions which
          > they
          > > claim in their own blocks
          >
          > Miners could fill their blocks with garbage transactions that agree with
          > their vote, but this wouldn't bring them any real income, as they'd be
          > paying their own money as fees to themselves. To get real income, miners
          > would have to vote in accordance with real users.
          >
          >
          > ------------------------------------------------------------------------------
          > _______________________________________________
          > Bitcoin-development mailing list
          > Bitcoin-development@lists•sourceforge.net
          > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
          >
          
          ------------------------------------------------------------------------------
          
          _______________________________________________
          Bitcoin-development mailing list
          Bitcoin-development@lists•sourceforge.net
          https://lists.sourceforge.net/lists/listinfo/bitcoin-development
          
          [-- Attachment #2: Type: text/html, Size: 3314 bytes --]
          
          ^ permalink raw reply	[flat|nested] 42+ messages in thread

        • • * Re: [Bitcoin-development] User vote in blocksize through fees
              2015-06-12 20:04         ` Eric Lombrozo
            @ 2015-06-12 23:01           ` Vincent Truong
              2015-06-12 23:11             ` Luke Dashjr
              2015-06-12 23:23           ` Aaron Gustafson
              1 sibling, 1 reply; 42+ messages in thread
            From: Vincent Truong @ 2015-06-12 23:01 UTC (permalink / raw)
              To: Eric Lombrozo; +Cc: bitcoin-development
            
            [-- Attachment #1: Type: text/plain, Size: 5209 bytes --]
            
            (Sorry for spam, forgot to cc the mailing list)
            
            RE: miner economics
            Miners who have an agenda can forego fees to achieve it and create their
            own txns if it is completely txn/user driven. It is better to just count
            miners votes and let the user votes be their backing.
            
            Although miners need to include txns that have the same vote as them, or
            you expect them be able to vote themselves with their own txns, with
            backing eventually there will be a large pool of unconfirmed txns that vote
            against them. Which means a juicy choice of fees for an honest or small
            miner to vote the other way (if there are any).
            
            If the votes are required to be near unanimous (almost 100%) rather than
            majority rule, there will be a small miner out there who will vote honestly
            and reset the vote on behalf of those users, because there is a fee
            incentive to do so (a pure honest miner doesn't care about fees. But
            they're a dying breed). If it is a majority rule type of vote, bigger
            miners will set the vote direction and small miners have no say no matter
            how they vote. From a decentralisation perspective, it is better to want
            the big guns to have a small voice, otherwise it will tend towards
            centralisation.
            
            Troll users (voting against when the direction is very clear) can still be
            ignored by excluding their txns unless they're paying attractive fees. (So
            it isn't exactly 100%, but it'll be close). Miners have some power but
            ultimately they will represent the users if the users votes are clearly
            divided.
            
            If you think 100% is hard, 95-90% could be a compromise but that requires
            an assumption that at least 5-10% will have their voices unheard. And that
            might be OK. Personally, 100% is consensus, anything less is just a
            democracy.
            
            RE: vote bits
            I think letting a vote go up and down in the same vote is a strange one.
            Personally I think binary votes simplify the process.
            
            Would it be better to 'announce' a vote that will contain a certain change.
            For example, hash of a config file that said change MAX_BLOCK_SIZE -> 8mb.
            More things can use the same mechanism by including changes in a config (or
            whatever script/markup) file as needed in the future, for whichever
            constants you want to expose to votes.
            
            Votes can just be 0 and 1 for no/yes and omitted for neutral. My preference
            is 1 for yes, 0 for no neutral/ignored and omitted for no, so that it is
            backwards compatible and doesn't skew votes to the agreeing direction, and
            forces node owners and wallet developers to upgrade and participate.
            On Jun 13, 2015 6:04 AM, "Eric Lombrozo" <elombrozo@gmail•com> wrote:
            
            > Miners currently only collect an almost negligible portion of their
            > revenue from fees. While I certainly welcome any proposals that move us in
            > the direction of defining a smooth metaconsensus process, I think with the
            > curent economics, miners (and especially those with significant hashing
            > power) have more of an incentive to block txs/spam their votes than to
            > adapt to tx sender preferences...unless people increase their tx fees
            > significantly. But without wallets that can make decent suggestions in this
            > regard, this feature will be almost inaccessible to most regular users. And
            > the economics still aren't entirely clear.
            >
            > - Eric Lombrozo
            > On Jun 12, 2015 12:30 PM, "Jannes Faber" <j.faber@elevate•nl> wrote:
            >
            > I'm imagining in Peter's proposal it's not the transaction votes that are
            > counted but only the votes in the blocks? So miners get to vote but they
            > risk losing money by having to exclude counter voting transactions. But
            > garbage transactions are no problem at all.
            >
            > Note that users that want to cast a vote "pay" for that by increased
            > confirmation time (on average, hopefully slightly depending on the trend).
            >
            > On Fri, Jun 12, 2015, 20:27 Matt Whitlock <bip@mattwhitlock•name> wrote:
            >
            >> On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
            >> > Peter it's not clear to me that your described protocol is free of miner
            >> > influence over the vote, by artificially generating transactions which
            >> they
            >> > claim in their own blocks
            >>
            >> Miners could fill their blocks with garbage transactions that agree with
            >> their vote, but this wouldn't bring them any real income, as they'd be
            >> paying their own money as fees to themselves. To get real income, miners
            >> would have to vote in accordance with real users.
            >>
            >>
            >> ------------------------------------------------------------------------------
            >> _______________________________________________
            >> Bitcoin-development mailing list
            >> Bitcoin-development@lists•sourceforge.net
            >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
            >>
            >
            >
            > ------------------------------------------------------------------------------
            >
            > _______________________________________________
            > Bitcoin-development mailing list
            > Bitcoin-development@lists•sourceforge.net
            > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
            >
            >
            >
            > ------------------------------------------------------------------------------
            >
            > _______________________________________________
            > Bitcoin-development mailing list
            > Bitcoin-development@lists•sourceforge.net
            > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
            >
            >
            
            [-- Attachment #2: Type: text/html, Size: 6785 bytes --]
            
            ^ permalink raw reply	[flat|nested] 42+ messages in thread

          • • * Re: [Bitcoin-development] User vote in blocksize through fees
                2015-06-12 23:01           ` Vincent Truong
              @ 2015-06-12 23:11             ` Luke Dashjr
                0 siblings, 0 replies; 42+ messages in thread
              From: Luke Dashjr @ 2015-06-12 23:11 UTC (permalink / raw)
                To: bitcoin-development
              
              On Friday, June 12, 2015 11:01:02 PM Vincent Truong wrote:
              > RE: miner economics
              > Miners who have an agenda can forego fees to achieve it and create their
              > own txns if it is completely txn/user driven. It is better to just count
              > miners votes and let the user votes be their backing.
              
              Just simplify this? Allow a miner to have their block counted as <max possible 
              votes> votes for X provided not a single transaction they include votes 
              against it. Then miners can explicitly forego the fees of opposing 
              transactions without having to bloat blocks.
              
              Luke
              
              
              
              ^ permalink raw reply	[flat|nested] 42+ messages in thread

          • * Re: [Bitcoin-development] User vote in blocksize through fees
              2015-06-12 20:04         ` Eric Lombrozo
              2015-06-12 23:01           ` Vincent Truong
            @ 2015-06-12 23:23           ` Aaron Gustafson
              1 sibling, 0 replies; 42+ messages in thread
            From: Aaron Gustafson @ 2015-06-12 23:23 UTC (permalink / raw)
              To: Eric Lombrozo; +Cc: Bitcoin Dev
            
            [-- Attachment #1: Type: text/plain, Size: 353 bytes --]
            
            On Fri, Jun 12, 2015 at 1:04 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
            
            > Miners currently only collect an almost negligible portion of their
            > revenue from fees.
            
            
            Then they shouldn't care about the block size limit, since an increase in
            block size (and thus in the number of txs they get fees from) will only
            increase their revenue "negligibly".
            
            [-- Attachment #2: Type: text/html, Size: 655 bytes --]
            
            ^ permalink raw reply	[flat|nested] 42+ messages in thread

• * Re: [Bitcoin-development] User vote in blocksize through fees
    2015-06-12 18:11 [Bitcoin-development] User vote in blocksize through fees Peter Todd
    2015-06-12 18:20 ` Mark Friedenbach
  @ 2015-06-12 18:22 ` Matt Whitlock
    2015-06-12 18:34   ` Peter Todd
    2015-06-13 22:20 ` Danny Thorpe
                     ` (2 subsequent siblings)
    4 siblings, 1 reply; 42+ messages in thread
  From: Matt Whitlock @ 2015-06-12 18:22 UTC (permalink / raw)
    To: bitcoin-development
  
  Why should miners only be able to vote for "double the limit" or "halve" the limit? If you're going to use bits, I think you need to use two bits:
  
  	0 0 = no preference ("wildcard" vote)
  	0 1 = vote for the limit to remain the same
  	1 0 = vote for the limit to be halved
  	1 1 = vote for the limit to be doubled
  
  User transactions would follow the same usage. In particular, a user vote of "0 0" (no preference) could be included in a block casting any vote, but a block voting "0 0" (no preference) could only contain transactions voting "0 0" as well.
  
  Incidentally, I love this idea, as it addresses a concern I immediately had with Jeff's proposal, which is that it hands control exclusively to the miners. And your proposal here fixes that shortcoming in a economically powerful way: miners lose out on fees if they don't represent the wishes of the users.
  
  
  On Friday, 12 June 2015, at 2:11 pm, Peter Todd wrote:
  > Jeff Garzik recently proposed that the upper blocksize limit be removed
  > entirely, with a "soft" limit being enforced via miner vote, recorded by
  > hashing power.
  > 
  > This mechanism within the protocol for users to have any influence over
  > the miner vote. We can add that back by providing a way for transactions
  > themselves to set a flag determining whether or not they can be included
  > in a block casting a specific vote.
  > 
  > We can simplify Garzik's vote to say that one of the nVersion bits
  > either votes for the blocksize to be increased, or decreased, by some
  > fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
  > nVersion bit in transactions themselves, also voting for an increase or
  > decrease. Transactions may only be included in blocks with an
  > indentical vote, thus providing miners with a monetary incentive via
  > fees to vote according to user wishes.
  > 
  > Of course, to cast a "don't care" vote we can either define an
  > additional bit, or sign the transaction with both versions. Equally we
  > can even have different versions with different fees, broadcast via a
  > mechanism such as replace-by-fee.
  > 
  > 
  > See also John Dillon's proposal for proof-of-stake blocksize voting:
  > 
  > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
  > 
  > -- 
  > 'peter'[:-1]@petertodd.org
  > 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
  
  
  
  ^ permalink raw reply	[flat|nested] 42+ messages in thread

• • * Re: [Bitcoin-development] User vote in blocksize through fees
      2015-06-12 18:22 ` Matt Whitlock
    @ 2015-06-12 18:34   ` Peter Todd
      2015-06-12 18:36     ` Matt Whitlock
      0 siblings, 1 reply; 42+ messages in thread
    From: Peter Todd @ 2015-06-12 18:34 UTC (permalink / raw)
      To: Matt Whitlock; +Cc: bitcoin-development
    
    [-- Attachment #1: Type: text/plain, Size: 1380 bytes --]
    
    On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
    > Why should miners only be able to vote for "double the limit" or "halve" the limit? If you're going to use bits, I think you need to use two bits:
    > 
    > 	0 0 = no preference ("wildcard" vote)
    > 	0 1 = vote for the limit to remain the same
    > 	1 0 = vote for the limit to be halved
    > 	1 1 = vote for the limit to be doubled
    > 
    > User transactions would follow the same usage. In particular, a user vote of "0 0" (no preference) could be included in a block casting any vote, but a block voting "0 0" (no preference) could only contain transactions voting "0 0" as well.
    
    Sounds like a good encoding to me. Taking the median of the three
    options, and throwing away "don't care" votes entirely, makes sense.
    
    > Incidentally, I love this idea, as it addresses a concern I immediately had with Jeff's proposal, which is that it hands control exclusively to the miners. And your proposal here fixes that shortcoming in a economically powerful way: miners lose out on fees if they don't represent the wishes of the users.
    
    Thanks! I personally expect disaster to ensue with this kind of
    proposal, but I'm less concerned if the disaster is something users
    explicitly allowed to happen in a consensual way.
    
    -- 
    'peter'[:-1]@petertodd.org
    0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
    
    [-- Attachment #2: Digital signature --]
    [-- Type: application/pgp-signature, Size: 650 bytes --]
    
    ^ permalink raw reply	[flat|nested] 42+ messages in thread

  • • * Re: [Bitcoin-development] User vote in blocksize through fees
        2015-06-12 18:34   ` Peter Todd
      @ 2015-06-12 18:36     ` Matt Whitlock
        2015-06-12 18:39       ` Benjamin
        2015-06-12 18:44       ` Peter Todd
        0 siblings, 2 replies; 42+ messages in thread
      From: Matt Whitlock @ 2015-06-12 18:36 UTC (permalink / raw)
        To: Peter Todd; +Cc: bitcoin-development
      
      On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
      > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
      > > Why should miners only be able to vote for "double the limit" or "halve" the limit? If you're going to use bits, I think you need to use two bits:
      > > 
      > > 	0 0 = no preference ("wildcard" vote)
      > > 	0 1 = vote for the limit to remain the same
      > > 	1 0 = vote for the limit to be halved
      > > 	1 1 = vote for the limit to be doubled
      > > 
      > > User transactions would follow the same usage. In particular, a user vote of "0 0" (no preference) could be included in a block casting any vote, but a block voting "0 0" (no preference) could only contain transactions voting "0 0" as well.
      > 
      > Sounds like a good encoding to me. Taking the median of the three
      > options, and throwing away "don't care" votes entirely, makes sense.
      
      I hope you mean the *plurality* of the three options after throwing away the "don't cares," not the *median*.
      
      
      
      ^ permalink raw reply	[flat|nested] 42+ messages in thread

    • • * Re: [Bitcoin-development] User vote in blocksize through fees
          2015-06-12 18:36     ` Matt Whitlock
        @ 2015-06-12 18:39       ` Benjamin
          2015-06-12 18:47         ` Peter Todd
          2015-06-12 18:44       ` Peter Todd
          1 sibling, 1 reply; 42+ messages in thread
        From: Benjamin @ 2015-06-12 18:39 UTC (permalink / raw)
          To: Matt Whitlock; +Cc: Bitcoin Dev
        
        This is a misguided idea, to say the least. If such a mechanism of of
        user input would be possible, one would use it for transaction
        verification in the first place. In proof-of-stake outcomes are
        determined by vote by stake (that vote has very different
        characteristics than vote by compute power). There is no such thing as
        making it possible to determine what "users want". That's what the
        proof-of-work mechanism does in the first place, only that it is now
        unfortunately skewed/corrupted/(whatever you want to call it). Before
        centralization the concept of "miners" didn't exist in Bitcoin and
        miners were roughly identical to users. Peer-to-Peer implies only one
        class of users.
        
        A big problem with such a vote (in PoW and PoS): miners get paid for
        their work and have incentives to raise fees. Those who pay fees would
        have no say in whether those fees are fair or not. Transaction
        verification has to be roughly profitable, but there is no fixed
        formula for determining profitability.
        
        On Fri, Jun 12, 2015 at 8:26 PM, Matt Whitlock <bip@mattwhitlock•name> wrote:
        > On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
        >> Peter it's not clear to me that your described protocol is free of miner
        >> influence over the vote, by artificially generating transactions which they
        >> claim in their own blocks
        >
        > Miners could fill their blocks with garbage transactions that agree with their vote, but this wouldn't bring them any real income, as they'd be paying their own money as fees to themselves. To get real income, miners would have to vote in accordance with real users.
        >
        > ------------------------------------------------------------------------------
        > _______________________________________________
        > Bitcoin-development mailing list
        > Bitcoin-development@lists•sourceforge.net
        > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
        
        On Fri, Jun 12, 2015 at 8:34 PM, Peter Todd <pete@petertodd•org> wrote:
        > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
        >> Why should miners only be able to vote for "double the limit" or "halve" the limit? If you're going to use bits, I think you need to use two bits:
        >>
        >>       0 0 = no preference ("wildcard" vote)
        >>       0 1 = vote for the limit to remain the same
        >>       1 0 = vote for the limit to be halved
        >>       1 1 = vote for the limit to be doubled
        >>
        >> User transactions would follow the same usage. In particular, a user vote of "0 0" (no preference) could be included in a block casting any vote, but a block voting "0 0" (no preference) could only contain transactions voting "0 0" as well.
        >
        > Sounds like a good encoding to me. Taking the median of the three
        > options, and throwing away "don't care" votes entirely, makes sense.
        >
        >> Incidentally, I love this idea, as it addresses a concern I immediately had with Jeff's proposal, which is that it hands control exclusively to the miners. And your proposal here fixes that shortcoming in a economically powerful way: miners lose out on fees if they don't represent the wishes of the users.
        >
        > Thanks! I personally expect disaster to ensue with this kind of
        > proposal, but I'm less concerned if the disaster is something users
        > explicitly allowed to happen in a consensual way.
        >
        > --
        > 'peter'[:-1]@petertodd.org
        > 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
        >
        > ------------------------------------------------------------------------------
        >
        > _______________________________________________
        > Bitcoin-development mailing list
        > Bitcoin-development@lists•sourceforge.net
        > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
        >
        
        On Fri, Jun 12, 2015 at 8:36 PM, Peter Todd <pete@petertodd•org> wrote:
        > On Fri, Jun 12, 2015 at 02:26:20PM -0400, Matt Whitlock wrote:
        >> On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
        >> > Peter it's not clear to me that your described protocol is free of miner
        >> > influence over the vote, by artificially generating transactions which they
        >> > claim in their own blocks
        >>
        >> Miners could fill their blocks with garbage transactions that agree with their vote, but this wouldn't bring them any real income, as they'd be paying their own money as fees to themselves. To get real income, miners would have to vote in accordance with real users.
        >
        > Exactly. I very explicitly am proposing that we consider giving users a
        > mechanism to pay for votes to give them a way to directly influence the
        > outcome.
        >
        > --
        > 'peter'[:-1]@petertodd.org
        > 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
        >
        > ------------------------------------------------------------------------------
        >
        > _______________________________________________
        > Bitcoin-development mailing list
        > Bitcoin-development@lists•sourceforge.net
        > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
        >
        
        On Fri, Jun 12, 2015 at 8:36 PM, Matt Whitlock <bip@mattwhitlock•name> wrote:
        > On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
        >> On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
        >> > Why should miners only be able to vote for "double the limit" or "halve" the limit? If you're going to use bits, I think you need to use two bits:
        >> >
        >> >     0 0 = no preference ("wildcard" vote)
        >> >     0 1 = vote for the limit to remain the same
        >> >     1 0 = vote for the limit to be halved
        >> >     1 1 = vote for the limit to be doubled
        >> >
        >> > User transactions would follow the same usage. In particular, a user vote of "0 0" (no preference) could be included in a block casting any vote, but a block voting "0 0" (no preference) could only contain transactions voting "0 0" as well.
        >>
        >> Sounds like a good encoding to me. Taking the median of the three
        >> options, and throwing away "don't care" votes entirely, makes sense.
        >
        > I hope you mean the *plurality* of the three options after throwing away the "don't cares," not the *median*.
        >
        > ------------------------------------------------------------------------------
        > _______________________________________________
        > Bitcoin-development mailing list
        > Bitcoin-development@lists•sourceforge.net
        > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
        
        
        
        ^ permalink raw reply	[flat|nested] 42+ messages in thread

      • • * Re: [Bitcoin-development] User vote in blocksize through fees
            2015-06-12 18:39       ` Benjamin
          @ 2015-06-12 18:47         ` Peter Todd
            0 siblings, 0 replies; 42+ messages in thread
          From: Peter Todd @ 2015-06-12 18:47 UTC (permalink / raw)
            To: Benjamin; +Cc: Bitcoin Dev
          
          [-- Attachment #1: Type: text/plain, Size: 1460 bytes --]
          
          On Fri, Jun 12, 2015 at 08:39:21PM +0200, Benjamin wrote:
          > This is a misguided idea, to say the least. If such a mechanism of of
          > user input would be possible, one would use it for transaction
          > verification in the first place. In proof-of-stake outcomes are
          > determined by vote by stake (that vote has very different
          > characteristics than vote by compute power). There is no such thing as
          > making it possible to determine what "users want". That's what the
          > proof-of-work mechanism does in the first place, only that it is now
          > unfortunately skewed/corrupted/(whatever you want to call it). Before
          > centralization the concept of "miners" didn't exist in Bitcoin and
          > miners were roughly identical to users. Peer-to-Peer implies only one
          > class of users.
          > 
          > A big problem with such a vote (in PoW and PoS): miners get paid for
          > their work and have incentives to raise fees. Those who pay fees would
          > have no say in whether those fees are fair or not. Transaction
          > verification has to be roughly profitable, but there is no fixed
          > formula for determining profitability.
          
          Read John Dillon's proposal then, which via proof-of-stake explicitly
          approportions control of increases via % of Bitcoin owned.
          
          
          Anyway, representing everyone is never going to be easy, but at least
          this nVersion thing is very easy to implement.
          
          -- 
          'peter'[:-1]@petertodd.org
          0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
          
          [-- Attachment #2: Digital signature --]
          [-- Type: application/pgp-signature, Size: 650 bytes --]
          
          ^ permalink raw reply	[flat|nested] 42+ messages in thread

      • * Re: [Bitcoin-development] User vote in blocksize through fees
          2015-06-12 18:36     ` Matt Whitlock
          2015-06-12 18:39       ` Benjamin
        @ 2015-06-12 18:44       ` Peter Todd
          2015-06-12 18:52         ` Matt Whitlock
          2015-06-12 18:54         ` Matt Whitlock
          1 sibling, 2 replies; 42+ messages in thread
        From: Peter Todd @ 2015-06-12 18:44 UTC (permalink / raw)
          To: Matt Whitlock; +Cc: bitcoin-development
        
        [-- Attachment #1: Type: text/plain, Size: 1403 bytes --]
        
        On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote:
        > On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
        > > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
        > > > Why should miners only be able to vote for "double the limit" or "halve" the limit? If you're going to use bits, I think you need to use two bits:
        > > > 
        > > > 	0 0 = no preference ("wildcard" vote)
        > > > 	0 1 = vote for the limit to remain the same
        > > > 	1 0 = vote for the limit to be halved
        > > > 	1 1 = vote for the limit to be doubled
        > > > 
        > > > User transactions would follow the same usage. In particular, a user vote of "0 0" (no preference) could be included in a block casting any vote, but a block voting "0 0" (no preference) could only contain transactions voting "0 0" as well.
        > > 
        > > Sounds like a good encoding to me. Taking the median of the three
        > > options, and throwing away "don't care" votes entirely, makes sense.
        > 
        > I hope you mean the *plurality* of the three options after throwing away the "don't cares," not the *median*.
        
        Median ensures that voting "no change" is meaningful. If "double" + "no
        change" = 66%-1, you'd expect the result to be "no change", not "halve""
        With a plurality vote you'd end up with a halving that was supported by
        a minority.
        
        -- 
        'peter'[:-1]@petertodd.org
        0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
        
        [-- Attachment #2: Digital signature --]
        [-- Type: application/pgp-signature, Size: 650 bytes --]
        
        ^ permalink raw reply	[flat|nested] 42+ messages in thread

      • • * Re: [Bitcoin-development] User vote in blocksize through fees
            2015-06-12 18:44       ` Peter Todd
          @ 2015-06-12 18:52         ` Matt Whitlock
            2015-06-12 18:54         ` Matt Whitlock
            1 sibling, 0 replies; 42+ messages in thread
          From: Matt Whitlock @ 2015-06-12 18:52 UTC (permalink / raw)
            To: Peter Todd; +Cc: bitcoin-development
          
          On Friday, 12 June 2015, at 7:44 pm, Peter Todd wrote:
          > On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote:
          > > On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
          > > > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
          > > > > Why should miners only be able to vote for "double the limit" or "halve" the limit? If you're going to use bits, I think you need to use two bits:
          > > > > 
          > > > > 	0 0 = no preference ("wildcard" vote)
          > > > > 	0 1 = vote for the limit to remain the same
          > > > > 	1 0 = vote for the limit to be halved
          > > > > 	1 1 = vote for the limit to be doubled
          > > > > 
          > > > > User transactions would follow the same usage. In particular, a user vote of "0 0" (no preference) could be included in a block casting any vote, but a block voting "0 0" (no preference) could only contain transactions voting "0 0" as well.
          > > > 
          > > > Sounds like a good encoding to me. Taking the median of the three
          > > > options, and throwing away "don't care" votes entirely, makes sense.
          > > 
          > > I hope you mean the *plurality* of the three options after throwing away the "don't cares," not the *median*.
          > 
          > Median ensures that voting "no change" is meaningful. If "double" + "no
          > change" = 66%-1, you'd expect the result to be "no change", not "halve""
          > With a plurality vote you'd end up with a halving that was supported by
          > a minority.
          
          I'm very confused.
          
          Let's say, out of the 12,000 blocks in a voting period:
          • 1000 blocks express no preference,
          • 2000 blocks vote to halve the limit,
          • 3500 blocks vote to double the limit, and
          • 5500 blocks vote to keep the limit the same.
          
           The plurality vote is to keep the limit the same. The median vote is… well, I'm not sure, since there are four choices, and an average of the two "middle" choices doesn't seem to make sense.
          
          
          
          ^ permalink raw reply	[flat|nested] 42+ messages in thread

        • * Re: [Bitcoin-development] User vote in blocksize through fees
            2015-06-12 18:44       ` Peter Todd
            2015-06-12 18:52         ` Matt Whitlock
          @ 2015-06-12 18:54         ` Matt Whitlock
            2015-06-12 18:56           ` Aaron Gustafson
            1 sibling, 1 reply; 42+ messages in thread
          From: Matt Whitlock @ 2015-06-12 18:54 UTC (permalink / raw)
            To: Peter Todd; +Cc: bitcoin-development
          
          On Friday, 12 June 2015, at 7:44 pm, Peter Todd wrote:
          > On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote:
          > > On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
          > > > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
          > > > > Why should miners only be able to vote for "double the limit" or "halve" the limit? If you're going to use bits, I think you need to use two bits:
          > > > > 
          > > > > 	0 0 = no preference ("wildcard" vote)
          > > > > 	0 1 = vote for the limit to remain the same
          > > > > 	1 0 = vote for the limit to be halved
          > > > > 	1 1 = vote for the limit to be doubled
          > > > > 
          > > > > User transactions would follow the same usage. In particular, a user vote of "0 0" (no preference) could be included in a block casting any vote, but a block voting "0 0" (no preference) could only contain transactions voting "0 0" as well.
          > > > 
          > > > Sounds like a good encoding to me. Taking the median of the three
          > > > options, and throwing away "don't care" votes entirely, makes sense.
          > > 
          > > I hope you mean the *plurality* of the three options after throwing away the "don't cares," not the *median*.
          > 
          > Median ensures that voting "no change" is meaningful. If "double" + "no
          > change" = 66%-1, you'd expect the result to be "no change", not "halve""
          > With a plurality vote you'd end up with a halving that was supported by
          > a minority.
          
          Never mind. I think I've figured out what you're getting at, and you're right. We wouldn't want "halve" to win on a plurality just because the remaining majority of the vote was split between double and remain-the-same. Good catch. :)
          
          
          
          ^ permalink raw reply	[flat|nested] 42+ messages in thread

        • • * Re: [Bitcoin-development] User vote in blocksize through fees
              2015-06-12 18:54         ` Matt Whitlock
            @ 2015-06-12 18:56           ` Aaron Gustafson
              0 siblings, 0 replies; 42+ messages in thread
            From: Aaron Gustafson @ 2015-06-12 18:56 UTC (permalink / raw)
              To: Matt Whitlock; +Cc: bitcoin-dev
            
            [-- Attachment #1: Type: text/plain, Size: 2435 bytes --]
            
            For the purposes of finding the median, halve < same < double. It will only
            change if a majority of non-apathetic votes are for halve or a majority of
            non-apathetic votes are for double.
            
            On Fri, Jun 12, 2015 at 11:54 AM, Matt Whitlock <bip@mattwhitlock•name>
            wrote:
            
            > On Friday, 12 June 2015, at 7:44 pm, Peter Todd wrote:
            > > On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote:
            > > > On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
            > > > > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
            > > > > > Why should miners only be able to vote for "double the limit" or
            > "halve" the limit? If you're going to use bits, I think you need to use two
            > bits:
            > > > > >
            > > > > >         0 0 = no preference ("wildcard" vote)
            > > > > >         0 1 = vote for the limit to remain the same
            > > > > >         1 0 = vote for the limit to be halved
            > > > > >         1 1 = vote for the limit to be doubled
            > > > > >
            > > > > > User transactions would follow the same usage. In particular, a
            > user vote of "0 0" (no preference) could be included in a block casting any
            > vote, but a block voting "0 0" (no preference) could only contain
            > transactions voting "0 0" as well.
            > > > >
            > > > > Sounds like a good encoding to me. Taking the median of the three
            > > > > options, and throwing away "don't care" votes entirely, makes sense.
            > > >
            > > > I hope you mean the *plurality* of the three options after throwing
            > away the "don't cares," not the *median*.
            > >
            > > Median ensures that voting "no change" is meaningful. If "double" + "no
            > > change" = 66%-1, you'd expect the result to be "no change", not "halve""
            > > With a plurality vote you'd end up with a halving that was supported by
            > > a minority.
            >
            > Never mind. I think I've figured out what you're getting at, and you're
            > right. We wouldn't want "halve" to win on a plurality just because the
            > remaining majority of the vote was split between double and
            > remain-the-same. Good catch. :)
            >
            >
            > ------------------------------------------------------------------------------
            > _______________________________________________
            > Bitcoin-development mailing list
            > Bitcoin-development@lists•sourceforge.net
            > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
            >
            
            
            
            -- 
            J. Aaron Gustafson
            Cornell University '16 | Computer Science, Engineering | Mathematics, Arts
            & Sciences
            Vice President, Kappa Delta Rho
            jag426@cornell•edu | Ithaca, New York
            
            [-- Attachment #2: Type: text/html, Size: 3925 bytes --]
            
            ^ permalink raw reply	[flat|nested] 42+ messages in thread

• * Re: [Bitcoin-development] User vote in blocksize through fees
    2015-06-12 18:11 [Bitcoin-development] User vote in blocksize through fees Peter Todd
    2015-06-12 18:20 ` Mark Friedenbach
    2015-06-12 18:22 ` Matt Whitlock
  @ 2015-06-13 22:20 ` Danny Thorpe
    2015-06-13 22:24   ` Eric Lombrozo
    2015-06-14  4:55   ` Chun Wang
    2015-06-14  4:16 ` Stephen
    2015-06-14  7:19 ` Ashley Holman
    4 siblings, 2 replies; 42+ messages in thread
  From: Danny Thorpe @ 2015-06-13 22:20 UTC (permalink / raw)
    To: Peter Todd; +Cc: Bitcoin Dev
  
  [-- Attachment #1: Type: text/plain, Size: 2077 bytes --]
  
  Please forgive my ignorance, but why should Bitcoin users have a say in
  block size limits?  It's the miners and Bitcoin node operators that bear
  the burden of managing large blocks, no?
  
  Users voting on network parameters sounds like neighbors voting on how deep
  my swimming pool should be.
  
  Thanks,
  -Danny
  
  On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd <pete@petertodd•org> wrote:
  
  > Jeff Garzik recently proposed that the upper blocksize limit be removed
  > entirely, with a "soft" limit being enforced via miner vote, recorded by
  > hashing power.
  >
  > This mechanism within the protocol for users to have any influence over
  > the miner vote. We can add that back by providing a way for transactions
  > themselves to set a flag determining whether or not they can be included
  > in a block casting a specific vote.
  >
  > We can simplify Garzik's vote to say that one of the nVersion bits
  > either votes for the blocksize to be increased, or decreased, by some
  > fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
  > nVersion bit in transactions themselves, also voting for an increase or
  > decrease. Transactions may only be included in blocks with an
  > indentical vote, thus providing miners with a monetary incentive via
  > fees to vote according to user wishes.
  >
  > Of course, to cast a "don't care" vote we can either define an
  > additional bit, or sign the transaction with both versions. Equally we
  > can even have different versions with different fees, broadcast via a
  > mechanism such as replace-by-fee.
  >
  >
  > See also John Dillon's proposal for proof-of-stake blocksize voting:
  >
  >
  > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
  >
  > --
  > 'peter'[:-1]@petertodd.org
  > 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
  >
  >
  > ------------------------------------------------------------------------------
  >
  > _______________________________________________
  > Bitcoin-development mailing list
  > Bitcoin-development@lists•sourceforge.net
  > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  >
  >
  
  [-- Attachment #2: Type: text/html, Size: 3020 bytes --]
  
  ^ permalink raw reply	[flat|nested] 42+ messages in thread

• • * Re: [Bitcoin-development] User vote in blocksize through fees
      2015-06-13 22:20 ` Danny Thorpe
    @ 2015-06-13 22:24   ` Eric Lombrozo
      2015-06-14  4:55   ` Chun Wang
      1 sibling, 0 replies; 42+ messages in thread
    From: Eric Lombrozo @ 2015-06-13 22:24 UTC (permalink / raw)
      To: Danny Thorpe; +Cc: Bitcoin Dev
    
    
    [-- Attachment #1.1: Type: text/plain, Size: 2907 bytes --]
    
    That’s exactly the problem with Bitcoin - it was supposed to be the case that users ARE the miners and node operators…but…alas…
    
    > On Jun 13, 2015, at 3:20 PM, Danny Thorpe <danny.thorpe@gmail•com> wrote:
    > 
    > Please forgive my ignorance, but why should Bitcoin users have a say in block size limits?  It's the miners and Bitcoin node operators that bear the burden of managing large blocks, no?
    > 
    > Users voting on network parameters sounds like neighbors voting on how deep my swimming pool should be.
    > 
    > Thanks,
    > -Danny
    > 
    > On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd <pete@petertodd•org <mailto:pete@petertodd•org>> wrote:
    > Jeff Garzik recently proposed that the upper blocksize limit be removed
    > entirely, with a "soft" limit being enforced via miner vote, recorded by
    > hashing power.
    > 
    > This mechanism within the protocol for users to have any influence over
    > the miner vote. We can add that back by providing a way for transactions
    > themselves to set a flag determining whether or not they can be included
    > in a block casting a specific vote.
    > 
    > We can simplify Garzik's vote to say that one of the nVersion bits
    > either votes for the blocksize to be increased, or decreased, by some
    > fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
    > nVersion bit in transactions themselves, also voting for an increase or
    > decrease. Transactions may only be included in blocks with an
    > indentical vote, thus providing miners with a monetary incentive via
    > fees to vote according to user wishes.
    > 
    > Of course, to cast a "don't care" vote we can either define an
    > additional bit, or sign the transaction with both versions. Equally we
    > can even have different versions with different fees, broadcast via a
    > mechanism such as replace-by-fee.
    > 
    > 
    > See also John Dillon's proposal for proof-of-stake blocksize voting:
    > 
    > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html <https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html>
    > 
    > --
    > 'peter'[:-1]@petertodd.org <http://petertodd.org/>
    > 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
    > 
    > ------------------------------------------------------------------------------
    > 
    > _______________________________________________
    > Bitcoin-development mailing list
    > Bitcoin-development@lists•sourceforge.net <mailto:Bitcoin-development@lists•sourceforge.net>
    > https://lists.sourceforge.net/lists/listinfo/bitcoin-development <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
    > 
    > 
    > ------------------------------------------------------------------------------
    > _______________________________________________
    > Bitcoin-development mailing list
    > Bitcoin-development@lists•sourceforge.net
    > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
    
    
    [-- Attachment #1.2: Type: text/html, Size: 4566 bytes --]
    
    [-- Attachment #2: Message signed with OpenPGP using GPGMail --]
    [-- Type: application/pgp-signature, Size: 842 bytes --]
    
    ^ permalink raw reply	[flat|nested] 42+ messages in thread

  • * Re: [Bitcoin-development] User vote in blocksize through fees
      2015-06-13 22:20 ` Danny Thorpe
      2015-06-13 22:24   ` Eric Lombrozo
    @ 2015-06-14  4:55   ` Chun Wang
      2015-06-14  4:59     ` Jeff Garzik
      2015-06-14  5:08     ` Eric Lombrozo
      1 sibling, 2 replies; 42+ messages in thread
    From: Chun Wang @ 2015-06-14  4:55 UTC (permalink / raw)
      To: Danny Thorpe; +Cc: Bitcoin Dev
    
    To tell you the truth. It is only because most miners are not located
    in the West. If Slush, Eligius and BTC Guild still on top 3, the core
    developers, including brain-dead Mike Hearn, would be very happy to do
    BIP100 just like they did BIP34 and BIP66. Shame on you!
    
    On Sun, Jun 14, 2015 at 6:20 AM, Danny Thorpe <danny.thorpe@gmail•com> wrote:
    > Please forgive my ignorance, but why should Bitcoin users have a say in
    > block size limits?  It's the miners and Bitcoin node operators that bear the
    > burden of managing large blocks, no?
    >
    > Users voting on network parameters sounds like neighbors voting on how deep
    > my swimming pool should be.
    >
    > Thanks,
    > -Danny
    >
    > On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd <pete@petertodd•org> wrote:
    >>
    >> Jeff Garzik recently proposed that the upper blocksize limit be removed
    >> entirely, with a "soft" limit being enforced via miner vote, recorded by
    >> hashing power.
    >>
    >> This mechanism within the protocol for users to have any influence over
    >> the miner vote. We can add that back by providing a way for transactions
    >> themselves to set a flag determining whether or not they can be included
    >> in a block casting a specific vote.
    >>
    >> We can simplify Garzik's vote to say that one of the nVersion bits
    >> either votes for the blocksize to be increased, or decreased, by some
    >> fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
    >> nVersion bit in transactions themselves, also voting for an increase or
    >> decrease. Transactions may only be included in blocks with an
    >> indentical vote, thus providing miners with a monetary incentive via
    >> fees to vote according to user wishes.
    >>
    >> Of course, to cast a "don't care" vote we can either define an
    >> additional bit, or sign the transaction with both versions. Equally we
    >> can even have different versions with different fees, broadcast via a
    >> mechanism such as replace-by-fee.
    >>
    >>
    >> See also John Dillon's proposal for proof-of-stake blocksize voting:
    >>
    >>
    >> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
    >>
    >> --
    >> 'peter'[:-1]@petertodd.org
    >> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
    >>
    >>
    >> ------------------------------------------------------------------------------
    >>
    >> _______________________________________________
    >> Bitcoin-development mailing list
    >> Bitcoin-development@lists•sourceforge.net
    >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
    >>
    >
    >
    > ------------------------------------------------------------------------------
    >
    > _______________________________________________
    > Bitcoin-development mailing list
    > Bitcoin-development@lists•sourceforge.net
    > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
    >
    
    
    
    ^ permalink raw reply	[flat|nested] 42+ messages in thread

  • • * Re: [Bitcoin-development] User vote in blocksize through fees
        2015-06-14  4:55   ` Chun Wang
      @ 2015-06-14  4:59     ` Jeff Garzik
        2015-06-14  5:08     ` Eric Lombrozo
        1 sibling, 0 replies; 42+ messages in thread
      From: Jeff Garzik @ 2015-06-14  4:59 UTC (permalink / raw)
        To: Chun Wang; +Cc: Bitcoin Dev
      
      [-- Attachment #1: Type: text/plain, Size: 523 bytes --]
      
      On Sun, Jun 14, 2015 at 12:55 AM, Chun Wang <1240902@gmail•com> wrote:
      
      > To tell you the truth. It is only because most miners are not located
      > in the West. If Slush, Eligius and BTC Guild still on top 3, the core
      > developers, including brain-dead Mike Hearn, would be very happy to do
      > BIP100 just like they did BIP34 and BIP66. Shame on you!
      >
      
      BIP 100 requires a hard fork to engage.  Users proactively opt-in.
      
      -- 
      Jeff Garzik
      Bitcoin core developer and open source evangelist
      BitPay, Inc.      https://bitpay.com/
      
      [-- Attachment #2: Type: text/html, Size: 954 bytes --]
      
      ^ permalink raw reply	[flat|nested] 42+ messages in thread

    • * Re: [Bitcoin-development] User vote in blocksize through fees
        2015-06-14  4:55   ` Chun Wang
        2015-06-14  4:59     ` Jeff Garzik
      @ 2015-06-14  5:08     ` Eric Lombrozo
        2015-06-14  5:13       ` Jeff Garzik
        1 sibling, 1 reply; 42+ messages in thread
      From: Eric Lombrozo @ 2015-06-14  5:08 UTC (permalink / raw)
        To: Chun Wang; +Cc: Bitcoin Dev
      
      [-- Attachment #1: Type: text/plain, Size: 3942 bytes --]
      
      Chun,
      
      With all due respect, there are a couple major differences between BIP34 and BIP66 on the one hand and BIP100 on the other.
      
      1) BIP34 and BIP66 are soft forks. Miners choosing to switch to them will not seriously impact validation rules for non-mining users that do not make the switch. With BIP66, the worst that can happen to them is noncompliant transactions will no longer be accepted by the network…but even nodes that do not switch over will continue to remain synched with the network.
      
      2) BIP100 has direct economic consequences…and particularly for miners. It lends itself to much greater corruptibility.
      
      - Eric Lombrozo
      
      > On Jun 13, 2015, at 9:55 PM, Chun Wang <1240902@gmail•com> wrote:
      > 
      > To tell you the truth. It is only because most miners are not located
      > in the West. If Slush, Eligius and BTC Guild still on top 3, the core
      > developers, including brain-dead Mike Hearn, would be very happy to do
      > BIP100 just like they did BIP34 and BIP66. Shame on you!
      > 
      > On Sun, Jun 14, 2015 at 6:20 AM, Danny Thorpe <danny.thorpe@gmail•com> wrote:
      >> Please forgive my ignorance, but why should Bitcoin users have a say in
      >> block size limits?  It's the miners and Bitcoin node operators that bear the
      >> burden of managing large blocks, no?
      >> 
      >> Users voting on network parameters sounds like neighbors voting on how deep
      >> my swimming pool should be.
      >> 
      >> Thanks,
      >> -Danny
      >> 
      >> On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd <pete@petertodd•org> wrote:
      >>> 
      >>> Jeff Garzik recently proposed that the upper blocksize limit be removed
      >>> entirely, with a "soft" limit being enforced via miner vote, recorded by
      >>> hashing power.
      >>> 
      >>> This mechanism within the protocol for users to have any influence over
      >>> the miner vote. We can add that back by providing a way for transactions
      >>> themselves to set a flag determining whether or not they can be included
      >>> in a block casting a specific vote.
      >>> 
      >>> We can simplify Garzik's vote to say that one of the nVersion bits
      >>> either votes for the blocksize to be increased, or decreased, by some
      >>> fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
      >>> nVersion bit in transactions themselves, also voting for an increase or
      >>> decrease. Transactions may only be included in blocks with an
      >>> indentical vote, thus providing miners with a monetary incentive via
      >>> fees to vote according to user wishes.
      >>> 
      >>> Of course, to cast a "don't care" vote we can either define an
      >>> additional bit, or sign the transaction with both versions. Equally we
      >>> can even have different versions with different fees, broadcast via a
      >>> mechanism such as replace-by-fee.
      >>> 
      >>> 
      >>> See also John Dillon's proposal for proof-of-stake blocksize voting:
      >>> 
      >>> 
      >>> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
      >>> 
      >>> --
      >>> 'peter'[:-1]@petertodd.org
      >>> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
      >>> 
      >>> 
      >>> ------------------------------------------------------------------------------
      >>> 
      >>> _______________________________________________
      >>> Bitcoin-development mailing list
      >>> Bitcoin-development@lists•sourceforge.net
      >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
      >>> 
      >> 
      >> 
      >> ------------------------------------------------------------------------------
      >> 
      >> _______________________________________________
      >> Bitcoin-development mailing list
      >> Bitcoin-development@lists•sourceforge.net
      >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
      >> 
      > 
      > ------------------------------------------------------------------------------
      > _______________________________________________
      > Bitcoin-development mailing list
      > Bitcoin-development@lists•sourceforge.net
      > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
      
      
      [-- Attachment #2: Message signed with OpenPGP using GPGMail --]
      [-- Type: application/pgp-signature, Size: 842 bytes --]
      
      ^ permalink raw reply	[flat|nested] 42+ messages in thread

    • • * Re: [Bitcoin-development] User vote in blocksize through fees
          2015-06-14  5:08     ` Eric Lombrozo
        @ 2015-06-14  5:13       ` Jeff Garzik
          2015-06-14  5:20         ` Eric Lombrozo
          0 siblings, 1 reply; 42+ messages in thread
        From: Jeff Garzik @ 2015-06-14  5:13 UTC (permalink / raw)
          To: Eric Lombrozo; +Cc: Bitcoin Dev
        
        [-- Attachment #1: Type: text/plain, Size: 502 bytes --]
        
        On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
        
        > 2) BIP100 has direct economic consequences…and particularly for miners. It
        > lends itself to much greater corruptibility.
        >
        >
        What is the alternative?  Have a Chief Scientist or Technical Advisory
        Board choose what is a proper fee, what is a proper level of
        decentralization, a proper growth factor?
        
        
        -- 
        Jeff Garzik
        Bitcoin core developer and open source evangelist
        BitPay, Inc.      https://bitpay.com/
        
        [-- Attachment #2: Type: text/html, Size: 927 bytes --]
        
        ^ permalink raw reply	[flat|nested] 42+ messages in thread

      • • * Re: [Bitcoin-development] User vote in blocksize through fees
            2015-06-14  5:13       ` Jeff Garzik
          @ 2015-06-14  5:20         ` Eric Lombrozo
            2015-06-14  5:36           ` Jeff Garzik
            0 siblings, 1 reply; 42+ messages in thread
          From: Eric Lombrozo @ 2015-06-14  5:20 UTC (permalink / raw)
            To: Jeff Garzik; +Cc: Bitcoin Dev
          
          
          [-- Attachment #1.1: Type: text/plain, Size: 739 bytes --]
          
          I definitely think we need some voting system for metaconsensus…but if we’re going to seriously consider this we should look at the problem much more generally. Using false choices doesn’t really help, though ;)
          
          - Eric Lombrozo
          
          
          > On Jun 13, 2015, at 10:13 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
          > 
          > On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo@gmail•com <mailto:elombrozo@gmail•com>> wrote:
          > 2) BIP100 has direct economic consequences…and particularly for miners. It lends itself to much greater corruptibility.
          > 
          > 
          > What is the alternative?  Have a Chief Scientist or Technical Advisory Board choose what is a proper fee, what is a proper level of decentralization, a proper growth factor?
          
          
          [-- Attachment #1.2: Type: text/html, Size: 3473 bytes --]
          
          [-- Attachment #2: Message signed with OpenPGP using GPGMail --]
          [-- Type: application/pgp-signature, Size: 842 bytes --]
          
          ^ permalink raw reply	[flat|nested] 42+ messages in thread

        • • * Re: [Bitcoin-development] User vote in blocksize through fees
              2015-06-14  5:20         ` Eric Lombrozo
            @ 2015-06-14  5:36           ` Jeff Garzik
              2015-06-14 10:06             ` Mats Henricson
              2015-06-15  3:59             ` Eric Lombrozo
              0 siblings, 2 replies; 42+ messages in thread
            From: Jeff Garzik @ 2015-06-14  5:36 UTC (permalink / raw)
              To: Eric Lombrozo; +Cc: Bitcoin Dev
            
            [-- Attachment #1: Type: text/plain, Size: 1980 bytes --]
            
            The choice is very real and on-point.  What should the block size limit
            be?  Why?
            
            There is a large consensus that it needs increasing.  To what?  By what
            factor?
            
            The size limit literally defines the fee market, the whole damn thing.  If
            software high priests choose a size limit of 300k, space is scarce, fees
            are bid high.  If software high priests choose a size limit of 32mb, space
            is plentiful, fees are near zero.  Market actors take their signals
            accordingly.  Some business models boom, some business models fail, as a
            direct result of changing this unintentionally-added speedbump.  Different
            users value adoption, decentralization etc. differently.
            
            The size limit is an economic policy lever that needs to be transitioned
            -away- from software and software developers, to the free market.
            
            A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance
            problems associated with actors lobbying developers, even if a cloistered
            and vetted Technical Advisory Board as has been proposed.
            
            
            
            
            
            
            
            On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
            
            > I definitely think we need some voting system for metaconsensus…but if
            > we’re going to seriously consider this we should look at the problem much
            > more generally. Using false choices doesn’t really help, though ;)
            >
            > - Eric Lombrozo
            >
            >
            > On Jun 13, 2015, at 10:13 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
            >
            > On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo@gmail•com>
            > wrote:
            >
            >> 2) BIP100 has direct economic consequences…and particularly for miners.
            >> It lends itself to much greater corruptibility.
            >>
            >>
            > What is the alternative?  Have a Chief Scientist or Technical Advisory
            > Board choose what is a proper fee, what is a proper level of
            > decentralization, a proper growth factor?
            >
            >
            >
            
            
            -- 
            Jeff Garzik
            Bitcoin core developer and open source evangelist
            BitPay, Inc.      https://bitpay.com/
            
            [-- Attachment #2: Type: text/html, Size: 4504 bytes --]
            
            ^ permalink raw reply	[flat|nested] 42+ messages in thread

          • • * Re: [Bitcoin-development] User vote in blocksize through fees
                2015-06-14  5:36           ` Jeff Garzik
              @ 2015-06-14 10:06             ` Mats Henricson
                2015-06-14 10:34               ` Benjamin
                2015-06-14 14:42               ` Jeff Garzik
                2015-06-15  3:59             ` Eric Lombrozo
                1 sibling, 2 replies; 42+ messages in thread
              From: Mats Henricson @ 2015-06-14 10:06 UTC (permalink / raw)
                To: bitcoin-development
              
              Jeff,
              
              with all due respect, but I've seen you saying this a few times
              now, that this decision is oh so difficult and important.
              
              But this is not helpful. We all know that. Even I.
              
              Make a suggestion, or stay out of the debate!
              
              Mats
              
              On 06/14/2015 07:36 AM, Jeff Garzik wrote:
              > The choice is very real and on-point.  What should the block size limit
              > be?  Why?
              > 
              > There is a large consensus that it needs increasing.  To what?  By what
              > factor?
              > 
              > The size limit literally defines the fee market, the whole damn thing.  If
              > software high priests choose a size limit of 300k, space is scarce, fees
              > are bid high.  If software high priests choose a size limit of 32mb, space
              > is plentiful, fees are near zero.  Market actors take their signals
              > accordingly.  Some business models boom, some business models fail, as a
              > direct result of changing this unintentionally-added speedbump.  Different
              > users value adoption, decentralization etc. differently.
              > 
              > The size limit is an economic policy lever that needs to be transitioned
              > -away- from software and software developers, to the free market.
              > 
              > A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance
              > problems associated with actors lobbying developers, even if a cloistered
              > and vetted Technical Advisory Board as has been proposed.
              > 
              > 
              > 
              > 
              > 
              > 
              > 
              > On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
              > 
              >> I definitely think we need some voting system for metaconsensus…but if
              >> we’re going to seriously consider this we should look at the problem much
              >> more generally. Using false choices doesn’t really help, though ;)
              >>
              >> - Eric Lombrozo
              >>
              >>
              >> On Jun 13, 2015, at 10:13 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
              >>
              >> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo@gmail•com>
              >> wrote:
              >>
              >>> 2) BIP100 has direct economic consequences…and particularly for miners.
              >>> It lends itself to much greater corruptibility.
              >>>
              >>>
              >> What is the alternative?  Have a Chief Scientist or Technical Advisory
              >> Board choose what is a proper fee, what is a proper level of
              >> decentralization, a proper growth factor?
              >>
              >>
              >>
              > 
              > 
              > 
              > 
              > ------------------------------------------------------------------------------
              > 
              > 
              > 
              > _______________________________________________
              > Bitcoin-development mailing list
              > Bitcoin-development@lists•sourceforge.net
              > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
              > 
              
              
              
              ^ permalink raw reply	[flat|nested] 42+ messages in thread

            • • * Re: [Bitcoin-development] User vote in blocksize through fees
                  2015-06-14 10:06             ` Mats Henricson
                @ 2015-06-14 10:34               ` Benjamin
                  2015-06-14 15:07                 ` Jeff Garzik
                  2015-06-14 20:10                 ` Eric Lombrozo
                  2015-06-14 14:42               ` Jeff Garzik
                  1 sibling, 2 replies; 42+ messages in thread
                From: Benjamin @ 2015-06-14 10:34 UTC (permalink / raw)
                  To: Mats Henricson; +Cc: Bitcoin Dev
                
                "The size limit is an economic policy lever that needs to be
                transitioned -away- from software and software developers, to the free
                market."
                
                Exactly right. Bitcoin does not have a free market for fee though, and
                literally all the discussion so far has neglected some fundamental
                aspect of this, as you described. It's not at all a "technical" or
                "engineering" decision. It's the question of how to potentially
                re-design a fundamental part of Bitcoin, and the proposals so far
                don't address this. What is the price of the scarce resource of the
                blockchain and the mechanism to decide on price, once the subsidy runs
                out?
                
                On Sun, Jun 14, 2015 at 12:06 PM, Mats Henricson <mats@henricson•se> wrote:
                > Jeff,
                >
                > with all due respect, but I've seen you saying this a few times
                > now, that this decision is oh so difficult and important.
                >
                > But this is not helpful. We all know that. Even I.
                >
                > Make a suggestion, or stay out of the debate!
                >
                > Mats
                >
                > On 06/14/2015 07:36 AM, Jeff Garzik wrote:
                >> The choice is very real and on-point.  What should the block size limit
                >> be?  Why?
                >>
                >> There is a large consensus that it needs increasing.  To what?  By what
                >> factor?
                >>
                >> The size limit literally defines the fee market, the whole damn thing.  If
                >> software high priests choose a size limit of 300k, space is scarce, fees
                >> are bid high.  If software high priests choose a size limit of 32mb, space
                >> is plentiful, fees are near zero.  Market actors take their signals
                >> accordingly.  Some business models boom, some business models fail, as a
                >> direct result of changing this unintentionally-added speedbump.  Different
                >> users value adoption, decentralization etc. differently.
                >>
                >> The size limit is an economic policy lever that needs to be transitioned
                >> -away- from software and software developers, to the free market.
                >>
                >> A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance
                >> problems associated with actors lobbying developers, even if a cloistered
                >> and vetted Technical Advisory Board as has been proposed.
                >>
                >>
                >>
                >>
                >>
                >>
                >>
                >> On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
                >>
                >>> I definitely think we need some voting system for metaconsensus…but if
                >>> we’re going to seriously consider this we should look at the problem much
                >>> more generally. Using false choices doesn’t really help, though ;)
                >>>
                >>> - Eric Lombrozo
                >>>
                >>>
                >>> On Jun 13, 2015, at 10:13 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
                >>>
                >>> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo@gmail•com>
                >>> wrote:
                >>>
                >>>> 2) BIP100 has direct economic consequences…and particularly for miners.
                >>>> It lends itself to much greater corruptibility.
                >>>>
                >>>>
                >>> What is the alternative?  Have a Chief Scientist or Technical Advisory
                >>> Board choose what is a proper fee, what is a proper level of
                >>> decentralization, a proper growth factor?
                >>>
                >>>
                >>>
                >>
                >>
                >>
                >>
                >> ------------------------------------------------------------------------------
                >>
                >>
                >>
                >> _______________________________________________
                >> Bitcoin-development mailing list
                >> Bitcoin-development@lists•sourceforge.net
                >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                >>
                >
                > ------------------------------------------------------------------------------
                > _______________________________________________
                > Bitcoin-development mailing list
                > Bitcoin-development@lists•sourceforge.net
                > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                
                
                
                ^ permalink raw reply	[flat|nested] 42+ messages in thread

              • • * Re: [Bitcoin-development] User vote in blocksize through fees
                    2015-06-14 10:34               ` Benjamin
                  @ 2015-06-14 15:07                 ` Jeff Garzik
                    2015-06-14 21:59                   ` odinn
                    2015-06-14 20:10                 ` Eric Lombrozo
                    1 sibling, 1 reply; 42+ messages in thread
                  From: Jeff Garzik @ 2015-06-14 15:07 UTC (permalink / raw)
                    To: Benjamin, Gavin Andresen, Gregory Maxwell, Pieter Wuille,
                  	Wladimir van der Laan
                    Cc: Bitcoin Dev
                  
                  [-- Attachment #1: Type: text/plain, Size: 5595 bytes --]
                  
                  Exactly -- both block size proponents and block size change conservatives
                  seem to be glossing over this aspect - much to my dismay.
                  
                  Choosing the size limit is choosing the size of a scarce resource.  By fiat.
                  
                  It is wrong to think that a "technical consensus" can choose what is best
                  here.
                  
                  The block size limit defines the scope of a resource for which all fee
                  market actors bid.  That, in turn, defines who is in the fee market and how
                  they behave, what market choices are made.
                  
                  It doesn't matter how or why the limit was originally enacted, what Satoshi
                  meant to do.  What matters, economically, is what is.  What the software
                  and our $3B economy & market knows and sees today.  (I think some block
                  size change proponents miss this!)
                  
                  The solution lies in transitioning this size limit to the free market.  In
                  the end, the users must choose their desired level of growth,
                  decentralization, etc.  We cannot rely on some dev's idea of the proper
                  level of fee, proper level of growth, proper level of decentralization.
                  
                  And IMO, a "floating limit with training wheels" is better and stronger for
                  bitcoin's health from a governance, user choice and free market perspective
                  than simply "hard fork to 2MB, come back again in 6 months."
                  
                  
                  
                  
                  
                  
                  
                  On Sun, Jun 14, 2015 at 6:34 AM, Benjamin <benjamin.l.cordes@gmail•com>
                  wrote:
                  
                  > "The size limit is an economic policy lever that needs to be
                  > transitioned -away- from software and software developers, to the free
                  > market."
                  >
                  > Exactly right. Bitcoin does not have a free market for fee though, and
                  > literally all the discussion so far has neglected some fundamental
                  > aspect of this, as you described. It's not at all a "technical" or
                  > "engineering" decision. It's the question of how to potentially
                  > re-design a fundamental part of Bitcoin, and the proposals so far
                  > don't address this. What is the price of the scarce resource of the
                  > blockchain and the mechanism to decide on price, once the subsidy runs
                  > out?
                  >
                  > On Sun, Jun 14, 2015 at 12:06 PM, Mats Henricson <mats@henricson•se>
                  > wrote:
                  > > Jeff,
                  > >
                  > > with all due respect, but I've seen you saying this a few times
                  > > now, that this decision is oh so difficult and important.
                  > >
                  > > But this is not helpful. We all know that. Even I.
                  > >
                  > > Make a suggestion, or stay out of the debate!
                  > >
                  > > Mats
                  > >
                  > > On 06/14/2015 07:36 AM, Jeff Garzik wrote:
                  > >> The choice is very real and on-point.  What should the block size limit
                  > >> be?  Why?
                  > >>
                  > >> There is a large consensus that it needs increasing.  To what?  By what
                  > >> factor?
                  > >>
                  > >> The size limit literally defines the fee market, the whole damn thing.
                  > If
                  > >> software high priests choose a size limit of 300k, space is scarce, fees
                  > >> are bid high.  If software high priests choose a size limit of 32mb,
                  > space
                  > >> is plentiful, fees are near zero.  Market actors take their signals
                  > >> accordingly.  Some business models boom, some business models fail, as a
                  > >> direct result of changing this unintentionally-added speedbump.
                  > Different
                  > >> users value adoption, decentralization etc. differently.
                  > >>
                  > >> The size limit is an economic policy lever that needs to be transitioned
                  > >> -away- from software and software developers, to the free market.
                  > >>
                  > >> A simple, e.g. hard fork to 2MB or 4MB does not fix higher level
                  > governance
                  > >> problems associated with actors lobbying developers, even if a
                  > cloistered
                  > >> and vetted Technical Advisory Board as has been proposed.
                  > >>
                  > >>
                  > >>
                  > >>
                  > >>
                  > >>
                  > >>
                  > >> On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo <elombrozo@gmail•com>
                  > wrote:
                  > >>
                  > >>> I definitely think we need some voting system for metaconsensus…but if
                  > >>> we’re going to seriously consider this we should look at the problem
                  > much
                  > >>> more generally. Using false choices doesn’t really help, though ;)
                  > >>>
                  > >>> - Eric Lombrozo
                  > >>>
                  > >>>
                  > >>> On Jun 13, 2015, at 10:13 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
                  > >>>
                  > >>> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo@gmail•com>
                  > >>> wrote:
                  > >>>
                  > >>>> 2) BIP100 has direct economic consequences…and particularly for
                  > miners.
                  > >>>> It lends itself to much greater corruptibility.
                  > >>>>
                  > >>>>
                  > >>> What is the alternative?  Have a Chief Scientist or Technical Advisory
                  > >>> Board choose what is a proper fee, what is a proper level of
                  > >>> decentralization, a proper growth factor?
                  > >>>
                  > >>>
                  > >>>
                  > >>
                  > >>
                  > >>
                  > >>
                  > >>
                  > ------------------------------------------------------------------------------
                  > >>
                  > >>
                  > >>
                  > >> _______________________________________________
                  > >> Bitcoin-development mailing list
                  > >> Bitcoin-development@lists•sourceforge.net
                  > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                  > >>
                  > >
                  > >
                  > ------------------------------------------------------------------------------
                  > > _______________________________________________
                  > > Bitcoin-development mailing list
                  > > Bitcoin-development@lists•sourceforge.net
                  > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                  >
                  >
                  > ------------------------------------------------------------------------------
                  > _______________________________________________
                  > Bitcoin-development mailing list
                  > Bitcoin-development@lists•sourceforge.net
                  > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                  >
                  
                  
                  
                  -- 
                  Jeff Garzik
                  Bitcoin core developer and open source evangelist
                  BitPay, Inc.      https://bitpay.com/
                  
                  [-- Attachment #2: Type: text/html, Size: 7784 bytes --]
                  
                  ^ permalink raw reply	[flat|nested] 42+ messages in thread

                • • * Re: [Bitcoin-development] User vote in blocksize through fees
                      2015-06-14 15:07                 ` Jeff Garzik
                    @ 2015-06-14 21:59                   ` odinn
                      0 siblings, 0 replies; 42+ messages in thread
                    From: odinn @ 2015-06-14 21:59 UTC (permalink / raw)
                      To: bitcoin-development
                    
                    -----BEGIN PGP SIGNED MESSAGE-----
                    Hash: SHA1
                    
                    Notionally, I agree with what I see written here by Jeff, and I
                    appreciate the thoughtfulness that went into this short post to list.
                    
                    On 06/14/2015 08:07 AM, Jeff Garzik wrote:
                    > Exactly -- both block size proponents and block size change 
                    > conservatives seem to be glossing over this aspect - much to my 
                    > dismay.
                    > 
                    > Choosing the size limit is choosing the size of a scarce resource. 
                    > By fiat.
                    > 
                    > It is wrong to think that a "technical consensus" can choose what 
                    > is best here.
                    > 
                    > The block size limit defines the scope of a resource for which all 
                    > fee market actors bid.  That, in turn, defines who is in the fee 
                    > market and how they behave, what market choices are made.
                    > 
                    > It doesn't matter how or why the limit was originally enacted, what
                    > Satoshi meant to do.  What matters, economically, is what is. What
                    > the software and our $3B economy & market knows and sees today.  (I
                    > think some block size change proponents miss this!)
                    > 
                    > The solution lies in transitioning this size limit to the free 
                    > market. In the end, the users must choose their desired level of 
                    > growth, decentralization, etc.  We cannot rely on some dev's idea 
                    > of the proper level of fee, proper level of growth, proper level
                    > of decentralization.
                    > 
                    > And IMO, a "floating limit with training wheels" is better and 
                    > stronger for bitcoin's health from a governance, user choice and 
                    > free market perspective than simply "hard fork to 2MB, come back 
                    > again in 6 months."
                    > 
                    > 
                    > 
                    > 
                    > 
                    > 
                    > 
                    > On Sun, Jun 14, 2015 at 6:34 AM, Benjamin 
                    > <benjamin.l.cordes@gmail•com <mailto:benjamin.l.cordes@gmail•com>> 
                    > wrote:
                    > 
                    > "The size limit is an economic policy lever that needs to be 
                    > transitioned -away- from software and software developers, to the 
                    > free market."
                    > 
                    > Exactly right. Bitcoin does not have a free market for fee though, 
                    > and literally all the discussion so far has neglected some 
                    > fundamental aspect of this, as you described. It's not at all a 
                    > "technical" or "engineering" decision. It's the question of how to 
                    > potentially re-design a fundamental part of Bitcoin, and the 
                    > proposals so far don't address this. What is the price of the 
                    > scarce resource of the blockchain and the mechanism to decide on 
                    > price, once the subsidy runs out?
                    > 
                    > On Sun, Jun 14, 2015 at 12:06 PM, Mats Henricson <mats@henricson•se
                    > <mailto:mats@henricson•se>> wrote:
                    >> Jeff,
                    >> 
                    >> with all due respect, but I've seen you saying this a few times 
                    >> now, that this decision is oh so difficult and important.
                    >> 
                    >> But this is not helpful. We all know that. Even I.
                    >> 
                    >> Make a suggestion, or stay out of the debate!
                    >> 
                    >> Mats
                    >> 
                    >> On 06/14/2015 07:36 AM, Jeff Garzik wrote:
                    >>> The choice is very real and on-point.  What should the block 
                    >>> size
                    > limit
                    >>> be?  Why?
                    >>> 
                    >>> There is a large consensus that it needs increasing.  To what?
                    >>> 
                    > By what
                    >>> factor?
                    >>> 
                    >>> The size limit literally defines the fee market, the whole 
                    >>> damn
                    > thing.  If
                    >>> software high priests choose a size limit of 300k, space is
                    > scarce, fees
                    >>> are bid high.  If software high priests choose a size limit of
                    > 32mb, space
                    >>> is plentiful, fees are near zero.  Market actors take their 
                    >>> signals accordingly.  Some business models boom, some business 
                    >>> models
                    > fail, as a
                    >>> direct result of changing this unintentionally-added
                    >>> speedbump.
                    >>> 
                    > Different
                    >>> users value adoption, decentralization etc. differently.
                    >>> 
                    >>> The size limit is an economic policy lever that needs to be
                    > transitioned
                    >>> -away- from software and software developers, to the free 
                    >>> market.
                    >>> 
                    >>> A simple, e.g. hard fork to 2MB or 4MB does not fix higher 
                    >>> level
                    > governance
                    >>> problems associated with actors lobbying developers, even if a
                    > cloistered
                    >>> and vetted Technical Advisory Board as has been proposed.
                    >>> 
                    >>> 
                    >>> 
                    >>> 
                    >>> 
                    >>> 
                    >>> 
                    >>> On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo
                    > <elombrozo@gmail•com <mailto:elombrozo@gmail•com>> wrote:
                    >>> 
                    >>>> I definitely think we need some voting system for
                    > metaconsensus…but if
                    >>>> we’re going to seriously consider this we should look at the
                    > problem much
                    >>>> more generally. Using false choices doesn’t really help, 
                    >>>> though ;)
                    >>>> 
                    >>>> - Eric Lombrozo
                    >>>> 
                    >>>> 
                    >>>> On Jun 13, 2015, at 10:13 PM, Jeff Garzik 
                    >>>> <jgarzik@bitpay•com
                    > <mailto:jgarzik@bitpay•com>> wrote:
                    >>>> 
                    >>>> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo
                    > <elombrozo@gmail•com <mailto:elombrozo@gmail•com>>
                    >>>> wrote:
                    >>>> 
                    >>>>> 2) BIP100 has direct economic consequences…and
                    >>>>> particularly for
                    > miners.
                    >>>>> It lends itself to much greater corruptibility.
                    >>>>> 
                    >>>>> 
                    >>>> What is the alternative?  Have a Chief Scientist or 
                    >>>> Technical
                    > Advisory
                    >>>> Board choose what is a proper fee, what is a proper level of
                    >>>>  decentralization, a proper growth factor?
                    >>>> 
                    >>>> 
                    >>>> 
                    >>> 
                    >>> 
                    >>> 
                    >>> 
                    >>> 
                    > ----------------------------------------------------------------------
                    - --------
                    >
                    >
                    > 
                    >> 
                    >>> 
                    >>> 
                    >>> _______________________________________________ 
                    >>> Bitcoin-development mailing list 
                    >>> Bitcoin-development@lists•sourceforge.net
                    > <mailto:Bitcoin-development@lists•sourceforge.net>
                    >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                    >
                    >>>
                    >>> 
                    >> 
                    >> 
                    >> 
                    > ----------------------------------------------------------------------
                    - --------
                    >
                    >
                    > 
                    _______________________________________________
                    >> Bitcoin-development mailing list 
                    >> Bitcoin-development@lists•sourceforge.net
                    > <mailto:Bitcoin-development@lists•sourceforge.net>
                    >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                    > 
                    > ----------------------------------------------------------------------
                    - --------
                    >
                    >
                    > 
                    _______________________________________________
                    > Bitcoin-development mailing list 
                    > Bitcoin-development@lists•sourceforge.net 
                    > <mailto:Bitcoin-development@lists•sourceforge.net> 
                    > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                    > 
                    > 
                    > 
                    > 
                    > -- Jeff Garzik Bitcoin core developer and open source evangelist 
                    > BitPay, Inc.      https://bitpay.com/
                    > 
                    > 
                    > ----------------------------------------------------------------------
                    - --------
                    >
                    >
                    > 
                    > 
                    > 
                    > _______________________________________________
                    > Bitcoin-development mailing list
                    > Bitcoin-development@lists•sourceforge.net 
                    > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                    > 
                    
                    - -- 
                    http://abis.io ~
                    "a protocol concept to enable decentralization
                    and expansion of a giving economy, and a new social good"
                    https://keybase.io/odinn
                    -----BEGIN PGP SIGNATURE-----
                    Version: GnuPG v1
                    
                    iQEcBAEBAgAGBQJVfflFAAoJEGxwq/inSG8CrWoIAJOsZHTWqdILE0IYmmE50E/S
                    BcbPJJtjodw1liPVJEybyNUKSgq4Ucw9tuQpMVv3hF8bvug6/6HtxAQCptuIKRSw
                    WigZyvgm79u474YsPULG+2SltMrOFqmA05jTF9vWo0LBSY4xiMXjT4VwVt9xEcFc
                    qHW5OUa1QoFZkaOf/jtY+H3a9w8cHZFlroTkf4MaJkaMo81oSRfWz3Mj8wOz6f8z
                    MSEpvQERzETEcV0SqTBnzsoX8toO1s24a9HejMMfbeD7JAy8EvayFb3G1LNzBNVC
                    1x/yeLBGnE3Z0P80J0oUR5taLbGJl9+7Hb16rEzxivtZF5FWBdDmvwKBOKJ1Alo=
                    =ubcH
                    -----END PGP SIGNATURE-----
                    
                    
                    
                    ^ permalink raw reply	[flat|nested] 42+ messages in thread

                • * Re: [Bitcoin-development] User vote in blocksize through fees
                    2015-06-14 10:34               ` Benjamin
                    2015-06-14 15:07                 ` Jeff Garzik
                  @ 2015-06-14 20:10                 ` Eric Lombrozo
                    1 sibling, 0 replies; 42+ messages in thread
                  From: Eric Lombrozo @ 2015-06-14 20:10 UTC (permalink / raw)
                    To: Benjamin; +Cc: Bitcoin Dev
                  
                  [-- Attachment #1: Type: text/plain, Size: 4614 bytes --]
                  
                  
                  > On Jun 14, 2015, at 3:34 AM, Benjamin <benjamin.l.cordes@gmail•com> wrote:
                  > 
                  > "The size limit is an economic policy lever that needs to be
                  > transitioned -away- from software and software developers, to the free
                  > market."
                  > 
                  > Exactly right. Bitcoin does not have a free market for fee though, and
                  > literally all the discussion so far has neglected some fundamental
                  > aspect of this, as you described. It's not at all a "technical" or
                  > "engineering" decision. It's the question of how to potentially
                  > re-design a fundamental part of Bitcoin, and the proposals so far
                  > don't address this. What is the price of the scarce resource of the
                  > blockchain and the mechanism to decide on price, once the subsidy runs
                  > out?
                  > 
                  
                  In addition, fees are complicated by the fact that they are used as an anti-spam measure for relay nodes…who don’t see ANY direct compensation whatsoever for providing that service. So we really have two different fees being tacked on…but the miners get to keep all of it…and the relay fee is being hard coded into the software.
                  
                  Fee calculation heuristics for wallets are already far from trivial - this is another issue that needs to be addressed.
                  
                  - Eric Lombrozo
                  
                  > On Sun, Jun 14, 2015 at 12:06 PM, Mats Henricson <mats@henricson•se> wrote:
                  >> Jeff,
                  >> 
                  >> with all due respect, but I've seen you saying this a few times
                  >> now, that this decision is oh so difficult and important.
                  >> 
                  >> But this is not helpful. We all know that. Even I.
                  >> 
                  >> Make a suggestion, or stay out of the debate!
                  >> 
                  >> Mats
                  >> 
                  >> On 06/14/2015 07:36 AM, Jeff Garzik wrote:
                  >>> The choice is very real and on-point.  What should the block size limit
                  >>> be?  Why?
                  >>> 
                  >>> There is a large consensus that it needs increasing.  To what?  By what
                  >>> factor?
                  >>> 
                  >>> The size limit literally defines the fee market, the whole damn thing.  If
                  >>> software high priests choose a size limit of 300k, space is scarce, fees
                  >>> are bid high.  If software high priests choose a size limit of 32mb, space
                  >>> is plentiful, fees are near zero.  Market actors take their signals
                  >>> accordingly.  Some business models boom, some business models fail, as a
                  >>> direct result of changing this unintentionally-added speedbump.  Different
                  >>> users value adoption, decentralization etc. differently.
                  >>> 
                  >>> The size limit is an economic policy lever that needs to be transitioned
                  >>> -away- from software and software developers, to the free market.
                  >>> 
                  >>> A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance
                  >>> problems associated with actors lobbying developers, even if a cloistered
                  >>> and vetted Technical Advisory Board as has been proposed.
                  >>> 
                  >>> 
                  >>> 
                  >>> 
                  >>> 
                  >>> 
                  >>> 
                  >>> On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
                  >>> 
                  >>>> I definitely think we need some voting system for metaconsensus…but if
                  >>>> we’re going to seriously consider this we should look at the problem much
                  >>>> more generally. Using false choices doesn’t really help, though ;)
                  >>>> 
                  >>>> - Eric Lombrozo
                  >>>> 
                  >>>> 
                  >>>> On Jun 13, 2015, at 10:13 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
                  >>>> 
                  >>>> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo@gmail•com>
                  >>>> wrote:
                  >>>> 
                  >>>>> 2) BIP100 has direct economic consequences…and particularly for miners.
                  >>>>> It lends itself to much greater corruptibility.
                  >>>>> 
                  >>>>> 
                  >>>> What is the alternative?  Have a Chief Scientist or Technical Advisory
                  >>>> Board choose what is a proper fee, what is a proper level of
                  >>>> decentralization, a proper growth factor?
                  >>>> 
                  >>>> 
                  >>>> 
                  >>> 
                  >>> 
                  >>> 
                  >>> 
                  >>> ------------------------------------------------------------------------------
                  >>> 
                  >>> 
                  >>> 
                  >>> _______________________________________________
                  >>> Bitcoin-development mailing list
                  >>> Bitcoin-development@lists•sourceforge.net
                  >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                  >>> 
                  >> 
                  >> ------------------------------------------------------------------------------
                  >> _______________________________________________
                  >> Bitcoin-development mailing list
                  >> Bitcoin-development@lists•sourceforge.net
                  >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                  > 
                  > ------------------------------------------------------------------------------
                  > _______________________________________________
                  > Bitcoin-development mailing list
                  > Bitcoin-development@lists•sourceforge.net
                  > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                  
                  
                  [-- Attachment #2: Message signed with OpenPGP using GPGMail --]
                  [-- Type: application/pgp-signature, Size: 842 bytes --]
                  
                  ^ permalink raw reply	[flat|nested] 42+ messages in thread

              • * Re: [Bitcoin-development] User vote in blocksize through fees
                  2015-06-14 10:06             ` Mats Henricson
                  2015-06-14 10:34               ` Benjamin
                @ 2015-06-14 14:42               ` Jeff Garzik
                  2015-06-14 22:26                 ` Mike Hearn
                  1 sibling, 1 reply; 42+ messages in thread
                From: Jeff Garzik @ 2015-06-14 14:42 UTC (permalink / raw)
                  To: Mats Henricson; +Cc: Bitcoin Dev
                
                [-- Attachment #1: Type: text/plain, Size: 3303 bytes --]
                
                Since you missed it, here is the suggestion again:
                http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
                
                
                On Sun, Jun 14, 2015 at 6:06 AM, Mats Henricson <mats@henricson•se> wrote:
                
                > Jeff,
                >
                > with all due respect, but I've seen you saying this a few times
                > now, that this decision is oh so difficult and important.
                >
                > But this is not helpful. We all know that. Even I.
                >
                > Make a suggestion, or stay out of the debate!
                >
                > Mats
                >
                > On 06/14/2015 07:36 AM, Jeff Garzik wrote:
                > > The choice is very real and on-point.  What should the block size limit
                > > be?  Why?
                > >
                > > There is a large consensus that it needs increasing.  To what?  By what
                > > factor?
                > >
                > > The size limit literally defines the fee market, the whole damn thing.
                > If
                > > software high priests choose a size limit of 300k, space is scarce, fees
                > > are bid high.  If software high priests choose a size limit of 32mb,
                > space
                > > is plentiful, fees are near zero.  Market actors take their signals
                > > accordingly.  Some business models boom, some business models fail, as a
                > > direct result of changing this unintentionally-added speedbump.
                > Different
                > > users value adoption, decentralization etc. differently.
                > >
                > > The size limit is an economic policy lever that needs to be transitioned
                > > -away- from software and software developers, to the free market.
                > >
                > > A simple, e.g. hard fork to 2MB or 4MB does not fix higher level
                > governance
                > > problems associated with actors lobbying developers, even if a cloistered
                > > and vetted Technical Advisory Board as has been proposed.
                > >
                > >
                > >
                > >
                > >
                > >
                > >
                > > On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo <elombrozo@gmail•com>
                > wrote:
                > >
                > >> I definitely think we need some voting system for metaconsensus…but if
                > >> we’re going to seriously consider this we should look at the problem
                > much
                > >> more generally. Using false choices doesn’t really help, though ;)
                > >>
                > >> - Eric Lombrozo
                > >>
                > >>
                > >> On Jun 13, 2015, at 10:13 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
                > >>
                > >> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo@gmail•com>
                > >> wrote:
                > >>
                > >>> 2) BIP100 has direct economic consequences…and particularly for miners.
                > >>> It lends itself to much greater corruptibility.
                > >>>
                > >>>
                > >> What is the alternative?  Have a Chief Scientist or Technical Advisory
                > >> Board choose what is a proper fee, what is a proper level of
                > >> decentralization, a proper growth factor?
                > >>
                > >>
                > >>
                > >
                > >
                > >
                > >
                > >
                > ------------------------------------------------------------------------------
                > >
                > >
                > >
                > > _______________________________________________
                > > Bitcoin-development mailing list
                > > Bitcoin-development@lists•sourceforge.net
                > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                > >
                >
                >
                > ------------------------------------------------------------------------------
                > _______________________________________________
                > Bitcoin-development mailing list
                > Bitcoin-development@lists•sourceforge.net
                > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
                >
                
                
                
                -- 
                Jeff Garzik
                Bitcoin core developer and open source evangelist
                BitPay, Inc.      https://bitpay.com/
                
                [-- Attachment #2: Type: text/html, Size: 4874 bytes --]
                
                ^ permalink raw reply	[flat|nested] 42+ messages in thread

              • • * Re: [Bitcoin-development] User vote in blocksize through fees
                    2015-06-14 14:42               ` Jeff Garzik
                  @ 2015-06-14 22:26                 ` Mike Hearn
                    0 siblings, 0 replies; 42+ messages in thread
                  From: Mike Hearn @ 2015-06-14 22:26 UTC (permalink / raw)
                    To: Jeff Garzik; +Cc: Bitcoin Dev
                  
                  [-- Attachment #1: Type: text/plain, Size: 307 bytes --]
                  
                  On Sun, Jun 14, 2015 at 4:42 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
                  
                  > Since you missed it, here is the suggestion again:
                  > http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
                  >
                  
                  Reposting as Jeff's mail got eaten by the anti-phishing filters, due to
                  SourceForge's obsolete mailman setup.
                  
                  [-- Attachment #2: Type: text/html, Size: 736 bytes --]
                  
                  ^ permalink raw reply	[flat|nested] 42+ messages in thread

            • * Re: [Bitcoin-development] User vote in blocksize through fees
                2015-06-14  5:36           ` Jeff Garzik
                2015-06-14 10:06             ` Mats Henricson
              @ 2015-06-15  3:59             ` Eric Lombrozo
                1 sibling, 0 replies; 42+ messages in thread
              From: Eric Lombrozo @ 2015-06-15  3:59 UTC (permalink / raw)
                To: Jeff Garzik; +Cc: Bitcoin Dev
              
              
              [-- Attachment #1.1: Type: text/plain, Size: 1468 bytes --]
              
              > On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo@gmail•com <mailto:elombrozo@gmail•com>> wrote:
              > 2) BIP100 has direct economic consequences…and particularly for miners. It lends itself to much greater corruptibility.
              > 
              > 
              > What is the alternative?  Have a Chief Scientist or Technical Advisory Board choose what is a proper fee, what is a proper level of decentralization, a proper growth factor?
              
              
              > On Jun 13, 2015, at 10:36 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
              > 
              > The choice is very real and on-point.  What should the block size limit be?  Why?
              > 
              > There is a large consensus that it needs increasing.  To what?  By what factor?
              
              To be clear, Jeff, I am 100% in agreement with you that a mechanism like what you’re proposing is a million times better than having high priests that ram hard forks without proper consensus. And perhaps given the present circumstances it seems like the only alternative. However, in my mind this block size limit controversy is actually a fairly superficial aspect - a mere symptom, a manifestation of the real problem...
              
              What I find somewhat irksome is that we’ve had six years to figure out a mechanism to enable hard forks (which we knew from the start would be inevitable) - and more to the point, we’ve known about this block size issue from the start as well…and only suddenly it becomes an issue of major urgency that we must bump up this parameter 20x…
              
              - Eric Lombrozo
              
              [-- Attachment #1.2: Type: text/html, Size: 3644 bytes --]
              
              [-- Attachment #2: Message signed with OpenPGP using GPGMail --]
              [-- Type: application/pgp-signature, Size: 842 bytes --]
              
              ^ permalink raw reply	[flat|nested] 42+ messages in thread

• * Re: [Bitcoin-development] User vote in blocksize through fees
    2015-06-12 18:11 [Bitcoin-development] User vote in blocksize through fees Peter Todd
                     ` (2 preceding siblings ...)
    2015-06-13 22:20 ` Danny Thorpe
  @ 2015-06-14  4:16 ` Stephen
    2015-06-14  4:50   ` Eric Lombrozo
    2015-06-14  4:56   ` Jeff Garzik
    2015-06-14  7:19 ` Ashley Holman
    4 siblings, 2 replies; 42+ messages in thread
  From: Stephen @ 2015-06-14  4:16 UTC (permalink / raw)
    To: Peter Todd; +Cc: bitcoin-development
  
  While this idea is theoretically interesting because it involves many stakeholders, rather than just miners, I think in practice this would not work very well. Users don't want to worry about this kind of technicality, they just want to be able to make a transaction and have it be processed. 
  
  In addition, while this gives stakeholders some weight with the fees they supply, these fees are marginal compared to the block size subsidy. If this proposal were actually implemented, I think miners would vote for whatever they think is best, and users would not contradict them with their votes to ensure a fast confirmation time. Users are incentivized to be in agreement with miners because the miners provide them with the confirmations they need, but fees do not provide a great incentive for miners to be in agreement with users, and likely won't for some time. 
  
  Best, 
  Stephen 
  
  
  
  
  > On Jun 12, 2015, at 2:11 PM, Peter Todd <pete@petertodd•org> wrote:
  > 
  > Jeff Garzik recently proposed that the upper blocksize limit be removed
  > entirely, with a "soft" limit being enforced via miner vote, recorded by
  > hashing power.
  > 
  > This mechanism within the protocol for users to have any influence over
  > the miner vote. We can add that back by providing a way for transactions
  > themselves to set a flag determining whether or not they can be included
  > in a block casting a specific vote.
  > 
  > We can simplify Garzik's vote to say that one of the nVersion bits
  > either votes for the blocksize to be increased, or decreased, by some
  > fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
  > nVersion bit in transactions themselves, also voting for an increase or
  > decrease. Transactions may only be included in blocks with an
  > indentical vote, thus providing miners with a monetary incentive via
  > fees to vote according to user wishes.
  > 
  > Of course, to cast a "don't care" vote we can either define an
  > additional bit, or sign the transaction with both versions. Equally we
  > can even have different versions with different fees, broadcast via a
  > mechanism such as replace-by-fee.
  > 
  > 
  > See also John Dillon's proposal for proof-of-stake blocksize voting:
  > 
  > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
  > 
  > -- 
  > 'peter'[:-1]@petertodd.org
  > 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
  > ------------------------------------------------------------------------------
  > _______________________________________________
  > Bitcoin-development mailing list
  > Bitcoin-development@lists•sourceforge.net
  > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  
  
  
  ^ permalink raw reply	[flat|nested] 42+ messages in thread

• • * Re: [Bitcoin-development] User vote in blocksize through fees
      2015-06-14  4:16 ` Stephen
    @ 2015-06-14  4:50   ` Eric Lombrozo
      2015-06-14  4:56   ` Jeff Garzik
      1 sibling, 0 replies; 42+ messages in thread
    From: Eric Lombrozo @ 2015-06-14  4:50 UTC (permalink / raw)
      To: Stephen; +Cc: bitcoin-development
    
    [-- Attachment #1: Type: text/plain, Size: 3722 bytes --]
    
    What Stephen said is very much along the same lines of my earlier critique. This voting mechanism would be all but unusable to most endusers without some pretty elaborate tools…and unless users are willing to pay substantially higher fees than they’re currently paying, their votes will not really count all that much. And it’s not all that clear that most users would really be able to make very rational economic decisions even having elaborate tools. More likely, a small group would figure out ways to exploit this for their own benefit - at everyone else’s expense.
    
    - Eric Lombrozo
    
    
    > On Jun 13, 2015, at 9:16 PM, Stephen <stephencalebmorse@gmail•com> wrote:
    > 
    > While this idea is theoretically interesting because it involves many stakeholders, rather than just miners, I think in practice this would not work very well. Users don't want to worry about this kind of technicality, they just want to be able to make a transaction and have it be processed.
    > 
    > In addition, while this gives stakeholders some weight with the fees they supply, these fees are marginal compared to the block size subsidy. If this proposal were actually implemented, I think miners would vote for whatever they think is best, and users would not contradict them with their votes to ensure a fast confirmation time. Users are incentivized to be in agreement with miners because the miners provide them with the confirmations they need, but fees do not provide a great incentive for miners to be in agreement with users, and likely won't for some time.
    > 
    > Best,
    > Stephen
    > 
    > 
    > 
    > 
    >> On Jun 12, 2015, at 2:11 PM, Peter Todd <pete@petertodd•org> wrote:
    >> 
    >> Jeff Garzik recently proposed that the upper blocksize limit be removed
    >> entirely, with a "soft" limit being enforced via miner vote, recorded by
    >> hashing power.
    >> 
    >> This mechanism within the protocol for users to have any influence over
    >> the miner vote. We can add that back by providing a way for transactions
    >> themselves to set a flag determining whether or not they can be included
    >> in a block casting a specific vote.
    >> 
    >> We can simplify Garzik's vote to say that one of the nVersion bits
    >> either votes for the blocksize to be increased, or decreased, by some
    >> fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
    >> nVersion bit in transactions themselves, also voting for an increase or
    >> decrease. Transactions may only be included in blocks with an
    >> indentical vote, thus providing miners with a monetary incentive via
    >> fees to vote according to user wishes.
    >> 
    >> Of course, to cast a "don't care" vote we can either define an
    >> additional bit, or sign the transaction with both versions. Equally we
    >> can even have different versions with different fees, broadcast via a
    >> mechanism such as replace-by-fee.
    >> 
    >> 
    >> See also John Dillon's proposal for proof-of-stake blocksize voting:
    >> 
    >> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
    >> 
    >> --
    >> 'peter'[:-1]@petertodd.org
    >> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
    >> ------------------------------------------------------------------------------
    >> _______________________________________________
    >> Bitcoin-development mailing list
    >> Bitcoin-development@lists•sourceforge.net
    >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
    > 
    > ------------------------------------------------------------------------------
    > _______________________________________________
    > Bitcoin-development mailing list
    > Bitcoin-development@lists•sourceforge.net
    > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
    
    
    [-- Attachment #2: Message signed with OpenPGP using GPGMail --]
    [-- Type: application/pgp-signature, Size: 842 bytes --]
    
    ^ permalink raw reply	[flat|nested] 42+ messages in thread

  • * Re: [Bitcoin-development] User vote in blocksize through fees
      2015-06-14  4:16 ` Stephen
      2015-06-14  4:50   ` Eric Lombrozo
    @ 2015-06-14  4:56   ` Jeff Garzik
      1 sibling, 0 replies; 42+ messages in thread
    From: Jeff Garzik @ 2015-06-14  4:56 UTC (permalink / raw)
      To: Stephen; +Cc: bitcoin-development
    
    [-- Attachment #1: Type: text/plain, Size: 4447 bytes --]
    
    Miner voting, while imperfect, is the least-worst of various solutions
    which inject market input into the system.  It is is known quantity, field
    tested, and must be sustained, in public, over a time span of months.  As
    this thread shows, stakeholder and direct user voting is nigh impossible to
    get right.
    
    Choosing block size is fundamentally a central bank directive shaping the
    fee market.  Whatever actor or algorithm or natural equilibrium picks the
    block size, that choice will dictate the level of competition for fees, the
    level of scarcity of an economically scarce resource.  Picking the block
    size advantages some businesses over others, some business models over
    others.  Software (and software devs) should not be the ones picking that
    limit.
    
    Checks-and-balances are also important.  BIP 100 notably includes two steps
    at which user input is visibly and actively injected:   1) hard fork to
    enable, and 2) a second hard fork if the system is to scale beyond 32MB.
    The network users (not miners) twice approve the system.  Further, one must
    remember all the basic miner incentives that do align with users, notably
    that of maintaining the value of bitcoin tokens as their primary income
    stream.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    On Sun, Jun 14, 2015 at 12:16 AM, Stephen <stephencalebmorse@gmail•com>
    wrote:
    
    > While this idea is theoretically interesting because it involves many
    > stakeholders, rather than just miners, I think in practice this would not
    > work very well. Users don't want to worry about this kind of technicality,
    > they just want to be able to make a transaction and have it be processed.
    >
    > In addition, while this gives stakeholders some weight with the fees they
    > supply, these fees are marginal compared to the block size subsidy. If this
    > proposal were actually implemented, I think miners would vote for whatever
    > they think is best, and users would not contradict them with their votes to
    > ensure a fast confirmation time. Users are incentivized to be in agreement
    > with miners because the miners provide them with the confirmations they
    > need, but fees do not provide a great incentive for miners to be in
    > agreement with users, and likely won't for some time.
    >
    > Best,
    > Stephen
    >
    >
    >
    >
    > > On Jun 12, 2015, at 2:11 PM, Peter Todd <pete@petertodd•org> wrote:
    > >
    > > Jeff Garzik recently proposed that the upper blocksize limit be removed
    > > entirely, with a "soft" limit being enforced via miner vote, recorded by
    > > hashing power.
    > >
    > > This mechanism within the protocol for users to have any influence over
    > > the miner vote. We can add that back by providing a way for transactions
    > > themselves to set a flag determining whether or not they can be included
    > > in a block casting a specific vote.
    > >
    > > We can simplify Garzik's vote to say that one of the nVersion bits
    > > either votes for the blocksize to be increased, or decreased, by some
    > > fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
    > > nVersion bit in transactions themselves, also voting for an increase or
    > > decrease. Transactions may only be included in blocks with an
    > > indentical vote, thus providing miners with a monetary incentive via
    > > fees to vote according to user wishes.
    > >
    > > Of course, to cast a "don't care" vote we can either define an
    > > additional bit, or sign the transaction with both versions. Equally we
    > > can even have different versions with different fees, broadcast via a
    > > mechanism such as replace-by-fee.
    > >
    > >
    > > See also John Dillon's proposal for proof-of-stake blocksize voting:
    > >
    > >
    > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
    > >
    > > --
    > > 'peter'[:-1]@petertodd.org
    > > 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
    > >
    > ------------------------------------------------------------------------------
    > > _______________________________________________
    > > Bitcoin-development mailing list
    > > Bitcoin-development@lists•sourceforge.net
    > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
    >
    >
    > ------------------------------------------------------------------------------
    > _______________________________________________
    > Bitcoin-development mailing list
    > Bitcoin-development@lists•sourceforge.net
    > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
    >
    
    
    
    -- 
    Jeff Garzik
    Bitcoin core developer and open source evangelist
    BitPay, Inc.      https://bitpay.com/
    
    [-- Attachment #2: Type: text/html, Size: 6176 bytes --]
    
    ^ permalink raw reply	[flat|nested] 42+ messages in thread

• * Re: [Bitcoin-development] User vote in blocksize through fees
    2015-06-12 18:11 [Bitcoin-development] User vote in blocksize through fees Peter Todd
                     ` (3 preceding siblings ...)
    2015-06-14  4:16 ` Stephen
  @ 2015-06-14  7:19 ` Ashley Holman
    4 siblings, 0 replies; 42+ messages in thread
  From: Ashley Holman @ 2015-06-14  7:19 UTC (permalink / raw)
    To: Peter Todd; +Cc: Bitcoin Development
  
  [-- Attachment #1: Type: text/plain, Size: 2721 bytes --]
  
  Economic policy sounds like a dirty word in the context of Bitcoin, but as
  Jeff Garzik said, choosing a block size cap is unfortunately an economic
  policy that has to be chosen somehow.  Enabling users to incentivise the
  voting process is an interesting tool to have in the toolbox, but I think
  it would be sensible to first observe how the miner-only voting system
  behaves on its own.
  
  If, for example, the hashing majority tended to favour a move towards
  centralization (big blocks), user preferences could potentially hasten this
  move by further punishing marginal miners through reduced fees.  On the
  other hand, if user preferences tended to oppose the preferences of miners,
  then such a system might function well in keeping a balance between
  usability and security (although it's not clear how this balance might
  change over time as the block subsidy drops).
  
  In short, I think it's wise to keep it simple and implement one mechanism
  at a time.
  
  On Sat, Jun 13, 2015 at 4:11 AM, Peter Todd <pete@petertodd•org> wrote:
  
  > Jeff Garzik recently proposed that the upper blocksize limit be removed
  > entirely, with a "soft" limit being enforced via miner vote, recorded by
  > hashing power.
  >
  > This mechanism within the protocol for users to have any influence over
  > the miner vote. We can add that back by providing a way for transactions
  > themselves to set a flag determining whether or not they can be included
  > in a block casting a specific vote.
  >
  > We can simplify Garzik's vote to say that one of the nVersion bits
  > either votes for the blocksize to be increased, or decreased, by some
  > fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
  > nVersion bit in transactions themselves, also voting for an increase or
  > decrease. Transactions may only be included in blocks with an
  > indentical vote, thus providing miners with a monetary incentive via
  > fees to vote according to user wishes.
  >
  > Of course, to cast a "don't care" vote we can either define an
  > additional bit, or sign the transaction with both versions. Equally we
  > can even have different versions with different fees, broadcast via a
  > mechanism such as replace-by-fee.
  >
  >
  > See also John Dillon's proposal for proof-of-stake blocksize voting:
  >
  >
  > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
  >
  > --
  > 'peter'[:-1]@petertodd.org
  > 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
  >
  >
  > ------------------------------------------------------------------------------
  >
  > _______________________________________________
  > Bitcoin-development mailing list
  > Bitcoin-development@lists•sourceforge.net
  > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  >
  >
  
  [-- Attachment #2: Type: text/html, Size: 3656 bytes --]
  
  ^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [Bitcoin-development] User vote in blocksize through fees
@ 2015-06-13 23:57 Raystonn
  2015-06-14  4:28 ` odinn
  0 siblings, 1 reply; 42+ messages in thread
From: Raystonn @ 2015-06-13 23:57 UTC (permalink / raw)
  To: Danny Thorpe, bitcoin-development

[-- Attachment #1: Type: text/html, Size: 5396 bytes --]

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

• * Re: [Bitcoin-development] User vote in blocksize through fees
    2015-06-13 23:57 Raystonn
  @ 2015-06-14  4:28 ` odinn
    2015-06-14  5:46   ` Aaron Voisine
    0 siblings, 1 reply; 42+ messages in thread
  From: odinn @ 2015-06-14  4:28 UTC (permalink / raw)
    To: bitcoin-development
  
  -----BEGIN PGP SIGNED MESSAGE-----
  Hash: SHA1
  
  A decentralized, distributed application should offer its users
  decentralized, distributed method of weighing in on the direction of
  how it evolves as well as having an open development model.  The
  reference to Facebook and Myspace is completely inapplicable here
  because the tyranny of such spaces isn't what we have with bitcoin
  (fortunately), nor would we want to try to replicate it, ever, in any
  way, shape, or form.
  
  Yes, it does bother (some) people to see the consensus based system
  because of the difficulties that can be associated with implementing
  it.  But that's the way it is.  If you don't like consensus based
  systems (or decentralized, distributed systems) this is probably the
  wrong space for you.
  
  On 06/13/2015 04:57 PM, Raystonn wrote:
  > Adding back the list. Did not intend to remove it. Apologies.
  > 
  > On 13 Jun 2015 4:52 pm, Raystonn <raystonn@hotmail•com> wrote:
  > 
  > Based on my observations, what the majority of Bitcoin users want 
  > is a system that can carry more transactions per second than any 
  > existing payment system while retaining most of the security 
  > offered today. The technicalities on how this is achieved are not 
  > as important as the end result. If the only user input is to 
  > technicalities, they will use that to voice their opinions.
  > 
  > On 13 Jun 2015 4:25 pm, Danny Thorpe <danny.thorpe@gmail•com> 
  > wrote:
  > 
  > I don't recall Facebook or MySpace asking end users to alter the 
  > parameters of their respective back-end network infrastructure.
  > 
  > How are Bitcoin end users qualified to make an informed decision 
  > regarding block size limits? And why should they care?
  > 
  > Sure, I want Bitcoin to grow its user base. But to do that,
  > Bitcoin has to be accessible to the nontechnical population.
  > Asking nontechnical people to make technical decisions leads
  > directly to stress and confusion, which most folks find
  > off-putting.
  > 
  > And please don't call me Shirley.  ;>
  > 
  > On Sat, Jun 13, 2015 at 3:42 PM, Raystonn <raystonn@hotmail•com 
  > <mailto:raystonn@hotmail•com>> wrote:
  > 
  > Surely you would prefer to actually have users? Bitcoin does not 
  > exist in a vacuum. Network effect alone is not enough to ensure 
  > success in the face of competition from alternatives with a much 
  > better user experience. See Facebook vs MySpace, IE vs Netscape, 
  > etc.
  > 
  > On 13 Jun 2015 3:20 pm, Danny Thorpe <danny.thorpe@gmail•com 
  > <mailto:danny.thorpe@gmail•com>> wrote:
  > 
  > Please forgive my ignorance, but why should Bitcoin users have a 
  > say in block size limits?  It's the miners and Bitcoin node 
  > operators that bear the burden of managing large blocks, no?
  > 
  > Users voting on network parameters sounds like neighbors voting on 
  > how deep my swimming pool should be.
  > 
  > Thanks, -Danny
  > 
  > On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd <pete@petertodd•org 
  > <mailto:pete@petertodd•org>> wrote:
  > 
  > Jeff Garzik recently proposed that the upper blocksize limit be 
  > removed entirely, with a "soft" limit being enforced via miner 
  > vote, recorded by hashing power.
  > 
  > This mechanism within the protocol for users to have any influence 
  > over the miner vote. We can add that back by providing a way for 
  > transactions themselves to set a flag determining whether or not 
  > they can be included in a block casting a specific vote.
  > 
  > We can simplify Garzik's vote to say that one of the nVersion bits
  >  either votes for the blocksize to be increased, or decreased, by 
  > some fixed ratio (e.g 2x or 1/2x) the next interval. Then we can 
  > use a nVersion bit in transactions themselves, also voting for an 
  > increase or decrease. Transactions may only be included in blocks 
  > with an indentical vote, thus providing miners with a monetary 
  > incentive via fees to vote according to user wishes.
  > 
  > Of course, to cast a "don't care" vote we can either define an 
  > additional bit, or sign the transaction with both versions.
  > Equally we can even have different versions with different fees,
  > broadcast via a mechanism such as replace-by-fee.
  > 
  > 
  > See also John Dillon's proposal for proof-of-stake blocksize 
  > voting:
  > 
  > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net
  /msg02323.html
  >
  >
  > 
  - -- 'peter'[:-1]@petertodd.org <http://petertodd.org>
  > 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
  > 
  > ----------------------------------------------------------------------
  - --------
  >
  >
  > 
  _______________________________________________
  > Bitcoin-development mailing list 
  > Bitcoin-development@lists•sourceforge.net 
  > <mailto:Bitcoin-development@lists•sourceforge.net> 
  > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  > 
  > 
  > 
  > 
  > 
  > ----------------------------------------------------------------------
  - --------
  >
  >
  > 
  > 
  > 
  > _______________________________________________
  > Bitcoin-development mailing list
  > Bitcoin-development@lists•sourceforge.net 
  > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  > 
  
  - -- 
  http://abis.io ~
  "a protocol concept to enable decentralization
  and expansion of a giving economy, and a new social good"
  https://keybase.io/odinn
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1
  
  iQEcBAEBAgAGBQJVfQL0AAoJEGxwq/inSG8CRqMH/0l9tHGA8figVGnIBoMgdpVi
  uwMGTQTjLUf12/NFS27vT+OLMWqZRvVXvlxDF25N7la+QImhh67LqmQy8fkwGg5T
  kJ6MkkFLgy05aqE/X3ywJUifOKmS3Y/RDDUJhrFjjHrsMGoF4ATtVwTpUBLik+kX
  G3XRNlInmyB55UEcpyfBg9kfLz8xiy6sBPeaeGnFLCNWTs5TgJ6DTFqhBAAmE8Hw
  k0tN6mW3wYS610FFkS2E3+W8O8KGs4oqAYLX/ZQOhX9oKjBvWWI4ppRpSDyBNcxd
  A6VAKyU8HCuDHAEwba6gdlUa+yf4qxuZV1KCNENbvtN1CTsJ6oh0OxnEO6dtogo=
  =KZmG
  -----END PGP SIGNATURE-----
  
  
  
  ^ permalink raw reply	[flat|nested] 42+ messages in thread

• • * Re: [Bitcoin-development] User vote in blocksize through fees
      2015-06-14  4:28 ` odinn
    @ 2015-06-14  5:46   ` Aaron Voisine
      2015-06-14 21:38     ` odinn
      0 siblings, 1 reply; 42+ messages in thread
    From: Aaron Voisine @ 2015-06-14  5:46 UTC (permalink / raw)
      To: odinn; +Cc: Bitcoin Development
    
    [-- Attachment #1: Type: text/plain, Size: 613 bytes --]
    
    >
    > Yes, it does bother (some) people to see the consensus based system
    > because of the difficulties that can be associated with implementing
    > it.  But that's the way it is.  If you don't like consensus based
    > systems (or decentralized, distributed systems) this is probably the
    > wrong space for you.
    >
    
    If consensus must be reached to make any changes, that just means that
    changes of anything more than trivial consequence simply can't be made.
    Extreme bias toward the status-quo will only work if external factors
    affecting the network also remain static.
    
    Aaron Voisine
    co-founder and CEO
    breadwallet.com
    
    [-- Attachment #2: Type: text/html, Size: 1100 bytes --]
    
    ^ permalink raw reply	[flat|nested] 42+ messages in thread

  • • * Re: [Bitcoin-development] User vote in blocksize through fees
        2015-06-14  5:46   ` Aaron Voisine
      @ 2015-06-14 21:38     ` odinn
        0 siblings, 0 replies; 42+ messages in thread
      From: odinn @ 2015-06-14 21:38 UTC (permalink / raw)
        To: Aaron Voisine; +Cc: Bitcoin Development
      
      -----BEGIN PGP SIGNED MESSAGE-----
      Hash: SHA1
      
      I agree that changes of anything more than trivial are difficult, but
      I would disagree that they can't be made.  It seems that the issue is
      one of roadblocks and muddling through when a major issue (e.g. the
      proposal of a hardfork / XT) is confronting the community and the
      question of how to address this issue in a timely manner. That does
      not mean that there isn't a process for the community to weigh in or
      for the decisions of the participants in the network to be measured
      because, of course, there is, but I submit that the larger issues are
      having to do with concerns over the problems inherent in the totally
      unnecessary XT proposal itself.
      
      My own thoughts on that proposal are written up at
      http://www.twitlonger.com/show/n_1smkanp
      
      And have been supported somewhat by various others in the community,
      such as GreenAddress (which is opposed at this time to increasing the
      blocksize limit as per Gavin's proposal) and Adam Back:
      https://twitter.com/adam3us/status/608920099609817088
      
      I think Jeff Garzik had some good thoughts specifically regarding this
      subject of user vote in blocksize through fees.  Although I do agree
      with you, Aaron, that the "changes more than trivial" are a tough nut
      to crack, I won't say that they can't be made in such processes and I
      am curious to see how this discussion progresses.
      
      - -O
      
      
      
      
      
      On 06/13/2015 10:46 PM, Aaron Voisine wrote:
      > Yes, it does bother (some) people to see the consensus based
      > system because of the difficulties that can be associated with
      > implementing it.  But that's the way it is.  If you don't like
      > consensus based systems (or decentralized, distributed systems)
      > this is probably the wrong space for you.
      > 
      > 
      > If consensus must be reached to make any changes, that just means
      > that changes of anything more than trivial consequence simply can't
      > be made. Extreme bias toward the status-quo will only work if
      > external factors affecting the network also remain static.
      > 
      > Aaron Voisine co-founder and CEO breadwallet.com
      > <http://breadwallet.com/>
      
      - -- 
      http://abis.io ~
      "a protocol concept to enable decentralization
      and expansion of a giving economy, and a new social good"
      https://keybase.io/odinn
      -----BEGIN PGP SIGNATURE-----
      Version: GnuPG v1
      
      iQEcBAEBAgAGBQJVffRMAAoJEGxwq/inSG8CGfIH/RkMNeJpcXdG+pC6Cg1XMELQ
      wa/fkdKnnkhhxNm4keHeO0YQFw0BL4rQSQ2PfGEXU3keJrWlmxchEQteAGDzL55Y
      1dSkQbfxsaEco2m6P0/1+WGuNOn2Sp653+/G/WoeaqMvp+b2ORbVZoqURv7Iz240
      sI6GqWxWxuGpJyaW/PwVYfvGAImeQRKgKiB3w001Q3Lc36wDr/EGs4lVWJTSk+g+
      60zj4+7jmqpr/Q/+sjQDE0KZSBU/EmrPYEuEdBkOmG4JnFgBqM7civtHis/zu7Uc
      1sr/LcqeGm0VB/yt0CfvtsAC5KZyMFQABF0/Q2qX0GtuLbjyKWf7B/KEAPdC+m0=
      =3cf3
      -----END PGP SIGNATURE-----
      
      
      
      ^ permalink raw reply	[flat|nested] 42+ messages in thread

end of thread, other threads:[~2015-06-15  3:59 UTC | newest]

Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-12 18:11 [Bitcoin-development] User vote in blocksize through fees Peter Todd
2015-06-12 18:20 ` Mark Friedenbach
2015-06-12 18:26   ` Matt Whitlock
2015-06-12 18:36     ` Peter Todd
2015-06-12 18:56     ` Jannes Faber
     [not found]       ` <CABr1YTfowMqgDZoWhDXiM0Bd3dwhVo6++FOvLntGc2HkApEbGw@mail.gmail.com>
2015-06-12 20:04         ` Eric Lombrozo
2015-06-12 23:01           ` Vincent Truong
2015-06-12 23:11             ` Luke Dashjr
2015-06-12 23:23           ` Aaron Gustafson
2015-06-12 18:22 ` Matt Whitlock
2015-06-12 18:34   ` Peter Todd
2015-06-12 18:36     ` Matt Whitlock
2015-06-12 18:39       ` Benjamin
2015-06-12 18:47         ` Peter Todd
2015-06-12 18:44       ` Peter Todd
2015-06-12 18:52         ` Matt Whitlock
2015-06-12 18:54         ` Matt Whitlock
2015-06-12 18:56           ` Aaron Gustafson
2015-06-13 22:20 ` Danny Thorpe
2015-06-13 22:24   ` Eric Lombrozo
2015-06-14  4:55   ` Chun Wang
2015-06-14  4:59     ` Jeff Garzik
2015-06-14  5:08     ` Eric Lombrozo
2015-06-14  5:13       ` Jeff Garzik
2015-06-14  5:20         ` Eric Lombrozo
2015-06-14  5:36           ` Jeff Garzik
2015-06-14 10:06             ` Mats Henricson
2015-06-14 10:34               ` Benjamin
2015-06-14 15:07                 ` Jeff Garzik
2015-06-14 21:59                   ` odinn
2015-06-14 20:10                 ` Eric Lombrozo
2015-06-14 14:42               ` Jeff Garzik
2015-06-14 22:26                 ` Mike Hearn
2015-06-15  3:59             ` Eric Lombrozo
2015-06-14  4:16 ` Stephen
2015-06-14  4:50   ` Eric Lombrozo
2015-06-14  4:56   ` Jeff Garzik
2015-06-14  7:19 ` Ashley Holman
2015-06-13 23:57 Raystonn
2015-06-14  4:28 ` odinn
2015-06-14  5:46   ` Aaron Voisine
2015-06-14 21:38     ` odinn

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