Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Sergio Demian Lerner via bitcoin-dev]

I'm not advocating. I'm mediating.


This is out of

On Wed, May 10, 2017 at 1:39 PM, Matt Corallo 
wrote:

> I highly disagree about the "not shit" part.  You're advocating for
> throwing away one of the key features of Segwit, something that is very
> important for Bitcoin's long-term reliability! If you think doing so is
> going to somehow help get support in a divided community, I don't
> understand how - more likely you're only going to make things significantly
> worse.
>
> On May 10, 2017 11:25:27 AM EDT, Sergio Demian Lerner <
> sergio.d.ler...@gmail.com> wrote:
> >Jaja. But no shit. Not perfect maybe, but Bitcoin was never perfect. It
> >has
> >always been good enough. And at the beginning it was quite simple.
> >Simple
> >enough it allowed gradual improvements that anyone with some technical
> >background could understand. Now we need a full website to explain an
> >improvement.
> >But this is becoming more and more out of topic.
> >
> >
> >On Wed, May 10, 2017 at 11:05 AM, Matt Corallo
> >
> >wrote:
> >
> >> I'm highly unconvinced of this point. Sure, you can change fewer
> >lines
> >> of code, but if the result is, lets be honest, shit, how do you
> >believe
> >> its going to have a higher chance of getting acceptance from the
> >broader
> >> community? I think you're over-optimizing in the wrong direction.
> >>
> >> Matt
> >>
> >> On 05/09/17 20:58, Sergio Demian Lerner wrote:
> >> > I agree with you Matt.
> >> > I'm artificially limiting myself to changing the parameters of
> >Segwit as
> >> > it is..
> >> >
> >> > This is motivated by the idea that a consensual HF in the current
> >state
> >> > would have greater chance of acceptance if it changes the minimum
> >number
> >> > of lines of code.
> >> >
> >> >
> >> >
> >> > On Tue, May 9, 2017 at 5:13 PM, Gregory Maxwell  >> > > wrote:
> >> >
> >> > On Tue, May 9, 2017 at 7:42 PM, Matt Corallo
> >> > >
> >wrote:
> >> > > at beast.
> >> >
> >> > Rawr.
> >> >
> >> >
> >>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Matt Corallo via bitcoin-dev]

I highly disagree about the "not shit" part.  You're advocating for throwing 
away one of the key features of Segwit, something that is very important for 
Bitcoin's long-term reliability! If you think doing so is going to somehow help 
get support in a divided community, I don't understand how - more likely you're 
only going to make things significantly worse.

On May 10, 2017 11:25:27 AM EDT, Sergio Demian Lerner 
 wrote:
>Jaja. But no shit. Not perfect maybe, but Bitcoin was never perfect. It
>has
>always been good enough. And at the beginning it was quite simple.
>Simple
>enough it allowed gradual improvements that anyone with some technical
>background could understand. Now we need a full website to explain an
>improvement.
>But this is becoming more and more out of topic.
>
>
>On Wed, May 10, 2017 at 11:05 AM, Matt Corallo
>
>wrote:
>
>> I'm highly unconvinced of this point. Sure, you can change fewer
>lines
>> of code, but if the result is, lets be honest, shit, how do you
>believe
>> its going to have a higher chance of getting acceptance from the
>broader
>> community? I think you're over-optimizing in the wrong direction.
>>
>> Matt
>>
>> On 05/09/17 20:58, Sergio Demian Lerner wrote:
>> > I agree with you Matt.
>> > I'm artificially limiting myself to changing the parameters of
>Segwit as
>> > it is..
>> >
>> > This is motivated by the idea that a consensual HF in the current
>state
>> > would have greater chance of acceptance if it changes the minimum
>number
>> > of lines of code.
>> >
>> >
>> >
>> > On Tue, May 9, 2017 at 5:13 PM, Gregory Maxwell > > > wrote:
>> >
>> > On Tue, May 9, 2017 at 7:42 PM, Matt Corallo
>> > >
>wrote:
>> > > at beast.
>> >
>> > Rawr.
>> >
>> >
>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Sergio Demian Lerner via bitcoin-dev]

Jaja. But no shit. Not perfect maybe, but Bitcoin was never perfect. It has
always been good enough. And at the beginning it was quite simple. Simple
enough it allowed gradual improvements that anyone with some technical
background could understand. Now we need a full website to explain an
improvement.
But this is becoming more and more out of topic.


On Wed, May 10, 2017 at 11:05 AM, Matt Corallo 
wrote:

