* [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect
@ 2015-12-19 16:49 jl2012
2015-12-19 17:43 ` Peter Todd
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: jl2012 @ 2015-12-19 16:49 UTC (permalink / raw)
To: bitcoin-dev
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect 2015-12-19 16:49 [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect jl2012 @ 2015-12-19 17:43 ` Peter Todd 2015-12-19 18:37 ` Santino Napolitano 2015-12-20 3:37 ` Chris Priest 2015-12-19 17:55 ` Justus Ranvier 2015-12-20 1:19 ` Douglas Roark 2 siblings, 2 replies; 7+ messages in thread From: Peter Todd @ 2015-12-19 17:43 UTC (permalink / raw) To: jl2012; +Cc: bitcoin-dev [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect 2015-12-19 17:43 ` Peter Todd @ 2015-12-19 18:37 ` Santino Napolitano 2015-12-19 18:48 ` Peter Todd 2015-12-20 3:37 ` Chris Priest 1 sibling, 1 reply; 7+ messages in thread From: Santino Napolitano @ 2015-12-19 18:37 UTC (permalink / raw) To: Peter Todd, jl2012; +Cc: bitcoin-dev 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect 2015-12-19 18:37 ` Santino Napolitano @ 2015-12-19 18:48 ` Peter Todd 0 siblings, 0 replies; 7+ messages in thread From: Peter Todd @ 2015-12-19 18:48 UTC (permalink / raw) To: Santino Napolitano; +Cc: bitcoin-dev [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect 2015-12-19 17:43 ` Peter Todd 2015-12-19 18:37 ` Santino Napolitano @ 2015-12-20 3:37 ` Chris Priest 1 sibling, 0 replies; 7+ messages in thread From: Chris Priest @ 2015-12-20 3:37 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-dev 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect 2015-12-19 16:49 [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect jl2012 2015-12-19 17:43 ` Peter Todd @ 2015-12-19 17:55 ` Justus Ranvier 2015-12-20 1:19 ` Douglas Roark 2 siblings, 0 replies; 7+ messages in thread From: Justus Ranvier @ 2015-12-19 17:55 UTC (permalink / raw) To: bitcoin-dev [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect 2015-12-19 16:49 [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect jl2012 2015-12-19 17:43 ` Peter Todd 2015-12-19 17:55 ` Justus Ranvier @ 2015-12-20 1:19 ` Douglas Roark 2 siblings, 0 replies; 7+ messages in thread From: Douglas Roark @ 2015-12-20 1:19 UTC (permalink / raw) To: bitcoin-dev -----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----- ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-12-20 3:37 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-12-19 16:49 [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect jl2012 2015-12-19 17:43 ` 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox