From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RBQwA-0005zh-F6 for bitcoin-development@lists.sourceforge.net; Wed, 05 Oct 2011 12:51:02 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.175 as permitted sender) client-ip=209.85.216.175; envelope-from=gmaxwell@gmail.com; helo=mail-qy0-f175.google.com; Received: from mail-qy0-f175.google.com ([209.85.216.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RBQw6-00038x-JX for bitcoin-development@lists.sourceforge.net; Wed, 05 Oct 2011 12:51:02 +0000 Received: by qyk10 with SMTP id 10so4651595qyk.13 for ; Wed, 05 Oct 2011 05:50:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.66.160 with SMTP id n32mr686773qci.33.1317819053138; Wed, 05 Oct 2011 05:50:53 -0700 (PDT) Received: by 10.229.214.144 with HTTP; Wed, 5 Oct 2011 05:50:52 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Oct 2011 08:50:52 -0400 Message-ID: From: Gregory Maxwell To: =?UTF-8?Q?Michael_Gr=C3=B8nager?= 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: 1RBQw6-00038x-JX Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] vtxPrev 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: Wed, 05 Oct 2011 12:51:02 -0000 On Wed, Oct 5, 2011 at 8:31 AM, Michael Gr=C3=B8nager wrote: > The vtxPrev stores 3 transactions back, but as transactions need 7 block = to maturity and respendability isn't it overkill - I mean it is highly unli= kely that a transaction gets invalid after 7 confirmations and They don't need 7 blocks to maturity and respendability. The software will attempt to use older inputs when available but if not it will use what it has. It's also prone to respending its own outputs quickly because it reasonably trusts that it won't doublespend its own transactions. And, yes, if there is a deep split then its possible that inputs might have been spent differently in the new split. But it's not especially likely. Retransmitting one of your own txn's parents if its dropped but not yet impossible sounds prudent to me.