Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jorge Timón via bitcoin-dev]

On Dec 26, 2015 5:45 PM, "Pieter Wuille via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> My opinion is that the role of Bitcoin Core maintainers is judging
whether consensus for a hard fork exists, and is technically necessary and
safe. We don't need a hashpower vote to decide whether a hardfork is
accepted or not, we need to be sure that full noded will accept it, and
adopt it in time. A hashpower vote can still be used to be sure that miners
_also_ agree.

To clarify, that's the role of Bitcoin Core maintainers because they decide
what goes into Bitcoin Core, not because they decide the consensus rules of
Bitcoin. Other full node implementations (say, libbitcoin) will have to
decide on their own and Bitcoin Core mainteiners don't have any authority
over libbitcoin (or other alternative implementations). Nobody has such
authority (not even the creator of the system if he was still maintaining
Bitcoin Core).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Pieter Wuille via bitcoin-dev]

On Dec 26, 2015 23:55, "Jonathan Toomim"  wrote:
>
> On Dec 26, 2015, at 8:44 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Furthermore, 75% is pretty terrible as a switchover point, as it
guarantees that old nodes will still see a 25% forked off chain temporarily.
>
> Yes, 75% plus a grace period is better. I prefer a grace period of about
4000 to 8000 blocks (1 to 2 months).

I think that's extremely short, even assuming there is no controversy about
changing the rules at all. Things like BIP65 and BIP66 already took
significantly longer than that, were uncontroversial, and only need miner
adoption. Full node adoption is even slower.

I think the shortest reasonable timeframe for an uncontroversial hardfork
is somewhere in the range between 6 and 12 months.

For a controversial one, not at all.

-- 
Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Bryan Bishop via bitcoin-dev]

On Sat, Dec 26, 2015 at 5:15 PM, Justus Ranvier via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 12/26/2015 05:01 PM, Pieter Wuille via bitcoin-dev wrote:
> > I think the shortest reasonable timeframe for an uncontroversial
> > hardfork is somewhere in the range between 6 and 12 months.
>
> This argument would hold more weight if it didn't looks like a stalling
> tactic in context.
>

I think you'll find that there hasn't been stalling regarding an
uncontroversial hard-fork deployment. You might be confusing an
uncontroversial hard-fork decision instead with how developers have brought
up many issues about various (hard-forking) block size proposals I
suspect this is what you're intending to mention instead, given your
mention of "capacity emergencies" and also the subject line.


> 6 months ago, there was a concerted effort to being the process then,
> for exactly this reason.
>

The uncontroversial hard-fork proposals from 6 months ago were mostly along
the lines of jtimon's proposals, which were not about capacity. (Although,
I should say "almost entirely uncontroversial"-- obviously has been some
minor (and in my opinion, entirely solvable) disagreement regarding
prioritization of deploying a jtimon's uncontroversial hard-fork idea I
guess, seeing as how it has not yet happened.)


> After 6 months of denial, stonewalling, and generally unproductive
> fighting, the need for proactivity is being acknowledged with no
> reference to the delay.
>

There wasn't 6 months of "stonewalling" or "denial" about an
uncontroversial hard-fork proposal. There has been extensive discussion
regarding the controversial (flawed?) properties of other (block size)
proposals. But that's something else. Much of this has been rehashed ad
nauseum on this mailing list already...  thankfully I think your future
emails could be improved and made more useful if you were to read the
mailing list archives, try to employ more careful reasoning, etc. Thanks.


> If the network ever ends up making a hasty forced upgrade to solve a
> capacity emergency the responsibility for that difficulty will not fall
> on those who did their best to prevent emergency upgrades by planning
> ahead.
>

("Capacity emergency" is too ambiguous in this context because of the
competing concerns and tradeoffs regarding transaction rate capacity
exhaustion vs. p2p low-bandwidth node bandwidth exhaustion.)

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jonathan Toomim via bitcoin-dev]

On Dec 26, 2015, at 8:44 AM, Pieter Wuille via bitcoin-dev 
 wrote:
> Furthermore, 75% is pretty terrible as a switchover point, as it guarantees 
> that old nodes will still see a 25% forked off chain temporarily.
> 
Yes, 75% plus a grace period is better. I prefer a grace period of about 4000 
to 8000 blocks (1 to 2 months).

From my discussions with miners, I think we will be able to create a hardfork 
proposal that reaches about 90% support among miners, or possibly higher. I'll 
post a summary of those discussions in the next 24 hours.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Pieter Wuille via bitcoin-dev]

