[Bitcoin-segwit2x] Proposal: Improvements to segwit discount with hardfork

[Jared Lee Richardson]

> What would be the timing for this? I'm asking with the upcoming
activationin mind.

It would have to be timed with a hardfork, unless it was completely
uncontroversial(That'll be the day!).

> I'm afraid this compromise is being taken as a chance to add features and
changes "since we're forking anyways"...

I only brought it up because of the recent discussion on blockweight
("segwit2x alpha release code drop" email by Jeff Garzik) that there were
options being considered for changing/adjusting either the weighting's
application to legacy transactions, or changing the witness scaling factor,
or both.  For this to be justifiable it must piggyback onto other hardforks.

> Sorry to be a naysayer, but it's time to stay focused in consensus.

I agree it is definitely not worth derailing anything.

Jared

On Tue, Jun 20, 2017 at 3:49 PM, nubis bruno <yo at nubis.im> wrote:

> What would be the timing for this? I'm asking with the upcoming
> activationin mind.
>
> Segwit2x means Segwit as it is, and a commitment to 2mb blocks.
>
> I think it's a great idea but way beyond the scope of the group, and can
> probably gain its own momentum later as it pleases both sides.
>
> I'm afraid this compromise is being taken as a chance to add features and
> changes "since we're forking anyways"...
>
> Sorry to be a naysayer, but it's time to stay focused in consensus.
>
> Cheers
>
> On Tue, Jun 20, 2017, 5:03 PM Jared Lee Richardson via Bitcoin-segwit2x <
> bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>
>> Hi everyone,
>>
>> I have a proposed solution that attempts to deal with the "garbage risk"
>> of the segwit discount - as well as the objections that the anti-segwit
>> side of the community debate consistently raises to the witness discount.
>>
>> This approach attempts to avoid any "discount" on data bytes entirely as
>> well as avoid having miners optimize for two different datablocks, while
>> still attempting to favor consuming utxo's rather than creating them.  This
>> is done by requiring, for block-weight purposes, that all transactions
>> pre-pay for UTXO consumption signatures, and simultaneously discounts input
>> data by an equivalent amount.
>>
>> Under this proposal, the weight of a transaction would be calculated by
>> subtracting X * <number of inputs> and adding X * <number of outputs>,
>> where X is the median "extra" weight associated with inputs versus outputs.
>>
>> I pulled a few random transactions by hand and compared the input
>> scriptsize versus the output scriptsize and got about 114 bytes(82 bytes
>> for P2SH), plus 32 bytes for the base input vs output size, so ~146 bytes
>> based on my very unscientific data sample.
>>
>> Comparing the final total transaction sizes with / without this change,
>> assuming 139 bytes per input script(my median) and X=146 bytes:
>>
>> [image: Inline image 1]
>>
>> (used the non-segwit transaction structure for exact byte counts in each
>> section)
>>
>> As shown above, this approach provides substantial discounts for
>> transactions that consume many inputs and produce few outputs, penalizes
>> those which create many outputs from a few inputs, and provides no data
>> discounts for the average case or over the long term.
>>
>> This proposal was likely not compatible with segwit's soft-fork only
>> activation, as it would reintroduce the max-baseblock-size versus
>> max-blockweight optimization problem under the 1mb limit.  As the +2mb
>> hardfork requires an upgrade, this change could take effect at the same
>> moment as the hardfork, and all clients would rely only on the
>> maxblockweight value going forward.  This change could apply equally to
>> legacy and segwit transactions.
>>
>> Over time, as with the segwit discount, this should drive down UTXO bloat
>> and reduce total network bandwidth usage without reducing usability.  This
>> change has the added advantage that average blocksizes will once again be
>> comparable to maximum blockweight for easy mental estimations by humans,
>> and because of that it may warrant a small adjustment to the maxblockweight
>> metric at hardfork time.
>>
>> Thoughts / feedback?
>>
>> Thanks, Jared
>> _______________________________________________
>> Bitcoin-segwit2x mailing list
>> Bitcoin-segwit2x at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170620/57aa713c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 12625 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170620/57aa713c/attachment-0001.png>