From: Anthony Towns <aj@erisian•com.au>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin
Date: Thu, 17 Dec 2015 20:57:13 +1000 [thread overview]
Message-ID: <20151217105713.GA16561@sapphire.erisian.com.au> (raw)
In-Reply-To: <9869fe48a4fc53fc355a35cead73fca2@xbt.hk>
On Thu, Dec 17, 2015 at 12:32:11AM -0500, jl2012 via bitcoin-dev wrote:
> There are at least 2 proposals on the table:
> 1. SWSF (segwit soft fork) with 1MB virtual block limit, approximately
> equals to 2MB actual limit
> 2. BIP102: 2MB actual limit
I think there's a few variants of (2) -- there's "just 2MB", "2MB now,
4MB in a while, 8MB after that", "1MB for a while longer, then 2MB,
then 4MB" (halved from 2/4/8 since segwit gives 1.6x-2x benefit), and
variations of those with different dates, whether or not to smooth out
the increases to avoid economic shocks, and how to determine activation
(flag day? miner consensus? combination?).
> Since the actual limits for both proposals are approximately the same, it is
> not a determining factor in this discussion
That's true on the benefit side (both give about double the number of
ordinary transactions per block; though segregated witness has other
benefits). On the cost side, the limits are different:
* worst case block data size is 2x for BIP102, 4x for segwit (affecting
bandwidth, latency and storage costs for nodes)
* worst case sigops is 2x for BIP102, but the same as today for segwit
(affecting block validation time)
* worst case bytes to hash a block is 4x for BIP102 (doubling block
size and sigops), but the same as today for segwit (again affecting
block validation time)
* worst case UTXO bloat is 2x for BIP102, but the same as today for
segwit (affecting memory usage, and validation time)
In the "expected" case (where people aren't attacking the blockchain)
I think they're the same on all these metrics. But increasing the
limits could easily make attacks more common, especially if it makes
them more effective.
I think the main attack vector of these is that increasing block
validation time via too many (active) sigops or too many bytes hashed
allows a selfish mining attack, but I'm not clear enough on how that
would work exactly to estimate where the boundary between acceptable and
unacceptable risk is (and how feasible non-consensus-level countermeasures
might be).
But at 1x sigops, you can already (accidently!) construct blocks that
take minutes to verify; and at 4x you can probably already construct a
block that takes 10 minutes to verify, which would probably be pretty
bad... But I'm not sure this isn't already exploitable, so maybe we're
already assuming a certain level of altruism and making things worse
doesn't actually make them worse?
I think it would be good for BIP102 or similar to include an evaluation
of that risk before being deployed [0].
> The major criticism for a hardfork is requiring everyone to upgrade. Is that
> really a big problem?
Yes. That doesn't mean it's not worth it, though.
(The 2-month timeline for the BIP50 accidental hardfork to be accepted
on the network seems persuasive to me that it's possible to roll out a
deliberate, SPV-compatible, hardfork on today's network in 3-6 months)
> My primary proposal:
> 1 Jun 2016: the first day a 2MB block may be allowed
>
> My secondary proposal:
> 1 Jun 2016: release SWSF
I think it makes sense to just do both of these independently; ie:
* release segwit via softfork ASAP (perhaps targetting March or April
to get it included in bitcoin, activation a month or three
afterwards?), with virtual block size calculated as proposed and
capped by MAX_BLOCK_SIZE [1]
* increase MAX_BLOCK_SIZE via hardfork to 2MB after block 420,000
(phased in gradually? with future scheduled increases to 4MB or 8MB?)
If segwit gets delayed because it's complicated, that's okay; if
it comes out earlier, that's okay too. If the hardfork gets delayed
because miners aren't ready or because it's better to introduce it in a
staggered fashion, or because there's no clear evaluation of the risks,
that's okay too.
But more importantly, it allows evaluate the pros and cons of each
implementation separately and on its own merits, rather than arguing
against working on one just because you're in favour of doing the
other ASAP.
They have benefits if you combine them too; for instance, if the
MAX_BLOCK_SIZE increase is phased in rather than done as a step increase
(ie block x's limit is 1MB, block x+1's limit is 1.005MB or similar,
and block x+2's limit is 1.01MB, etc) having segwit available in parallel
could provide a helpful escape valve: if an individual bitcoin user has
been dying for more capacity, they can spend the time/effort to update
their software for segwit and get it immediately without having to wait
as the consensus limits rise.
Conversely, having both segwit and a phased increase to MAX_BLOCK_SIZE
means that miners generally won't be immediately mining 2MB (or 4MB)
blocks halfway through the year, which should avoid both technological
shocks (bandwidth just doubled!) or economic shocks (supply has increased
so fees have plummeted), which could be good.
FWIW, the worst case scenarios are:
* block data size:
BIP102: 2x (worst/avg)
segwit: 4x (worst, ~2x avg)
both: 8x (worst, ~4x avg)
BIP101: 8x (worst/avg)
* sigops per block:
BIP102: 2x
segwit: 1x
both: 2x
BIP101: 8x
* bytes hashed per block:
BIP102: 4x
segwit: 1x
both: 4x
BIP101: 64x
* UTXO rate of increase:
BIP102: 2x
segwit: 1x
both: 2x
BIP101: 8x
Compared to the (expected, eventual, near-term) benefits:
* transactions per block:
BIP102: 2x
segwit: 1.6x-2x
both: 3.2x-4x
BIP101: 8x
* misc:
BIP101/2: planned hardforks are possible, bitcoin community governance
is demonstrably working, etc
segwit: malleability fixes, script improvements, lightning
enablement, etc
The block data is the only case where the average case is already just
about the worst case; for the others, as long as the worst case doesn't
inspire new attacks, the future average case should just increase in
proportion to the additional transactions.
Cheers,
aj
[0] (and segwit should actually account for sigops in witness data before
being deployed...)
[1] If segwit warrants a hardfork to clean up data structures, I think
that should be deferred until well after the MAX_BLOCK_SIZE hardfork,
rather than trying to do it at the same time. As such, doing segwit by
soft fork in the short term seems to make sense, since it also helps
with transaction malleability and further improvements to script.
next prev parent reply other threads:[~2015-12-17 10:57 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 20:38 Jeff Garzik
2015-12-16 20:50 ` Matt Corallo
2015-12-16 21:51 ` Jameson Lopp
2015-12-16 22:29 ` Matt Corallo
2015-12-16 22:32 ` Matt Corallo
2015-12-17 2:21 ` Jeff Garzik
2015-12-17 2:44 ` Eric Lombrozo
2015-12-17 2:58 ` Jeff Garzik
2015-12-17 3:48 ` Adam Back
2015-12-17 5:32 ` jl2012
2015-12-17 7:54 ` Corey Haddad
2015-12-17 13:09 ` Jorge Timón
2015-12-17 15:51 ` sickpig
2015-12-17 17:55 ` Anthony Towns
2015-12-18 10:01 ` sickpig
2015-12-19 7:50 ` Mark Friedenbach
2015-12-19 23:03 ` Dave Scotese
2015-12-17 9:33 ` Mark Friedenbach
2015-12-17 10:00 ` jl2012
2015-12-17 10:57 ` Anthony Towns [this message]
2015-12-17 6:14 ` Marcel Jamin
2015-12-16 20:59 ` Pieter Wuille
2015-12-16 21:27 ` Jeff Garzik
2015-12-16 21:36 ` Pieter Wuille
2015-12-16 22:09 ` Jeff Garzik
2015-12-16 22:10 ` Jeff Garzik
2015-12-17 18:27 ` Jeff Garzik
2015-12-17 18:46 ` jl2012
2015-12-17 18:52 ` Jeff Garzik
2015-12-17 21:18 ` Eric Lombrozo
2015-12-17 21:31 ` Adam Back
2015-12-17 3:52 ` Anthony Towns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151217105713.GA16561@sapphire.erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox