From: "Jorge Timón" <jtimon@jtimon•cc>
To: Natanael <natanael.l@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments
Date: Sun, 2 Apr 2017 06:57:48 +0200 [thread overview]
Message-ID: <CABm2gDqMGBiwZppcyt6yF2sMJVs=nCr0M8u4H_22QDMR3wCFxQ@mail.gmail.com> (raw)
In-Reply-To: <CAAt2M1835S3YYJ_p0_zvDR9U6EfYAt7SWTAEPNHnNfgstKpgMg@mail.gmail.com>
On Sat, Apr 1, 2017 at 5:34 PM, Natanael <natanael.l@gmail•com> wrote:
> Den 1 apr. 2017 16:07 skrev "Jorge Timón" <jtimon@jtimon•cc>:
> On Sat, Apr 1, 2017 at 3:15 PM, Natanael <natanael.l@gmail•com> wrote:
>> Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev"
>> <bitcoin-dev@lists•linuxfoundation.org>:
>> Segwit replaces the 1 mb size limit with a weight limit of 4 mb.
>> That would make it a hardfork, not a softfork, if done exactly as you say.
> No, because of the way the weight is calculated, it is impossible to
> create a block that old nodes would perceive as bigger than 1 mb
> without also violating the weight limit.
> After segwit activation, nodes supporting segwit don't need to
> validate the 1 mb size limit anymore as long as they validate the
> weight limit.
>
> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Block_size
>
> Huh, that's odd. It really does still count raw blockchain data blocksize.
It's not odd, it's just counter-intuitive. How can "< 4 mb weight" be
a more restrictive rule than "< 1 mb size"? Well, it is, that's why
segwit's size increase is a softfork.
It is not that hard once you look at the actual weight formula:
segregated_sigs_sise + (other_size * 4) < 4 "mb"
It is impossible to produce to produce a block that violates the 1 mb
size limit but doesn't violate the 4 mb weight limit too.
There can be block that are < 1 mb size but 20 mb in weight, but those
are invalid according to the new 4 mb weight rule.
At the same time, any block that violates the < 1 mb rule for old
nodes will be invalid not only to old nodes but also to any node
validating the new 4mb rule. This is not by chance but a design choice
for any block size increase within segwit to remain a softfork, which
is what can be deployed faster.
One extreme example would be any 1 mb block today. 1 "mb" of a block
today times 4 is 4 mb, so it complies with the new 4 mb weight rule.
The opposite extreme example would be 4 mb of signatures and 0 mb of
"other data", but this example is not really possible in practice
because signatures need some tx to be part of to be part of the block
itself.
The most extreme examples I have seen on testnet are 3.7 mb blocks,
but those don't represent the average usage today (whenever you read
this).
One common misunderstanding is that users who aren't using payment
channels (that includes lightning but also other smart contracts) or
users that aren't using mutlisig can't enjoy the so called "discount":
there's no reasonable argument for rejecting the "discount" on your
own transactions once/if segwit gets activated.
I would prefer to call the absence of "discount" *penalization*.
Signatures are unreasonable penalized pre-segwit, and there's more
things that remain unreasonably penalized with respect to their
influence on the current utxo after segwit. But signatures are by far
the biggest in data space and validation time, and the most important
unreasonable yet unintended penalization pre-segwit.
> It just uses a ratio between how many units each byte is worth for block
> data vs signature data, plus a cap to define the maximum. So the current max
> is 4 MB, with 1 MB of non-witness blockchain data being weighted to 4x = 4
> MB. That just means you replaced the two limits with one limit and a ratio.
Exactly, once one maximum limit is defined, no need for two limits.
But the current max is 1 mb size, not 4 mb weight until/unless segwit
is activated.
Some people complain about 4 mb weight not being as much as 4 mb size,
and that is correct, but both are bigger than 1 mb size.
> A hardfork increasing the size would likely have the ratio modified too.
If the single ratio needs to be modified, it can be modified now
before any rule changes are activated, no need to change the consensus
rules more than needed.
> With exactly the same effect as if it was two limits...
If you don't see any disadvantage on having one single limit if/when
segwit gets activated, I don't see the point of maintaining two
limits, but if you're happy to maintain the branch with the redundant
one you may get my ack: I don't see any disadvantage on checking the
same thing twice besides performance,
> Either way, there's still going to be non-segwit nodes for ages.
That's precisely why it's good segwit has been designed to be backward
compatible as a bip9 softfork.
next prev parent reply other threads:[~2017-04-02 4:57 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-31 21:09 Sergio Demian Lerner
2017-03-31 21:18 ` Matt Corallo
2017-03-31 21:22 ` praxeology_guy
2017-03-31 21:50 ` Sergio Demian Lerner
2017-03-31 21:22 ` Matt Corallo
2017-03-31 22:13 ` Sergio Demian Lerner
2017-04-01 3:03 ` Samson Mow
2017-04-01 3:35 ` Sergio Demian Lerner
2017-06-02 20:04 ` Erik Aronesty
2017-04-01 6:55 ` Jared Lee Richardson
2017-04-01 11:44 ` Sergio Demian Lerner
2017-04-01 12:33 ` Jorge Timón
2017-04-01 13:15 ` Natanael
2017-04-01 14:07 ` Jorge Timón
[not found] ` <CAAt2M1_gDzEuDLSvVsJARvdCAtUyM3Yuu7TT25sbm3L-Zi6+0Q@mail.gmail.com>
[not found] ` <CAAt2M18=Tjw+05QCv6G7Abv=idB6ONgU9xvtrR=fn731452_mg@mail.gmail.com>
2017-04-01 15:34 ` Natanael
2017-04-02 4:57 ` Jorge Timón [this message]
2017-04-02 10:03 ` Natanael
2017-04-02 11:43 ` Jorge Timón
2017-06-02 20:04 ` Erik Aronesty
2017-06-02 21:51 ` Sergio Demian Lerner
2017-06-03 0:53 ` Erik Aronesty
2017-06-03 2:03 ` Oliver Petruzel
2017-06-03 21:05 ` Oliver Petruzel
2017-04-03 14:40 ` Btc Drak
2017-04-06 2:27 ` Erik Aronesty
2017-04-06 20:58 ` Sergio Demian Lerner
2017-04-06 20:42 ` Sergio Demian Lerner
2017-04-06 21:03 ` Sergio Demian Lerner
2017-04-06 22:29 ` Aymeric Vitte
2017-06-02 12:29 ` R E Broadley
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='CABm2gDqMGBiwZppcyt6yF2sMJVs=nCr0M8u4H_22QDMR3wCFxQ@mail.gmail.com' \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=natanael.l@gmail$(echo .)com \
/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