On Dec 27, 2015 00:06, "Jonathan Toomim"  wrote:

> Given that a supermajority of users and miners have been asking for a
hard fork to increase the blocksize for years, I do not think that
mobilizing people to upgrade their nodes is going to be hard.
>
> When we do the hard fork, we will need to encourage people to upgrade
their full nodes. We may want to request that miners not trigger the fork
until some percentage of visible full nodes have upgraded.

I am generally not interested in a system where we rely on miners to make
that judgement call to fork off nodes that don't pay attention and/or
disagree with the change. This is not because I don't trust them, but
because I believe one of the principle values of the system is that its
consensus system should be hard to change.

I can't tell you what code to run of course, but I can decide what system I
find interesting to build. And it seems many people have signed off on
working towards a plan that does not include a hard fork being scheduled
right now: https://bitcoin.org/en/bitcoin-core/capacity-increases

Cheers,

-- 
Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Justus Ranvier via bitcoin-dev]

On 12/26/2015 06:13 PM, Bryan Bishop wrote:
> I think you'll find that there hasn't been stalling regarding an
> uncontroversial hard-fork deployment. You might be confusing an
> uncontroversial hard-fork decision instead with how developers have
> brought up many issues about various (hard-forking) block size
> proposals I suspect this is what you're intending to mention
> instead, given your mention of "capacity emergencies" and also the
> subject line.

I think you'll find that writing in that tone makes one come across as a
complete and utter douchebag.

I suspect what you're intending to do is to use faux-polite
condescension to bait me into responding in a way to will justify my
subsequent banning from this mailing list so that the people who aren't
interested in answering certain uncomfortable questions will have a
plausible excuse for preventing them from being asked here.

> There wasn't 6 months of "stonewalling" or "denial" about an
> uncontroversial hard-fork proposal. There has been extensive discussion
> regarding the controversial (flawed?) properties of other (block size)
> proposals. But that's something else. Much of this has been rehashed ad
> nauseum on this mailing list already...  thankfully I think your future
> emails could be improved and made more useful if you were to read the
> mailing list archives, try to employ more careful reasoning, etc. Thanks.

Actually there's been 3+ years of stonewalling, deception, conflicts of
interest, and outright crimes, which have been generally ignored by
those who are desperately attempting to assume good faith.

The purpose of my email was to remind everyone that nobody is going to
get away with avoiding ownership of the consequences of their actions.

If the network experiences a painful upgrade because six months of time
that could have been used to prepare a smooth upgrade was lost, the
individuals who squandered that time own the result. They can't get
around it by demanding six additional months, as if they had nothing to
do with the six lost months.




0xEAD9E623.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Aaron Voisine via bitcoin-dev]

> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for
> making changes to it in order to satisfy economic demand. If that is
> the case, Bitcoin has failed, in my opinion.

Pieter, what's actually happening is that the bitcoin-core release has
become a Schelling point in the consensus game:

https://en.wikipedia.org/wiki/Schelling_point

Due to the strong incentives for consensus, everyone is looking for an
obvious reference point that they think everyone else will also pick, even
though the point itself isn't critical, only that everyone agree on
whatever point is picked. Like it or not, the bitcoin-core release, and by
extension it's committers have a great degree of influence over what the
community as a whole decides to do. If core screws things up badly enough,
yes, the community will settle on some other focal point for consensus, but
the cost and risk of doing so is high, so there is indeed unavoidable moral
hazard for whoever has control over any such focus point.

Aaron Voisine
co-founder and CEO
breadwallet 

On Wed, Dec 16, 2015 at 10:34 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
>  wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > that of "healthy fee market" and strongly urge users to examine their fee
> > policies, wallet software, transaction volumes and other possible User
> > impacting outcomes.
>
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for making
> changes to it in order to satisfy economic demand. If that is the
> case, Bitcoin has failed, in my opinion.
>
> What the Bitcoin Core team should do, in my opinion, is merge any
> consensus change that is uncontroversial. We can certainly -
> individually or not - propose solutions, and express opinions, but as
> far as maintainers of the software goes our responsibility is keeping
> the system running, and risking either a fork or establishing
> ourselves as the de-facto central bank that can make any change to the
> system would greatly undermine the system's value.
>
> Hard forking changes require that ultimately every participant in the
> system adopts the new rules. I find it immoral and dangerous to merge
> such a change without extremely widespread agreement. I am personally
> fine with a short-term small block size bump to kick the can down the
> road if that is what the ecosystem desires, but I can only agree with
> merging it in Core if I'm convinced that there is no strong opposition
> to it from others.
>
> Soft forks on the other hand only require a majority of miners to
> accept them, and everyone else can upgrade at their leisure or not at
> all. Yes, old full nodes after a soft fork are not able to fully
> validate the rules new miners enforce anymore, but they do still
> verify the rules that their operators opted to enforce. Furthermore,
> they can't be prevented. For that reason, I've proposed, and am
> working hard, on an approach that includes Segregated Witness as a
> first step. It shows the ecosystem that something is being done, it
> kicks the can down the road, it solves/issues half a dozen other
> issues at the same time, and it does not require the degree of
> certainty needed for a hardfork.
>
> --
> Pieter
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Dave Scotese via bitcoin-dev]

