[bitcoin-dev] Bitcoin Core and hard forks

[Pieter Wuille via 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.

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

[Ross Nicoll via bitcoin-dev]

So, if consensus shouldn't really be between the developers (which is
fine), should we empower users to control consensus? I've been working
on a fork framework anyway, which can support reasonably arbitrary
consensus changes (currently against block height, but moving towards
block time). Theoretically it could be modified to load consensus
parameters (which block size would have to be added to) from disk at
startup, rather than having them hard-coded.

Is that considered desirable? Will raise as a PR if so. If not, where do
we draw a line between developer and user consensus?

Ross

On 22/07/2015 17:52, Pieter Wuille via bitcoin-dev wrote:
>
> 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-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Milly Bitcoin via bitcoin-dev]

>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

[Bryan Cheng via bitcoin-dev]

Pieter, I agree with the overall gist of your statement (that Bitcoin is a
consensus-driven protocol that's incompatible with certain forms of central
governance) but I respectfully disagree with some of the conclusions you're
drawing.

> Consensus changes should be done using consensus, _and the default in
case of controversy is no change_.

(emphasis mine)

I think that there's a disconnect between the idea that Bitcoin Core making
a consensus-driven change in turn means that the network is being forced
down a certain path. This takes away a great deal of the individual agency
that makes Bitcoin what it is today. 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. (For example, re: block sizes,
if the majority of hashing power remains on a version or fork that does not
mine >1MB blocks, a chain of <1MB blocks will continue to be the longest,
and up to date clients will still respect that. That is consensus at work,
pure and simple.)

Obviously Core is in a unique position as a reference client and ignoring
that would be irresponsible. If broad consensus among the developers cannot
be reached, then Core should not make a given change. However, freezing
Core's ability to make changes in light of _any_ controversy is allowing a
few voices to dictate direction and is counter to any kind of
consensus-driven decision making.

Placing Core and its developers on some sort of pedestal where we believe
that they dictate policy and therefore shouldn't be allowed to take any
risks will create the very situation that you're advocating against- that a
small group of developers have control over Bitcoin's policies. Instead, we
should strive to treat Core as _just another Bitcoin Client_, we should
educate users to make informed choices about the version of software they
are running and the choices implicit in that, and we should allow consensus
at the protocol level to make the decisions on the overall direction of the
network.

> My personal opinion is that we - as a community - should indeed let a fee
market develop, and rather sooner than later

I will keep this brief because this is straying off topic of the idea of
this thread- but I don't believe that increasing Bitcoin's capacity as a
network is inherently incompatible with the development of a fee market,
and considering a fee market to be formed of only a single set of variables
(transaction rate versus block size) is not sound economic analysis.

On Wed, Jul 22, 2015 at 10:32 AM, Milly Bitcoin via bitcoin-dev <
bitcoin-***@lists.linuxfoundation.org> wrote:

> 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-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[Jeff Garzik via bitcoin-dev]

On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev <
bitcoin-***@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.

[Alex Morcos via bitcoin-dev]

Jeff I respectively disagree with many of your points, but let me just
point out 2.

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?

I know you respect Pieter's work, so I don't want to twist your words, but
for the clarity of other people reading these posts, it sounds like you're
accusing Pieter and others of stonewalling size increases and not
participating in planning for them. Without debate, no one has done more
for this project to make eventual size increases technically feasible than
Pieter. We only have the privilege of even having this debate as a result
of his work.



On Wed, Jul 22, 2015 at 1:33 PM, Jeff Garzik via bitcoin-dev <
bitcoin-***@lists.linuxfoundation.org> wrote:

> On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev <
> bitcoin-***@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-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[Jeff Garzik via bitcoin-dev]

On Wed, Jul 22, 2015 at 11:03 AM, Alex Morcos <***@gmail.com> wrote:

> 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?
>

There is a vast difference between what software developers have been
chattering about in the background versus what the users actually
experience in the field.

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.

This new policy should be debated and consensus achieved, not simply rolled
out by fiat without user notification.

Otherwise it is engaging in precisely the economic wizardry that this
thread opened with decrying.

Just like block size, there are multiple sides to the fee market debate.
However, Bitcoin Core has (unfortunately) outsized decision making power in
that simply avoiding progress on block size limit will achieve the "let a
fee market develop" economic policy change. Ironic but true - sitting
around and doing nothing dumps users into a new economic policy.

[Jorge Timón via bitcoin-dev]

On Wed, Jul 22, 2015 at 8:24 PM, Jeff Garzik via bitcoin-dev
<bitcoin-***@lists.linuxfoundation.org> wrote:
> 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

That's because demand for space (transactions) was always lower than
the supply (block space) and no market price (fees) arose.
Now the market (not the supply) has changed: demand has increased.
With a fixed supply, it was perfectly reasonable to expect that fees
would rise (from zero).
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.

> 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.

It is not a new economic policy, it is a new market situation. Please,
stop saying that.

> 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.

If "not now", then when?
I've been asking that question repeatedly and the closest to an answer
that I got from the "not now side" was "the hashrate being paid by
fees instead of subsidy it's too far away in the future to worry about
it now".
That answer is not very satisfying to me.

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

