Quadratic hashing solution for a post-segwit hard fork
4 messages, 14 to 17 Mar 2017. Started by Erik Aronesty.
Erik Aronesty (2), Alphonse Pace, Jorge Timón
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.
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.
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.
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-dev@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.