diff options
| author | Luke Dashjr <luke@dashjr.org> | 2015-10-21 23:20:30 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-10-21 23:21:36 +0000 |
| commit | 9c22a3ac7b760d47fc1314dd79c3ecd16547cdf3 (patch) | |
| tree | 4017fba17fb8c354cf188545646865c5dda0fab4 | |
| parent | 546419574d59d4928f64e5bc5920e116cc3797d6 (diff) | |
| download | pi-bitcoindev-9c22a3ac7b760d47fc1314dd79c3ecd16547cdf3.tar.gz pi-bitcoindev-9c22a3ac7b760d47fc1314dd79c3ecd16547cdf3.zip | |
Re: [bitcoin-dev] [BIP] Normalized transaction IDs
| -rw-r--r-- | ae/6da04f38141c383b41d2711c4f0b475af9fada | 66 |
1 files changed, 66 insertions, 0 deletions
diff --git a/ae/6da04f38141c383b41d2711c4f0b475af9fada b/ae/6da04f38141c383b41d2711c4f0b475af9fada new file mode 100644 index 000000000..19954d306 --- /dev/null +++ b/ae/6da04f38141c383b41d2711c4f0b475af9fada @@ -0,0 +1,66 @@ +Return-Path: <luke@dashjr.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 89493258 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 21 Oct 2015 23:21:36 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) + by smtp1.linuxfoundation.org (Postfix) with ESMTP id 2CD74E0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 21 Oct 2015 23:21:36 +0000 (UTC) +Received: from ishibashi.localnet (unknown + [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) + (Authenticated sender: luke-jr) + by zinan.dashjr.org (Postfix) with ESMTPSA id DE80338A5500; + Wed, 21 Oct 2015 23:20:31 +0000 (UTC) +X-Hashcash: 1:25:151021:danny.thorpe@gmail.com::dNVy9r97/Ew4Qciz:bINTD +X-Hashcash: 1:25:151021:decker.christian@gmail.com::0MZIuUPegaYt98jF:tbiY +X-Hashcash: 1:25:151021:bitcoin-dev@lists.linuxfoundation.org::49+=CioccXZm6YbC:dVCL4 +From: Luke Dashjr <luke@dashjr.org> +To: Danny Thorpe <danny.thorpe@gmail.com> +Date: Wed, 21 Oct 2015 23:20:30 +0000 +User-Agent: KMail/1.13.7 (Linux/4.1.9-gentoo-r1; KDE/4.14.8; x86_64; ; ) +References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com> + <201510210846.43988.luke@dashjr.org> + <CAJN5wHXSbZPuXN7PQRyOgOMuk2Ogooiww3hW93uNipQJnfkeOg@mail.gmail.com> +In-Reply-To: <CAJN5wHXSbZPuXN7PQRyOgOMuk2Ogooiww3hW93uNipQJnfkeOg@mail.gmail.com> +X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F +X-PGP-Key-ID: BD02942421F4889F +X-PGP-Keyserver: hkp://pgp.mit.edu +MIME-Version: 1.0 +Content-Type: Text/Plain; + charset="iso-8859-15" +Content-Transfer-Encoding: 7bit +Message-Id: <201510212320.31052.luke@dashjr.org> +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 21 Oct 2015 23:21:36 -0000 + +On Wednesday, October 21, 2015 6:22:25 PM Danny Thorpe wrote: +> Let's keep canonical ordering separate from the normalized transaction ID +> proposal. Baby steps. Normalized transaction IDs provide an immediate +> benefit against the hazard of third party manipulation of transactions in +> the mempool, even without canonical ordering. + +My point is that third-party manipulation is not much more of a problem than +signing-party manipulation. Solving the former (at a high cost), without +solving the latter, seems not worth it IMO. + +Luke + |