Yes, business plans that rely on free in-chain transactions may fail,
business plans that are planning for a future with fees and without
subsidies may get the advantage they deserve. But "kicking the can" is
just picking winners and losers in opposite way.
You seem to imply that rewarding inertia and laziness is the best
option for short-term bitcoin adoption and you may be right.
I simply think these arguments shouldn't be considered at all: the
criteria for the consensus block size should be purely based on
technological capacity (propagation benchmarking, etc) and
centralization concerns (those in the "not now side" have already seen
this 2-year-old video[1], right?).
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've even read that the consensus limit "was just a
temporary measure". Then Gavin lowers his 32 GB limit to an 8 GB
"compromise".
Maybe I'm being paranoid, but I'm really afraid that when the "not
now side" wins this battle (like they've won for 6 years, as you say)
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?

[1] https://www.youtube.com/watch?v=cZp7UGgBR0I

[Tom Harding via bitcoin-dev]

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.

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.

[Gavin Andresen via bitcoin-dev]

On Thu, Jul 23, 2015 at 12:17 PM, Tom Harding via bitcoin-dev <
bitcoin-***@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

[cipher anthem via bitcoin-dev]

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

[Robert Learney via bitcoin-dev]

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.

-Rob.

> On 23 Jul 2015, at 17:50, cipher anthem via bitcoin-dev <bitcoin-***@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-***@lists.linuxfoundation.org>
> To: "Tom Harding" <***@thinlink.com>
> Cc: bitcoin-***@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-***@lists.linuxfoundation.org <x-msg://14/bitcoin-***@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-***@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>_______________________________________________
> bitcoin-dev mailing list
> bitcoin-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Eric Lombrozo via bitcoin-dev]

> On Jul 23, 2015, at 10:14 AM, Robert Learney via bitcoin-dev <bitcoin-***@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.

The issue isn’t really whether it’s 1MB or 2MB or 4MB or 8MB or whatever. First of all, the burden of justifying this change should be on those proposing a hardfork. The default is to not have a hard fork. Second of all, it’s not really about *whether* the block size is increased
but about *when* and *how* it is increased. There’s a good argument to be made that right now it is more important to address issues such as the fact that validation is so expensive (which as others and myself have pointed out has led to a collapse of the security model in the past, requiring manual intervention to temporarily “fix”)
and the fact that we don’t yet have great solutions to dealing with fees, which are a crucial component of the design of the protocol.

[Jorge Timón via bitcoin-dev]

On Thu, Jul 23, 2015 at 7:14 PM, Robert Learney via bitcoin-dev
<bitcoin-***@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.

His proposals actually end up with 20 GB and 8 GB respectively. I'm
not sure if you count me on the ‘1Mb or bust’ group, but I'm not
firmly stuck anywhere.
I've never said that the block size should never be increased, that it
shouldn't change now, that 8 MB is too much or anything like that
because I simply don't have the data (and I don't think anybody has
it). I invite people to collect that data and I've written a patch to
bitcoin to facilitate that task.
Do you really think that's an obstructionist attitude?

My position could be summarized like this:

- We're going to hit the limit tomorrow, and Bitcoin will fail when we do.
- I'm not so sure we will hit the limit tomorrow but even accepting
the premise, this is a non sequitur. Fees will probably rise, but
that's not necessarily a bad thing. A limit that is meaningful in
practice must happen eventually, mustn't it? If not now, when are we
planning to let that "disaster" happen?
- That's too far in the future to worry about it.
- Does that mean waiting, say, 4 more subsidy halvings, 8? 10?
- Just don't worry about it

I'm not opposing to anything, I'm just patiently waiting for some
answers that never seem to arrive.
If people interpret questions or the fact that when people use
fallacious arguments I like to identify the concrete fallacy they're
using and state it so publicly (I do it for sport and "against all
sides") as "opposition", I don't really think I can do anything about
it.

[Eric Lombrozo via bitcoin-dev]

> On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev <bitcoin-***@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.

Increasing block size only temporarily addresses one significant issue - 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-***@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-***@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

[Jameson Lopp via bitcoin-dev]

On Thu, Jul 23, 2015 at 1:43 PM, Eric Lombrozo via bitcoin-dev <
bitcoin-***@lists.linuxfoundation.org> wrote:

>
> On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev <
> bitcoin-***@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.
>
>
Increasing block size only temporarily addresses one significant issue -
> 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.
>
>
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.

- Jameson

> On Jul 23, 2015, at 9:50 AM, cipher anthem via bitcoin-dev <
> bitcoin-***@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-***@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-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[Eric Lombrozo via bitcoin-dev]

> On Jul 23, 2015, at 11:10 AM, 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.

[Gavin Andresen via bitcoin-dev]

On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo <***@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

[Eric Lombrozo via bitcoin-dev]

> On Jul 23, 2015, at 12:35 PM, Gavin Andresen <***@gmail.com> wrote:
>
>
> On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo <***@gmail.com <mailto:***@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
>

Regarding rhetoric, fair enough, Gavin - I’m human and I could be wrong. It is my educated best guess, a conclusion I’ve drawn given my understanding of computer science, economics, and what’s been happening in this space.

[Eric Lombrozo via bitcoin-dev]

> On Jul 23, 2015, at 12:35 PM, Gavin Andresen <***@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).

