Re: [bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork
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
Re: [bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork
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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
