[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.

[Gregory Maxwell via bitcoin-dev]

On Mon, May 8, 2017 at 10:42 PM, Sergio Demian Lerner via bitcoin-dev

Post by Sergio Demian Lerner via bitcoin-dev
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.

Post by Sergio Demian Lerner via bitcoin-dev
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.)

[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 <

Post by 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[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 <

Post by Gregory Maxwell 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 <

Post by 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[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

Post by 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.
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

Post by Gregory Maxwell 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

Post by 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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

[Johnson Lau via bitcoin-dev]

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.

[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.

Post by Sergio Demian Lerner via bitcoin-dev

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

[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.

Post by 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.

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.

[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

Post by 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.

Post by Johnson Lau via bitcoin-dev

On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[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.

Post by 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.
https://github.com/SergioDemianLerner/SegwitStats
[1] https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e
<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
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
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
<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
<http://p2sh.info>) would like to double-check.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Sergio Demian Lerner via bitcoin-dev]

Post by Matt Corallo 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.

[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 <

Post by Sergio Demian Lerner via bitcoin-dev

Post by Matt Corallo 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.

[Gregory Maxwell via bitcoin-dev]

On Tue, May 9, 2017 at 7:15 PM, Sergio Demian Lerner via bitcoin-dev

Post by Sergio Demian Lerner via bitcoin-dev
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.

[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

Post by Gregory Maxwell via bitcoin-dev
On Tue, May 9, 2017 at 7:15 PM, Sergio Demian Lerner via bitcoin-dev

Post by Sergio Demian Lerner via bitcoin-dev
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.

[Gregory Maxwell via bitcoin-dev]

Post by Matt Corallo via bitcoin-dev
at beast.

Rawr.

[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.

Post by Matt Corallo via bitcoin-dev
at beast.

Rawr.

[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" <

Post by 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.

Post by Matt Corallo via bitcoin-dev
at beast.

Rawr.

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

[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

Post by 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 7:42 PM, Matt Corallo

Post by Matt Corallo via bitcoin-dev
at beast.

Rawr.

[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.

Post by 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

Post by 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 7:42 PM, Matt Corallo

Post by Matt Corallo via bitcoin-dev
at beast.

Rawr.

[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.

Post by 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

Post by Matt Corallo via bitcoin-dev
I'm highly unconvinced of this point. Sure, you can change fewer

lines

Post by Matt Corallo via bitcoin-dev
of code, but if the result is, lets be honest, shit, how do you

believe

Post by Matt Corallo via bitcoin-dev
its going to have a higher chance of getting acceptance from the

broader

Post by Matt Corallo via bitcoin-dev
community? I think you're over-optimizing in the wrong direction.
Matt

Post by Sergio Demian Lerner via bitcoin-dev
I agree with you Matt.
I'm artificially limiting myself to changing the parameters of

Segwit as

Post by Matt Corallo via bitcoin-dev

Post by Sergio Demian Lerner via bitcoin-dev
it is..
This is motivated by the idea that a consensual HF in the current

state

Post by Matt Corallo via bitcoin-dev

Post by Sergio Demian Lerner via bitcoin-dev
would have greater chance of acceptance if it changes the minimum

number

Post by Matt Corallo via bitcoin-dev

Post by Sergio Demian Lerner via bitcoin-dev
of lines of code.
On Tue, May 9, 2017 at 7:42 PM, Matt Corallo

Post by Matt Corallo via bitcoin-dev
at beast.

Rawr.

[Sergio Demian Lerner via bitcoin-dev]

I'm not advocating. I'm mediating.


This is out of

Post by 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 <

Post by 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

Post by Matt Corallo via bitcoin-dev
I'm highly unconvinced of this point. Sure, you can change fewer

lines

Post by Matt Corallo via bitcoin-dev
of code, but if the result is, lets be honest, shit, how do you

believe

Post by Matt Corallo via bitcoin-dev
its going to have a higher chance of getting acceptance from the

broader

Post by Matt Corallo via bitcoin-dev
community? I think you're over-optimizing in the wrong direction.
Matt

Post by Sergio Demian Lerner via bitcoin-dev
I agree with you Matt.
I'm artificially limiting myself to changing the parameters of

Segwit as

Post by Matt Corallo via bitcoin-dev

Post by Sergio Demian Lerner via bitcoin-dev
it is..
This is motivated by the idea that a consensual HF in the current

state

Post by Matt Corallo via bitcoin-dev

Post by Sergio Demian Lerner via bitcoin-dev
would have greater chance of acceptance if it changes the minimum

number

Post by Matt Corallo via bitcoin-dev

Post by Sergio Demian Lerner via bitcoin-dev
of lines of code.
On Tue, May 9, 2017 at 7:42 PM, Matt Corallo

Post by Matt Corallo via bitcoin-dev
at beast.

Rawr.