I also wanted to point out I fully agree with you that there are still many optimizations we could do to reduce costs, and think many of these things are certainly worth doing. However, there’s only so much we can do in this regard. Sooner or later we still run up against theoretical limitations. These optimizations can reduce costs by some factor
but they are highly unlikely to overcome the Ω(n) validation complexity barring some major algorithmic breakthrough (and perhaps allowing for nondeterminism, perhaps accepting a negligible but finite error probability).

[Jameson Lopp via bitcoin-dev]

On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo <***@gmail.com> wrote:

>
> On Jul 23, 2015, at 11:10 AM, 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.
>

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.

- Jameson

>
> 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.
>

[Jorge Timón via bitcoin-dev]

On Thu, Jul 23, 2015 at 9:52 PM, Jameson Lopp via bitcoin-dev
<bitcoin-***@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.

[Eric Lombrozo via bitcoin-dev]

> On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo <***@gmail.com <mailto:***@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.cc> wrote:
>
> On Thu, Jul 23, 2015 at 9:52 PM, Jameson Lopp via bitcoin-dev
> <bitcoin-***@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.

[Benedict Chan via bitcoin-dev]

On Thu, Jul 23, 2015 at 1:52 PM, Eric Lombrozo via bitcoin-dev
<bitcoin-***@lists.linuxfoundation.org> wrote:
> On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo <***@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.
>

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 1:26 PM, Jorge Timón <***@jtimon.cc> wrote:
>
> On Thu, Jul 23, 2015 at 9:52 PM, Jameson Lopp via bitcoin-dev
> <bitcoin-***@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-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[Eric Lombrozo via bitcoin-dev]

> On Jul 23, 2015, at 4:42 PM, Benedict Chan <***@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.

[Eric Lombrozo via bitcoin-dev]

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 <***@gmail.com> wrote:
>
>
>> On Jul 23, 2015, at 4:42 PM, Benedict Chan <***@fragnetics.com <mailto:***@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.

[Simon Liu via bitcoin-dev]

Increasing the block size does not hinder research and development of
Lightning or other technologies.


On 07/23/2015 05:04 PM, Eric Lombrozo via bitcoin-dev 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.
>

[Jean-Paul Kogelman via bitcoin-dev]

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 24, 2015, at 8:04 AM, Eric Lombrozo via bitcoin-dev <bitcoin-***@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 <***@gmail.com> wrote:
>>>
>>>
>>> On Jul 23, 2015, at 4:42 PM, Benedict Chan <***@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-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Eric Lombrozo via bitcoin-dev]

> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman <***@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.

[Eric Lombrozo via bitcoin-dev]

Are you referring to mining contracts?

> On Jul 23, 2015, at 5:32 PM, Eric Lombrozo <***@gmail.com> wrote:
>
>
>> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman <***@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.

[Jean-Paul Kogelman via bitcoin-dev]

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 <***@gmail.com> wrote:
>
>
>> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman <***@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.

[Jean-Paul Kogelman via 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 24, 2015, at 8:45 AM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-***@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 <***@gmail.com> wrote:
>>
>>
>>> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman <***@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-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Peter Todd via bitcoin-dev]

On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev <bitcoin-***@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.

[Jean-Paul Kogelman via bitcoin-dev]

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 <***@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-***@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-----
>

[Eric Lombrozo via bitcoin-dev]

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-***@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 <***@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-***@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-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Jean-Paul Kogelman via bitcoin-dev]

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 <***@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-***@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 <***@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-***@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-***@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[Eric Lombrozo via bitcoin-dev]

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 <***@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 <***@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-***@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 <***@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-***@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-***@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>

[Eric Lombrozo via bitcoin-dev]

I think it’s pretty clear by now that the assumption that all nodes have pretty similar computational resources leads to very misplaced incentives. Ultimately, cryptocurrencies will allow direct outsourcing of computation, making it possible to distribute computational tasks in an economically sensible way.

Wallets should be assumed to have low computational resources and intermittent Internet connections for the foreseeable future if we ever intend for this to be a practical payment system, methinks.


> On Jul 23, 2015, at 6:28 PM, Eric Lombrozo <***@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 <***@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 <***@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-***@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 <***@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-***@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-***@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>

[Jean-Paul Kogelman via bitcoin-dev]

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 <***@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 <***@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 <***@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-***@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 <***@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-***@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-***@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[Eric Lombrozo via bitcoin-dev]

I agree that the fewer the necessary parties the better - however, some entities are much better positioned to offer certain services on the network than others - and the fact we can trustlessly negotiate smart contracts with them is one of the most significant developments in the cryptospace - it’s one of the most revolutionary aspects of this technology
it accomplishes something we’ve never really been able to do before.

Notice that third parties can encapsulate complex tasks and provide a far simpler interface. Crypto contracts provide the incentives for them to do this. And by having competition and transparency, these services automatically get optimized via human ingenuity. We don’t need to design top-down for it.

> On Jul 23, 2015, at 6:42 PM, Jean-Paul Kogelman <***@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 <***@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 <***@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 <***@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-***@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 <***@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-***@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-***@lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>

