Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2017-05-09 📝 Original message:On Tue, May 9, 2017 at ...
📅 Original date posted:2017-05-09
📝 Original message:On Tue, May 9, 2017 at 7:15 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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.
📝 Original message:On Tue, May 9, 2017 at 7:15 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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.