[bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork

[bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 605 bytes --]

Re: [bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork

[Alphonse Pace]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

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.



​

[-- Attachment #2: Type: text/html, Size: 627 bytes --]

Re: [bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 254 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 305 bytes --]

Re: [bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

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.



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

[-- Attachment #2: Type: text/html, Size: 1206 bytes --]