Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XD3Z0-0003Bz-DY for bitcoin-development@lists.sourceforge.net; Fri, 01 Aug 2014 03:31:26 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.180 as permitted sender) client-ip=209.85.220.180; envelope-from=gmaxwell@gmail.com; helo=mail-vc0-f180.google.com; Received: from mail-vc0-f180.google.com ([209.85.220.180]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XD3Yz-0005tc-8F for bitcoin-development@lists.sourceforge.net; Fri, 01 Aug 2014 03:31:26 +0000 Received: by mail-vc0-f180.google.com with SMTP id ij19so5635826vcb.25 for ; Thu, 31 Jul 2014 20:31:19 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.220.74.10 with SMTP id s10mr3096498vcj.61.1406863879656; Thu, 31 Jul 2014 20:31:19 -0700 (PDT) Received: by 10.52.187.132 with HTTP; Thu, 31 Jul 2014 20:31:19 -0700 (PDT) In-Reply-To: <1515086.GQImTWpAiA@crushinator> References: <3826251.5rGb1MfKOu@crushinator> <1515086.GQImTWpAiA@crushinator> Date: Thu, 31 Jul 2014 20:31:19 -0700 Message-ID: From: Gregory Maxwell To: Matt Whitlock Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1XD3Yz-0005tc-8F Cc: Bitcoin Development Subject: Re: [Bitcoin-development] deterministic transaction expiration X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 03:31:26 -0000 On Thu, Jul 31, 2014 at 8:26 PM, Matt Whitlock wrot= e: > I understand what you're saying, but I don't understand why it's a proble= m. Transactions shouldn't be considered "final" until a reasonable number o= f confirmations anyway, so the possibility that an "accepted" transaction c= ould become invalid due to a chain reorganization is not a new danger. Ordi= nary transactions can similarly become invalid due to chain reorganizations= , due to inputs already having been spent in the new branch. A distinction there is that they can only become invalid via a conflict=E2=80=94 replaced by another transaction authored by the prior signers. If no other transaction could be created (e.g. you're a multisigner and won't sign it again) then there is no such risk. It now introduces chance events ("act of god") into the mix where they they didn't exist before. Basically it takes was what is a very loose one way coupling and makes it much tighter. I'm sure if you spend a bit thinking you can come up with some more corner cases that it would expose=E2=80=94 e.g. flooding the network with unrelated high fee transacti= ons in order to push a transaction out to where it can never be mined at all.