> I'm highly unconvinced of this point. Sure, you can change fewer lines
> of code, but if the result is, lets be honest, shit, how do you believe
> its going to have a higher chance of getting acceptance from the broader
> community? I think you're over-optimizing in the wrong direction.
>
> Matt
>
> On 05/09/17 20:58, Sergio Demian Lerner wrote:
> > I agree with you Matt.
> > I'm artificially limiting myself to changing the parameters of Segwit as
> > it is..
> >
> > This is motivated by the idea that a consensual HF in the current state
> > would have greater chance of acceptance if it changes the minimum number
> > of lines of code.
> >
> >
> >
> > On Tue, May 9, 2017 at 5:13 PM, Gregory Maxwell  > > wrote:
> >
> > On Tue, May 9, 2017 at 7:42 PM, Matt Corallo
> > > wrote:
> > > at beast.
> >
> > Rawr.
> >
> >
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Matt Corallo via bitcoin-dev]

I'm highly unconvinced of this point. Sure, you can change fewer lines
of code, but if the result is, lets be honest, shit, how do you believe
its going to have a higher chance of getting acceptance from the broader
community? I think you're over-optimizing in the wrong direction.

Matt

On 05/09/17 20:58, Sergio Demian Lerner wrote:
> I agree with you Matt. 
> I'm artificially limiting myself to changing the parameters of Segwit as
> it is.. 
> 
> This is motivated by the idea that a consensual HF in the current state
> would have greater chance of acceptance if it changes the minimum number
> of lines of code.
> 
> 
> 
> On Tue, May 9, 2017 at 5:13 PM, Gregory Maxwell  > wrote:
> 
> On Tue, May 9, 2017 at 7:42 PM, Matt Corallo
> > wrote:
> > at beast.
> 
> Rawr.
> 
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Jorge Timón via bitcoin-dev]

If there's a better factor than 0.25 I would change it now before deploying
segwit instead of leaving it to be changed later with a hf.

On 9 May 2017 10:59 pm, "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I agree with you Matt.
> I'm artificially limiting myself to changing the parameters of Segwit as
> it is..
>
> This is motivated by the idea that a consensual HF in the current state
> would have greater chance of acceptance if it changes the minimum number of
> lines of code.
>
>
>
> On Tue, May 9, 2017 at 5:13 PM, Gregory Maxwell  wrote:
>
>> On Tue, May 9, 2017 at 7:42 PM, Matt Corallo 
>> wrote:
>> > at beast.
>>
>> Rawr.
>>
>
>
> ___
> 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

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Sergio Demian Lerner via bitcoin-dev]

I agree with you Matt.
I'm artificially limiting myself to changing the parameters of Segwit as it
is..

This is motivated by the idea that a consensual HF in the current state
would have greater chance of acceptance if it changes the minimum number of
lines of code.



On Tue, May 9, 2017 at 5:13 PM, Gregory Maxwell  wrote:

> On Tue, May 9, 2017 at 7:42 PM, Matt Corallo 
> wrote:
> > at beast.
>
> Rawr.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Gregory Maxwell via bitcoin-dev]

On Tue, May 9, 2017 at 7:42 PM, Matt Corallo  wrote:
> at beast.

Rawr.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Matt Corallo via bitcoin-dev]

There is something in between throwing the SegWit goals out the window
(as Sergio seems to be advocating for) and having a higher discount
ratio (which is required for the soft fork version to be useful).

When I first started looking at the problem I very much wanted to reduce
the worst-case block size (though have come around to caring a bit less
about that thanks to all the work in FIBRE and other similar systems
over the past year or two), but rapidly realized that just reducing the
Segwit discount wasn't really the right solution here.

You might as well take the real win and reduce the cost of the input
prevout itself so that average inputs are less expensive than outputs
(which SegWit doesn't quite achieve due to the large prevout size - 40
bytes). This way you can reduce the discount, still get the SegWit goal,
and get a lower ratio between worst-case and average-case block size,
though, frankly, I'm less interested in the last one these days, at
least for reasonable parameters. If you're gonna look at hard forks,
limiting yourself to just the parameters that we can tweak in a soft
fork seems short-sighted, at beast.

Matt

On 05/09/17 19:30, Gregory Maxwell wrote:
> On Tue, May 9, 2017 at 7:15 PM, Sergio Demian Lerner via bitcoin-dev
>  wrote:
>> The capacity of Segwit(50%)+2MbHF is 50% more than Segwit, and the maximum
>> block size is the same.
> 
> And the UTXO bloat potential is twice as large and the cost of that
> UTXO bloat is significantly reduced.  So you're basically gutting the
> most of the gain from weight, making something incompatible, etc.
> 
> I'm not sure what to explain-- even that page on segwit.org explains
> that the values are selected to balance worst case costs not to
> optimize one to the total exclusion of others. Raw size is not very
> relevant in the long run, but if your goal were to optimize for it
> (which it seems to be), then the limit should be pure size.
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Sergio Demian Lerner via bitcoin-dev]