I've already publicly declared that I offer one bitcoin to "those who
suffer from a May 5, 2016 hardfork to 2MB blocks" but that's probably way
too sloppy.  Here's a better idea that transmits the economic power of
merchants and customers (well, anyone with bitcoin) to the miners on whom
they must rely for confirmations:

The bitcoin I offer is part of a fund that, when it reaches 25 BTC, will be
pledged to a miner.  Here is how that miner earns the reward:

   1. Wait until a core dev signs a release of bitcoin core in which the
   limit is double it's current level.
   2. Use the new release to mine, but use a soft limit on the blocksize to
   produce only blocks that are valid according to the old software.
   3. Wait until May 5th, 2016.
   4. Remove the soft limit on blocksize.
   5. Create a block that breaks the old limit and is valid according to
   the new signed release.
   6. Wait for the new large block to be orphaned.

Hopefully, the reward will be greater than 25 bitcoins and therefore cover
the transaction fees.  Of course, if they wait until after the halving in
step 3, then they will get twice the (new, 12.5 btc) reward if they can
arrange for the orphaning of their own block.

Any core dev could do this but I guess it would be playing with fire.  So
maybe Satoshi will do it.  He played with fire (right?) and look how that
worked out.  Come on, someone, be a hero.  Mike and Gavin tried, but I
think they went a little overboard.

Another way to do this is to identify the position in each binary where the
hard limit is stored, and write a little script that will (check the date
first, and then) alter the data at that position so that currently running
bitcoin software can be hot-patched on May 5th without the help of any core
devs (if that would work).  Obviously, the little script should be signed
by a competent programmer whom the user trusts, a slightly less stringent
requirement than being an actual core dev.

notplato

On Fri, Dec 18, 2015 at 7:48 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> On Dec 18, 2015 2:13 AM, "sick...@gmail.com"  wrote:
> > 1.75 x 0.5 + 1 x 0.5 = 1.375
> >
> > after six month.
> >
> > An hard-fork on the others side would bring 1.75 since the activation,
> am I right?
>
> Yes.
>
> However, SW immediately gives a 1.75 capacity increase for anyone who
> adopts it, after the softfork, instantly. They don't need to wait for
> anyone else.
>
> A hard fork is an orthogonal improvement, which is also needed if we don't
> want to be stuck with a constant maximum ultimately.
>
> Hardforks can however only be deployed at a time when all full node
> software can reasonably have agreed to upgrade, while a softfork can be
> deployed much earlier.
>
> They are independent improvements, and we need both. I am however of the
> opinion that hard forks need a much clearer consensus and much longer
> rollout timeframes to be safe (see my thread on the security of softforks).
>
> --
> Pieter
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy  and Meme Racing
 (in alpha).
I'm the webmaster for The Voluntaryist  which
now accepts Bitcoin.
I also code for The Dollar Vigilante .
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Tier Nolan via bitcoin-dev]

On Thu, Dec 17, 2015 at 7:44 PM, Peter Todd  wrote:

> If Bitcoin remains decentralized, miners have veto power over any
> blocksize increases. You can always soft-fork in a blocksize reduction
> in a decentralized blockchain that actually works.
>

The actual users of the system have significant power, if they (could)
choose to use it.  There are "chicken" effects though.  They can impose
costs on the other participants but using those options harms themselves.
If the cost of inaction is greater than the costs of action, then the
chicken effects go away.

In the extreme, they could move away from decentralisation and the concept
of miners and have a centralised checkpointing system.  This would be a
bankrupting cost to miners but at the cost to the users of the
decentralised nature of the system.

At a lower extreme, they could change the mining hash function.  This would
devalue all of the miner's investments.  A whole new program of ASIC
investments would have to happen and the new miners would be significantly
different.  It would also establish that merchants and users are not to be
ignored.  On the other hand, bankrupting miners would make it harder to
convince new miners to make the actual investments in ASICs required to
establish security.

As a gesture, if merchants and exchanges wanted to get their "seat" at the
table, they could create a representative group that insists on a trivial
soft fork.  For example, they could say that they will not accept any block
from block N to block N + 5000 that doesn't have a specific bit set in the
version.

Miners have an advantage where they can say that they have the majority of
the hashing power.  As part of the public action problem that merchants
face, there is no equivalent metric.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jeff Garzik via bitcoin-dev]

On Fri, Dec 18, 2015 at 2:56 AM, Pieter Wuille 
wrote:

> On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik  wrote:
> >> You present this as if the Bitcoin Core development team is in charge
> >> of deciding the network consensus rules, and is responsible for making
> >> changes to it in order to satisfy economic demand. If that is the
> >> case, Bitcoin has failed, in my opinion.
> >
> > Diverging from the satoshi block size change plan[1] and current
> economics
> > would seem to require a high level of months-ahead communication to
> users.
>
> I don't see any plan, but will you say the same thing when the subsidy
>

Yes, I forgot the link:

[1] https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366



> dwindles, and mining income seems to become uncertain? It will equally
> be an economic change, which equally well will have been predictable,
> and it will equally well be treatable with a hardfork to increase the
> subsidy.
>

That is a red herring.  Nobody I know has proposed this, and I am opposed
to changing that fundamental.

It is well known that the 1M limit was never intended to stay, unlike 21M
coin limit etc.

1M was set high in the beginning because it is a DoS engineering limit, not
an [accidental] economic policy tool.




> But I am not against a block size increase hard fork. My talk on
> segregated witness even included proposed pursuing a hard fork at a
> slightly later stage.
>

Great!



> But what you're arguing for is that - despite being completely
> expected - blocks grew fuller, and people didn't adapt to block size
> pressure and a fee market, so the Core committee now needs to kick the
> can down the road, because we can't accept the risk of economic
> change. That sounds very much like a bailout to me.
>

I am arguing for continuing what we know works.  We are 100% certain
blocks-not-full-on-avg works, where a "buffer" of space exists between avg
block size and hard limit.

Any other avenue is by definition speculation and risk.  You _think_ you
know what a healthy fee market _should_ be.  Massive damage occurs to
bitcoin if you are wrong - and I listed several

vis expectation, there is clear consensus and expectation that block size
would increase, from 2010 onward.  It was always a question of _when_ not
if.

Sticking with 1M presents clear risk of (a) economic fracture and (b)
community fracture.  It quite clearly risks massive change to an unknown
system at an unknown, unpredictable date in the future.

BIP 102 presents an expected upgrade at a predictable date in the future.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Tier Nolan via bitcoin-dev]

On Wed, Dec 16, 2015 at 9:11 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> We are not avoiding a choice. We don't have the authority to make a choice.
>

This is really the most important question.

Bitcoin is kind of like a republic where there is separation of powers
between various groups.

The power blocs in the process include

- Core Devs
- Miners
- Exchanges
- Merchants
- Customers

Complete agreement is not required for a change.  If merchants and their
customers were to switch to different software, then there is little any of
the other groups could do.

Consensus is nice, certainly, and it is a good social norm to seek
widespread agreement before committing to a decision above objection.
Committing to no block increase is also committing to a decision against
objections.

Having said that, each of the groups are not equal in power and
organisation.

Merchants and their customers have potentially a large amount of power, but
they are disorganised.  There is little way for them to formally express a
view, much less put their power behind making a change.  Their potential
power is crippled by public action problems.

On the other extreme is the core devs. Their power is based on legitimacy
due to having a line of succession starting with Satoshi and respect gained
due to technical and political competence.  Being a small group, they are
organised and they are also more directly involved.

The miners are less centralised, but statements supported by the majority
of the hashing power are regularly made.  The miners' position is that they
want dev consensus.  This means that they have delegated their decision
making to the core devs.

The means that the two most powerful groups in Bitcoin have given the core
devs the authority to make the decision.  They don't have carte blanche
from the miners.

If the core devs made the 2MB hard-fork with a 75% miner threshold, it is
highly likely that the other groups would accept it.

That is the only authority that exists in Bitcoin.  The check is that if
the authority is abused, the other groups can simply leave (or use
checkpointing)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Peter Todd via bitcoin-dev]

On Thu, Dec 17, 2015 at 04:58:02PM +, Tier Nolan via bitcoin-dev wrote:
> This is really the most important question.
> 
> Bitcoin is kind of like a republic where there is separation of powers
> between various groups.
> 
> The power blocs in the process include
> 
> - Core Devs
> - Miners
> - Exchanges
> - Merchants
> - Customers
> 
> Complete agreement is not required for a change.  If merchants and their
> customers were to switch to different software, then there is little any of
> the other groups could do.

If Bitcoin remains decentralized, miners have veto power over any
blocksize increases. You can always soft-fork in a blocksize reduction
in a decentralized blockchain that actually works.

-- 
'peter'[:-1]@petertodd.org
01bd68962863e6fa34e9776df361d4926912f52fc5f4b618


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Pieter Wuille via bitcoin-dev]

On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik  wrote:
>> You present this as if the Bitcoin Core development team is in charge
>> of deciding the network consensus rules, and is responsible for making
>> changes to it in order to satisfy economic demand. If that is the
>> case, Bitcoin has failed, in my opinion.
>
> Diverging from the satoshi block size change plan[1] and current economics
> would seem to require a high level of months-ahead communication to users.

I don't see any plan, but will you say the same thing when the subsidy
dwindles, and mining income seems to become uncertain? It will equally
be an economic change, which equally well will have been predictable,
and it will equally well be treatable with a hardfork to increase the
subsidy.

Yes, I'm aware the argument above is a straw man, because there was
clear expectation that the subsidy would go down asymptotically, and
much less an expectation that the blocksize would remain fixed
forever.

But I am not against a block size increase hard fork. My talk on
segregated witness even included proposed pursuing a hard fork at a
slightly later stage.

But what you're arguing for is that - despite being completely
expected - blocks grew fuller, and people didn't adapt to block size
pressure and a fee market, so the Core committee now needs to kick the
can down the road, because we can't accept the risk of economic
change. That sounds very much like a bailout to me.

Again. I am not against growth, but increasing in response to fear of
economic change is the wrong approach. Economic change is inevitable.

> Segregated Witness does not kick the can, it solves none of the problems #1,
> #3 - #8 explicitly defined and listed in email #1.
>
> 1)  A plan of "SW + no hard fork" is gambling with ECE risk, gambling there
> will be no Fee Event, because the core block size is still heavily contended
> -- 100% contended at time out SW rollout.

That is an assumption. I expect demand for transactions at a given
feerate to stop growing at a certain contention level (and we've
reached some level of contention already, with mempools not being
cleared for significant amounts of time already).

> SW mitigates this
> - only after several months

That is assuming a hard fork consensus forming, deployment,
activation, ... goes faster than a softfork.

> - only assuming robust adoption rates by up-layer ecosystem software, and

That's not required. Everyone who individually switches to new
transactions gets to do 1.75x more transactions for the same price
(and at the same time gets safer contracts, better script
upgradability, and more security models at their disposal), completely
independent of whether anyone else in the ecosystem does the same.

> - only assuming transaction volume growth is flat or sub-linear

The only question is how many transactions for what price. Contention
always happens at a specific feerate level anyway.

> Those conditions must go as planned to fulfill "SW kicked the can" -- a lot
> of if's.
>
> As stated, SW is orthogonal to the drift-into-uncharted-waters problem
> outlined in email #1, which a short term bump does address.

Both SW and a short bump (which is apparently not what BIP102 does
anymore?) increase capacity available per price, and yes, they are
completely orthogonal.

My only disagreement is the motivation (avoiding economic change, as
opposed to aiming for safe growth) and the claim that a capacity
increase hardfork is easier and safe(r) to roll out quickly than
sortfork SW.

Apart from that, we clearly need to do both at some point.

-- 
Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jameson Lopp via bitcoin-dev]

On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Dec 16, 2015 at 10:08 PM, Jeff Garzik  wrote:
> >> You present this as if the Bitcoin Core development team is in charge
> >> of deciding the network consensus rules, and is responsible for making
> >> changes to it in order to satisfy economic demand. If that is the
> >> case, Bitcoin has failed, in my opinion.
> >
> >
> > This circles back to Problem #1:   Avoidance of a choice is a still a
> choice
> > - failing to ACK a MAX_BLOCK_SIZE increase still creates very real
> Economic
> > Change Event risk.
>
> We are not avoiding a choice. We don't have the authority to make a choice.
>
> > And #3:  If the likely predicted course is that Bitcoin Core will not
> accept
> > a protocol change changing MAX_BLOCK_SIZE via hard fork in the short
> term,
> > the core dev team should communicate that position clearly to users and
> > media.
>
> I indeed think we can communicate much better that deciding consensus
> rules is not within our power.
>

