[bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect

[bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect

[jl2012]

I have done some calculation for the effect of a SW softfork on the 
actual total block size.

Definitions:

Core block size (CBS): The block size as seen by a non-upgrading full 
node
Witness size (WS): The total size of witness in a block
Total block size (TBS): CBS + WS
Witness discount (WD): A discount factor for witness for calculation of 
VBS (1 = no discount)
Virtual block size (VBS): CBS + (WS * WD)
Witness adoption (WA): Proportion of new format transactions among all 
transactions
Prunable ratio (PR): Proportion of signature data size in a transaction

With some transformation it could be shown that:

  TBS = CBS / (1 - WA * PR) = VBS / (1 - WA * PR * (1 - WD))

sipa suggested a WD of 25%.

The PR heavily depends on the transaction script type and input-output 
ratio. For example, the PR of 1-in 2-out P2PKH and 1-in 1-out 2-of-2 
multisig P2SH are about 47% and 72% respectively. According to sipa's 
presentation, the current average PR on the blockchain is about 60%.

Assuming WD=25% and PR=60%, the MAX TBS with different MAX VBS and WA is 
listed at:

http://i.imgur.com/4bgTMRO.png

The highlight indicates whether the CBS or VBS is the limiting factor.

With moderate SW adoption at 40-60%, the total block size is 1.32-1.56MB 
when MAX VBS is 1.25MB, and 1.22-1.37MB when MAX VBS is 1.00MB.

P2SH has been introduced for 3.5 years and only about 10% of bitcoin is 
stored this way (I can't find proportion of existing P2SH address). A 
1-year adoption rate of 40% for segwit is clearly over-optimistic unless 
the tx fee becomes really high.

(btw the PR of 60% may also be over-optimistic, as using SW nested in 
P2SH will decrease the PR, and therefore TBS becomes even lower)

I am not convinced that SW softfork should be the *only* short term 
scalability solution

Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

On Sat, Dec 19, 2015 at 11:49:25AM -0500, jl2012 via bitcoin-dev wrote:
> I have done some calculation for the effect of a SW softfork on the
> actual total block size.

Note how the fact that segwit needs client-side adoption to enable an
actual blocksize increase can be a good thing: it's a clear sign that
the ecosystem as a whole has opted-into a blocksize increase.

Not as good as a direct proof-of-stake vote, and somewhat coercive as a
vote as you pay lower fees, but it's an interesting side-effect.

-- 
'peter'[:-1]@petertodd.org
00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect

[Justus Ranvier]

[-- Attachment #1.1: Type: text/plain, Size: 961 bytes --]

On 12/19/2015 10:49 AM, jl2012 via bitcoin-dev wrote:
> I am not convinced that SW softfork should be the *only* short term
> scalability solution

I don't think SW is relevant at all with respect to scalability.

Fraud proofs are extremely important from a security perspective. The
network as it exists now places too much trust in miners. Creating a way
for non-full node clients to reject chains with contain invalid
transactions regardless of how much hashing power produces the invalid
chains is essential for the security of the network.

Adding a fraud proof system into blocks means that other features, like
committed UTXO sets, become less unsafe to deploy.

Solving transaction malleability is a very nice to have feature.

A scalability solution, IMHO, is "how do we buy some time to allow
continue usage growth while working on creating a situation where it
becomes safe to eliminate maximum block size as a consensus rule?"


[-- Attachment #1.2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 23699 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect

[Santino Napolitano]

I disagree. I think all client-side adoption of SW reliably tells you is that those implementers saw value in it greater than the cost of implementation. It's possible what they valued was the malleability fix and didn't see the limited potential circumvention of MAX_BLOCK_SIZE material to their decision.

They could just as easily attach an OP_RETURN output to all of their transactions which pushes "big blocks please" which would more directly indicate their preference for larger blocks. You could also let hand-signed letters from the heads of businesses explicitly stating their desire speak for their intentions vs. any of this nonsense. Or the media interviews, forum comments, tweets, etc...

19.12.2015, 20:43, "Peter Todd via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>:
> On Sat, Dec 19, 2015 at 11:49:25AM -0500, jl2012 via bitcoin-dev wrote:
>>  I have done some calculation for the effect of a SW softfork on the
>>  actual total block size.
>
> Note how the fact that segwit needs client-side adoption to enable an
> actual blocksize increase can be a good thing: it's a clear sign that
> the ecosystem as a whole has opted-into a blocksize increase.
>
> Not as good as a direct proof-of-stake vote, and somewhat coercive as a
> vote as you pay lower fees, but it's an interesting side-effect.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d
> ,
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]

On Sat, Dec 19, 2015 at 09:37:06PM +0300, Santino Napolitano wrote:
> I disagree. I think all client-side adoption of SW reliably tells you is that those implementers saw value in it greater than the cost of implementation. It's possible what they valued was the malleability fix and didn't see the limited potential circumvention of MAX_BLOCK_SIZE material to their decision.
> 
> They could just as easily attach an OP_RETURN output to all of their transactions which pushes "big blocks please" which would more directly indicate their preference for larger blocks. You could also let hand-signed letters from the heads of businesses explicitly stating their desire speak for their intentions vs. any of this nonsense. Or the media interviews, forum comments, tweets, etc...

Note that English-language measures of Bitcoin usage/activity are very
misleading, as a significant - probably super majority - of economnic
activity happens outside the English language, Western world.
Centralized forums such as twitter and reddit are easily censored and
manipulated. Finally, we can't discount the significant amount of
non-law-abiding Bitcoin economic activity that does happen, and I do not
believe we should adopt consensus-building processes that shut those
stakeholders out of the discussion.

As an aside, I have a friend of mine who made a Bitcoin related product
with non-culturally-specific appeal.  I asked where she was shipping her
product, and it turned out that a super majority went to
non-English-speaking countries. (she might be willing to go on public
record about this; I can ask)

-- 
'peter'[:-1]@petertodd.org
00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect

[Douglas Roark]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2015/12/19 08:49, jl2012 via bitcoin-dev wrote:
> P2SH has been introduced for 3.5 years and only about 10% of
> bitcoin is stored this way (I can't find proportion of existing
> P2SH address). A 1-year adoption rate of 40% for segwit is clearly
> over-optimistic unless the tx fee becomes really high.

I don't think one can necessarily conflate P2SH and SegWit uptake. In
the case of P2SH, there's the "if it ain't broke, don't fix it"
problem. P2PKH works just fine for an awful lot of Bitcoin users. Why
should they switch over to P2SH? In the absence of a compelling
reason, they'll probably stick to a proven solution. (You can see that
line of thinking anywhere.) Even Armory, which values security and
whiz-bang features over usability, offers P2SH but keeps it off by
default.

Meanwhile, SegWit fixes multiple problems, or at least fixes some
while also sticking a bit of gum on others. True, it'll rely on wallet
uptake. I just think wallet developers will see the value in it. The
big question, of course, is when they'll enable it by default, which
is the only way SegWit will gain serious traction. My personal,
semi-educated guess is that you'll see 3-6 months of wallet
integration and testnet tweaking, then another 3-6 months of mainnet
availability if explicitly enabled by the user, and finally the switch
being thrown for all wallet users. I'm hoping for the aggressive
timeframes. I'm expecting the conservative ones.

Is 40% optimistic? Maybe, and I'd personally like to see it enabled in
concert with a minimal block size increase. I don't think 40% within a
year of deployment is out of the realm of possibility, though.

- -- 
- ---
Douglas Roark
Cryptocurrency, network security, travel, and art.
https://onename.com/droark
joroark@vt.edu
PGP key ID: 26623924
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWdgI/AAoJEEOBHRomYjkkZwsP/iZT+qa/Yp2xIE6ConcTrbbx
IOmz6h4O+ro/Egx/6XrukBSRybn8gsjize279WQWjR0h7O3KS4YAGuR/TKx6IrOw
cz7lZpwC08ZcZb83fUqEqz4q/Rbgp4cPU8WU1niLCYg2OCGqtTEhSSRatmO1ULXp
6KJrBCaoVBzaoqFXx6nXiJF/K1dKZsb/IuFFJZisXEmoDkvTunE82sjHZ+JgmHk9
jhhlk+JU43C7lXXkk+3KPbD+z3dMZNDYrIopaWOUXfk6yXIp8cy7MUK/z58PCm8C
V/pTk0edkMIRxu6ybJLKNNZHqhSQipyEMfG/CojVb6Qtt8zC0RIEUsYj5uDk9RQL
ITxql9RtPHQPx+uoxoCr7Zitx0448YFNpQs6S5/g81vDt7ilh5k5PgnILkMvuA7Y
F6abFvsP/ahmAkisiyDzwMmcM+xzxvJkaY9aDvKy4NNiFw8kUxkAJ2VlMeQvwVTK
2ePzyrFTOGFJRk/a1uTr0aUOxpCdI8rB1O6jcrhmLl2ENRMjN1I3Ksl79Q6h3P+F
zj3hR9CyuXrzoPxAISYF58ot32fil9nEnLcchu2mdWArYKBY2IDWVv7JiK8RCJ8b
2XymxccKsXIUHTrYJfrHg+AeRHkVuV8emyUp95A/8kb8meWbLbmpxOrt6JLEE4k9
qsl9Zkg/0IsCr+JzE6Ko
=696M
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect

[Chris Priest]

By that same logic, any wallet that implemented P2SH is also voting
for an increased block size, since P2SH results in smaller
transactions, in the same way SW results in smaller transactions.

On 12/19/15, Peter Todd via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Sat, Dec 19, 2015 at 11:49:25AM -0500, jl2012 via bitcoin-dev wrote:
>> I have done some calculation for the effect of a SW softfork on the
>> actual total block size.
>
> Note how the fact that segwit needs client-side adoption to enable an
> actual blocksize increase can be a good thing: it's a clear sign that
> the ecosystem as a whole has opted-into a blocksize increase.
>
> Not as good as a direct proof-of-stake vote, and somewhat coercive as a
> vote as you pay lower fees, but it's an interesting side-effect.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d
>