From: Christian Decker <decker.christian@gmail•com>
To: Luke Dashjr <luke@dashjr•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
Date: Tue, 03 Nov 2015 20:37:44 +0000 [thread overview]
Message-ID: <CALxbBHV4JU7TG8QutkX7m9V4n_ANgKAgWO8ZA2KxQk8jP=kF0g@mail.gmail.com> (raw)
In-Reply-To: <201510220905.27124.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 2428 bytes --]
Ok, getting the ball rolling again after some downtime. I amended the
proposal to use a simple version number instead of the binary flags, added
the normalization of inputs before computing the signaturehash and added
Schnorr signatures as requested.
The BIP has also been assigned number 130 :-)
I am still very much intrigued by Luke's idea of having empty scriptsigs
and ship the signatures in external scripts, however the proposal uses the
on-the-fly normalization because we have no good way of relaying the
external scripts. Since we are still in the drafting phase I am open to
suggestions and if there is a good/working solution I can amend/withdraw
the proposal.
As for open venues for malleability, I'm not sure we can fix them at all,
after all the ability of a single signer to doublespend by
appending/replacing inputs/outputs in an arbitrary fashion is not fixable
IMHO and will cause any future transaction building on its outputs to be
orphaned. What would the perfect properties for such a fix be?
Regards,
Christian
On Thu, Oct 22, 2015 at 11:05 AM Luke Dashjr <luke@dashjr•org> wrote:
> On Thursday, October 22, 2015 8:26:58 AM Christian Decker wrote:
> > I think the scenario of the single signer re-ordering the outputs and
> > inputs and then re-signing the transaction is in the same category of
> > simple double-spends. The signer could just as well sign a completely
> > different transaction spending the same coins to somewhere else, so I
> don't
> > think there is a lot we can do about it even if we instate a canonical
> > ordering. Even if we order the inputs and outputs the signer can just
> add a
> > new input and output and we would have a different transaction.
> >
> > 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.
>
> Except that unlike malicious double spending, adding more outputs to
> unconfirmed transactions is what wallets *should ideally be doing every
> time
> they send another transaction*. Spending unconfirmed change is the wrong
> approach. So half-fixing malleability as this PR would, encourages
> inefficient behaviour in multiple ways (first, by not making it
> malleability-
> safe; second, by encouraging spending unconfirmed change).
>
> Luke
>
[-- Attachment #2: Type: text/html, Size: 2881 bytes --]
next prev parent reply other threads:[~2015-11-03 20:37 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
2015-10-22 9:05 ` Luke Dashjr
2015-11-03 20:37 ` Christian Decker [this message]
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='CALxbBHV4JU7TG8QutkX7m9V4n_ANgKAgWO8ZA2KxQk8jP=kF0g@mail.gmail.com' \
--to=decker.christian@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/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