Re: [bitcoin-dev] [BIP] Normalized transaction IDs

[Christian Decker <decker.christian@gmail.com>]

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

Indeed the reason I got started with all of this is the use of normalized
transaction IDs within smart contracts with multiple signers. Sorry if I
was perceived as overselling it :-)

So to summarize the discussions that have been on-going here as well as in
the PR so far, most people seem to agree that the BIP is an improvement for
smart-contracts as well as the third-party modification scenario. It comes
at the cost of increased UTXO size due to the additional hash being stored
per transaction with unclaimed outputs and some additional computations.
The additional computation is for the normalized ID computation and the
swapping in of normalized IDs during verification. No additional coin
lookups are needed as they are retrieved and cached anyway when verifying
the transaction. Would everybody agree with this assessment so far?

On the PR there were some additional suggestions of treating singlesig
transactions as 1-of-1 transactions and using Schnorr signatures for the
new opcode. Schnorr has been in the works for a long time and gives a
multitude of advantages, e.g., batch validation, and seems like a good
addition. Since the verify flag is mandatory due to the soft-fork migration
and we might merge singlesig and multisig into a single opcode we can
replace the bitmap of flags with a simple version number. Clients would
fall back to OP_NOP behaviour for versions they do not implement,
maintaining soft-fork semantics to build more future signing and
verification methods.

On Thu, Oct 22, 2015 at 10:57 AM Gregory Maxwell <gmaxwell@gmail.com> wrote:

> On Thu, Oct 22, 2015 at 8:26 AM, Christian Decker via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Normalized transaction IDs do help in the case that the single signer
> wants
> > to immediately follow up its transaction with another transaction
> spending
> > the first one's change output, and it prevents any modification in the
> > multi-signer scenario.
>
> For ordinary transactions which are not performing interesting smart
> contracts that particular is better addressed via canonical encoding,
> which is immediately available and doesn't have the associated costs
> (new pubkey type adoption, 20%-30% UTXO size increase, need for nodes
> to fixup txid references, etc.).
>
> Please, as I said up-thread: this is good and importantstuff to work
> on, but it shouldn't be oversold.
>

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