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 1SIP0u-0003z7-Rz for bitcoin-development@lists.sourceforge.net; Thu, 12 Apr 2012 18:45:00 +0000 X-ACL-Warn: Received: from mail-vb0-f47.google.com ([209.85.212.47]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1SIP0u-00087L-1j for bitcoin-development@lists.sourceforge.net; Thu, 12 Apr 2012 18:45:00 +0000 Received: by vbbfr13 with SMTP id fr13so2457116vbb.34 for ; Thu, 12 Apr 2012 11:44:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=xQY5mUzqqIyjYZrZhP71B2OmIJmuv6gfQSTIsXuTRqk=; b=a1AInh2EGE6cncCtIxtDo2nstDYxCurriTU3As6SKoeLEAmuc+xypa1gnCHfLjm6IX yL8U9bRsDVrESEdIqAJb9vEEIdgXj6DOVE0ZQ6i5eUwiDbAk8yNP0EYePN4nvup2IaNa 6aSAEmvZN1lCyCLC7iioHI8zyQXqZ3xttM58VeIf7ZDjvgKmc+QdcrzPCyyifts9GFq4 2D+aUDzJI1oi7jIGGPHgIksns3vJ3IsqrEHOpql2AeEedhFgeoQcnJMzfLx7Rf4KFV1z A7zJYgUyjMMbaeVEqGztdrGyuBHKOySmx/QMf6zpgZdeKtkMGBGsQn7ixxhnzX0Yf9xe y1xw== MIME-Version: 1.0 Received: by 10.220.151.133 with SMTP id c5mr1866660vcw.1.1334255923596; Thu, 12 Apr 2012 11:38:43 -0700 (PDT) Received: by 10.52.109.33 with HTTP; Thu, 12 Apr 2012 11:38:43 -0700 (PDT) X-Originating-IP: [99.43.178.25] Date: Thu, 12 Apr 2012 14:38:43 -0400 Message-ID: From: Jeff Garzik To: Bitcoin Development Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmfLy5JB6sEzjCfMLj/pt0cGoMo6/XSTadZz/3N7sJeS7/5j8UhgRo8qlavrxfb5Ac47og0 X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1SIP0u-00087L-1j Subject: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior 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: Thu, 12 Apr 2012 18:45:00 -0000 Not sure whether this rises to the level of a BIP or not, as it is largely an implementation change. One of my From-Day-One complaints about bitcoin is that transactions behavior could be far more deterministic (predictable), from a user standpoint. Transactions in the current system can easily remain in limbo forever. One big step in making transactions behave more predictably would be to remove transactions from the memory pool, if they have not made it into a block for a couple days. i.e. 1. N = 1 or 2 or whatever the community prefers. Ideally enough time for a third-tier miner, mining strange TXs, finds a block. 2. H1 = height of block chain, when a TX is received 3. H2 = H1 + (144 * N) 4. If block chain height reaches H2, and TX has not made it into a block, drop TX from memory pool Although this only impacts a small amount of TX's ultimately, what it does do is give us the ability -- once miners have upgraded to this rule -- to tell bitcoin users that their transactions "expire" after N days. Backwards compatibility should not be an issue; clients are free to retransmit their TX at any time, as usual, thereby "resetting the clock" for all peers who have forgotten the TX in question. Once in place, clients may then implement code that notices a TX has expired (read: likely to have been forgotten by the network, assuming they themselves have stopped retransmitting it). Then you can start working on wallet/coin recovery, perhaps resending with a higher fee etc. The above change is not really "fill-or-kill" but it should be a big step, opening the door to deterministic TX behavior. -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti.com