Indeed, because I sometimes find these statements to be confusing as well -
I can completely understand what you mean if you're speaking from a moral
standpoint. If you're saying that it's unacceptable for the Bitcoin Core
developers to force consensus changes upon the system, I agree. But
thankfully the design of the system does not allow the developers to do so.
Developers can commit amazing code or terrible code, but it must be
voluntarily adopted by the rest of the ecosystem. Core developers can't
decide these changes, they merely propose them to the ecosystem by writing
and releasing code.

I agree that Core developers have no authority to make these decisions on
behalf of all of the network participants. However, they are in a position
of authority when it comes to proposing changes. One of my takeaways from
Hong Kong was that most miners have little interest in taking
responsibility for consensus changes - they trust the Core developers to
use their expertise to propose changes that will result in the continued
operation of the network and not endanger their business operations.

A non-trivial portion of the ecosystem is requesting that the Core
developers make a proposal so that the network participants can make a
choice. Jeff noted that we can expect for the economic conditions of the
network to change significantly in 2016, barring higher throughput
capacity. If the year+ deployment timeframe for hard forks proposed by Matt
on another thread is what we can expect for any proposed consensus change,
then it should be non-contentious to announce that there will be no hard
fork in 2016. This will give clarity to the rest of the ecosystem as to how
they should prepare.


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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jeff Garzik via bitcoin-dev]

On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille 
wrote:

> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
>  wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > that of "healthy fee market" and strongly urge users to examine their fee
> > policies, wallet software, transaction volumes and other possible User
> > impacting outcomes.
>
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for making
> changes to it in order to satisfy economic demand. If that is the
> case, Bitcoin has failed, in my opinion.
>

Diverging from the satoshi block size change plan[1] and current economics
would seem to require a high level of months-ahead communication to users.




> all. Yes, old full nodes after a soft fork are not able to fully
> validate the rules new miners enforce anymore, but they do still
> verify the rules that their operators opted to enforce. Furthermore,
> they can't be prevented. For that reason, I've proposed, and am
> working hard, on an approach that includes Segregated Witness as a
> first step. It shows the ecosystem that something is being done, it
> kicks the can down the road, it solves/issues half a dozen other
> issues at the same time, and it does not require the degree of
> certainty needed for a hardfork.
>

Segregated Witness does not kick the can, it solves none of the problems
#1, #3 - #8 explicitly defined and listed in email #1.

1)  A plan of "SW + no hard fork" is gambling with ECE risk, gambling there
will be no Fee Event, because the core block size is still heavily
contended -- 100% contended at time out SW rollout.

2) We are only 100% certain that bitcoin works in the
blocks-not-full-on-avg state, where there is a healthy buffer between the
hard limit and the average block size.

There is remains major ECE risk due to the core block size freeze, possibly
pushing the system into a new, untried economic state and causing major
market and actor disruption.  Users of the Service can still drift randomly
and unpredictably into a Fee Event.

SW mitigates this
- only after several months
- only assuming robust adoption rates by up-layer ecosystem software, and
- only assuming transaction volume growth is flat or sub-linear

Those conditions *must* go as planned to fulfill "SW kicked the can" -- a
lot of if's.

As stated, SW is orthogonal to the drift-into-uncharted-waters problem
outlined in email #1, which a short term bump does address.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jorge Timón via bitcoin-dev]

On Thu, Dec 17, 2015 at 8:44 PM, Peter Todd via bitcoin-dev
 wrote:
> If Bitcoin remains decentralized, miners have veto power over any
> blocksize increases. You can always soft-fork in a blocksize reduction
> in a decentralized blockchain that actually works.

You can always schism hardfork miners out...
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jeff Garzik via bitcoin-dev]

On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille 
wrote:

> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
>  wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > that of "healthy fee market" and strongly urge users to examine their fee
> > policies, wallet software, transaction volumes and other possible User
> > impacting outcomes.
>
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for making
> changes to it in order to satisfy economic demand. If that is the
> case, Bitcoin has failed, in my opinion.
>

This circles back to Problem #1:   Avoidance of a choice is a still a
choice - failing to ACK a MAX_BLOCK_SIZE increase still creates very real
Economic Change Event risk.

And #3:  If the likely predicted course is that Bitcoin Core will not
accept a protocol change changing MAX_BLOCK_SIZE via hard fork in the short
term, the core dev team should communicate that position clearly to users
and media.

Hitting a Fee Event is market changing, potentially reshuffling economic
actors to a notable degree.  Maintaining a short term economic policy of
fixed 1M supply in the face of rising transaction volume carries risks that
should be analyzed and communicated.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Pieter Wuille via bitcoin-dev]

On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
 wrote:
> 2) If block size stays at 1M, the Bitcoin Core developer team should sign a
> collective note stating their desire to transition to a new economic policy,
> that of "healthy fee market" and strongly urge users to examine their fee
> policies, wallet software, transaction volumes and other possible User
> impacting outcomes.

You present this as if the Bitcoin Core development team is in charge
of deciding the network consensus rules, and is responsible for making
changes to it in order to satisfy economic demand. If that is the
case, Bitcoin has failed, in my opinion.

What the Bitcoin Core team should do, in my opinion, is merge any
consensus change that is uncontroversial. We can certainly -
individually or not - propose solutions, and express opinions, but as
far as maintainers of the software goes our responsibility is keeping
the system running, and risking either a fork or establishing
ourselves as the de-facto central bank that can make any change to the
system would greatly undermine the system's value.

Hard forking changes require that ultimately every participant in the
system adopts the new rules. I find it immoral and dangerous to merge
such a change without extremely widespread agreement. I am personally
fine with a short-term small block size bump to kick the can down the
road if that is what the ecosystem desires, but I can only agree with
merging it in Core if I'm convinced that there is no strong opposition
to it from others.

Soft forks on the other hand only require a majority of miners to
accept them, and everyone else can upgrade at their leisure or not at
all. Yes, old full nodes after a soft fork are not able to fully
validate the rules new miners enforce anymore, but they do still
verify the rules that their operators opted to enforce. Furthermore,
they can't be prevented. For that reason, I've proposed, and am
working hard, on an approach that includes Segregated Witness as a
first step. It shows the ecosystem that something is being done, it
kicks the can down the road, it solves/issues half a dozen other
issues at the same time, and it does not require the degree of
certainty needed for a hardfork.

-- 
Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[jl2012 via bitcoin-dev]

I would also like to summarize my observation and thoughts after the 
Hong Kong workshop.


1. I'm so glad that I had this opportunity to meet so many smart 
developers who are dedicated to make Bitcoin better. Regular conference 
like this is very important for a young project, and it is particularly 
important for Bitcoin, with consensus as the core value. I hope such a 
conference could be conducted at least once in 2 years in Hong Kong, 
which is visa-friendly for most people in both East and West.


2. I think some consensus has emerged at/after the conference. There is 
no doubt that segregated witness will be implemented. For block size, I 
believe 2MB as the first step is accepted by the super majority of 
miners, and is generally acceptable / tolerable for devs.


3. Chinese miners are requesting consensus among devs nicely, instead of 
using their majority hashing power to threaten the community. However, 
if I were allowed to speak for them, I think 2MB is what they really 
want, and they believe it is for the best interest of themselves and the 
whole community


4. In the miners round table on the second day, one of the devs 
mentioned that he didn't want to be seen as the decision maker of 
Bitcoin. On the other hand, Chinese miners repeatedly mentioned that 
they want several concrete proposals from devs which they could choose. 
I see no contradiction between these 2 viewpoints.


Below are some of my personal views:

5. Are we going to have a "Fee Event" / "Economic Change Event" in 2-6 
months as Jeff mentioned? Frankly speaking I don't know. As the fee 
starts to increase, spammers will first get squeezed --- which could be 
a good thing. However, I have no idea how many txs on the blockchain are 
spam. We also need to consider the effect of halving in July, which may 
lead to speculation bubble and huge legitimate tx volume.


6. I believe we should avoid a radical "Economic Change Event" at least 
in the next halving cycle, as Bitcoin was designed to bootstrap the 
adoption by high mining reward in the beginning. For this reason, I 
support an early and conservative increase, such as BIP102 or 2-4-8. 2MB 
is accepted by most people and it's better than nothing for BIP101 
proponents. By "early" I mean to be effective by May, at least 2 months 
before the halving.


