Ok, so the normalization step could add a sorting step for inputs/outputs (which is going to be nasty for SIGHASH_SINGLE), that would solve the issue.
On Wed, Oct 21, 2015 at 10:49 AM Christian Decker < [email protected]> wrote: > On Wed, Oct 21, 2015 at 10:26 AM Gregory Maxwell <[email protected]> > wrote: > >> On Wed, Oct 21, 2015 at 7:48 AM, Gregory Maxwell <[email protected]> >> wrote: >> > I'm still sad that uniform segregated witeness is so hard to deploy, >> > adding another id to every utxo set won't be a nice cost. :( But I >> > have been trying for a long time to come up with anything better and >> > not being successful. >> >> Oh good. Luke solved it. >> >> To deploy SW without a disruptive flag day this encoding could be used: >> >> A new P2SH like scriptPubkey type is defined. In the soft-fork, the >> scriptsig for this scriptPubkey is required to be empty. >> >> Signatures are not covered under txid, but carried along side. Then >> committed to in blocks in a separate hashtree. >> >> > Isn't that sort of what this BIP describes as well? Except that we use the > scriptSig to transport the signatures internally to the transactions and > strip them when it comes to signing/checking? The wire format and transport > of transactions do not change so old clients continue to fetch and process > transactions as before, they just can't verify the TX. Blocks still > reference the instance but verification uses the stripped TX with the > signatures on the side, etc. > > >> The only disadvantage to the approach used in elements alpha that I >> can come up with so far (in the few minutes since luke turned my can't >> into a can) is that that the approach in EA did not disrupt the normal >> relay handling process, and this would, since relay that transports >> the extradata either needs to use a different hash that includes the >> witness, or have a separate mechanism for witness transport. >> >
_______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
