public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
To: Alphonse Pace <alp.bitcoin@gmail.com>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Some real-world results about the current Segwit Discount
Date: Tue, 9 May 2017 10:49:05 -0300	[thread overview]
Message-ID: <CAKzdR-on-w9EF+2hLjchdyHB1gj7fi4QnybA=J4Cz7yyN3KKNA@mail.gmail.com> (raw)
In-Reply-To: <CAMBsKS_j7Lso6fHoMPkrQ7UFwKfxOERAAqL=aUF83O4CqL+iFg@mail.gmail.com>

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

This [1] article says the current discount prevents witness spam. Witness
spam is free space in the witness part of the block that can be filled by
miners to create bigger blocks with almost no cost for the benefit a
cluster of miners with low latency, increasing centralization.

The 75% discount does not prevent it, but on the contrary leaves a lot of
extra witness space for spam.

If the maximum block weight is set to 2.7M, each byte of non-witness block
costs 1.7, and each byte of witness costs 1, then a normal filled block
would be 2.7M bytes (1.7+1), and there will be no need to create ever a 4
Mbyte block. The worst case would be the average case, and the transaction
rate would be the maximum possible.

The current 75% discount can only achieve more transactions per second if
the type of transactions change. Therefore the current 75% discount only
makes the block size worst case worse (4 Mbytes when it should be 2.7
Mbytes).

80% of all inputs/outputs are P2PKH. The only way to make use of the extra
witness
space If most P2PKH transactions are replaced by multisigs (typically for
LN).

So it seems the 75% discount has been chosen with the idea that in the
future the current transaction pattern will shift towards multisigs. This
is not a bad idea, as it's the only direction Bitcoin can scale without a
HF.
But it's a bad idea if we end up doing, for example, a 2X blocksize
increase HF in the future. In that case it's much better to use a 50%
witness discount, and do not make scaling risky by making the worse case
block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.

I've uploaded the code here:
https://github.com/SergioDemianLerner/SegwitStats

 [1] https://segwit.org/why-a-discount-factor-of-4-why-not-
2-or-8-bbcebe91721e.


On Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Sergio,
>
> I'm not sure what the data you present has to do with the discount.  A 75%
> discount prevents witness spam precisely because it is 75%, nothing more.
> The current usage simply gives a guideline on how much capacity is gained
> through a particular discount.  With the data you show, it would imply that
> those blocks, with SegWit used where possible, would result in blocks of
> ~1.8MB.
>
>
>
> On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I have processed 1000 blocks starting from Block #461653.
>>
>> I computed several metrics, including the supposed size of witness data
>> and non-witness data (onchain), assuming all P2SH inputs/outputs are
>> converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH.
>>
>> This takes into account that other types of transactions will not be
>> modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't
>> take into account that LN transactions may affect the current state,
>>  increasing the segwit/nosegwit ratio.
>>
>> Among a lot of information, I've got the following real world results...
>>
>> acMainChainSpace =352608924
>> acSegwitSpace =599400403
>> Ratio segwit/nosegwit=1.6999
>>
>> This implies that the 75% that discount is not the best option to prevent
>> witness spam in a block of 4 MB, as stated in
>> https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e
>> .
>>
>> The non-witness data weight factor should not be 4 but 2.35. The closest
>> integer value is 2, which leads to a 50% witness discount.
>>
>> The Bitcoinj source code is available for anyone to review. I encourage
>> anyone to re-compute this with another utility to cross-check. Maybe
>> Antoine Le Calvez (p2sh.info) would like to double-check.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 6245 bytes --]

  reply	other threads:[~2017-05-09 13:49 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-08 22:42 [bitcoin-dev] Some real-world results about the current Segwit Discount Sergio Demian Lerner
2017-05-08 23:47 ` Alphonse Pace
2017-05-09 13:49   ` Sergio Demian Lerner [this message]
2017-05-09 14:33     ` James Hilliard
2017-05-09 15:45     ` Johnson Lau
2017-05-09 16:19       ` Sergio Demian Lerner
2017-05-09 16:27         ` Johnson Lau
2017-05-09 16:27         ` James Hilliard
2017-05-09 18:15     ` Matt Corallo
2017-05-09 18:58       ` Sergio Demian Lerner
2017-05-09 19:15         ` Sergio Demian Lerner
2017-05-09 19:30           ` Gregory Maxwell
2017-05-09 19:42             ` Matt Corallo
2017-05-09 20:13               ` Gregory Maxwell
2017-05-09 20:58                 ` Sergio Demian Lerner
2017-05-10  5:37                   ` Jorge Timón
2017-05-10 14:05                   ` Matt Corallo
2017-05-10 15:25                     ` Sergio Demian Lerner
2017-05-10 16:39                       ` Matt Corallo
2017-05-10 19:40                         ` Sergio Demian Lerner
2017-05-08 23:56 ` Gregory Maxwell

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='CAKzdR-on-w9EF+2hLjchdyHB1gj7fi4QnybA=J4Cz7yyN3KKNA@mail.gmail.com' \
    --to=sergio.d.lerner@gmail.com \
    --cc=alp.bitcoin@gmail.com \
    --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