From: Jonathan Toomim <j@toom•im>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segregated Witness features wish list
Date: Mon, 14 Dec 2015 19:44:34 +0800 [thread overview]
Message-ID: <05E42ED2-8F04-4018-B137-74D79BD46348@toom.im> (raw)
In-Reply-To: <b13f6152767473dcf44a1d8965fdd32c@xbt.hk>
[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]
1. I think we should limit the sum of the block and witness data to nBlockMaxSize*7/4 per block, for a maximum of 1.75 MB total. I don't like the idea that SegWit would give us 1.75 MB of capacity in the typical case, but we have to have hardware capable of 4 MB in adversarial conditions (i.e. intentional multisig). I think a limit to the segwit size allays that concern.
2. I think that segwit is a substantial change to how Bitcoin works, and I very strongly believe that we should not rush this. It changes the block structure, it changes the transaction structure, it changes the network protocol, it changes SPV wallet software, it changes block explorers, and it has changes that affect most other parts of the Bitcoin ecosystem. After we decide to implement it, and have a final version of the code that will be merged, we should give developers of other Bitcoin software time to implement code that supports the new transaction/witness formats.
When you guys say "as soon as possible," what do you mean exactly?
On Dec 10, 2015, at 2:47 PM, jl2012--- via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> It seems the current consensus is to implement Segregated Witness. SW opens many new possibilities but we need a balance between new features and deployment time frame. I'm listing by my priority:
>
> 1-2 are about scalability and have highest priority
>
> 1. Witness size limit: with SW we should allow a bigger overall block size. It seems 2MB is considered to be safe for many people. However, the exact size and growth of block size should be determined based on testing and reasonable projection.
>
> 2. Deployment time frame: I prefer as soon as possible, even if none of the following new features are implemented. This is not only a technical issue but also a response to the community which has been waiting for a scaling solution for years
>
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]
next prev parent reply other threads:[~2015-12-14 11:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-10 6:47 jl2012
2015-12-10 8:26 ` Gregory Maxwell
2015-12-10 8:28 ` Bryan Bishop
2015-12-10 9:51 ` Gregory Maxwell
2015-12-13 15:25 ` jl2012
2015-12-13 18:07 ` Pieter Wuille
2015-12-13 18:41 ` jl2012
2015-12-10 12:54 ` Tamas Blummer
2015-12-12 0:43 ` Jannes Faber
2015-12-13 20:34 ` Rusty Russell
2015-12-14 11:44 ` Jonathan Toomim [this message]
2015-12-14 12:32 Adam Back
2015-12-14 12:50 ` Jonathan Toomim
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=05E42ED2-8F04-4018-B137-74D79BD46348@toom.im \
--to=j@toom$(echo .)im \
--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