Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 815FAB3E for ; Thu, 17 Nov 2016 00:53:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f178.google.com (mail-pf0-f178.google.com [209.85.192.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F13EF8D for ; Thu, 17 Nov 2016 00:53:44 +0000 (UTC) Received: by mail-pf0-f178.google.com with SMTP id i88so45441376pfk.2 for ; Wed, 16 Nov 2016 16:53:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=BRHcscN3KBBYRVPTc/m/fls+8ZzvocvZJ7Cqg3sO7qY=; b=ERLmKlT90+23CZig7pbmB2Fl35p7GRLvEgDmttAiD2O7nX66sI1al3f7xfK6OMVyqR NAAKgLjzP1cTuoXYDl12oKEGGYwnFUglOWRPUJGScIUPxIy1MtHx/FxBqyMhS8mETBdu lgUfdxNv9AaQybt7fFU8dw4l6Ikozg4r3svSWoXe3Uq/0zIl9W6cJ9NqD4NS8ohHhcW0 jLcIEkVSrOIA0nyFPg/UUWirquDmEkbDZ3UujexCiSpepafT9FB2waky9kWzvJ7dCiyf CQH+c1/sBPWLcwFIHsu0+Q4m3+doxrynjzWdeGXaxqLSRlQ0pVIrFhmTaAc+SBKzQnBf EBhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=BRHcscN3KBBYRVPTc/m/fls+8ZzvocvZJ7Cqg3sO7qY=; b=LEuz1Pz8LRGKtgApZHkx8KrVu74JFTZuFslB1ct7ye2wRJQgZCvRfbV56LZGHOz1xc tcAQ79Hn0jPBfw4Oo1uzibmAIZBZrop7O6vNcyZTxTABY/Z3LO0HkqFYFyzkLaf+2wBo 8Av/r27xaVl81tIPlNliHAZTM3MWpnjKTMXsbQd5lroOSNtaqtyDvI0LZDZ/T2SYI2x1 WYzuqW+16Z98rHbkQL7Dveusm4cbbAL/N5N7e5cDKCYv6nVmjyodIME7a690yKyE6rXh IrcdFqvRTPzpAN51OYi5ST8i4abpsKHLA0mFCE6+L3wrUCH10PETasPtYUe87CTCuXzh PTGg== X-Gm-Message-State: ABUngvcYNSPsu0KA/uEffeh7zcgWOM7psU4s5hUt8vwQtfITPx6a3PPuOIswbsvOcCjzJg== X-Received: by 10.99.117.71 with SMTP id f7mr1085366pgn.126.1479344024449; Wed, 16 Nov 2016 16:53:44 -0800 (PST) Received: from ?IPv6:2601:600:9000:d69e:8084:4206:2529:776d? ([2601:600:9000:d69e:8084:4206:2529:776d]) by smtp.gmail.com with ESMTPSA id 72sm498025pfw.37.2016.11.16.16.53.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 16:53:43 -0800 (PST) To: Tier Nolan , Bitcoin Protocol Discussion References: From: Eric Voskuil X-Enigmail-Draft-Status: N1110 Message-ID: Date: Wed, 16 Nov 2016 16:53:45 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BAerLQSgxw9XmB2oMpUnoW0uL7FReeTvR" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE 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: Thu, 17 Nov 2016 01:18:54 +0000 Subject: Re: [bitcoin-dev] BIP30 and BIP34 interaction (was Re: [BIP Proposal] Buried Deployments) 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: Thu, 17 Nov 2016 00:53:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BAerLQSgxw9XmB2oMpUnoW0uL7FReeTvR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Also, it's important to take note of the motivation behind not banning duplicate tx hashes outright. Doing so would require that spent tx hashes are retained forever. A pruning node will have no way of knowing whether a new tx duplicates the hash of a preceding tx. Any implementation that does retain such hashes and dismisses new txs on that basis would fork against pruning nodes. e On 11/16/2016 04:43 PM, Eric Voskuil wrote: >> This means that all future transactions will have different txids... > rules do guarantee it. >=20 > No, it means that the chance is small, there is a difference. >=20 > If there is an address collision, someone may lose some money. If there= > is a tx hash collision, and implementations handle this differently, it= > will produce a chain split. As such this is not something that a node > can just dismiss. If they do they are implementing a hard fork. >=20 > e >=20 > On 11/16/2016 04:31 PM, Tier Nolan via bitcoin-dev wrote: >> >> >> On Thu, Nov 17, 2016 at 12:10 AM, Eric Voskuil via bitcoin-dev >> > > wrote: >> >> Both of these cases resulted from exact duplicate txs, which BIP34= now >> precludes. However nothing precludes different txs from having the= same >> hash. >> >> >> The only way to have two transactions have the same txid is if their >> parents are identical, since the txids of the parents are included in = a >> transaction. >> >> Coinbases have no parents, so it used to be possible for two of them t= o >> be identical. >> >> Duplicate outputs weren't possible in the database, so the later >> coinbase transaction effectively overwrote the earlier one. >> >> The happened for two coinbases. That is what the exceptions are for. >> >> Neither of the those coinbases were spent before the overwrite >> happened. I don't even think those coinbases were spent at all. >> >> This means that every activate coinbase transaction has a unique hash >> and all new coinbases will be unique. >> >> This means that all future transactions will have different txids. >> >> There might not be an explicit rule that says that txids have to be >> unique, but barring a break of the hash function, they rules do >> guarantee it. >=20 --BAerLQSgxw9XmB2oMpUnoW0uL7FReeTvR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJYLP+ZAAoJEDzYwH8LXOFO44UIAJKCj8c/lv6VM2ISJn+Inhvm 2NwWJUd8ruezqxGyvOxCADnPir2pSqZDWTf0+HqEr7eThN6MYwuvqXk1nzdmWwFn E35v7KLkU0DDKeiih8DSCcO3KLfEWf7m1KesqsViNze3Gd9yUySsmOKWXHFSHWY8 VRm5nhWDHNqw4mUXb9h+ncO6F5Ben8qo8Q9QT6Wau9jsgBEz1vTJBgKHy0/DYxMi CokGl2T3bHFbaIkzyJI8mtYo2YXSMo1g2Dz69c7TafF1o0sgPi7R+Ntw6b0cgLzp eB40PHKOHOOK/qhoBKWBfQXOystSf9RUg7Zr9tZE3zXA3fXAO+Rvlk00+UKHnho= =DdfR -----END PGP SIGNATURE----- --BAerLQSgxw9XmB2oMpUnoW0uL7FReeTvR--