Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0FBE29C for ; Sat, 17 Sep 2016 21:14:52 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com [209.85.220.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 55DC3124 for ; Sat, 17 Sep 2016 21:14:51 +0000 (UTC) Received: by mail-qk0-f169.google.com with SMTP id w204so116462165qka.0 for ; Sat, 17 Sep 2016 14:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uSJJnPpt7v13vkArB3LZCo90GdDPunjAloC1uCWz6FA=; b=P198K8W/Ix/ZFrrti10ZG3lPjI426FTvyupqCHUmsntvr7MRHiADL3OKLtGWDLZM1T V4dySqYAN5obrET7mVbVOOriFTEAnN80t9hT+02L4WTtp5Ql1PA3fC1wNUcwxi6d+JQ/ 5OMfxU0UGugoXgShKOv0erwneOR0W5ZmlUh/0xFKOydQZH4jTa21Y16LITNoEcuzcV+V 6jA2hK4pU6AACTrcEbu8fstV0048v0Vv7H/7Dkerquj6IHklqlpg2YijgyLJsq1ELlhp dCT2Poa/4WTKn7cSxKw2XCb0GYt3hIwjsNhU7DhmrXeIJpAxqde/p2tCn7gfCM40vMtZ Asyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uSJJnPpt7v13vkArB3LZCo90GdDPunjAloC1uCWz6FA=; b=foh6164zbhmkp95LZas9uWZNEmozGoToa9MLjCzedPAZ3+439cEn8hmnpdiX51trAk 8JmI3KCb8OuzEEhY5d5pZFad1V5fNCf9qZ6c5hTrLyl+6Svt0Q+jKE3Km/bO8GpASSPZ 3WlRi28y/CYO+DGLL+3ISiZm276cb7z94kIwAkNZD3ZHBvqYJ5Kv1t8IQwaG2KxA4Jjr Qn6vDj2KHOPW6w5c8dN1kQnRiQf3oaYOVTvR7fNroCMnKU7Of8T5O9i3Z8H1H7u7K5T5 9kI+5UBfYgmMoaTgKcuNl0/PvK2QEwa+QVFCYAY1EhDbltnh9a0IjWpgXWIioJpvZvD2 lq4w== X-Gm-Message-State: AE9vXwOE8dv5bg3gswrLrYVeHwbWaAGdmC9TLoJNU4PTkOgGOHh2k5Sf3MGKtPq55afcXEGv/fFb2qWYgPEjIQ== X-Received: by 10.55.48.9 with SMTP id w9mr21610090qkw.147.1474146890622; Sat, 17 Sep 2016 14:14:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.145.33 with HTTP; Sat, 17 Sep 2016 14:14:30 -0700 (PDT) In-Reply-To: <715F2390-221E-4646-A7F6-3FB937A08764@mattcorallo.com> References: <715F2390-221E-4646-A7F6-3FB937A08764@mattcorallo.com> From: "Rune K. Svendsen" Date: Sat, 17 Sep 2016 23:14:30 +0200 Message-ID: To: Bitcoin Content-Type: multipart/alternative; boundary=001a11471b10c32af9053cba91fe X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 17 Sep 2016 21:46:18 +0000 Subject: Re: [bitcoin-dev] Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2016 21:14:52 -0000 --001a11471b10c32af9053cba91fe Content-Type: text/plain; charset=UTF-8 I hadn't thought of that... There is a solution, I think, but it makes the operation less simple. If a transaction contains at least two OP_TXHASHVERIFY-protected inputs, signed without ANYONECANPAY, their signatures would cover the other input's OP_TXHASHVERIFY hash, right? /Rune On Sat, Sep 17, 2016 at 10:56 PM, Matt Corallo wrote: > (removing the list) > > Because the tx hash in your construction is not signed, someone wishing to > maleate a transaction may do so by also updating the hash in the scriptSig. > > Matt > > On September 17, 2016 4:45:17 PM EDT, "Rune K. Svendsen via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I would really like to be able to create transactions that are immune to >> transaction ID malleability now, so I have been thinking of the simplest >> solution possible, in order to get a BIP through without too much trouble. >> >> An opcode we could call OP_TXHASHVERIFY could be introduced. It would be >> defined to work only if added to a scriptSig as the very first operation, >> and would abort if the hash of the transaction **with all OP_TXHASHVERIFY >> operations (including stack push) removed** does not match what has been >> pushed on the stack. >> >> So, in order to produce a transaction with one or more inputs protected >> against tx ID malleability, one would: >> >> 1. Calculate tx ID of the tx: TX_HASH >> 2. For each input you wish to protect, add "0x32 $TX_HASH >> OP_TXHASHVERIFY" to the beginning of the scriptSig >> >> When evaluating OP_TXHASHVERIFY, we make a copy of the tx in question, >> and remove the "0x32 <32 bytes> OP_TXHASHVERIFY" sequence from the >> beginning of all scriptSigs (if present), and abort if the tx copy hash >> does not match the top stack item. >> >> This is a very simple solution that only adds 34 bytes per input, and >> when something better becomes available (eg. Segwit), we will stop using >> this. But in the meantime it's very valuable to be able to not worry about >> tx ID malleability. >> >> Please let me know what you think. >> >> >> >> /Rune >> >> ------------------------------ >> >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> --001a11471b10c32af9053cba91fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I hadn't thought of that... There is a solution, I thi= nk, but it makes the operation less simple.

If a transac= tion contains at least two OP_TXHASHVERIFY-protected=C2=A0inputs, signed wi= thout ANYONECANPAY, their signatures would cover the other input's=C2= =A0OP_TXHASHVERIFY hash, right?


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /Rune


On Sat, Sep 17, = 2016 at 10:56 PM, Matt Corallo <lf-lists@mattcorallo.com> wrote:
(removing the list)

Because the tx hash in your construction is not signed, someone wishing to = maleate a transaction may do so by also updating the hash in the scriptSig.=

Matt

On September = 17, 2016 4:45:17 PM EDT, "Rune K. Svendsen via bitcoin-dev" <<= a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b= itcoin-dev@lists.linuxfoundation.org> wrote:
I would really like to be able to create transactions that= are immune to transaction ID malleability now, so I have been thinking of = the simplest solution possible, in order to get a BIP through without too m= uch trouble.

An opcode we could call OP_TXHASHVERIFY cou= ld be introduced. It would be defined to work only if added to a scriptSig = as the very first operation, and would abort if the hash of the transaction= **with all OP_TXHASHVERIFY operations (including stack push) removed** doe= s not match what has been pushed on the stack.

So,= in order to produce a transaction with one or more inputs protected agains= t tx ID malleability, one would:

1. Calculate tx I= D of the tx: TX_HASH
2. For each input you wish to protect, add &= quot;0x32 $TX_HASH OP_TXHASHVERIFY" to the beginning of the scriptSig<= /div>

When evaluating OP_TXHASHVERIFY, we make a copy of= the tx in question, and remove the "0x32 <32 bytes> OP_TXHASHVERIFY" = sequence from the beginning of all scriptSigs (if present), and abort if th= e tx copy hash does not match the top stack item.

= This is a very simple solution that only adds 34 bytes per input, and when = something better becomes available (eg. Segwit), we will stop using this. B= ut in the meantime it's very valuable to be able to not worry about tx = ID malleability.

Please let me know what you think= .



=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 /Rune

bitcoin-dev@list= s.linuxfoundation.org
https://lists.linuxfoun= dation.org/mailman/listinfo/bitcoin-dev


--001a11471b10c32af9053cba91fe--