Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

From: Adam Back <adam@cypherspace•org>
To: Jeff Garzik <jgarzik@gmail•com>
Cc: Jeff Garzik via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin
Date: Thu, 17 Dec 2015 04:48:29 +0100	[thread overview]
Message-ID: <CALqxMTEqFR_HzXaBDfU8qe6KR3AJ6BziqtXHn5-dnSQ-eU8yqA@mail.gmail.com> (raw)
In-Reply-To: <CADm_WcYhPqZZ5KQ7DxyFgkk5td4ircrXwArg_guWDPWPtnCxhw@mail.gmail.com>

There are a range of opinions about input assumptions by different
people.  In each case, short of misunderstanding, if we have the same
input assumptions we're going to reach the same conclusions.  This is
the way of the world in a meritocracy.  The interesting point is to
compare the input assumptions and try to figure out which are more
realistic, pragmatic and achieve the best outcome.

It might be instructive to re-read Greg's roadmap and others to
re-read Jeff's original post (I will).

There is a proposed roadmap and soft-fork block-size increase and code
that Pieter is working on.  There has been rationale described for
this approach, and it achieves many useful things both short, mid and
long term for scale and other issues.

There seem to be a range of opinions on the fee market, and one
question is when do we deem it safe to aim to be prepared to support a
fee market.

How elastic is block-size demand?  (I think there is evidence of some
elasticity which indicates a partly working fee market already).  What
I mean by elasticity of block-size demand is there are off-chain
transactions and people make an economic choice of whether to go on
chain or not, and the vast majority of transactions, all told, are
off-chain.  Clearly it is ideal if they all go on chain, scale
permitting.

If we look at the roadmap at high-level:

1) bump (seg-wit or ...)
2) network improvements (IBLT/weak-block/other)
3) longer term dynamic block-size (flexcap)
4) write-cache (lightning)

It would probably be good to see some work on preparing for fee
markets.  That has happened somewhat recently in response to the
stress tests.  We do have an observed problem that if there is no
incentive to prepare, the improvements dont happen, and so we can
never be ready for a fee market.  That's kind of how we got here,
people were talking about fee-estimation and dynamic fees several
years ago before the block-size went from 250kB to 750kB, and then
lost interest as there was another 500kB to play with.  There could be
a best practice doc written asking people to prepare.  That might
help.

Presumably it's good if we do see the fee market more, for it to come
in gradually.  Flexcap probably helps there because the block-size
itself becomes elastic to demand (pay for bigger blocks).

If we want to avoid a fee market for the immediate term, are we more
worried about period 1, or period 2 or 3.  Probably 2 is more of a
worry as we're scaling in 1 where in period 2 we're preparing for
scaling and more time has passed for demand to grow.  That might for
example argue for seg-wit because it brings us closer to 4) and if we
spread things out we might delay the possibility to do lightning as
there is only so many cycles for forks (hard or soft) in testing,
deployment planning etc so it can be good to have a holistic view.

Also the question of time-frame that is safe for soft-forks or
hard-forks is another input where views seem to vary.  I think some
people are more optimistic about being able to avoid people losing
money in fast hard-forks.  One lesson on users, is users find failure
modes that testing cant, or do things you would expect them not to do.

Also we're calling hard-forks things that are really soft-forks to SPV
clients, and hard-forks only to full-nodes.  If we wanted to make a
real economic choice, we could artificially make an SPV hard-fork,
however that would make upgrade harder.

As I said in an earlier email I think everyone is empathetic to user
requirements, including economic desires - but Bitcoin has inherent
constraints that are complex to improve.  Each proposal is trying to
best meet those holistic user requirements.  There are no free lunches
and we dont want to economically hurt anyone in total or as a group or
type of use.  Not all requirements can be met, they are in a trade
off, so that calls for balance, planning and transparency.

This is also a market, we can discuss protocol tradeoffs without being
melodramatic - would be kind of undesirable if a dramatic or emotive
way to express something as easily or more clearly expressed in
technical constructive words is moving the price around.

Adam

On 17 December 2015 at 03:58, Jeff Garzik via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Wed, Dec 16, 2015 at 9:44 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>
>> At least SW *is* a scaling solution (albeit most of the important benefits
>> are long term). The issue of fee events has nothing to do with scaling - it
>> has to do with economics...specifically whether we should be subsidizing
>> transactions, who should pay the bill for it, etc. My own personal opinion
>> is that increasing validation costs works against adoption, not for
>> it...even if it artificially keeps fees low - and we'll have to deal with a
>> fee event sooner or later anyhow. You may disagree with my opinion, but
>> please, let's stop confounding the economic issues with actual scaling.
>
>
> At least on my part, the title of the 1st email was "It's economics & ..."
> and focused on (a) economics and (b) transition issues.  There was no
> confounding.  There was a list of real problems and risks taken when 1M is
> not lifted in the short term.
>
> Thus "SW is orthogonal" in these emails, because these problems remain
> regardless of SW or no, as the 1st email outlined.
>
> The 2nd email addresses the specific assertion of "no 1M hard fork needed,
> because SW."
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>