Bitcoin Core and hard forks

>
> Hello all,
>
> I'd like to talk a bit about my view on the relation between the
> Bitcoin Core project, and the consensus rules of Bitcoin.
>
> I believe it is the responsibility of the maintainers/developers of
> Bitcoin Core to create software which helps guarantee the security and
> operation of the Bitcoin network.
>
> In addition to normal software maintenance, bug fixes and performance
> improvements, this includes DoS protection mechanism deemed necessary
> to keep the network operational. Sometimes, such (per-node
> configurable) policies have had economic impact, for example the dust
> rule.
>
> This also includes participating in discussions about consensus
> changes, but not the responsibility to decide on them - only to
> implement them when agreed upon. It would be irresponsible and
> dangerous to the network and thus the users of the software to risk
> forks, or to take a leading role in pushing dramatic changes. Bitcoin
> Core developers obviously have the ability to make any changes to the
> codebase or its releases, but it is still up to the community to
> choose to run that code.
>
> Some people have called the prospect of limited block space and the
> development of a fee market a change in policy compared to the past. I
> respectfully disagree with that. Bitcoin Core is not running the
> Bitcoin economy, and its developers have no authority to set its
> rules. Change in economics is always happening, and should be
> expected. Worse, intervening in consensus changes would make the
> ecosystem more dependent on the group taking that decision, not less.
>
> So to point out what I consider obvious: if Bitcoin requires central
> control over its rules by a group of developers, it is completely
> uninteresting to me. Consensus changes should be done using consensus,
> and the default in case of controversy is no change.
>
> ===
>
> My personal opinion is that we - as a community - should indeed let a
> fee market develop, and rather sooner than later, and that "kicking
> the can down the road" is an incredibly dangerous precedent: if we are
> willing to go through the risk of a hard fork because of a fear of
> change of economics, then I believe that community is not ready to
> deal with change at all. And some change is inevitable, at any block
> size. Again, this does not mean the block size needs to be fixed
> forever, but its intent should be growing with the evolution of
> technology, not a panic reaction because a fear of change.
>
> But I am not in any position to force this view. I only hope that
> people don't think a fear of economic change is reason to give up
> consensus.
>
> --
> Pieter
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

>default in case of controversy is no change.

> Some people have called the prospect of limited block space and the
> development of a fee market a change in policy compared to the past. I
> respectfully disagree with that. Bitcoin Core is not running the Bitcoin
> economy, and its developers have no authority to set its rules. Change in
> economics is always happening, and should be expected. Worse, intervening
> in consensus changes would make the ecosystem more dependent on the group
> taking that decision, not less.
>
>

> So to point out what I consider obvious: if Bitcoin requires central
> control over its rules by a group of developers, it is completely
> uninteresting to me. Consensus changes should be done using consensus, and
> the default in case of controversy is no change.
>

> My personal opinion is that we - as a community - should indeed let a fee
> market develop, and rather sooner than later, and that "kicking the can
> down the road" is an incredibly dangerous precedent: if we are willing to
> go through the risk of a hard fork because of a fear of change of
> economics, then I believe that community is not ready to deal with change
> at all. And some change is inevitable, at any block size. Again, this does
> not mean the block size needs to be fixed forever, but its intent should be
> growing with the evolution of technology, not a panic reaction because a
> fear of change.
>
> But I am not in any position to force this view. I only hope that people
> don't think a fear of economic change is reason to give up consensus.
>

> On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
>> Some people have called the prospect of limited block space and the
>> development of a fee market a change in policy compared to the past. I
>> respectfully disagree with that. Bitcoin Core is not running the Bitcoin
>> economy, and its developers have no authority to set its rules. Change in
>> economics is always happening, and should be expected. Worse, intervening
>> in consensus changes would make the ecosystem more dependent on the group
>> taking that decision, not less.
>>
>>
> This completely ignores *reality*, what users have experienced for the
> past ~6 years.
>
> "Change in economics is always happening" does not begin to approach the
> scale of the change.
>
> For the entirety of bitcoin's history, absent long blocks and traffic
> bursts, fee pressure has been largely absent.
>
> Moving to a new economic policy where fee pressure is consistently present
> is radically different from what users, markets, and software have
> experienced and *lived.*
>
> Analysis such as [1][2] and more shows that users will hit a "painful"
> "wall" and market disruption will occur - eventually settling to a new
> equilibrium after a period of chaos - when blocks are consistently full.
>
> [1] http://hashingit.com/analysis/34-bitcoin-traffic-bulletin
> [2] http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent
>
> First, users & market are forced through this period of chaos by "let a
> fee market develop" as the whole market changes to a radically different
> economic policy, once the network has never seen before.
>
> Next, when blocks are consistently full, the past consensus was that block
> size limit will be increased eventually.  What happens at that point?
>
> Answer - Users & market are forced through a second period of chaos and
> disruption as the fee market is rebooted *again* by changing the block
> size limit.
>
> The average user hears a lot of noise on both sides of the block size
> debate, and really has no idea that the new "let a fee market develop"
> Bitcoin Core policy is going to *raise fees* on them.
>
> It is clear that
> - "let the fee market develop, Right Now" has not been thought through
> - Users are not prepared for a brand new economic policy
> - Users are unaware that a brand new economic policy will be foisted upon
> them
>
>
>
>> So to point out what I consider obvious: if Bitcoin requires central
>> control over its rules by a group of developers, it is completely
>> uninteresting to me. Consensus changes should be done using consensus, and
>> the default in case of controversy is no change.
>>
>
> False.
>
> All that has to do be done to change bitcoin to a new economic policy -
> not seen in the entire 6 year history of bitcoin - is to stonewall work on
> block size.
>
> Closing size increase PRs and failing to participate in planning for a
> block size increase accomplishes your stated goal of changing bitcoin to a
> new economic policy.
>
> "no [code] change"... changes bitcoin to a brand new economic policy,
> picking economic winners & losers.  Some businesses will be priced out of
> bitcoin, etc.
>
> Stonewalling size increase changes is just as much as a Ben Bernanke/FOMC
> move as increasing the hard limit by hard fork.
>
>
>
>> My personal opinion is that we - as a community - should indeed let a fee
>> market develop, and rather sooner than later, and that "kicking the can
>> down the road" is an incredibly dangerous precedent: if we are willing to
>> go through the risk of a hard fork because of a fear of change of
>> economics, then I believe that community is not ready to deal with change
>> at all. And some change is inevitable, at any block size. Again, this does
>> not mean the block size needs to be fixed forever, but its intent should be
>> growing with the evolution of technology, not a panic reaction because a
>> fear of change.
>>
>> But I am not in any position to force this view. I only hope that people
>> don't think a fear of economic change is reason to give up consensus.
>>
>
> Actually you are.
>
> When size increase progress gets frozen out of Bitcoin Core, that just
> *increases* the chances that progress must be made through a contentious
> hard fork.
>
> Further, it increases the market disruption users will experience, as
> described above.
>
> Think about the users.  Please.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

> Over the last 6 years there may not have been fee pressure, but certainly
> there was the expectation that it was going to happen.  Look at all the
> work that has been put into fee estimation, why do that work if the
> expectation was there would be no fee pressure?
>

> Consensus changes should be done using consensus, _and the default in

> My personal opinion is that we - as a community - should indeed let a fee

> default in case of controversy is no change.
>>
>
> I think the result of this would probably be that no controversial changes
> ever get implemented via this process so others will hard fork the code and
> eventually make this process irrelevant.  Since you need close to 100%
> agreement the irrelevance would have to come as a step function which will
> manifest itself in a rather disruptive manner.
>
> The question is really is this hark-forking disruption worse than coming
> up with some kind of process to handle controversial changes.
>
> Russ
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> On Jul 22, 2015, at 10:33 AM, Jeff Garzik via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> Some people have called the prospect of limited block space and the development of a fee market a change in policy compared to the past. I respectfully disagree with that. Bitcoin Core is not running the Bitcoin economy, and its developers have no authority to set its rules. Change in economics is always happening, and should be expected. Worse, intervening in consensus changes would make the ecosystem more dependent on the group taking that decision, not less.
>
>
>
> This completely ignores reality, what users have experienced for the past ~6 years.
>
> "Change in economics is always happening" does not begin to approach the scale of the change.
>
> For the entirety of bitcoin's history, absent long blocks and traffic bursts, fee pressure has been largely absent.

>
> Moving to a new economic policy where fee pressure is consistently present is radically different from what users, markets, and software have experienced and lived.
>
> Analysis such as [1][2] and more shows that users will hit a "painful" "wall" and market disruption will occur - eventually settling to a new equilibrium after a period of chaos - when blocks are consistently full.
>
> [1] http://hashingit.com/analysis/34-bitcoin-traffic-bulletin <http://hashingit.com/analysis/34-bitcoin-traffic-bulletin>
> [2] http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent <http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent>
>
> First, users & market are forced through this period of chaos by "let a fee market develop" as the whole market changes to a radically different economic policy, once the network has never seen before.
>
> Next, when blocks are consistently full, the past consensus was that block size limit will be increased eventually.  What happens at that point?
>
> Answer - Users & market are forced through a second period of chaos and disruption as the fee market is rebooted again by changing the block size limit.
>
> The average user hears a lot of noise on both sides of the block size debate, and really has no idea that the new "let a fee market develop" Bitcoin Core policy is going to raise fees on them.
>
> It is clear that
> - "let the fee market develop, Right Now" has not been thought through
> - Users are not prepared for a brand new economic policy
> - Users are unaware that a brand new economic policy will be foisted upon them
>

>
> So to point out what I consider obvious: if Bitcoin requires central control over its rules by a group of developers, it is completely uninteresting to me. Consensus changes should be done using consensus, and the default in case of controversy is no change.
>
>
> False.
>
> All that has to do be done to change bitcoin to a new economic policy - not seen in the entire 6 year history of bitcoin - is to stonewall work on block size.
>
> Closing size increase PRs and failing to participate in planning for a block size increase accomplishes your stated goal of changing bitcoin to a new economic policy.
>

> "no [code] change"... changes bitcoin to a brand new economic policy, picking economic winners & losers.  Some businesses will be priced out of bitcoin, etc.
>
> Stonewalling size increase changes is just as much as a Ben Bernanke/FOMC move as increasing the hard limit by hard fork.
>
>
> My personal opinion is that we - as a community - should indeed let a fee market develop, and rather sooner than later, and that "kicking the can down the road" is an incredibly dangerous precedent: if we are willing to go through the risk of a hard fork because of a fear of change of economics, then I believe that community is not ready to deal with change at all. And some change is inevitable, at any block size. Again, this does not mean the block size needs to be fixed forever, but its intent should be growing with the evolution of technology, not a panic reaction because a fear of change.
>
> But I am not in any position to force this view. I only hope that people don't think a fear of economic change is reason to give up consensus.
>
>
> Actually you are.
>
> When size increase progress gets frozen out of Bitcoin Core, that just increases the chances that progress must be made through a contentious hard fork.
>
> Further, it increases the market disruption users will experience, as described above.
>
> Think about the users.  Please.
>

>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

> Bitcoin Core is not running the Bitcoin economy, and its developers have
> no authority to set its rules.
>

> On Jul 22, 2015, at 2:43 PM, Mike Hearn via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> Hi Pieter,
>
> I think a core area of disagreement is this:
> Bitcoin Core is not running the Bitcoin economy, and its developers have no authority to set its rules.
>
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do have the authority to set its rules. This is enforced by the reality of ~100% market share and limited github commit access.
>
> You may not like this situation, but it is what it is. By refusing to make a release with different rules, people who disagree are faced with only two options:
>
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
>
> There are no alternatives. People who object to (2) are inherently suggesting (1) is the only acceptable path, which not surprisingly, makes a lot of people very angry.

> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

>
> Until we’re able to merge blockchain forks like we’re able to merge git
> repo forks, the safest option is no fork.
>

> On Jul 22, 2015, at 3:01 PM, Mike Hearn <hearn@vinumeris•com> wrote:
>
> Until we’re able to merge blockchain forks like we’re able to merge git repo forks, the safest option is no fork.
>
> Block chain forks merge in the same way as git forks all the time, that's how the reorg algorithm works. Transactions that didn't make it into the post-reorg chain go back into the mempool and miners attempt to reinclude them: this is the "merge" process. If they now conflict with other transactions they are dropped and this is "resolving merge conflicts".
>

> However you have to want to merge with the new chain. If your software is programmed not to do that out of some bizarre belief that throttling your own user base is a good idea, then of course, no merge happens. Once you stop telling your computer to do that, you can then merge (reorg) back onto the main chain again.
>

> Upgrading to a version of Bitcoin Core that is incompatible with your

> Hi Pieter,
>
> I think a core area of disagreement is this:
>
>> Bitcoin Core is not running the Bitcoin economy, and its developers have
>> no authority to set its rules.
>>
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
> have the authority to set its rules. This is enforced by the reality of
> ~100% market share and limited github commit access.
>
> You may not like this situation, but it is what it is. By refusing to make
> a release with different rules, people who disagree are faced with only two
> options:
>
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
>
> There are no alternatives. People who object to (2) are inherently
> suggesting (1) is the only acceptable path, which not surprisingly, makes a
> lot of people very angry.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

> If the developers fail to reflect user consensus, the network will let us know.

> Upgrading to a version of Bitcoin Core that is incompatible with your ideals is in no way a forced choice, as you have stated in your email; forks, alternative clients, or staying on an older version are all valid choices. If the majority of the network chooses not to endorse a specific change, then the majority of the network will continue to operate just fine without it, and properly structured consensus rules will pull the minority along as well.

>> If the developers fail to reflect user consensus, the network will let us
>> know.
>
> This is true with the caveat that there must be more than one option present
> for the network to show it's preference.  If developers discourage anything
> that forks from the rules enforced by Bitcoin Core, they harm the network's
> ability to inform us of a failure to reflect user consensus.
>
> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> I wouldn't go quite that far.  The reality is somewhere in the middle, as
> Bryan Cheng noted in this thread:
>
> Quoting BC,
>> Upgrading to a version of Bitcoin Core that is incompatible with your
>> ideals is in no way a forced choice, as you have stated in your email;
>> forks, alternative clients, or staying on an older version are all valid
>> choices. If the majority of the network chooses not to endorse a specific
>> change, then the majority of the network will continue to operate just fine
>> without it, and properly structured consensus rules will pull the minority
>> along as well.
>
> The developers propose a new version, by publishing a new release.  The
> individual network nodes choose to accept or reject that.
>
> So I respectfully disagree with "core devs don't control the network" and
> "core devs control the network" both.
>
> There are checks-and-balances that make the system work.  Consensus is most
> strongly measured by user actions after software release.  If the developers
> fail to reflect user consensus, the network will let us know.
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> Hi Pieter,
>
> I think a core area of disagreement is this:
>
> Bitcoin Core is not running the Bitcoin economy, and its developers have no
> authority to set its rules.
>
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
> have the authority to set its rules. This is enforced by the reality of
> ~100% market share and limited github commit access.
>
> You may not like this situation, but it is what it is. By refusing to make a
> release with different rules, people who disagree are faced with only two
> options:
>
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
>
> There are no alternatives. People who object to (2) are inherently
> suggesting (1) is the only acceptable path, which not surprisingly, makes a
> lot of people very angry.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> I'm not sure why Bitcoin Core and the rules and policies that it
> enforces are being conflated in this thread. There's nothing stopping
> us from adding the ability for the user to decide what their consensus
> parameters should be at runtime. In fact, that's already in use:
> ./bitcoind -testnet. As mentioned in another thread, the chain params
> could even come from a config file that the user could edit without
> touching the code.
>
> I realize that it'd be opening Pandora's Box, and likely met with very
> loud and reasonable arguments about the obvious terrible implications,
> but it's at least an alternative to the current status quo of Core's
> conflation with the consensus rules. The idea really is no different
> than suggesting that someone fork the codebase and implement their own
> changes, it just cuts out most of the work required.
>
> With that in place, consensus changes would be more about lobbying and
> coalitions, and less about pull requests.
>
> Cory
>
> On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>> If the developers fail to reflect user consensus, the network will let us
>>> know.
>>
>> This is true with the caveat that there must be more than one option present
>> for the network to show it's preference.  If developers discourage anything
>> that forks from the rules enforced by Bitcoin Core, they harm the network's
>> ability to inform us of a failure to reflect user consensus.
>>
>> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>
>> I wouldn't go quite that far.  The reality is somewhere in the middle, as
>> Bryan Cheng noted in this thread:
>>
>> Quoting BC,
>>> Upgrading to a version of Bitcoin Core that is incompatible with your
>>> ideals is in no way a forced choice, as you have stated in your email;
>>> forks, alternative clients, or staying on an older version are all valid
>>> choices. If the majority of the network chooses not to endorse a specific
>>> change, then the majority of the network will continue to operate just fine
>>> without it, and properly structured consensus rules will pull the minority
>>> along as well.
>>
>> The developers propose a new version, by publishing a new release.  The
>> individual network nodes choose to accept or reject that.
>>
>> So I respectfully disagree with "core devs don't control the network" and
>> "core devs control the network" both.
>>
>> There are checks-and-balances that make the system work.  Consensus is most
>> strongly measured by user actions after software release.  If the developers
>> fail to reflect user consensus, the network will let us know.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>
>> Hi Pieter,
>>
>> I think a core area of disagreement is this:
>>
>> Bitcoin Core is not running the Bitcoin economy, and its developers have no
>> authority to set its rules.
>>
>> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
>> have the authority to set its rules. This is enforced by the reality of
>> ~100% market share and limited github commit access.
>>
>> You may not like this situation, but it is what it is. By refusing to make a
>> release with different rules, people who disagree are faced with only two
>> options:
>>
>> 1. Swallow it even if they hate it
>> 2. Fork the project and fork the block chain with it (XT)
>>
>> There are no alternatives. People who object to (2) are inherently
>> suggesting (1) is the only acceptable path, which not surprisingly, makes a
>> lot of people very angry.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

> FWIW, I had worked on something similar a while back:
> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>
> I like the idea in principle…but we should require a new genesis block,
> different magic bytes, and a different network port at the very least. :)
>

> On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> I'm not sure why Bitcoin Core and the rules and policies that it
> enforces are being conflated in this thread. There's nothing stopping
> us from adding the ability for the user to decide what their consensus
> parameters should be at runtime. In fact, that's already in use:
> ./bitcoind -testnet. As mentioned in another thread, the chain params
> could even come from a config file that the user could edit without
> touching the code.
>
> I realize that it'd be opening Pandora's Box, and likely met with very
> loud and reasonable arguments about the obvious terrible implications,
> but it's at least an alternative to the current status quo of Core's
> conflation with the consensus rules. The idea really is no different
> than suggesting that someone fork the codebase and implement their own
> changes, it just cuts out most of the work required.
>
> With that in place, consensus changes would be more about lobbying and
> coalitions, and less about pull requests.
>
> Cory
>
> On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> If the developers fail to reflect user consensus, the network will let us
> know.
>
>
> This is true with the caveat that there must be more than one option present
> for the network to show it's preference.  If developers discourage anything
> that forks from the rules enforced by Bitcoin Core, they harm the network's
> ability to inform us of a failure to reflect user consensus.
>
> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> I wouldn't go quite that far.  The reality is somewhere in the middle, as
> Bryan Cheng noted in this thread:
>
> Quoting BC,
>
> Upgrading to a version of Bitcoin Core that is incompatible with your
> ideals is in no way a forced choice, as you have stated in your email;
> forks, alternative clients, or staying on an older version are all valid
> choices. If the majority of the network chooses not to endorse a specific
> change, then the majority of the network will continue to operate just fine
> without it, and properly structured consensus rules will pull the minority
> along as well.
>
>
> The developers propose a new version, by publishing a new release.  The
> individual network nodes choose to accept or reject that.
>
> So I respectfully disagree with "core devs don't control the network" and
> "core devs control the network" both.
>
> There are checks-and-balances that make the system work.  Consensus is most
> strongly measured by user actions after software release.  If the developers
> fail to reflect user consensus, the network will let us know.
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> Hi Pieter,
>
> I think a core area of disagreement is this:
>
> Bitcoin Core is not running the Bitcoin economy, and its developers have no
> authority to set its rules.
>
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
> have the authority to set its rules. This is enforced by the reality of
> ~100% market share and limited github commit access.
>
> You may not like this situation, but it is what it is. By refusing to make a
> release with different rules, people who disagree are faced with only two
> options:
>
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
>
> There are no alternatives. People who object to (2) are inherently
> suggesting (1) is the only acceptable path, which not surprisingly, makes a
> lot of people very angry.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

> On Jul 22, 2015, at 5:05 PM, Cory Fields <lists@coryfields•com> wrote:
>
> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>> FWIW, I had worked on something similar a while back:
>> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>>
>> I like the idea in principle…but we should require a new genesis block,
>> different magic bytes, and a different network port at the very least. :)
>>
>
> Not sure if serious, so I'll assume you are :)

> Why? The idea in this case would be to allow the user to decide
> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
> runtime rather than the likely alternative of "./bitcoind" vs
> "./bitcoin-fork”.

> Chain params may be identical other than the value of some future
> event (miner vote for example), in which case the configs would run
> identically until that point.

> If your concern is about nodes with different configs communicating
> with eachother, I'd like to reiterate: the idea really is no different
> than suggesting that someone fork the codebase and implement their own
> changes, it just cuts out most of the work required.

