From: Christian Decker <decker.christian@gmail•com>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
Date: Thu, 22 Oct 2015 11:54:17 +0000 [thread overview]
Message-ID: <CALxbBHWaQ=_w0F=LkJHDxUB6QVM8MpH_Y-n2U3eowxYVpdBmQA@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgTGaonZ=f9LbwYBa7_wnJdfmr-z3_7aTT8d1NewFHGS7g@mail.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 --]
next prev parent reply other threads:[~2015-10-22 11:54 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-19 14:01 Christian Decker
2015-10-19 15:23 ` Tier Nolan
2015-10-19 19:28 ` Christian Decker
2015-10-19 22:22 ` s7r
2015-10-20 10:30 ` Christian Decker
2015-10-21 6:18 ` Luke Dashjr
2015-10-21 7:39 ` Christian Decker
2015-10-21 7:52 ` Luke Dashjr
2015-10-21 8:31 ` Christian Decker
2015-10-21 8:39 ` Luke Dashjr
2015-10-21 8:44 ` Christian Decker
2015-10-21 8:46 ` Luke Dashjr
2015-10-21 18:22 ` Danny Thorpe
2015-10-21 19:27 ` Gregory Maxwell
2015-10-21 23:20 ` Luke Dashjr
2015-10-22 8:26 ` Christian Decker
2015-10-22 8:57 ` Gregory Maxwell
2015-10-22 11:54 ` Christian Decker [this message]
2015-10-22 9:05 ` Luke Dashjr
2015-11-03 20:37 ` Christian Decker
2015-11-03 20:48 ` Luke Dashjr
2015-11-03 21:44 ` Christian Decker
2015-11-03 22:01 ` Luke Dashjr
2015-11-05 15:27 ` Jorge Timón
2015-11-05 19:36 ` Luke Dashjr
2015-11-05 20:25 ` Jorge Timón
2015-11-05 22:46 ` s7r
2015-11-05 22:29 ` Adam Back
2015-11-06 14:52 ` Christian Decker
2015-11-04 4:00 ` Peter Todd
2015-11-05 9:38 ` Christian Decker
2015-10-21 7:48 ` Gregory Maxwell
2015-10-21 8:26 ` Gregory Maxwell
2015-10-21 8:49 ` Christian Decker
2015-10-21 8:50 ` Christian Decker
2015-10-21 10:14 ` Gregory Maxwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALxbBHWaQ=_w0F=LkJHDxUB6QVM8MpH_Y-n2U3eowxYVpdBmQA@mail.gmail.com' \
--to=decker.christian@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox