public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: jl2012 <jl2012@xbt.hk>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect
Date: Sat, 19 Dec 2015 11:49:25 -0500	[thread overview]
Message-ID: <b19eb676c18ba451605cb02159541dd9@xbt.hk> (raw)

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






             reply	other threads:[~2015-12-19 16:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-19 16:49 jl2012 [this message]
2015-12-19 17:43 ` [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect Peter Todd
2015-12-19 18:37   ` Santino Napolitano
2015-12-19 18:48     ` Peter Todd
2015-12-20  3:37   ` Chris Priest
2015-12-19 17:55 ` Justus Ranvier
2015-12-20  1:19 ` Douglas Roark

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=b19eb676c18ba451605cb02159541dd9@xbt.hk \
    --to=jl2012@xbt.hk \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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