7. Segregated witness must be done. However, it can't replace a 
short-term block size hardfork for the following reasons:
(a) SW softfork does not allow higher volume if users are not upgrading. 
In order to bootstrap the new tx type, we may need the help of 
altruistic miners to provide a fee discount for SW tx.
(b) In terms of block space saving, SW softfork is most efficient for 
multisig tx, which is still very uncommon
(c) My most optimistic guess is SW will be ready in 6 months, which will 
be very close to halving and potential tx volume burst. And it may not 
be done in 2016, as it does not only involve consensus code, but also 
change in the p2p protocol and wallet design


8. Duplex payment channel / Lightning Network may be viable solutions. 
However, they won't be fully functional until SW is done so they are 
irrelevant in this discussion


9. No matter what is going to be done / not done, I believe we should 
now have a clear road map and schedule for the community: a short-term 
hardfork or not? The timeline of SW? It is bad to leave everything 
uncertain and people can't well prepared for any potential radical 
changes


10. Finally, I hope this discussion remains educated and evidence-based, 
and no circling

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

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jeff Garzik via bitcoin-dev]

On Wed, Dec 16, 2015 at 4:24 PM, Jorge Timón  wrote:

> Assuming we adopt bip102, eventually you will be able to say exactly the
> same about 2 MB. When does this "let's not change the economics" finishes
> (if ever)?
>

The question is answered in the original email.

In the short term, the risk of a Fee Event and lack of solid post-Fee-Event
economic plan implies "short term bump" reduces those risks.

It is also true - as noted in [1], a bump does create the danger of long
term moral hazard.

This is why a bump should be accompanied with at least a weak public
commitment to flexcap or a similar long term proposal, as the original
email recommended.  Communicate clearly the conditions for future change,
then iterate as needs and feedback indicate.



[1] http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Dave Scotese via bitcoin-dev]

On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I indeed think we can communicate much better that deciding consensus
> rules is not within our power.

I'm not a core dev, so maybe I have the power to change the consensus
rules.  No one has that power, actually, at least not legitimately.  All we
can do is build it and hope enough people find it acceptable to adopt.  Who
doesn't want to hard fork to 2MB blocks on May 5th and why not?

I have a bitcoin to be split up among all those who suffer from a May 5,
2016 hardfork to 2MB blocks if they can prove it to me, or prove it to
enough engineers that I succumb to peer pressure.  I would have to respect
the engineers though.

There!

Now that we've agreed to have a hard fork on May 5th, 2016, we might decide
to implement some other methods of avoiding the FFM, like braiding the
blockchain or flexcap, or just let anyone mining on top of a block make one
that is a five or ten Kb larger.

notplato

On Wed, Dec 16, 2015 at 2:27 PM, Jeff Garzik via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Dec 16, 2015 at 1:36 PM, jl2012  wrote:
>
>> 4. In the miners round table on the second day, one of the devs mentioned
>> that he didn't want to be seen as the decision maker of Bitcoin. On the
>> other hand, Chinese miners repeatedly mentioned that they want several
>> concrete proposals from devs which they could choose. I see no
>> contradiction between these 2 viewpoints.
>>
>
> This was a very interesting dynamic, and seems fair (menu).
>
>
>
>> 6. I believe we should avoid a radical "Economic Change Event" at least
>> in the next halving cycle, as Bitcoin was designed to bootstrap the
>> adoption by high mining reward in the beginning. For this reason, I support
>> an early and conservative increase, such as BIP102 or 2-4-8. 2MB is
>> accepted by most people and it's better than nothing for BIP101 proponents.
>> By "early" I mean to be effective by May, at least 2 months before the
>> halving.
>>
>
> That was precisely my logic for picking May 5 as the hard fork date.  Some
> buffer before halving, enough for caution and iteration in the meantime.
>
>
>
>
>
>
>>
>> (c) My most optimistic guess is SW will be ready in 6 months, which will
>> be very close to halving and potential tx volume burst. And it may not be
>> done in 2016, as it does not only involve consensus code, but also change
>> in the p2p protocol and wallet design
>>
>
> Not just wallet design -- you have to game through the standard steps of:
>  update dev lib (bitcoin-core.js/bitcoinj) + release cycle, update app +
> release cycle, for most actors in the ecosystem, on top of the Bitcoin Core
> roll out.
>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy  and Meme Racing
 (in alpha).
I'm the webmaster for The Voluntaryist  which
now accepts Bitcoin.
I also code for The Dollar Vigilante .
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev