From: Anthony Towns <aj@erisian•com.au>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
Date: Mon, 21 Dec 2015 18:07:47 +1000 [thread overview]
Message-ID: <20151221080747.GA24839@sapphire.erisian.com.au> (raw)
In-Reply-To: <CADJgMzuk9Q09AnmR5=77p0HfkeUWOTRSNCSkAAQN0zDq4Hsbqw@mail.gmail.com>
On Mon, Dec 21, 2015 at 05:21:55AM +0000, Btc Drak via bitcoin-dev wrote:
> On Mon, Dec 21, 2015 at 4:33 AM, Pieter Wuille via bitcoin-dev <
> > So I'd like to ask the community that we work towards this plan, as it
> > allows to make progress without being forced to make a possibly divisive
> > choice for one hardfork or another yet.
> Thank you for saying this. I also think the plan is solid and delivers
> multiple benefits without being contentious. The number of wins are so
> numerous, it's frankly a no-brainer.
+1's are off-topic, but... +1. My impression is that each of libsecp256k1,
versionbits, segregated witness, IBLT, weak blocks, and OP_CSV have
been demonstrated to be significant improvements that are implementable,
and don't introduce any new attacks or risks [0]. There's some freaking
awesome engineering that's gone into all of those.
> I guess the next step for segwit is a BIP and deployment on a testnet?
I think the following proposed features are as yet missing from Pieter's
segwit branch, and I'm guessing patches for them would be appreciated:
- enforcing the proposed base+witness/4 < 1MB calculation
- applying limits to sigops seen in witness signatures
I guess there might be other things that still need to be implemented
as well (and presumably bugs of course)?
I think I'm convinced that the proposed plan is the best approach (as
opposed to separate base<1MB, witness<3MB limits, or done as a hard fork,
or without committing to a merkle head for the witnesses, eg), though.
jl2012 already pointed to a draft segwit BIP in another thread, repeated
here though:
https://github.com/jl2012/bips/blob/segwit/bip-segwit.mediawiki
Cheers,
aj (hoping that was enough content after the +1 to not get modded ;)
[0] I'm still not persuaded that even a small increase in blocksize
doesn't introduce unacceptable risks (frankly, I'm not entirely
persuaded the *current* limits don't have unacceptable risk) and that
frustrates me no end. But I guess (even after six months of reading
arguments about it!) I'm equally unpersuaded that there's actually
more to the intense desire for more blocksize is anything other than
fear/uncertainty/doubt mixed with a desire for transactions to be
effectively free, rather than costing even a few cents each... So,
personally, since the above doesn't really resolve that quandry
for me, it doesn't really resolve the blocksize debate for me
either. YMMV.
next prev parent reply other threads:[~2015-12-21 8:07 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-07 22:02 Gregory Maxwell
2015-12-07 22:54 ` Bryan Bishop
2015-12-08 2:42 ` Anthony Towns
2015-12-08 4:58 ` Anthony Towns
2015-12-08 5:21 ` Gregory Maxwell
2015-12-08 6:54 ` Anthony Towns
2016-01-18 12:02 ` Anthony Towns
2016-01-22 9:46 ` Anthony Towns
2015-12-08 11:07 ` Wladimir J. van der Laan
2015-12-08 11:14 ` Jorge Timón
2015-12-08 15:12 ` Gavin Andresen
2015-12-08 15:55 ` Justus Ranvier
2015-12-08 17:41 ` Mark Friedenbach
2015-12-08 18:43 ` Justus Ranvier
2015-12-08 19:08 ` Tier Nolan
2015-12-08 19:31 ` Gregory Maxwell
2015-12-08 23:40 ` Jonathan Toomim
2015-12-08 23:48 ` Luke Dashjr
2015-12-09 0:54 ` Jonathan Toomim
2015-12-08 23:50 ` Jorge Timón
2015-12-09 0:56 ` Jonathan Toomim
2015-12-08 23:59 ` Gregory Maxwell
2015-12-09 0:58 ` Jorge Timón
2015-12-09 1:02 ` Jorge Timón
2015-12-09 1:09 ` Gavin Andresen
2015-12-09 1:31 ` Gregory Maxwell
2015-12-09 4:44 ` Ryan Butler
2015-12-09 6:29 ` Gregory Maxwell
2015-12-09 6:36 ` Ryan Butler
2015-12-09 6:59 ` Mark Friedenbach
2015-12-09 7:17 ` Gregory Maxwell
2015-12-09 7:54 ` Jorge Timón
2015-12-09 8:03 ` Gregory Maxwell
2015-12-09 8:46 ` Mark Friedenbach
2015-12-09 11:08 ` Jorge Timón
2015-12-09 16:40 ` Gavin Andresen
2015-12-11 16:18 ` Jorge Timón
2015-12-11 16:43 ` Gavin Andresen
2015-12-12 5:13 ` digitsu
2015-12-12 15:18 ` Mark Friedenbach
2015-12-14 11:21 ` Jonathan Toomim
2015-12-14 12:44 ` Adam Back
2015-12-09 4:51 ` Anthony Towns
2015-12-09 14:51 ` Chris
[not found] ` <CAPWm=eUomq6SBC0ky0WSs5=_G942vigm4RmgYuq0O-yJ-vqC2A@mail.gmail.com>
[not found] ` <CAPg+sBig9O5+he0PWhTkX5iin14QLz5+eCCu6KfwU=DxntKYtg@mail.gmail.com>
2015-12-21 4:33 ` Pieter Wuille
2015-12-21 4:42 ` Justus Ranvier
2015-12-21 4:44 ` Alex Morcos
2015-12-21 4:50 ` Mark Friedenbach
2015-12-21 5:29 ` Douglas Roark
2015-12-21 5:21 ` Btc Drak
2015-12-21 8:07 ` Anthony Towns [this message]
2015-12-21 9:56 ` Jorge Timón
2015-12-08 23:48 ` Jonathan Toomim
2015-12-09 0:23 ` Gregory Maxwell
[not found] ` <CAAS2fgRP8bLWZoKR9-iJS-2RKTGQQ9NG-LpAfa2BOdcR=GuB_A@mail.gmail.com>
2015-12-09 0:40 ` Jonathan Toomim
2015-12-09 12:28 Daniele Pinna
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=20151221080747.GA24839@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