[Raystonn . via bitcoin-dev]

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.

Raystonn

[Jonas Schnelli via bitcoin-dev]

> 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

[Jorge Timón via bitcoin-dev]

Well, I think "fast international transactions" is still true. An hour is
pretty fast when you compare it with several days. But yeah, "free" and
"instant" are misleading words.
Low fees may be ok. One thing that is not mentioned often is that the fact
that the system is p2p is what makes transactions irreversible (otherwise a
court order can tell any centralized server to cancel any transaction).
Irreversible transactions don't need proportional fees, because there's
nothing being ensured and the amount being moved is irrelevant. So even if
we have a future with 5 usd fees, that's still a very low fee for moving,
say 1 M usd worth of btc. So I'm not opposed to talking about low fees,
just not free and not instant (although lightning can actually provide free
and instant transactions).
On Jul 24, 2015 10:48 AM, "Jonas Schnelli via bitcoin-dev" <
bitcoin-***@lists.linuxfoundation.org> wrote:

> -----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-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[Vincent Truong via bitcoin-dev]

"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.

[gb via bitcoin-dev]

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-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Slurms MacKenzie via bitcoin-dev]

How do you explain to end users that a "validated" transaction can instantly become completely unspendable by a mined block? This seems like setting up people to just be Finney attacked even more.


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

[Thomas Kerin via bitcoin-dev]

FWIW, the 6 confirmations figure came from a modest estimate of a miner
with 10% of the hash rate, such that there is < 0.1% probability of the
transaction being undone.

I wonder at times if this figure should fluctuate with the hashrate of
the largest player. Presently, AntMiner has 20% of the hashrate,
requiring 11 blocks to give you the same certainty. And previously when
GHash.io had 45%, the number of blocks to wait would be 340 - over two days!

With this in mind, I would be wary about publishing these numbers as
they are prone to change.

On 25/07/15 03:18, gb via bitcoin-dev wrote:
>
> 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-***@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

- --
My PGP key can be found here <https://thomaskerin.io/me.pub.asc>

[Eric Lombrozo via bitcoin-dev]

> On Jul 23, 2015, at 5:45 PM, Jean-Paul Kogelman <***@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.

[Jean-Paul Kogelman via bitcoin-dev]

There really isn't any need for a 3rd party here. Those "services" can just be the miners themselves.


jp

> On Jul 24, 2015, at 8:56 AM, Eric Lombrozo <***@gmail.com> wrote:
>
>
>> On Jul 23, 2015, at 5:45 PM, Jean-Paul Kogelman <***@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.

[Slurms MacKenzie via bitcoin-dev]

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

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.


> 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),

I should stress that I didn't present that timing information as a dig against their software, it just happens to be something I have direct access to and can prevent clean data about. The point that I was attempting to make is that Bitcoin Core isn't the only piece of software in the ecosystem with performance problems, given that a large portion of users have Electrum wallets it would be insane not to consider the impact changes will have on the people that charitably run servers for the community.

By the way, is that an offer to buy my dedicated server some new SSDs?


> 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.

Scaling up isn't tweaking parameters and ignoring the brickwork falling around your head. You mention that you think the merkle tree can hold an unlimited amount of information, that's all very well so long as people can actually validate the thing. Miners aren't even willing to validate their own blocks at the peril of losing $7000 USD (on two occasions now), so why would anybody else?

[Mike Hearn via bitcoin-dev]

>
> 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.
>

He hasn't ignored you, and he wasn't responding to your email specifically
but rather the general attitude displayed in this forum for the last
several months (and I'd argue the last year or so).

Your data is interesting but ultimately tell us what we already know - that
the next bottleneck after the hard coded limit could easily be propagation
speed. The solution is likely to be a better protocol. Matt's custom
network already has optimised things, rolling some of those ideas into the
P2P protocol may be a good place to start, or something fancier like IBLTs.

Regardless, the *next* bottleneck is not the protocol, it's the hard cap.

So the conclusion remains unchanged: Bitcoin must grow, and solutions for
scaling it up will be found as the need arises.

[Jorge Timón via bitcoin-dev]

On Thu, Jul 23, 2015 at 6:17 PM, Tom Harding via bitcoin-dev
<bitcoin-***@lists.linuxfoundation.org> wrote:
> 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.

We know perfectly well that the system will need to eventually be
sustained by fees.
We should stop misinforming new users talking them about how bitcoin
transactions "are free", because they're clearly not.

>> 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.

Am I "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.

Timestamping data using the blockchain is not the same as including
that the data in the blockchain itself because the later is a scarce
resource.
The "timestamping space" is already unlimited today with no changes.
You can use a bitcoin transaction to timestamp an unbounded amount of
external data using exactly 0 extra bytes in your transaction!
Here's the code: https://github.com/Blockstream/contracthashtool

And I'm very interested in scaling Bitcoin, I just disagree that
changing a constant is a "scaling solution".

On Thu, Jul 23, 2015 at 6:28 PM, Gavin Andresen via bitcoin-dev
<bitcoin-***@lists.linuxfoundation.org> wrote:
> 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!

I extremely disagree that having a block limit is failure. It's a
design decision to protect the system against centralization (which we
will be able to rise as we solve technical and centralization problems
we have today).
But thank you for being more clear about it now, Gavin. You won't stop
on a 8GB or 32GB limit because you think having ANY limit would be a
failure.
Is that correct?
If not, can you please answer clearly when and why you think the
blocksize should be lower than demand (when you will be ok with
bitcoin users having to pay fees for the service they're enjoying)?
If your answer is "never", I would prefer to hear it from you than
just concluding it by the lack of an answer.

[Tom Harding via bitcoin-dev]

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).


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

Nobody here thinks that. Even on Reddit, not very many people seem to
think that.

[Jorge Timón via bitcoin-dev]

On Jul 24, 2015 8:30 AM, "Tom Harding" <***@thinlink.com> wrote:
>
> 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).
>

Why do you expect users to "increase the number of fee-paying transactions"
if their free transactions reliably get mined relatively fast?
And if it's good that they pay fees, why is not good when the reason they
do it is because there's limited space in the block? Is user's paying fees
soon a good thing or the "catastrophe" we need to avoid by rising the block
size, what is it? Or is there something else wrong with having a limit
other than "fees will hurt short-term adoption"? I'm confused about your
position now...

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.

[Tom Harding via bitcoin-dev]

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 Timón via bitcoin-dev]

On Sat, Jul 25, 2015 at 12:50 AM, Tom Harding <***@thinlink.com> wrote:
> 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.

My level of contributions are irrelevant to this discussion. But
still, I feel I should clarify some of the metrics you are looking to.
Most of my contributions so far are code refactors (with a small
change on the command-line options and a small optimization here and
there). This type of changes is usually better done incrementally to
be less risky and disruptive (this is specially important for
consensus-related code), and that makes my total commit count
unusually high, even when some people have contributed more in new
functionality than me in a single commit.
Also code movements (often required as part of these refactors)
produce unusually high total diff counts even when they require little
less than copy and paste (once you know what you want to move and
where, of course).
If I didn't thought this work is extremely important in the long term
(among other things, to make the code more accessible to new
reviewers/developers) I wouldn't be doing it, but you can't just
compare contributions counting commits or lines changed, that's not
how it works.
Github may say that I'm #10 with 96 commits / 9,371 ++ / 8,962 --, but
it's obvious to me that, say, gmaxwell #13 with 71 commits / 807 ++ /
707 -- has done a lot more for Bitcoin Core than I have.
Even if it was true that I'm the person currently coding more for
Bitcoin Core, I wouldn't write any of that if I had no hope of getting
review, so review is certain sense much more important than coding.

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

Who cares?
If my work is good for the software, my motivations are irrelevant. If
I accidentally PR a bug, my motivations are again: the bug should not
be accepted no matter how pure and noble my intentions are.
But, no, making Bitcoin's price (no offense taken, but there's an
spanish say that goes like this "Sólo un necio confunde valor y
precio" which translates to "Only a fool confuses value and price")
rise is not one of my main motivations.
I'm much more concerned about the long term success of the currency
(for which turnover is a much more interesting metric than market cap
IMO) and about learning a technology that I believe will revolutionize
the world, but maybe you don't believe me. There's a Bitcoin incentive
as part of my Blockstream's contract, so I have a financial incentive
for Bitcoin's price to increase, but, in fact, when I started
contributing to bitcoin core my bitcoin holdings where extremely low.
It bothers me that so many people seem to assume that Bitcoin
developers are also hardcore currency speculators and are also good at
it (I can say Bitcoin has teach me that I'm a terrible day-trader
myself).
There's many reasons to contribute to Bitcoin core and none of them
are relevant to this discussion.

> 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?"

The fact is that there's no "bitcoin developer dance" that makes it
rain and also raises bitcoin's market price 100 usd. And suggesting
"rising the price" as a solution to any problem just cannot be
considered a serious proposal.
No, we can't just ACK a "double the price" PR when the next halving comes.

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

If that's what you're doing as a currency speculator, that's fine.
It's just off-topic to this list.
And, no, that's not "what I am doing" as a software developer.
I want the system to improve, like that "Jessie J" singer said, forget
about the priceeeeeeeeee, yeah.

[Jorge Timón via bitcoin-dev]

s/no offense taken/no offense intended

[Tom Harding via bitcoin-dev]

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.

[Jorge Timón via bitcoin-dev]

That's not what I said. We don't seem able to communicate with each other
efficiently, probably my fault since English is not my native language. But
I don't want to use more of my time (or yours) in this discussion, since
it's clearly unproductive.
On Jul 28, 2015 6:45 PM, "Tom Harding" <***@thinlink.com> wrote:

> 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.
>
>

[Jeff Garzik via bitcoin-dev]

Addendum:

Please do not interpret - as many have - my points as advocating against
letting a fee market ever develop(!).

Fees are useful against DoS, increasing cost of attack etc. Further,
continuing the artificially-low fee policy ad infinitum is unsustainable
and constitutes a moral hazard.

Examine from the user's point of view. If you want to develop a fee
market, think it through in the context of user expectation/experience -
which translates to how software is written and users behave, the context
of market disruption, and the context of further block size increases.

Transition to a new economic policy should be planned. It should give
users and markets time to adjust.

It is grossly irresponsible to simply drop users into a new economic policy
with no warning and no preparation.

[Eric Lombrozo via bitcoin-dev]

> On Jul 22, 2015, at 10:33 AM, Jeff Garzik via bitcoin-dev <bitcoin-***@lists.linuxfoundation.org> wrote:
>
> On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev <bitcoin-***@lists.linuxfoundation.org <mailto:bitcoin-***@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.

This is only because of the fact that only a negligible portion of miner income comes from fees - the vast majority still continues to be subsidized by block rewards. The original design of the protocol was such that this subsidy would be decreased over time to let fees become the predominant source of income for miners. Until we have fee pressures, there’s no incentive for the industry to find solutions to real problems that need solving. I think you underestimate the ingenuity of people when pressed for real solutions. The main barrier to Bitcoin adoption is NOT this issue
and I believe the priorities are misplaced here. We’ve had over six years to start working on solutions but we keep “kicking the can down the road” - until when?!?! I believe unless there’s a strong need to find a solution no solutions will really be found.

>
> 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
>

The current userbase and market is still tiny - we have to think bigger than this. We already go through loads of pain to use the current system
and quite frankly, there are a number of other significant issues that I think are far bigger obstacles to widespread adoption than “I have to pay a fee”. For example, the current cost of verification is too high to continue to ensure the security of the network (as the July 4th fork clearly illustrated)
and places huge centralization pressures on validation
and simply will not support hundreds of millions of users or billions of users. Increasing block size actually worsens the scaling properties, it does not improve them. We need better scaling solutions - almost certainly this will require avoiding the need for global consensus for the vast majority of transactions (nested consensus or off-chain direct party-to-party contract negotiation, the lightning network, etc. The focus on reducing fee pressure by increasing block size is a distraction from far more fundamental issues, IMHO.

>
> 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.
>

Wrong - the economic policy of bitcoin has always been, from the beginning, to subsidize blocks initially and transition to fees. Artificially continuing to rely on block reward subsidies is what is a new economic policy. We’re already six years in, pretty soon another halving is coming - how long are we going to wait to start transitioning? The lower block reward subsidies are, the more pain fee pressures will cause.


> "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.
>

I think about the billions of people out there in the world that could be using this technology that simply have no access to it right now. The majority or them which are unbanked, etc


More the reason to go through the steps needed while we’re still small to correct the core issues.

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

[Mike Hearn via bitcoin-dev]

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.

[Eric Lombrozo via bitcoin-dev]

> On Jul 22, 2015, at 2:43 PM, Mike Hearn via bitcoin-dev <bitcoin-***@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.

It would be truly awesome to be able to give people more choice on consensus rules. Unfortunately, cryptoledgers do not fork gracefully (yet). Until we’re able to merge blockchain forks like we’re able to merge git repo forks, the safest option is no fork.

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

[Mike Hearn via 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.
>

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.

[Eric Lombrozo via bitcoin-dev]

> On Jul 22, 2015, at 3:01 PM, Mike 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".
>

Blockchain reorgs are part of the consensus rules. We’re talking not about forks caused by network partitions
but forks caused by the use of distinct consensus rules.

> 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.
>

You cannot merge two chains that have incompatible transactions in them without throwing away one of the two conflicting transactions (along with all dependencies). In the reorg process, this occurs naturally
and we allow for it by using confirmation count as a metric of irreversibility. Until one chain wins (by overwhelming consensus) or all chains include a particular transaction in question, we cannot treat that transaction as irreversible. Propose a model in which we can still reliably measure irreversibility in the presence of multiple chains and you might have a point.

[Eric Lombrozo via bitcoin-dev]

> On Jul 22, 2015, at 3:01 PM, Mike 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.
>

Mike, you might be surprized to learn that there are other hard fork proposals out there besides increasing block size.

[Jeff Garzik via bitcoin-dev]

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-***@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-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[Raystonn via bitcoin-dev]

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

[Cory Fields via 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.

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-***@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-***@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-***@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-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[Eric Lombrozo via bitcoin-dev]

FWIW, I had worked on something similar a while back: https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf <https://github.com/CodeShark/bitcoin/blob/coinparams_new/altconf/bitcoin.conf>

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-***@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-***@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-***@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-***@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-***@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-***@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Cory Fields via bitcoin-dev]

On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <***@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-***@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-***@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-***@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-***@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-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[Eric Lombrozo via bitcoin-dev]

> On Jul 22, 2015, at 5:05 PM, Cory Fields <***@coryfields.com> wrote:
>
> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <***@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.

> Cory
>
>> On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev
>> <bitcoin-***@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-***@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-***@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-***@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-***@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-***@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-***@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>

[Cory Fields via bitcoin-dev]

On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo <***@gmail.com> wrote:
>
>> On Jul 22, 2015, at 5:05 PM, Cory Fields <***@coryfields.com> wrote:
>>
>> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <***@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.

[Eric Lombrozo via bitcoin-dev]

> On Jul 22, 2015, at 5:34 PM, Cory Fields <***@coryfields.com> wrote:
>
> On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo <***@gmail.com> wrote:
>>
>>> On Jul 22, 2015, at 5:05 PM, Cory Fields <***@coryfields.com> wrote:
>>>
>>> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <***@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.

[Ross Nicoll via bitcoin-dev]

The code so far is fairly limited in scope, essentially making it
possible to change the values in consensus/params.h based on block
height. The actual code to interpret those values does need to be
provided ahead of time, of course, so there's still developer time to
implement, it just moves consensus arguments to the users.

Loading the values from disk rather than hard-coding them is a
reasonably straight forward extension to the code, in theory. The
existing work has application-specific changes that would need stripping
out, but you can get an idea of what this would look like from
https://github.com/rnicoll/dogecoin/commit/949b1ccd88ff13c74a3c1a7b9faa7f36c1085904

Ross

On 23/07/2015 01:43, Eric Lombrozo via bitcoin-dev wrote:
>> On Jul 22, 2015, at 5:34 PM, Cory Fields <***@coryfields.com> wrote:
>>
>> On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo <***@gmail.com> wrote:
>>>> On Jul 22, 2015, at 5:05 PM, Cory Fields <***@coryfields.com> wrote:
>>>>
>>>> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <***@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-***@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Eric Voskuil via bitcoin-dev]

On 07/22/2015 05:13 PM, Eric Lombrozo via bitcoin-dev wrote:
> 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...

We (libbitcoin) have taken the time to publish and maintain bitcoind's
"libbitcoinconsensus" source files as an independent C++ library (with
Java and Python bindings).

https://en.bitcoin.it/wiki/Libbitcoin_Consensus

It can be easily verified against bitcoind sources and in builds of
libbitcoin-blockchain it can be swapped out for libbitcoin's native
consensus checks.

https://en.bitcoin.it/wiki/Libbitcoin_Blockchain#Consensus_Validation

So there is really no reason to consider the original client synonymous
with consensus. I initially argued for this library to be natively
isolated from bitcoind, but that didn't seem to be in the cards so we
did it independently.

In any case I agree with your stated need for this isolation (if not the
means) for the reasons you state. The community needs to move beyond a
largely singular and monolithic codebase that is holding that position
in part due to fear about consensus bug forks.

To make choice regarding consensus an actual choice (and thereby actual
consensus) the modularity you suggest is essential. One must be able to
take new developments without having to take consensus changes. The
option to fork the codebase is not reasonable for most people. At this
point there is no defensible reason for coupling consensus checks with
other features.

e

[Jorge Timón via bitcoin-dev]

On Thu, Jul 23, 2015 at 1:42 AM, Cory Fields via bitcoin-dev
<bitcoin-***@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.

For what is worth, here's yet another piece of code from the "doing
nothing" side:

https://github.com/bitcoin/bitcoin/pull/6382

It allows you to create a regtest-like testchain with a maximum block
size chosen at run time.
Rusty used a less generic testchain for testing 8 MB blocks:

http://rusty.ozlabs.org/?p=509

Unfortunately I don't know of anybody that has used my patch to test
any other size (maybe there's not that much interest in testing other
sizes after all?).

I'm totally in favor of preemptively adapting the code so that when a
new blocksize is to be deployed, adapting the code is not a problem.
Developers can agree on many changes in the code without users having
to agree on a concrete block size first.
I offer my help to do that. That's what I'm trying to do in #6382 and
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008961.html
but to my surprise that gets disregarded as "doing nothing" and as
"having a negative attitude", when not simply ignored.

[Tom Harding via bitcoin-dev]

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

[Eric Lombrozo via bitcoin-dev]

> On Jul 22, 2015, at 5:27 PM, Tom Harding via bitcoin-dev <bitcoin-***@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
>

I take it you mean allowing bitcoin to *not* become space-constrained - because all real-world computers are space-constrained



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

[Edmund Edgar via bitcoin-dev]

> 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.

This is a really interesting thread. Since we're no longer talking
about a consensus of the core committers, which would be central
control, but instead something broader, could you say a bit more about
what this consensus might look like, and how we'll know if we've got
one?

In plain language "no controversy" sounds like very high bar for a
diverse community like this; Even bringing in P2SH kicked up a fair
bit of fur and feathers. Do you have a definition in mind where it
isn't an _impossibly_ high one?

--
Edmund Edgar
Founder, Social Minds Inc (KK)
Twitter: @edmundedgar
Linked In: edmundedgar
Skype: edmundedgar
http://www.socialminds.jp

Reality Keys
@realitykeys
***@realitykeys.com
https://www.realitykeys.com

[Gareth Williams via bitcoin-dev]

I've seen a lot of talk on this list debating the role of Bitcoin Core and its maintainers WRT consensus, typically focused around whether they can technically force anyone to run their code (of course, they can't.)

I've yet to see the discussion framed in terms of influence and leadership. Which is why I want to highlight:

>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

Perhaps s/helps guarantee/promotes/ , but this stands out as an excellent description of Bitcoin Core's relationship to the Bitcoin network.

Defaults are powerful. Users technically /can/ compile and run any code they like, but very few even bother to change configurable settings. They just want a trusted brand ("Bitcoin Core") that does the right thing out of the box. Bitcoin Core and its maintainers play a valuable /leadership/ role for the network. Whether they can force people to run their code is uninteresting -- people trust them.

That trust is well earned, precisely because they have always promoted the operation and security of the network.

In light of this responsibility it seems unreasonable for anyone to expect Core maintainers to promote patches that endanger network consensus (e.g. user configurable consensus parameters.)

Consensus is order of business #1. If we can't all agree to use the same money then the grand experiment is resolved as a failure. Everyone has consensus parameters they'd (strongly) prefer. Somebody needs to heard us all toward using the same ones, sometimes even in the face of very high costs.

- -Gareth

[Peter Todd via bitcoin-dev]

On Wed, Jul 22, 2015 at 12:52:20PM -0400, Pieter Wuille via bitcoin-dev wrote:
> 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.

It's worth reminding people that Bitcoin Core, Bitcoin XT, my own
Bitcoin RBF, Luke-Jr's Bitcoin distribution, etc. are all software
packages that implement the Bitcoin protocol. Like many protocols,
changing the Bitcoin protocol isn't easy, and requires a broad consensus
among many players for any change to proceed smoothly. Conversely,
changing non-protocol aspects of any of those software packages is easy,
and requires little to no coordination.

