Discussion:
Quadratic hashing solution for a post-segwit hard fork
(too old to reply)
Erik Aronesty via bitcoin-dev
2017-03-14 23:26:17 UTC
Permalink
Raw Message
Some discussion today led me to believe that a post segwit hard fork could
include:

1MB old tx non-witness segment
XMB new segwit non-witness segment
XMB witness segment

By partitioning off old transactions, it allows users of older, more
expensive validation transactions to continue using them, albeit with
higher fees required for the restricted space.

New segwit blocks, which don't have the hashing problem could be included
in the new non-witness segment of the block.
Alphonse Pace via bitcoin-dev
2017-03-16 15:24:14 UTC
Permalink
Raw Message
This unnecessarily complicates transaction selection for miners by
introducing a second (and possibly third if I understand your proposal
correctly) dimension to try to optimize.

See: https://en.wikipedia.org/wiki/Bin_packing_problem

Segwit already solves this exact issue by replacing block size with block
weight, so I fail to see how this proposal would make any improvements
without introducing significant complications.



​
Erik Aronesty via bitcoin-dev
2017-03-17 00:44:27 UTC
Permalink
Raw Message
Yeah, it does make things harder, and it's easy enough to soft fork to
handle arbitrary opt-in protocol improvements, new much larger block sizes,
whatever you want. Even OK to migrate to a new system by not allowing
old->old or new->old transactions.
Jorge Timón via bitcoin-dev
2017-03-17 10:39:07 UTC
Permalink
Raw Message
Segwit allows old -> old, old -> new, new -> old and of course new -> new
txs.

On 17 Mar 2017 1:47 a.m., "Erik Aronesty via bitcoin-dev" <
bitcoin-***@lists.linuxfoundation.org> wrote:

Yeah, it does make things harder, and it's easy enough to soft fork to
handle arbitrary opt-in protocol improvements, new much larger block sizes,
whatever you want. Even OK to migrate to a new system by not allowing
old->old or new->old transactions.

Loading...