Let n be the non-segwit bytes. Let the seg/noseg ratio be 1.7.

Segwit with 75% discount: (let WITNESS_SCALE_FACTOR=4)
n*WITNESS_SCALE_FACTOR+n*1.7 = 4,000,000
Then n=4,000,000 / 5.7 = 701K
Average block size = 701K*(1+1.7)=1.8 Mbytes
Maximum block size = 4 MBytes

Segwit with 50% discount + 2MB HF: (let WITNESS_SCALE_FACTOR=2)
n*2+n*1.7 = 4,000,000
n = 4,000,000/ 3.7 = 1.08M
Average block size = 1.08M*(1+1.7)=2.9 Mbytes
Maximum block size = 4 MBytes

The capacity of Segwit(50%)+2MbHF is 50% more than Segwit, and the maximum
block size is the same.


On Tue, May 9, 2017 at 3:58 PM, Sergio Demian Lerner <
sergio.d.ler...@gmail.com> wrote:

>
>>
>> You suggested "If the maximum block weight is set to 2.7M, each byte of
>> non-witness block costs 1.7", but these numbers dont work out - setting
>> the discount to 1.7 gets you a maximum block size of 1.7MB (in a soft
>> fork), not 2.7MB.
>
>
> Yes. In a soft-fork is true.
> I was thinking about what a HF could do to optimize the balance, and I
> forgot I was in the context of a SF.
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Sergio Demian Lerner via bitcoin-dev]

>
>
>
> You suggested "If the maximum block weight is set to 2.7M, each byte of
> non-witness block costs 1.7", but these numbers dont work out - setting
> the discount to 1.7 gets you a maximum block size of 1.7MB (in a soft
> fork), not 2.7MB.


Yes. In a soft-fork is true.
I was thinking about what a HF could do to optimize the balance, and I
forgot I was in the context of a SF.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Matt Corallo via bitcoin-dev]

I'm not sure who wrote segwit.org, but I wouldn't take it as
authoritative reasoning why we must do X over Y.

You seem to be claiming that there is not cost for a miner to fill
"extra witness space", but this is very untrue - in order to do so they
must forgo fees on other transactions. Your analysis on worst-case vs
normal-case blocks also seems flawed - there is a single limit, and not
a separate, secondary, witness limit.

You suggested "If the maximum block weight is set to 2.7M, each byte of
non-witness block costs 1.7", but these numbers dont work out - setting
the discount to 1.7 gets you a maximum block size of 1.7MB (in a soft
fork), not 2.7MB. If you set the max block weight to 2.7 with a 1.7x
discount, you have a hard fork. If you set the discount to 2.7x with a
2.7 weight limit, you dont get 2.7MB average-sized blocks, but smaller,
and still have the potential for padding blocks with pure-witness data
to create larger blocks.

Additionally, note that by padding blocks with larger witness data you
lose some of the CPU cost to validate as you no longer have as many
inputs (which have a maximal validation cost).

Further, I'm not sure why you're arguing for a given witness discount on
the basis of a future hardfork - it seems highly unlikely the community
is in a position to pull something like that off, and even if it were,
why set the witness discount with that assumption? If there were to be a
hardfork, we should probably tweak a bunch of parameters (see, eg, my
post from February of last year at
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012403.html).

Maybe you could clarify your proposal a bit here, because the way I read
it you seem to have misunderstood SegWit's discount system.

On 05/09/17 13:49, Sergio Demian Lerner via bitcoin-dev wrote:
> 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
>  > 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
>  > 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, 

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[James Hilliard via bitcoin-dev]

Doing a second soft-fork from 50% to 75% sounds more difficult since
that's going from a more restrictive ruleset to less restrictive, you
might be able to hack around it but it wouldn't be a fully backwards
compatible change like going from 75% to 50% would be. 50% vs 75% does
affect max transactions/second in practice, the exact amount depends
on the real world usage of course though.

On Tue, May 9, 2017 at 11:19 AM, Sergio Demian Lerner via bitcoin-dev
 wrote:
> Thanks Johnson and Hampus for the clarifications.
> However, I would rather do the opposite: soft-fork to 50% now, and soft-fork
> again to 75% discount later if needed, because it doesn't affect the max
> transactions/second.
>
> Segwit as it is today should be activated. However if it is not before
> November, then for the next Segwit attempt I would choose a more
> conservative 50% discount.
>
>
>
> On Tue, May 9, 2017 at 12:45 PM, Johnson Lau  wrote:
>>
>>
>> > On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev
>> >  wrote:
>> >
>> >
>> > 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.
>> >
>>
>> As we could change any parameter in a hardfork, I don’t think this has any
>> relation with the current BIP141 proposal. We could just use 75% in a
>> softfork, and change that to a different value (or completely redefine the
>> definition of weight) with a hardfork later.
>>
>>
>
>
> ___
> 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

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Johnson Lau via bitcoin-dev]

No, changing from 50% to 75% is a hardfork. (75 -> 50 is a softfork). Unless 
you make it pre-scheduled, or leave a special “backdoor” softfork to change the 
discount.

And that would certainly reduce the max tx/s with 50% discount, also reduce the 
incentive to spend witness UTXO. 

> On 10 May 2017, at 00:19, Sergio Demian Lerner  
> wrote:
> 
> Thanks Johnson and Hampus for the clarifications. 
> However, I would rather do the opposite: soft-fork to 50% now, and soft-fork 
> again to 75% discount later if needed, because it doesn't affect the max 
> transactions/second. 
> 
> Segwit as it is today should be activated. However if it is not before 
> November, then for the next Segwit attempt I would choose a more conservative 
> 50% discount.
> 
> 
> 
> On Tue, May 9, 2017 at 12:45 PM, Johnson Lau  > wrote:
> 
> > On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev 
> >  > > wrote:
> >
> >
> > 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.
> >
> 
> As we could change any parameter in a hardfork, I don’t think this has any 
> relation with the current BIP141 proposal. We could just use 75% in a 
> softfork, and change that to a different value (or completely redefine the 
> definition of weight) with a hardfork later.
> 
> 
> 


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Sergio Demian Lerner via bitcoin-dev]

Thanks Johnson and Hampus for the clarifications.
However, I would rather do the opposite: soft-fork to 50% now, and
soft-fork again to 75% discount later if needed, because it doesn't affect
the max transactions/second.

Segwit as it is today should be activated. However if it is not before
November, then for the next Segwit attempt I would choose a more
conservative 50% discount.



On Tue, May 9, 2017 at 12:45 PM, Johnson Lau  wrote:

>
> > On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >
> > 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.
> >
>
> As we could change any parameter in a hardfork, I don’t think this has any
> relation with the current BIP141 proposal. We could just use 75% in a
> softfork, and change that to a different value (or completely redefine the
> definition of weight) with a hardfork later.
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Johnson Lau via bitcoin-dev]

> On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev 
>  wrote:
> 
> 
> 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.
> 

As we could change any parameter in a hardfork, I don’t think this has any 
relation with the current BIP141 proposal. We could just use 75% in a softfork, 
and change that to a different value (or completely redefine the definition of 
weight) with a hardfork later.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[James Hilliard via bitcoin-dev]

The discount is designed to reduce UTXO bloat primarily, witness spam
data would not make it into the UTXO set. The discount brings the fee
of a transaction more in line with the actual costs to the network for
the transaction. A miner spamming the network with 4MB witness blocks
would have very little impact on the UTXO size compared with 1MB
non-witness blocks. UTXO size is a bigger issue than blockchain size
since full nodes can't prune the UTXO set.

The discount of 75% for the SegWit softfork doesn't really have any
effect on future hard forks as it can always be adjusted as needed
later on as part of a HF.

On Tue, May 9, 2017 at 8:49 AM, Sergio Demian Lerner via bitcoin-dev
 wrote:
> 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
>  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
>>  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
>>
>
>
> 

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Sergio Demian Lerner via bitcoin-dev]

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
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Alphonse Pace via bitcoin-dev]

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

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

[Gregory Maxwell via bitcoin-dev]

On Mon, May 8, 2017 at 10:42 PM, Sergio Demian Lerner via bitcoin-dev
 wrote:
> 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.

Sergio, You've provided absolutely no information to qualify your
"should be".  It sounds like you are only measuring how much data is
witness vs non-witness while completely ignoring the relative cost of
UTXO bloat?  It's perfectly acceptable to increase the worst case in
one dimension while decreasing it in another-- and thats what segwit
does.

This sounds like a misunderstanding of what the factors should have
accomplish. The non-witness factor should be as large as possible
because the prunable witness data has little to no long term cost to
the system, no cost to lite clients, etc-- as eventually the system's
survival will require transitioning to starting from a state snapshot.
But it cannot be too large because of the hyperbolic increase in worst
case bandwidth.   Also, when starting from a state snapshot security
will require starting from an old one-- otherwise the whole system
becomes much closer to SPV security, so the cost of witness data
between there and the tip will still matter.

If I had any leaning to adjust it, it would be towards five-- not
towards even lower values.

> The Bitcoinj source code is available for anyone to review.

Where is it? (I have to say, I haven't found bitcoinj based things at
all readable but it would be worth seeing.)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Some real-world results about the current Segwit Discount

[Sergio Demian Lerner via bitcoin-dev]

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