> Cory
>
>> On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>
>> I'm not sure why Bitcoin Core and the rules and policies that it
>> enforces are being conflated in this thread. There's nothing stopping
>> us from adding the ability for the user to decide what their consensus
>> parameters should be at runtime. In fact, that's already in use:
>> ./bitcoind -testnet. As mentioned in another thread, the chain params
>> could even come from a config file that the user could edit without
>> touching the code.
>>
>> I realize that it'd be opening Pandora's Box, and likely met with very
>> loud and reasonable arguments about the obvious terrible implications,
>> but it's at least an alternative to the current status quo of Core's
>> conflation with the consensus rules. The idea really is no different
>> than suggesting that someone fork the codebase and implement their own
>> changes, it just cuts out most of the work required.
>>
>> With that in place, consensus changes would be more about lobbying and
>> coalitions, and less about pull requests.
>>
>> Cory
>>
>> On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>
>> If the developers fail to reflect user consensus, the network will let us
>> know.
>>
>>
>> This is true with the caveat that there must be more than one option present
>> for the network to show it's preference.  If developers discourage anything
>> that forks from the rules enforced by Bitcoin Core, they harm the network's
>> ability to inform us of a failure to reflect user consensus.
>>
>> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>
>> I wouldn't go quite that far.  The reality is somewhere in the middle, as
>> Bryan Cheng noted in this thread:
>>
>> Quoting BC,
>>
>> Upgrading to a version of Bitcoin Core that is incompatible with your
>> ideals is in no way a forced choice, as you have stated in your email;
>> forks, alternative clients, or staying on an older version are all valid
>> choices. If the majority of the network chooses not to endorse a specific
>> change, then the majority of the network will continue to operate just fine
>> without it, and properly structured consensus rules will pull the minority
>> along as well.
>>
>>
>> The developers propose a new version, by publishing a new release.  The
>> individual network nodes choose to accept or reject that.
>>
>> So I respectfully disagree with "core devs don't control the network" and
>> "core devs control the network" both.
>>
>> There are checks-and-balances that make the system work.  Consensus is most
>> strongly measured by user actions after software release.  If the developers
>> fail to reflect user consensus, the network will let us know.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>
>> Hi Pieter,
>>
>> I think a core area of disagreement is this:
>>
>> Bitcoin Core is not running the Bitcoin economy, and its developers have no
>> authority to set its rules.
>>
>> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
>> have the authority to set its rules. This is enforced by the reality of
>> ~100% market share and limited github commit access.
>>
>> You may not like this situation, but it is what it is. By refusing to make a
>> release with different rules, people who disagree are faced with only two
>> options:
>>
>> 1. Swallow it even if they hate it
>> 2. Fork the project and fork the block chain with it (XT)
>>
>> There are no alternatives. People who object to (2) are inherently
>> suggesting (1) is the only acceptable path, which not surprisingly, makes a
>> lot of people very angry.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>

> It would be irresponsible and dangerous to the network and thus the
> users of the software to risk forks, or to take a leading role in
> pushing dramatic changes.

>
>> On Jul 22, 2015, at 5:05 PM, Cory Fields <lists@coryfields•com> wrote:
>>
>> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>> FWIW, I had worked on something similar a while back:
>>> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>>>
>>> I like the idea in principle…but we should require a new genesis block,
>>> different magic bytes, and a different network port at the very least. :)
>>>
>>
>> Not sure if serious, so I'll assume you are :)
>
> Only being partly serious - I strongly am in favor of a sufficiently modularized codebase that swapping out consensus rules is fairly straightforward and easy to test. I’m not in favor of encouraging forking an existing blockchain without having mechanisms in place to gracefully merge back without significant network disruptions. We do not have this yet.
>

>> Why? The idea in this case would be to allow the user to decide
>> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
>> runtime rather than the likely alternative of "./bitcoind" vs
>> "./bitcoin-fork”.
>
> That’s exactly what my coinparams_new branch does. Adding a parameter for maximum block size would be straightforward.
>
>> Chain params may be identical other than the value of some future
>> event (miner vote for example), in which case the configs would run
>> identically until that point.
>
> Yes, indeed - this would be a special case.
>
>> If your concern is about nodes with different configs communicating
>> with eachother, I'd like to reiterate: the idea really is no different
>> than suggesting that someone fork the codebase and implement their own
>> changes, it just cuts out most of the work required.
>
> I do not encourage anyone to try to fork an existing blockchain without first securing overwhelming (near unanimous) consensus…or without having yet built a mechanism that can merge divergent chains gracefully.

> On Jul 22, 2015, at 5:27 PM, Tom Harding via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> On 7/22/2015 9:52 AM, Pieter Wuille via bitcoin-dev wrote:
>> It would be irresponsible and dangerous to the network and thus the users of the software to risk forks, or to take a leading role in pushing dramatic changes.
>
> Count me among those who see allowing bitcoin to become space-constrained, without technical reason, as a dramatic change. Especially when the reasons cited in support are
>
> - Various species of vaporware
> - Amateurish economic thinking surrounding fees
> - "We don't support it because not everyone supports it because we don't support it because ..." infinite descent
>

> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

> On Jul 22, 2015, at 5:34 PM, Cory Fields <lists@coryfields•com> wrote:
>
> On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>
>>> On Jul 22, 2015, at 5:05 PM, Cory Fields <lists@coryfields•com> wrote:
>>>
>>> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>>> FWIW, I had worked on something similar a while back:
>>>> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>>>>
>>>> I like the idea in principle…but we should require a new genesis block,
>>>> different magic bytes, and a different network port at the very least. :)
>>>>
>>>
>>> Not sure if serious, so I'll assume you are :)
>>
>> Only being partly serious - I strongly am in favor of a sufficiently modularized codebase that swapping out consensus rules is fairly straightforward and easy to test. I’m not in favor of encouraging forking an existing blockchain without having mechanisms in place to gracefully merge back without significant network disruptions. We do not have this yet.
>>
>
> Again, why? If someone wants to create a scamcoin, they can. If
> someone wants to burn money on a scamcoin, equally, they can. I'm not
> sure how this is any different. If someone manages to garner realistic
> support for a hard-fork, I don't see the benefit in forcing them to
> use forked software.. that only leaves Core in the middle because it's
> forced to choose a side (not choosing is unfortunately a side as
> well). It doesn't remove the reality of the split.

>>> Why? The idea in this case would be to allow the user to decide
>>> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
>>> runtime rather than the likely alternative of "./bitcoind" vs
>>> "./bitcoin-fork”.
>>
>> That’s exactly what my coinparams_new branch does. Adding a parameter for maximum block size would be straightforward.
>>
>>> Chain params may be identical other than the value of some future
>>> event (miner vote for example), in which case the configs would run
>>> identically until that point.
>>
>> Yes, indeed - this would be a special case.
>>
>>> If your concern is about nodes with different configs communicating
>>> with eachother, I'd like to reiterate: the idea really is no different
>>> than suggesting that someone fork the codebase and implement their own
>>> changes, it just cuts out most of the work required.
>>
>> I do not encourage anyone to try to fork an existing blockchain without first securing overwhelming (near unanimous) consensus…or without having yet built a mechanism that can merge divergent chains gracefully.
>
> Well of course. It would be a terrible idea. People would try it and
> fail, and lose money. But for those crying foul at Core for being the
> consensus/policy gatekeeper, it seems to me that user-selectable
> params is the only logical solution.

> Only being partly serious - I strongly am in favor of a sufficiently

> On Jul 22, 2015, at 3:01 PM, Mike Hearn <hearn@vinumeris•com> wrote:
>
> Until we’re able to merge blockchain forks like we’re able to merge git repo forks, the safest option is no fork.
>
> Block chain forks merge in the same way as git forks all the time, that's how the reorg algorithm works. Transactions that didn't make it into the post-reorg chain go back into the mempool and miners attempt to reinclude them: this is the "merge" process. If they now conflict with other transactions they are dropped and this is "resolving merge conflicts".
>
> However you have to want to merge with the new chain. If your software is programmed not to do that out of some bizarre belief that throttling your own user base is a good idea, then of course, no merge happens. Once you stop telling your computer to do that, you can then merge (reorg) back onto the main chain again.
>

> So to point out what I consider obvious: if Bitcoin requires central
> control over its rules by a group of developers, it is completely
> uninteresting to me. Consensus changes should be done using consensus, and
> the default in case of controversy is no change.

>> On Jul 22, 2015, at 5:34 PM, Cory Fields <lists@coryfields•com> wrote:
>>
>> On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>>> On Jul 22, 2015, at 5:05 PM, Cory Fields <lists@coryfields•com> wrote:
>>>>
>>>> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>>>> FWIW, I had worked on something similar a while back:
>>>>> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>>>>>
>>>>> I like the idea in principle…but we should require a new genesis block,
>>>>> different magic bytes, and a different network port at the very least. :)
>>>>>
>>>> Not sure if serious, so I'll assume you are :)
>>> Only being partly serious - I strongly am in favor of a sufficiently modularized codebase that swapping out consensus rules is fairly straightforward and easy to test. I’m not in favor of encouraging forking an existing blockchain without having mechanisms in place to gracefully merge back without significant network disruptions. We do not have this yet.
>>>
>> Again, why? If someone wants to create a scamcoin, they can. If
>> someone wants to burn money on a scamcoin, equally, they can. I'm not
>> sure how this is any different. If someone manages to garner realistic
>> support for a hard-fork, I don't see the benefit in forcing them to
>> use forked software.. that only leaves Core in the middle because it's
>> forced to choose a side (not choosing is unfortunately a side as
>> well). It doesn't remove the reality of the split.
> In general, new consensus rules are not trivial to implement. Block size limits are exceptional in being so simple to change in the code. So what you’re proposing sounds more like a plugin model supporting dynamic linking than a configuration file.
>
>>>> Why? The idea in this case would be to allow the user to decide
>>>> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
>>>> runtime rather than the likely alternative of "./bitcoind" vs
>>>> "./bitcoin-fork”.
>>> That’s exactly what my coinparams_new branch does. Adding a parameter for maximum block size would be straightforward.
>>>
>>>> Chain params may be identical other than the value of some future
>>>> event (miner vote for example), in which case the configs would run
>>>> identically until that point.
>>> Yes, indeed - this would be a special case.
>>>
>>>> If your concern is about nodes with different configs communicating
>>>> with eachother, I'd like to reiterate: the idea really is no different
>>>> than suggesting that someone fork the codebase and implement their own
>>>> changes, it just cuts out most of the work required.
>>> I do not encourage anyone to try to fork an existing blockchain without first securing overwhelming (near unanimous) consensus…or without having yet built a mechanism that can merge divergent chains gracefully.
>> Well of course. It would be a terrible idea. People would try it and
>> fail, and lose money. But for those crying foul at Core for being the
>> consensus/policy gatekeeper, it seems to me that user-selectable
>> params is the only logical solution.
> The real problem isn’t so much the difficulty of creating forks of the codebase - but the fact that unless a fork has overwhelming support, blockchains cannot guarantee irreversibility of transactions…which defeats their entire purpose.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

>I believe it is the responsibility of the maintainers/developers of
>Bitcoin
>Core to create software which helps guarantee the security and
>operation of
>the Bitcoin network

> To the user, talk of a fee market is equivalent to talk about block size -
> various opinions are tossed about, but it doesn't really impact them.  Fees
> have been low for 6 years.
>
> We see this with the actual data - no fee pressure on average for the
> entirety of bitcoin's history.  We see this with the recent stress tests,
> which exposed dumb wallet behavior WRT fees.   Users -and software- had the
> expectation

> Remember, this is not a judgement on whether or not fee market/pressure
> should exist.  It is simply a factual observation that users/market have not
> experienced this new economic policy.

> That opens the question - why now?   Why make bitcoin growth more expensive
> at this time in its young life?  Many smart people would prefer that bitcoin
> continue to grow, rather than making the system more expensive to use right
> now.

> Choosing "let a fee market develop" -- today -- is picking economic sides,
> picking winners & losers in the market.

> If the user expectation is that a price would never arise because
> supply is going to be increased ad infinitum and they will always be
> able to send fast in-chain bitcoin transactions for free, just like
> breath air (an abundant resource) for free, then we should change that
> expectation as soon as possible.

> the criteria for the consensus block size should be purely based on
> technological capacity (propagation benchmarking, etc) and
> centralization concerns

> they will simply advance the front and start another battle, because
> their true hidden faction is the "not ever side". Please, Jeff, Gavin,
> Mike, show me that I'm wrong on this point. Please, answer my question
> this time. If "not now", then when?

> On 7/23/2015 5:17 AM, Jorge Timón via bitcoin-dev wrote:
> > they will simply advance the front and start another battle, because
> > their true hidden faction is the "not ever side". Please, Jeff, Gavin,
> > Mike, show me that I'm wrong on this point. Please, answer my question
> > this time. If "not now", then when?
>
> Bitcoin has all the hash power.  The merkle root has effectively
> infinite capacity.  We should be asking HOW to scale the supporting
> information propagation system appropriately, not WHEN to limit the
> capacity of the primary time-stamping machine.
>
> We haven't tried yet.  I can't answer for the people you asked, but
> personally I haven't thought much about when we should declare failure.

> they will simply advance the front and start another battle, because

> their true hidden faction is the "not ever side". Please, Jeff, Gavin,

> Mike, show me that I'm wrong on this point. Please, answer my question

> this time. If "not now", then when?

> On 23 Jul 2015, at 17:50, cipher anthem via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> Why not help on a project that actually seems to offer great scalability like the lightning network? There have been great progress there.
>
> Seems like you did your calculations some time ago to prove that your increase is reasonable, yet when others come with different numbers that don't support your position you say it doesn't matter.
>
> Sent: Thursday, July 23, 2015 at 4:28 PM
> From: "Gavin Andresen via bitcoin-dev" <bitcoin-dev@lists•linuxfoundation•org>
> To: "Tom Harding" <tomh@thinlink•com>
> Cc: bitcoin-dev@lists•linuxfoundation•org
> Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
> On Thu, Jul 23, 2015 at 12:17 PM, Tom Harding via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org <x-msg://14/bitcoin-dev@lists.linuxfoundation.org>> wrote:
> On 7/23/2015 5:17 AM, Jorge Timón via bitcoin-dev wrote:
> > they will simply advance the front and start another battle, because
> > their true hidden faction is the "not ever side". Please, Jeff, Gavin,
> > Mike, show me that I'm wrong on this point. Please, answer my question
> > this time. If "not now", then when?
>
> Bitcoin has all the hash power.  The merkle root has effectively
> infinite capacity.  We should be asking HOW to scale the supporting
> information propagation system appropriately, not WHEN to limit the
> capacity of the primary time-stamping machine.
>
> We haven't tried yet.  I can't answer for the people you asked, but
> personally I haven't thought much about when we should declare failure.
>
> Yes! Lets plan for success!
>
> I'd really like to move from "IMPOSSIBLE because...  (electrum hasn't been optimized
> (by the way: you should run on SSDs, LevelDB isn't designed for spinning disks),
> what if the network is attacked?  (attacked HOW???), current p2p network is using
> the simplest, stupidest possible block propagation algorithm...)"
>
> ... to "lets work together and work through the problems and scale it up."
>
> I'm frankly tired of all the negativity here; so tired of it I've decided to mostly ignore
> all the debate for a while, not respond to misinformation I see being spread
> (like "miners have some incentive to create slow-to-propagate blocks"),
> work with people like Tom and Mike who have a 'lets get it done' attitude, and
> focus on what it will take to scale up.
>
> --
> --
> Gavin Andresen
>
> _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists•linuxfoundation•org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>_______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

> On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> I'd really like to move from "IMPOSSIBLE because...  (electrum hasn't been optimized
> (by the way: you should run on SSDs, LevelDB isn't designed for spinning disks),
> what if the network is attacked?  (attacked HOW???), current p2p network is using
> the simplest, stupidest possible block propagation algorithm...)"
>
> ... to "lets work together and work through the problems and scale it up."

> On Jul 23, 2015, at 9:50 AM, cipher anthem via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> Why not help on a project that actually seems to offer great scalability like the lightning network? There have been great progress there.

> On Jul 23, 2015, at 5:17 AM, Jorge Timón via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> But it seems to me that the "not now side" has no centralization
> concerns at all and their true position is "not ever hit the blocksize
> limit", that's the only explanation I can find to their lack of
> answers to the "when do you think we should allow users to notice that
> there's a limit in the blocksize to guarantee that the system can be
> decentralized?".

> On 7/23/2015 5:17 AM, Jorge Timón via bitcoin-dev wrote:
>
>> If the user expectation is that a price would never arise because
>> supply is going to be increased ad infinitum and they will always be
>> able to send fast in-chain bitcoin transactions for free, just like
>> breath air (an abundant resource) for free, then we should change that
>> expectation as soon as possible.
>
> No.  We should accept that reality may change, and we should promote
> understanding of that fact.
>
> We should not artificially manipulate the market "as soon as possible,"
> since we ourselves don't know much at all about how the market will
> unfold in the future.

>> the criteria for the consensus block size should be purely based on
>> technological capacity (propagation benchmarking, etc) and
>> centralization concerns
>
> Right, purely these.  There is no place for artificially manipulating
> expectations.

>> they will simply advance the front and start another battle, because
>> their true hidden faction is the "not ever side". Please, Jeff, Gavin,
>> Mike, show me that I'm wrong on this point. Please, answer my question
>> this time. If "not now", then when?
>
> Bitcoin has all the hash power.  The merkle root has effectively
> infinite capacity.  We should be asking HOW to scale the supporting
> information propagation system appropriately, not WHEN to limit the
> capacity of the primary time-stamping machine.

> On Thu, Jul 23, 2015 at 12:17 PM, Tom Harding via bitcoin-dev
>> We haven't tried yet.  I can't answer for the people you asked, but
>> personally I haven't thought much about when we should declare failure.
>
>
> Yes! Lets plan for success!

>
> On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> I'd really like to move from "IMPOSSIBLE because...  (electrum hasn't been
> optimized
> (by the way: you should run on SSDs, LevelDB isn't designed for spinning
> disks),
> what if the network is attacked?  (attacked HOW???), current p2p network
> is using
> the simplest, stupidest possible block propagation algorithm...)"
>
> ... to "lets work together and work through the problems and scale it up."
>
>
> Let’s be absolutely clear about one thing - block size increases are *not*
> about scaling the network. Can we please stop promoting this falsehood? It
> doesn’t matter by what number we multiply the block size…we can NEVER
> satisfy the full demand if we insist on every single transaction from every
> single person everywhere in the world being on the blockchain…it’s just
> absurd.
>
>

> how to postpone having to deal with transaction fees, which by design, are
> how the cost of operating the Bitcoin network (which is already very
> expensive) is supposed to be paid for ultimately. Suggesting we avoid
> dealing with this constitutes a new economic policy - dealing with it is
> the default economic policy we’ve all known about from the beginning…so
> please stop claiming otherwise.
>
>

> On Jul 23, 2015, at 9:50 AM, cipher anthem via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> Why not help on a project that actually seems to offer great scalability
> like the lightning network? There have been great progress there.
>
>
> Exactly. There’s been tremendous progress here in addressing scalability,
> yet I don’t see you participating in that discussion, Gavin.
>
> On Jul 23, 2015, at 5:17 AM, Jorge Timón via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> But it seems to me that the "not now side" has no centralization
> concerns at all and their true position is "not ever hit the blocksize
> limit", that's the only explanation I can find to their lack of
> answers to the "when do you think we should allow users to notice that
> there's a limit in the blocksize to guarantee that the system can be
> decentralized?".
>
>
> I agree with what you’re saying, Jorge…but It’s even worse than that. The
> July 4th fork illustrated that the security model of the network itself
> could be at risk from the increasing costs in validation causing people to
> rely on others to validate for them…and increasing block size only makes
> the problem worse.
>
> - Eric Lombrozo
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

> I'm not sure why Bitcoin Core and the rules and policies that it
> enforces are being conflated in this thread. There's nothing stopping
> us from adding the ability for the user to decide what their consensus
> parameters should be at runtime. In fact, that's already in use:
> ./bitcoind -testnet. As mentioned in another thread, the chain params
> could even come from a config file that the user could edit without
> touching the code.

> Sent: Thursday, July 23, 2015 at 7:28 PM
> From: "Gavin Andresen via bitcoin-dev" <bitcoin-dev@lists•linuxfoundation•org>
> To: "Tom Harding" <tomh@thinlink•com>
> Cc: bitcoin-dev@lists•linuxfoundation•org
> Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
>
> I'm frankly tired of all the negativity here

> I'd really like to move from "IMPOSSIBLE because...  (electrum hasn't been optimized
> (by the way: you should run on SSDs, LevelDB isn't designed for spinning disks),

> work with people like Tom and Mike who have a 'lets get it done' attitude, and
> focus on what it will take to scale up.

> On Jul 23, 2015, at 10:14 AM, Robert Learney via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> That’s not exactly what’s happened though, is it Cipher? Gavin put forward 20Mb then after analysis and discussion has moved to 8Mb, whereas the other camp of core developers is firmly stuck in the ‘1Mb or bust’ group.

> That’s not exactly what’s happened though, is it Cipher? Gavin put forward
> 20Mb then after analysis and discussion has moved to 8Mb, whereas the other
> camp of core developers is firmly stuck in the ‘1Mb or bust’ group.

>
> You complained about the lack of quantitative analysis being used, I gave
> it to you. There's nothing "negative" about displaying data which doesn't
> completely back up what your position is, I made a sensible conclusion
> based on the facts I have in front of me. Ignoring the information I
> collected and presented for you is incredibly childish.
>

> On Jul 23, 2015, at 11:10 AM, Jameson Lopp <jameson.lopp@gmail•com> wrote:
>
> Larger block sizes don't scale the network, they merely increase how much load we allow the network to bear.

> On the flip side, the scalability proposals will still require larger blocks if we are ever to support anything close to resembling "mainstream" usage. This is not an either/or proposition - we clearly need both.

> Mainstream usage of cryptocurrency will be enabled primarily by direct
> party-to-party contract negotiation…with the use of the blockchain
> primarily as a dispute resolution mechanism. The block size isn’t about
> scaling but about supply and demand of finite resources. As demand for
> block space increases, we can address it either by increasing computational
> resources (block size) or by increasing fees. But to do the former we need
> a way to offset the increase in cost by making sure that those who
> contribute said resources have incentive to do so.

> On Jul 23, 2015, at 12:35 PM, Gavin Andresen <gavinandresen@gmail•com> wrote:
>
>
> On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo <elombrozo@gmail•com <mailto:elombrozo@gmail.com>> wrote:
> Mainstream usage of cryptocurrency will be enabled primarily by direct party-to-party contract negotiation…with the use of the blockchain primarily as a dispute resolution mechanism. The block size isn’t about scaling but about supply and demand of finite resources. As demand for block space increases, we can address it either by increasing computational resources (block size) or by increasing fees. But to do the former we need a way to offset the increase in cost by making sure that those who contribute said resources have incentive to do so.
>
> There are so many things wrong with this paragraph I just can't let it slide.
>
> "Mainstream usage will be enabled primarily by..."  Maybe. Maybe not, we don't know what use case(s) will primarily take cryptocurrency mainstream. I believe it is a big mistake to pick one and bet "THIS is going to be the winner".
>
> "we can address it either by... or..."  False dichotomy. There are lots of things we can do to decrease costs, and a lot of things have ALREADY been done (e.g. running a pruned full node).  I HATE the "it must be this or that" "us or them" attitude, it fosters unproductive bickering and negativity.
>
> (and yes, I'm human, I'm sure you can find instances in the recent past where I did it, too... mea culpa)
>
> --
> --
> Gavin Andresen
>

> On Jul 23, 2015, at 12:35 PM, Gavin Andresen <gavinandresen@gmail•com> wrote:
>
> There are lots of things we can do to decrease costs, and a lot of things have ALREADY been done (e.g. running a pruned full node).

>
> On Jul 23, 2015, at 11:10 AM, Jameson Lopp <jameson.lopp@gmail•com> wrote:
>
> Larger block sizes don't scale the network, they merely increase how much
> load we allow the network to bear.
>
>
> Very well put, Jameson. And the cost of bearing this load must be paid
> for. And unless we’re willing to accept that computational resources are
> finite and subject to the same economic issues as any other finite
> resource, our incentive model collapses the security of the network will be
> significantly at risk. Whatever your usability concerns may be regarding
> fees, when the security model’s busted usability issues are moot.
>
> Larger blocks support more transactions…but they also incur Ω(n) overhead
> in bandwidth, CPU, and space. These are finite resources that must be paid
> for somehow…and as we all already know miners are willing to cut corners on
> all this and push the costs onto others (not to mention wallets and online
> block explorers). And who can really blame them? It’s rational behavior
> given the skewed incentives.
>

>
> On the flip side, the scalability proposals will still require larger
> blocks if we are ever to support anything close to resembling "mainstream"
> usage. This is not an either/or proposition - we clearly need both.
>
>
> Mainstream usage of cryptocurrency will be enabled primarily by direct
> party-to-party contract negotiation…with the use of the blockchain
> primarily as a dispute resolution mechanism. The block size isn’t about
> scaling but about supply and demand of finite resources. As demand for
> block space increases, we can address it either by increasing computational
> resources (block size) or by increasing fees. But to do the former we need
> a way to offset the increase in cost by making sure that those who
> contribute said resources have incentive to do so.
>

> Running a node certainly has real-world costs that shouldn't be ignored.
> There are plenty of advocates who argue that Bitcoin should strive to keep
> it feasible for the average user to run their own node (as opposed to
> Satoshi's vision of beefy servers in data centers.) My impression is that
> even most of these advocates agree that it will be acceptable to eventually
> increase block sizes as resources become faster and cheaper because it won't
> be 'pricing out' the average user from running their own node. If this is
> the case, it seems to me that we have a problem given that there is no
> established baseline for the acceptable performance / hardware cost
> requirements to run a node. I'd really like to see further clarification
> from these advocates around the acceptable cost of running a node and how we
> can measure the global reduction in hardware and bandwidth costs in order to
> establish a baseline that we can use to justify additional resource usage by
> nodes.

> On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo <elombrozo@gmail•com <mailto:elombrozo@gmail.com>> wrote:
> Mainstream usage of cryptocurrency will be enabled primarily by direct party-to-party contract negotiation…with the use of the blockchain primarily as a dispute resolution mechanism. The block size isn’t about scaling but about supply and demand of finite resources. As demand for block space increases, we can address it either by increasing computational resources (block size) or by increasing fees. But to do the former we need a way to offset the increase in cost by making sure that those who contribute said resources have incentive to do so.’

> On Jul 23, 2015, at 1:26 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
>
> On Thu, Jul 23, 2015 at 9:52 PM, Jameson Lopp via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>> Running a node certainly has real-world costs that shouldn't be ignored.
>> There are plenty of advocates who argue that Bitcoin should strive to keep
>> it feasible for the average user to run their own node (as opposed to
>> Satoshi's vision of beefy servers in data centers.) My impression is that
>> even most of these advocates agree that it will be acceptable to eventually
>> increase block sizes as resources become faster and cheaper because it won't
>> be 'pricing out' the average user from running their own node. If this is
>> the case, it seems to me that we have a problem given that there is no
>> established baseline for the acceptable performance / hardware cost
>> requirements to run a node. I'd really like to see further clarification
>> from these advocates around the acceptable cost of running a node and how we
>> can measure the global reduction in hardware and bandwidth costs in order to
>> establish a baseline that we can use to justify additional resource usage by
>> nodes.
>
> Although I don't have a concrete proposals myself, I agree that
> without having any common notion of what the "minimal target hardware"
> looks like, it is very difficult to discuss other things that depend
> on that.
> If there's data that shows that a 100 usd raspberry pi with a 1 MB
> connection in say, India (I actually have no idea about internet
> speeds there) size X is a viable full node, then I don't think anybody
> can reasonably oppose to rising the block size to X, and such a
> hardfork can perfectly be uncontroversial.
> I'm exaggerating ultra-low specifications, but it's just an example to
> illustrate your point.
> There was a thread about formalizing such "minimum hardware
> requirements", but I think the discussion simply finished there:
> - Let's do this
> - Yeah, let's do it
> - +1, let's have concrete values, I generally agree.

> On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>
>> Mainstream usage of cryptocurrency will be enabled primarily by direct
>> party-to-party contract negotiation…with the use of the blockchain primarily
>> as a dispute resolution mechanism. The block size isn’t about scaling but
>> about supply and demand of finite resources. As demand for block space
>> increases, we can address it either by increasing computational resources
>> (block size) or by increasing fees. But to do the former we need a way to
>> offset the increase in cost by making sure that those who contribute said
>> resources have incentive to do so.’
>
>
> I should also point out, improvements in hardware and network infrastructure
> can also reduce costs…and we could very well have a model where resource
> requirements can be increased as technology improves. However, currently,
> the computational cost of validation is clearly growing far more quickly
> than the cost of computational resources is going down. There are
> 7,000,000,000 people in the world. Payment networks in the developed world
> already regularly handle thousands of transactions a second. Even with
> highly optimized block propagation, pruning, and signature validation, we’re
> still many orders shy of being able to satisfy demand. To achieve mainstream
> adoption, we’ll have to pass through a period of quasi-exponential growth in
> userbase (until the market saturates…or until the network resources run
> out). Unless we’re able to achieve a validation complexity of O(polylog n)
> or better, it’s not a matter of having a negative attitude about the
> prospects…it’s just math. Whether we have 2MB or 20MB or 100MB blocks (even
> assuming the above mentioned optimizations and that the computational
> resources exist and are willing to handle it) we will not be able to satisfy
> demand if we insist on requiring global validation for all transactions.
>

>
> On Jul 23, 2015, at 1:26 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
>
> On Thu, Jul 23, 2015 at 9:52 PM, Jameson Lopp via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> Running a node certainly has real-world costs that shouldn't be ignored.
> There are plenty of advocates who argue that Bitcoin should strive to keep
> it feasible for the average user to run their own node (as opposed to
> Satoshi's vision of beefy servers in data centers.) My impression is that
> even most of these advocates agree that it will be acceptable to eventually
> increase block sizes as resources become faster and cheaper because it won't
> be 'pricing out' the average user from running their own node. If this is
> the case, it seems to me that we have a problem given that there is no
> established baseline for the acceptable performance / hardware cost
> requirements to run a node. I'd really like to see further clarification
> from these advocates around the acceptable cost of running a node and how we
> can measure the global reduction in hardware and bandwidth costs in order to
> establish a baseline that we can use to justify additional resource usage by
> nodes.
>
>
> Although I don't have a concrete proposals myself, I agree that
> without having any common notion of what the "minimal target hardware"
> looks like, it is very difficult to discuss other things that depend
> on that.
> If there's data that shows that a 100 usd raspberry pi with a 1 MB
> connection in say, India (I actually have no idea about internet
> speeds there) size X is a viable full node, then I don't think anybody
> can reasonably oppose to rising the block size to X, and such a
> hardfork can perfectly be uncontroversial.
> I'm exaggerating ultra-low specifications, but it's just an example to
> illustrate your point.
> There was a thread about formalizing such "minimum hardware
> requirements", but I think the discussion simply finished there:
> - Let's do this
> - Yeah, let's do it
> - +1, let's have concrete values, I generally agree.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> On Jul 23, 2015, at 4:42 PM, Benedict Chan <bencxr@fragnetics•com> wrote:
>
> Scaling the network will come in the form of a combination of many
> optimizations. Just because we do not know for sure how to eventually
> serve 7 billion people does not mean we should make decisions on
> global validation that impact our ability to serve the current set of
> users.

> Also, blocking a change because it's "more important to address issues
> such as..." other improvements will further slow down the discussion.
> I believe an increase will not prevent the development of other
> improvements that we need - in contrast, the sooner we can get over
> the limit (which, as you agree, needs to be changed at some point),
> the sooner we can get back to work.

> On Jul 23, 2015, at 4:57 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>
>
>> On Jul 23, 2015, at 4:42 PM, Benedict Chan <bencxr@fragnetics•com <mailto:bencxr@fragnetics.com>> wrote:
>>
>> Scaling the network will come in the form of a combination of many
>> optimizations. Just because we do not know for sure how to eventually
>> serve 7 billion people does not mean we should make decisions on
>> global validation that impact our ability to serve the current set of
>> users.
>
> Agreed. But I believe the economic and security arguments I gave regarding fees and incentives still hold and are largely separate from the scalability issue. Please correct me if I overlooked something.
>
>
>> Also, blocking a change because it's "more important to address issues
>> such as..." other improvements will further slow down the discussion.
>> I believe an increase will not prevent the development of other
>> improvements that we need - in contrast, the sooner we can get over
>> the limit (which, as you agree, needs to be changed at some point),
>> the sooner we can get back to work.
>
> An increase in block size at this time will exacerbate security concerns around nodes relying on other nodes to validate (particularly miners and wallets). It’s not really a matter of having limited developer resources that need to be budgeted, as you seem to suggest.
>
> Regarding developments on properly handling fees, there must exist the economic need for it before there’s an earnest effort to solve it. Increasing the block size right now will, in all likelihood, delay this effort. I’d much prefer to first let the fee market evolve because it’s a crucial component to the protocol’s design and its security model…and so we can get a better sense for fee economics. Then we might be able to figure out better approaches to block size changes in the future that makes sense economically…perhaps with mechanisms that can dynamically adjust it to reflect resource availability and network load.

> I should also add that I think those who claim that fee pressure will
> scare away users and break the industry are *seriously* underestimating
> human ingenuity in the face of a challenge. We can do this - we can
> overcome this obstacle…we can find good solutions to a fee market.
> Unless someone can come up with another way to pay for the operation of
> the network, we NEED to do this. What makes anyone think it will be
> easier to do later rather than now? The longer we wait, the lower block
> rewards get, the larger the deployed infrastructure, the larger our
> userbase, the HARDER it will be to solve it. We should solve it now - we
> will be much better off for it…and so will our users.
>

> On Jul 24, 2015, at 8:04 AM, Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> I should also add that I think those who claim that fee pressure will scare away users and break the industry are *seriously* underestimating human ingenuity in the face of a challenge. We can do this - we can overcome this obstacle…we can find good solutions to a fee market. Unless someone can come up with another way to pay for the operation of the network, we NEED to do this. What makes anyone think it will be easier to do later rather than now? The longer we wait, the lower block rewards get, the larger the deployed infrastructure, the larger our userbase, the HARDER it will be to solve it. We should solve it now - we will be much better off for it…and so will our users.
>
>
>>> On Jul 23, 2015, at 4:57 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>>
>>>
>>> On Jul 23, 2015, at 4:42 PM, Benedict Chan <bencxr@fragnetics•com> wrote:
>>>
>>> Scaling the network will come in the form of a combination of many
>>> optimizations. Just because we do not know for sure how to eventually
>>> serve 7 billion people does not mean we should make decisions on
>>> global validation that impact our ability to serve the current set of
>>> users.
>>
>> Agreed. But I believe the economic and security arguments I gave regarding fees and incentives still hold and are largely separate from the scalability issue. Please correct me if I overlooked something.
>>
>>
>>> Also, blocking a change because it's "more important to address issues
>>> such as..." other improvements will further slow down the discussion.
>>> I believe an increase will not prevent the development of other
>>> improvements that we need - in contrast, the sooner we can get over
>>> the limit (which, as you agree, needs to be changed at some point),
>>> the sooner we can get back to work.
>>
>> An increase in block size at this time will exacerbate security concerns around nodes relying on other nodes to validate (particularly miners and wallets). It’s not really a matter of having limited developer resources that need to be budgeted, as you seem to suggest.
>>
>> Regarding developments on properly handling fees, there must exist the economic need for it before there’s an earnest effort to solve it. Increasing the block size right now will, in all likelihood, delay this effort. I’d much prefer to first let the fee market evolve because it’s a crucial component to the protocol’s design and its security model…and so we can get a better sense for fee economics. Then we might be able to figure out better approaches to block size changes in the future that makes sense economically…perhaps with mechanisms that can dynamically adjust it to reflect resource availability and network load.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman <jeanpaulkogelman@me•com> wrote:
>
> You are not going to get a fair fee market if your only form of enforcement is the threat of exclusion.
>
> A more fair fee market will develop if miners start offering quality of service, preferably at multiple tiers. At that point any interference from a block size cap will only be detrimental. In fact it will only highlight what the cap is actually for; to prevent monster blocks.
>
> Add better QoS tools for miners and extend the cap (when possible) and there's your fee market.
>
> jp

> On Jul 23, 2015, at 5:32 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>
>
>> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman <jeanpaulkogelman@me•com> wrote:
>>
>> You are not going to get a fair fee market if your only form of enforcement is the threat of exclusion.
>>
>> A more fair fee market will develop if miners start offering quality of service, preferably at multiple tiers. At that point any interference from a block size cap will only be detrimental. In fact it will only highlight what the cap is actually for; to prevent monster blocks.
>>
>> Add better QoS tools for miners and extend the cap (when possible) and there's your fee market.
>>
>> jp
>
> Not sure what you mean by QoS here. Either your transaction is included or it isn’t. It’s not like you can upgrade to a master suite with a view or anything.

> X satoshi / kb = included in block currently worked on;

> Y satoshi / kb = included in next block;

> Z satoshi / kb = included in block after that, etc.

> On Jul 24, 2015, at 8:32 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>
>
>> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman <jeanpaulkogelman@me•com> wrote:
>>
>> You are not going to get a fair fee market if your only form of enforcement is the threat of exclusion.
>>
>> A more fair fee market will develop if miners start offering quality of service, preferably at multiple tiers. At that point any interference from a block size cap will only be detrimental. In fact it will only highlight what the cap is actually for; to prevent monster blocks.
>>
>> Add better QoS tools for miners and extend the cap (when possible) and there's your fee market.
>>
>> jp
>
> Not sure what you mean by QoS here. Either your transaction is included or it isn’t. It’s not like you can upgrade to a master suite with a view or anything.

> On Jul 24, 2015, at 8:45 AM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> Quality of service as in:
>
>> X satoshi / kb = included in block currently worked on;
>
>> Y satoshi / kb = included in next block;
>
>> Z satoshi / kb = included in block after that, etc.
>
> Block count starts when transaction is first seen. Miners can set X, Y, Z.
>
> Market develops when miners start setting different values and adding more transactions to blocks as opposed to other miners with higher settings.
>
> It basically comes down to the miners themselves if they want a healthy fee market. If they stick to their guns, their influence on the fees will be proportional to their hashing power.
>
> jp
>
>> On Jul 24, 2015, at 8:32 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>
>>
>>> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman <jeanpaulkogelman@me•com> wrote:
>>>
>>> You are not going to get a fair fee market if your only form of enforcement is the threat of exclusion.
>>>
>>> A more fair fee market will develop if miners start offering quality of service, preferably at multiple tiers. At that point any interference from a block size cap will only be detrimental. In fact it will only highlight what the cap is actually for; to prevent monster blocks.
>>>
>>> Add better QoS tools for miners and extend the cap (when possible) and there's your fee market.
>>>
>>> jp
>>
>> Not sure what you mean by QoS here. Either your transaction is included or it isn’t. It’s not like you can upgrade to a master suite with a view or anything.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

>
>And it's obvious how a size cap would interfere with such a QoS scheme.
>Miners wouldn't be able to deliver the below guarantees if they have to
>start excluding transactions.

> On Jul 23, 2015, at 5:45 PM, Jean-Paul Kogelman <jeanpaulkogelman@me•com> wrote:
>
> Quality of service as in:
>
>> X satoshi / kb = included in block currently worked on;
>
>> Y satoshi / kb = included in next block;
>
>> Z satoshi / kb = included in block after that, etc.
>
> Block count starts when transaction is first seen. Miners can set X, Y, Z.
>
> Market develops when miners start setting different values and adding more transactions to blocks as opposed to other miners with higher settings.
>
> It basically comes down to the miners themselves if they want a healthy fee market. If they stick to their guns, their influence on the fees will be proportional to their hashing power.
>
> jp

> On Jul 24, 2015, at 8:53 AM, Peter Todd <pete@petertodd•org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>
>> And it's obvious how a size cap would interfere with such a QoS scheme.
>> Miners wouldn't be able to deliver the below guarantees if they have to
>> start excluding transactions.
>
> As mining is a random, poisson process, obviously giving guarantees without a majority of hashing power isn't possible.
>
>
> -----BEGIN PGP SIGNATURE-----
>
> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
> =LY1+
> -----END PGP SIGNATURE-----
>

> On Jul 24, 2015, at 8:56 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>
>
>> On Jul 23, 2015, at 5:45 PM, Jean-Paul Kogelman <jeanpaulkogelman@me•com> wrote:
>>
>> Quality of service as in:
>>
>>> X satoshi / kb = included in block currently worked on;
>>
>>> Y satoshi / kb = included in next block;
>>
>>> Z satoshi / kb = included in block after that, etc.
>>
>> Block count starts when transaction is first seen. Miners can set X, Y, Z.
>>
>> Market develops when miners start setting different values and adding more transactions to blocks as opposed to other miners with higher settings.
>>
>> It basically comes down to the miners themselves if they want a healthy fee market. If they stick to their guns, their influence on the fees will be proportional to their hashing power.
>>
>> jp
>
>
> The scheme I’ve been considering is the use of services (separate from miners) that guarantee inclusion for you for some predetermined price and then do the bidding on your behalf. Via contracts you can guarantee you get included within a certain number of blocks or you receive a full refund…or even possibly receive compensation for failure to deliver.

> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>
> Doesn't matter.
>
> It's not going to be perfect given the block time variance among other factors but it's far more workable than guessing whether or not your transaction is going to end up in a block at all.
>
> jp
>
>
>> On Jul 24, 2015, at 8:53 AM, Peter Todd <pete@petertodd•org> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>>
>>
>>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>>
>>> And it's obvious how a size cap would interfere with such a QoS scheme.
>>> Miners wouldn't be able to deliver the below guarantees if they have to
>>> start excluding transactions.
>>
>> As mining is a random, poisson process, obviously giving guarantees without a majority of hashing power isn't possible.
>>
>>
>> -----BEGIN PGP SIGNATURE-----
>>
>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
>> =LY1+
>> -----END PGP SIGNATURE-----
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

> On Jul 24, 2015, at 9:08 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>
> By using third parties separate from individual miners that do bidding on your behalf you get a mechanism that allows QoS guarantees and shifting the complexity and risk from the wallet with little computational resources to a service with abundance of them. Using timelocked contracts it’s possible to enforce the guarantees.
>
> Negotiating directly with miners via smart contracts seems difficult at best.
>
>
>> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>
>> Doesn't matter.
>>
>> It's not going to be perfect given the block time variance among other factors but it's far more workable than guessing whether or not your transaction is going to end up in a block at all.
>>
>> jp
>>
>>
>>> On Jul 24, 2015, at 8:53 AM, Peter Todd <pete@petertodd•org> wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>>
>>>
>>>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>>>
>>>> And it's obvious how a size cap would interfere with such a QoS scheme.
>>>> Miners wouldn't be able to deliver the below guarantees if they have to
>>>> start excluding transactions.
>>>
>>> As mining is a random, poisson process, obviously giving guarantees without a majority of hashing power isn't possible.
>>>
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>>
>>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
>>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
>>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
>>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
>>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
>>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
>>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
>>> =LY1+
>>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> On Jul 23, 2015, at 6:25 PM, Jean-Paul Kogelman <jeanpaulkogelman@me•com> wrote:
>
> I think implicit QoS is far simpler to implement, requires less parties and is closer to what Bitcoin started out as: a peer-to-peer digital cash system, not a peer-to-let-me-handle-that-for-you-to-peer system.
>
> jp
>
>> On Jul 24, 2015, at 9:08 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>
>> By using third parties separate from individual miners that do bidding on your behalf you get a mechanism that allows QoS guarantees and shifting the complexity and risk from the wallet with little computational resources to a service with abundance of them. Using timelocked contracts it’s possible to enforce the guarantees.
>>
>> Negotiating directly with miners via smart contracts seems difficult at best.
>>
>>
>>> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>>
>>> Doesn't matter.
>>>
>>> It's not going to be perfect given the block time variance among other factors but it's far more workable than guessing whether or not your transaction is going to end up in a block at all.
>>>
>>> jp
>>>
>>>
>>>> On Jul 24, 2015, at 8:53 AM, Peter Todd <pete@petertodd•org> wrote:
>>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA256
>>>>
>>>>
>>>>
>>>>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>>>>
>>>>> And it's obvious how a size cap would interfere with such a QoS scheme.
>>>>> Miners wouldn't be able to deliver the below guarantees if they have to
>>>>> start excluding transactions.
>>>>
>>>> As mining is a random, poisson process, obviously giving guarantees without a majority of hashing power isn't possible.
>>>>
>>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>>
>>>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
>>>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
>>>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
>>>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
>>>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
>>>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
>>>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
>>>> =LY1+
>>>> -----END PGP SIGNATURE-----
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists•linuxfoundation•org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>

> On Jul 23, 2015, at 6:28 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>
> I suppose you can use a timelocked output that is spendable by anyone you could go somewhat in this direction…the thing is it still means the wallet must make fee estimations rather than being able to get a quick quote.
>
>> On Jul 23, 2015, at 6:25 PM, Jean-Paul Kogelman <jeanpaulkogelman@me•com> wrote:
>>
>> I think implicit QoS is far simpler to implement, requires less parties and is closer to what Bitcoin started out as: a peer-to-peer digital cash system, not a peer-to-let-me-handle-that-for-you-to-peer system.
>>
>> jp
>>
>>> On Jul 24, 2015, at 9:08 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>>
>>> By using third parties separate from individual miners that do bidding on your behalf you get a mechanism that allows QoS guarantees and shifting the complexity and risk from the wallet with little computational resources to a service with abundance of them. Using timelocked contracts it’s possible to enforce the guarantees.
>>>
>>> Negotiating directly with miners via smart contracts seems difficult at best.
>>>
>>>
>>>> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>>>
>>>> Doesn't matter.
>>>>
>>>> It's not going to be perfect given the block time variance among other factors but it's far more workable than guessing whether or not your transaction is going to end up in a block at all.
>>>>
>>>> jp
>>>>
>>>>
>>>>> On Jul 24, 2015, at 8:53 AM, Peter Todd <pete@petertodd•org> wrote:
>>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA256
>>>>>
>>>>>
>>>>>
>>>>>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>>>>>
>>>>>> And it's obvious how a size cap would interfere with such a QoS scheme.
>>>>>> Miners wouldn't be able to deliver the below guarantees if they have to
>>>>>> start excluding transactions.
>>>>>
>>>>> As mining is a random, poisson process, obviously giving guarantees without a majority of hashing power isn't possible.
>>>>>
>>>>>
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>
>>>>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
>>>>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
>>>>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
>>>>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
>>>>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
>>>>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
>>>>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
>>>>> =LY1+
>>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists•linuxfoundation•org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>

> On Jul 24, 2015, at 9:28 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>
> I suppose you can use a timelocked output that is spendable by anyone you could go somewhat in this direction…the thing is it still means the wallet must make fee estimations rather than being able to get a quick quote.
>
>> On Jul 23, 2015, at 6:25 PM, Jean-Paul Kogelman <jeanpaulkogelman@me•com> wrote:
>>
>> I think implicit QoS is far simpler to implement, requires less parties and is closer to what Bitcoin started out as: a peer-to-peer digital cash system, not a peer-to-let-me-handle-that-for-you-to-peer system.
>>
>> jp
>>
>>> On Jul 24, 2015, at 9:08 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>>
>>> By using third parties separate from individual miners that do bidding on your behalf you get a mechanism that allows QoS guarantees and shifting the complexity and risk from the wallet with little computational resources to a service with abundance of them. Using timelocked contracts it’s possible to enforce the guarantees.
>>>
>>> Negotiating directly with miners via smart contracts seems difficult at best.
>>>
>>>
>>>> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>>>
>>>> Doesn't matter.
>>>>
>>>> It's not going to be perfect given the block time variance among other factors but it's far more workable than guessing whether or not your transaction is going to end up in a block at all.
>>>>
>>>> jp
>>>>
>>>>
>>>>> On Jul 24, 2015, at 8:53 AM, Peter Todd <pete@petertodd•org> wrote:
>>>>>
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA256
>>>>>
>>>>>
>>>>>
>>>>>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>>>>>
>>>>>> And it's obvious how a size cap would interfere with such a QoS scheme.
>>>>>> Miners wouldn't be able to deliver the below guarantees if they have to
>>>>>> start excluding transactions.
>>>>>
>>>>> As mining is a random, poisson process, obviously giving guarantees without a majority of hashing power isn't possible.
>>>>>
>>>>>
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>
>>>>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
>>>>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
>>>>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
>>>>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
>>>>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
>>>>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
>>>>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
>>>>> =LY1+
>>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists•linuxfoundation•org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> On Jul 23, 2015, at 6:42 PM, Jean-Paul Kogelman <jeanpaulkogelman@me•com> wrote:
>
> Miners could include their fee tiers in the coinbase, but this is obviously open to manipulation, with little recourse (unless they are a pool and miners move away because of it).
>
> In any event, I think that trying out a solution that is both simple and involves the least number of parties necessary is preferable.
>
> Have miners set their tiers, have users select the level of quality they want, ignore the block size.
>
> Miners will adapt their tiers depending on how many transactions actually end up in them. If for example they set the first tier to be $1 to be included in the current block and no user chooses that level of service, they've obviously priced themselves out of the market. The opposite is also true; if a tier is popular they can choose to increase the cost of that tier.
>
> jp
>
>> On Jul 24, 2015, at 9:28 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>
>> I suppose you can use a timelocked output that is spendable by anyone you could go somewhat in this direction…the thing is it still means the wallet must make fee estimations rather than being able to get a quick quote.
>>
>>> On Jul 23, 2015, at 6:25 PM, Jean-Paul Kogelman <jeanpaulkogelman@me•com> wrote:
>>>
>>> I think implicit QoS is far simpler to implement, requires less parties and is closer to what Bitcoin started out as: a peer-to-peer digital cash system, not a peer-to-let-me-handle-that-for-you-to-peer system.
>>>
>>> jp
>>>
>>>> On Jul 24, 2015, at 9:08 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>>>
>>>> By using third parties separate from individual miners that do bidding on your behalf you get a mechanism that allows QoS guarantees and shifting the complexity and risk from the wallet with little computational resources to a service with abundance of them. Using timelocked contracts it’s possible to enforce the guarantees.
>>>>
>>>> Negotiating directly with miners via smart contracts seems difficult at best.
>>>>
>>>>
>>>>> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>>>>
>>>>> Doesn't matter.
>>>>>
>>>>> It's not going to be perfect given the block time variance among other factors but it's far more workable than guessing whether or not your transaction is going to end up in a block at all.
>>>>>
>>>>> jp
>>>>>
>>>>>
>>>>>> On Jul 24, 2015, at 8:53 AM, Peter Todd <pete@petertodd•org> wrote:
>>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA256
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
>>>>>>>
>>>>>>> And it's obvious how a size cap would interfere with such a QoS scheme.
>>>>>>> Miners wouldn't be able to deliver the below guarantees if they have to
>>>>>>> start excluding transactions.
>>>>>>
>>>>>> As mining is a random, poisson process, obviously giving guarantees without a majority of hashing power isn't possible.
>>>>>>
>>>>>>
>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>>
>>>>>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
>>>>>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
>>>>>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
>>>>>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
>>>>>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
>>>>>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
>>>>>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
>>>>>> =LY1+
>>>>>> -----END PGP SIGNATURE-----
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev@lists•linuxfoundation•org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>

> We know perfectly well that the system will need to eventually be
> sustained by fees.

> I just disagree that changing a constant is a "scaling solution".
>

> There is now a pull request to remove mention of "zero or low
> fees", "fast international payments", and "instant peer-to-peer
> transactions" from bitcoin.org.  For those non-technical users who
> do not read source code, this may come across as the breaking of
> the social contract on what Bitcoin is ultimately intended to be.
> It looks like we already have a Reddit post on the subject as
> well.

>
> On 7/23/2015 10:51 AM, Jorge Timón wrote:
> > We know perfectly well that the system will need to eventually be
> > sustained by fees.
>
> Fee revenue can rise just as easily without increased BTC fee rates.
>
> Two avenues that are just as effective: increased exchange rate,
> increased number of fee-paying transactions.  Neither of these avenues
> benefits from increased "fee pressure" (scarcity of block space).
>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> > There is now a pull request to remove mention of "zero or low
> > fees", "fast international payments", and "instant peer-to-peer
> > transactions" from bitcoin.org.  For those non-technical users who
> > do not read source code, this may come across as the breaking of
> > the social contract on what Bitcoin is ultimately intended to be.
> > It looks like we already have a Reddit post on the subject as
> > well.
>
> This PR makes absolutely sense.
> A documentation or description should reflect how a system works NOW.
> Not how it *was working and how it *might work once.
>
> The concept of free transaction just doens't really work well with the
> current system and advertising bitcoin with "free transaction" is
> missleading.
>
> /jonas
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJVsfvOAAoJECnUvLZBb1PseawP/1KrqKw5IGKUHmTf1E+oOLmq
> nD7c1JekBGrJc7Lk0PfKZqS21aQZIt145DnFPv//u/C43x3zt7QSggMNSVYJmI85
> AnrTRRP18TBGDm9CwVFjTbZ4tY/sRoDX9XMDBtlGDdAABX47C493PEI9pXZ5pRc7
> cuLsSTKNqQdJgl3vUydfwddgaaVKPWN+zO72lZVo/edrUwzpjqjO3tu/+36ytto7
> Ebm/vxOT+afrcFfAt3ZwuSwx7uiVoqsVRAwV1LWobod2wejpkUxf7Qkb1XRraSEV
> m2opX6UAmPc3emKP+nT2ufDUM3z8YnW1WgjGB6UDXcCge+X5B7aXICI+qOzVR5Ck
> djf4XMY9gXku26K72zk27XxmutajAYzsFvFbhm+HYa1q9yKRvDg8A9hYZ/6sKPQD
> s6Hn3jou75YVz0mLpAKP7hkP7AmzOkS2gq/M/6SL3Fq+B3mObRMhpMgcpebzT2Oq
> p7vLuh5OejcBX7VasVeodAEh9BkTJH9ll72QaJ63C4AjZ1Si87CnijIf8ACmmSxQ
> wImwWs7aH0/x8xwxrpZzvVTf0/4hrPu5St6IMhz0DZlEaKJ/Rg6gI2/UKy/jma6u
> 6uVEGBft4eJH+zQN1Ddral5d56P3DSW7ClLLjiMXx1NpB2U1XAWDXNybqYIrSlvX
> ej0qto4XVj20K3JS3CMl
> =e71j
> -----END PGP SIGNATURE-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

> Regarding "increasing the exchange rate" it would be really nice to
> just push a button and double bitcoin's price just before the next
> subsidy halving, but unfortunately that's something out of our control.

>
> "Fast transactions"
> Fast transactions implies it is slower than Visa, and Visa is
> 'instant' by comparison from the spender's POV. Bitcoin is still very
> instant because wallets still send notifications/pings when
> transactions are first seen, not when it goes into a block. We
> shouldn't mislead people into thinking a transaction literally takes
> 10 minutes to travel the globe.
>
> Maybe this feels like PR speak. But being too humble about Bitcoin's
> attributes isn't a good idea either.
>
> If we're going to look at perception, image and expectations, perhaps
> we can start to look at redefining some terminology too. Like
> confirmations, which is an arbitrary concept. Where possible we should
> describe it with finance terminology.
>
> "0 conf transaction"
> 0 conf is the 'transaction' - just the act of making an exchange. It
> doesn't imply safe and I believe using the word 'settle' in place of
> confirmations will automatically click with merchants.
>
> "1st conf"
> A 'confirmation' is a 'settlement'. If it is 'settled', it implies
> final (except by court order), whereas confirmation usually means 'ah,
> I've seen it come through'. I rarely hear any sales clerk call credit
> card transactions confirmed. More often you will hear 'approved'
> instead. Although 1st conf can be overtaken, so...
>
> "n confirmations"
> This term can probably stay since I can't come up with a better word.
> Settlements only happen once, putting a number next to it breaks the
> meaning of the word. "Settled with 4 confirmations" seems pretty
> clear. Alternatively I think instead of displaying a meaningless
> number we ought to go by a percentage (the double spend improbability)
> and go by 'confidence'. "Settled with 92% confidence." Or we can pick
> an arbitrary number like 6 and use 'settling...' and 'settled' when
> reached.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

> Sent: Saturday, July 25, 2015 at 4:18 AM
> From: "gb via bitcoin-dev" <bitcoin-dev@lists•linuxfoundation•org>
> To: "Vincent Truong" <vincent.truong@procabiak•com>
> Cc: bitcoin-dev@lists•linuxfoundation•org
> Subject: Re: [bitcoin-dev] Bitcoin, Perceptions, and Expectations
>
>
> Validated - (seen on network)
>
> Settled/Cleared - 1 conf
>
> Finalised - 6 confs
>

>
> Validated - (seen on network)
>
> Settled/Cleared - 1 conf
>
> Finalised - 6 confs
>
> On Sat, 2015-07-25 at 00:37 +1000, Vincent Truong via bitcoin-dev wrote:
>>
>> "Fast transactions"
>> Fast transactions implies it is slower than Visa, and Visa is
>> 'instant' by comparison from the spender's POV. Bitcoin is still very
>> instant because wallets still send notifications/pings when
>> transactions are first seen, not when it goes into a block. We
>> shouldn't mislead people into thinking a transaction literally takes
>> 10 minutes to travel the globe.
>>
>> Maybe this feels like PR speak. But being too humble about Bitcoin's
>> attributes isn't a good idea either.
>>
>> If we're going to look at perception, image and expectations, perhaps
>> we can start to look at redefining some terminology too. Like
>> confirmations, which is an arbitrary concept. Where possible we should
>> describe it with finance terminology.
>>
>> "0 conf transaction"
>> 0 conf is the 'transaction' - just the act of making an exchange. It
>> doesn't imply safe and I believe using the word 'settle' in place of
>> confirmations will automatically click with merchants.
>>
>> "1st conf"
>> A 'confirmation' is a 'settlement'. If it is 'settled', it implies
>> final (except by court order), whereas confirmation usually means 'ah,
>> I've seen it come through'. I rarely hear any sales clerk call credit
>> card transactions confirmed. More often you will hear 'approved'
>> instead. Although 1st conf can be overtaken, so...
>>
>> "n confirmations"
>> This term can probably stay since I can't come up with a better word.
>> Settlements only happen once, putting a number next to it breaks the
>> meaning of the word. "Settled with 4 confirmations" seems pretty
>> clear. Alternatively I think instead of displaying a meaningless
>> number we ought to go by a percentage (the double spend improbability)
>> and go by 'confidence'. "Settled with 92% confidence." Or we can pick
>> an arbitrary number like 6 and use 'settling...' and 'settled' when
>> reached.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

> Hello all,
>
> I'd like to talk a bit about my view on the relation between the Bitcoin
> Core project, and the consensus rules of Bitcoin.
>
> I believe it is the responsibility of the maintainers/developers of Bitcoin
> Core to create software which helps guarantee the security and operation of
> the Bitcoin network.
>
> In addition to normal software maintenance, bug fixes and performance
> improvements, this includes DoS protection mechanism deemed necessary to
> keep the network operational. Sometimes, such (per-node configurable)
> policies have had economic impact, for example the dust rule.
>
> This also includes participating in discussions about consensus changes,
> but not the responsibility to decide on them - only to implement them when
> agreed upon. It would be irresponsible and dangerous to the network and
> thus the users of the software to risk forks, or to take a leading role in
> pushing dramatic changes. Bitcoin Core developers obviously have the
> ability to make any changes to the codebase or its releases, but it is
> still up to the community to choose to run that code.
>
> Some people have called the prospect of limited block space and the
> development of a fee market a change in policy compared to the past. I
> respectfully disagree with that. Bitcoin Core is not running the Bitcoin
> economy, and its developers have no authority to set its rules. Change in
> economics is always happening, and should be expected. Worse, intervening
> in consensus changes would make the ecosystem more dependent on the group
> taking that decision, not less.
>
> So to point out what I consider obvious: if Bitcoin requires central
> control over its rules by a group of developers, it is completely
> uninteresting to me. Consensus changes should be done using consensus, and
> the default in case of controversy is no change.

> ===
>
> My personal opinion is that we - as a community - should indeed let a fee
> market develop, and rather sooner than later, and that "kicking the can
> down the road" is an incredibly dangerous precedent: if we are willing to
> go through the risk of a hard fork because of a fear of change of
> economics, then I believe that community is not ready to deal with change
> at all. And some change is inevitable, at any block size. Again, this does
> not mean the block size needs to be fixed forever, but its intent should be
> growing with the evolution of technology, not a panic reaction because a
> fear of change.

> The ugly thing is I think everyone in this process recognises the
> meta-consensus nature of the debate already. Notice how Gavin Andresen's
> initial blocksize posts were in the form of a non-technical blog, making
> non-technical arguments to the public - not the Core dev team - in ways
> not conducive to open response.  A rather annoying example is Jeff
> Garzik's recent efforts: a fundementally broken troll pull-req raising
> the blocksize to 2MB that simply can't be merged for reasons unrelated
> to the blocksize, followed by very public and loud efforts to spin a
> non-issue - closing a pull-req that had no real impact on blockchain
> capacity - into a broader reddit furor over a "changed" policy on
> scaling. As a PR effort to the public this was fairly effective: framing
> the Core dev team's actions as a change and raising the blocksize as a
> default action puts the team on the defensive. As a way of building
> consensus among the Core dev team, Garzik's actions are very
> counterproductive.

> You are correct.  It is also counterproductive to take cheap shots at
> vendors in order to garner consulting revenue.  Measuring risk in a
> systematic way against known metrics is the way to go.  Tweeting,
> blogging, and drama are generally counterproductive.
>
> When the issue is raised most of the developers shun the idea so until
> some of the developers become mature and experienced you will be left
> with all this teenager nonsense where everybody calls each other
> "trolls" on Reddit instead of engaging in real risk analysis.

> The twitter teenage nonsense from Todd is ridiculous:
> https://twitter.com/playatodd (warning, triggering)

> On 7/24/2015 2:24 AM, Jorge Timón wrote:
>
>> Regarding "increasing the exchange rate" it would be really nice to
>> just push a button and double bitcoin's price just before the next
>> subsidy halving, but unfortunately that's something out of our control.
>
> Jorge, right now, from the activity on github, you are working at least
> as hard as anyone else, probably harder.

> Why?  Why, if not to make
> bitcoin more valuable?

> Even apart from the convenience/curse of real-time exchange markets,
> just with an abstract definition of "value," isn't that exactly what a
> developer can influence, if not "control?"

> Isn't figuring out ways to increase the value of bitcoin what we are doing?

> Jorge,
>
> We obviously disagree fundamentally on the role of societal adoption, in
> the system that Satoshi designed.
>
> Adoption is well ahead of Satoshi's schedule, and the measure of this is
> the exchange rate.  It is at once an imperfect measure, and one of the most
> perfect markets that has ever existed.
>
> As long as hardware, electric power, and bandwidth are priced in fiat
> currency, the exchange rate is a critical variable to security, capacity,
> and other metrics of network health.
>
> It's not inconsistent that you consider the exchange rate irrelevant.  In
> fact it explains why you believe that Satoshi's timetable for transitioning
> to fee incentives can be summarily tossed aside and replaced with something
> you think is better.
>
> Here's an English saying I just invented.  A bunch of geniuses can do a
> lot more damage than one fool.
>
>