Of course, in practice the Bitcoin Core dev team does have a lot of
influence, to the point where soft-forks proposed by them are adopted
pretty much blindly by most users. This is essentially a meta-consensus:
the community is assuming what the Bitcoin Core team releases will be a
good idea to run as well as non-controversial without necessarily
investigating too closely. The Core dev team has a strong track record
of making good decisions with very few mistakes, while still adding new
features, fixing security bugs, and improving performance significantly.
That leads to a fairly strong meta-consensus of "Just run Bitcoin Core"

Of course, if the Core team was taking changes and making controversial
changes, I suspect that meta-consensus would quickly break down! So it's
not as strong as it looks - the Core team doesn't really have the
ability to push through controversial changes, and the Core team acts
accordingly.

If you don't agree with that "meta-consensus", running an alternative
Bitcoin protocol implementation such as Bitcoin XT is a logical way of
showing your support for a different way of coming to consensus on
protocol changes. It's not totally clear yet what that way actually is,
but it's certainly shaping up to have a lot less emphasis on broad
consensus among the technical community. (of course, the XT team to date
has much less experience with the Bitcoin protocol and codebase than the
combined Core team does)

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.

I personally have a fairly high tolerance to trolling, but I wouldn't be
surprised if other devs start getting tired of this stuff and just leave
Bitcoin development to focus on more productive stuff. To many it's
discouraging when the other side gets to "promise ponies" - we've got a
fundamentally uphill PR battle in arguing for the development of
scalability tech.

For the long term, I think it'd be useful for research to be done on how
to better manage these social issues. I suspect a lot of the problem -
at least for non-scalable blockchain designs - stems from how
centralization failures aren't gradual, and the ease of relying on trust
rather than verification. While we get a lot of warning of issues, the
warning isn't directly associated with losses at first, making the
problem hard to explain to the general public.

> ===
>
> 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.

Agreed.

You know, those promoting the idea of a "one-time-only" blocksize
increase would do well to get the stakeholders affected to publicly
explain what exactly are their plans with regard to scalability in the
long run. If they don't have any, then it's a strong sign that said
stakeholders don't actually intend to have a "one-time-only" blocksize
increase. Remember that there's no guarantee that the technology
limiting the blocksize will improve as fast as desired, or even for that
matter, improve at all. (bandwidth is limited by politics far more than
it is limited by technology)

There's strong parallels to zeroconf safety, where as far as I can tell
the relevant stakeholders - pretty much all large payment providers -
have no plans at all to move to genuine decentralized zeroconf
technology. Rather they have backup plans to get into dangerous and
centralizing mining contracts if zeroconf security gets any worse,
something Coinbase even publicly admitted on this list.

--
'peter'[:-1]@petertodd.org
000000000000000014e0038d4c6614025cf655cc976fcd11ee4c4f7861136b9f

[Milly Bitcoin via bitcoin-dev]

> 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.

Russ

[Alice Larson via bitcoin-dev]

> 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)

Mike Hearn has mentioned a few times how Todd's habit of creating drama
on twitter and reddit every time anyone wants to change something in
Bitcoin in a way he doesn't like is driving away vendors. Openly
commenting on a female developers cleavage on twitter, as well as
referring to a female journalist as "naughty" is disgusting. Him
constantly hitting on women developers in Bitcoin is driving away
females.

[Eric Voskuil via bitcoin-dev]

https://twitter.com/petertoddbtc

Thanks for the triggering warning, if not for that I may have gone into
seizures.

e


On 07/27/2015 10:05 AM, Alice Larson via bitcoin-dev wrote:
> The twitter teenage nonsense from Todd is ridiculous:
> https://twitter.com/playatodd (warning, triggering)

[Wladimir J. van der Laan via bitcoin-dev]

Eric Voskuil, Alice Larson, others:

Personal attacks or bullying of any kind are not tolerated on this mailing list.

This list is meant to be a low-volume community for technical proposals and discussion regarding Bitcoin. See the archive for say, 2012, for example.

What Peter Todd or anyone else is doing on Twitter or other places is not relevant here. This list is not a pillory for your issues, nor a place to exhibit your personal hobby horses.

Wladimir