* [bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork
@ 2017-03-14 23:26 Erik Aronesty
2017-03-16 15:24 ` Alphonse Pace
0 siblings, 1 reply; 4+ messages in thread
From: Erik Aronesty @ 2017-03-14 23:26 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork
2017-03-14 23:26 [bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork Erik Aronesty
@ 2017-03-16 15:24 ` Alphonse Pace
2017-03-17 0:44 ` Erik Aronesty
0 siblings, 1 reply; 4+ messages in thread
From: Alphonse Pace @ 2017-03-16 15:24 UTC (permalink / raw)
To: Erik Aronesty, Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork
2017-03-16 15:24 ` Alphonse Pace
@ 2017-03-17 0:44 ` Erik Aronesty
2017-03-17 10:39 ` Jorge Timón
0 siblings, 1 reply; 4+ messages in thread
From: Erik Aronesty @ 2017-03-17 0:44 UTC (permalink / raw)
To: Alphonse Pace; +Cc: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork
2017-03-17 0:44 ` Erik Aronesty
@ 2017-03-17 10:39 ` Jorge Timón
0 siblings, 0 replies; 4+ messages in thread
From: Jorge Timón @ 2017-03-17 10:39 UTC (permalink / raw)
To: Erik Aronesty, Bitcoin Dev
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-03-17 10:39 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-14 23:26 [bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork Erik Aronesty
2017-03-16 15:24 ` Alphonse Pace
2017-03-17 0:44 ` Erik Aronesty
2017-03-17 10:39 ` Jorge Timón
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox