Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XEiqr-00029y-Fa for bitcoin-development@lists.sourceforge.net; Tue, 05 Aug 2014 17:48:45 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.223.170 as permitted sender) client-ip=209.85.223.170; envelope-from=jgarzik@bitpay.com; helo=mail-ie0-f170.google.com; Received: from mail-ie0-f170.google.com ([209.85.223.170]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XEiqq-0004dr-BX for bitcoin-development@lists.sourceforge.net; Tue, 05 Aug 2014 17:48:45 +0000 Received: by mail-ie0-f170.google.com with SMTP id rl12so1489954iec.1 for ; Tue, 05 Aug 2014 10:48:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+abJyQZGk+kZA+773GQTsQaGhqbFIUZIuoQAHE9cNd4=; b=cNuMKfmSsdYnCT2QIYAf7DiUCXUDtNCMlEKlUSuJC0mRrEb5NzcuX5rRfh7gNvMxEd d6fSuMUE9c+6XLj7vcLFf5CeQjh+ii600qXaTa3pBLHWQX3V1WPR51+rJdsxGeljUT8V eU0UmXE90tzjMSGObNu0h/CCntRPTd8kEOTZP2TMYkpTnKo1u2e6X9LD556USS+9maxW JgkHBUZeJbXj9KcCsCOEh8klB8azOqblHLjbm1+lclM0gqtDFK/vCL3n1iMWLMhSVxFf IJsbkjdTEMshkX2ZhNhFNu0GDuh3NPCNg75EAy7LDFR5ebrI6DxBaDkIj+kh9zsbUXhr wSZw== X-Gm-Message-State: ALoCoQnUDYmNANLtrZZl7b/I2gdm+plMnqATsqCt8/4vCmFZiuEVxKl6pJYJztSRFl8CAqBWDDDA X-Received: by 10.50.80.116 with SMTP id q20mr50871128igx.22.1407260918977; Tue, 05 Aug 2014 10:48:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.78 with HTTP; Tue, 5 Aug 2014 10:48:18 -0700 (PDT) In-Reply-To: References: From: Jeff Garzik Date: Tue, 5 Aug 2014 13:48:18 -0400 Message-ID: To: Kaz Wesley Content-Type: multipart/alternative; boundary=089e015366822eae5504ffe57711 X-Spam-Score: -0.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 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1XEiqq-0004dr-BX Cc: Bitcoin Dev 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: Tue, 05 Aug 2014 17:48:45 -0000 --089e015366822eae5504ffe57711 Content-Type: text/plain; charset=UTF-8 Glad this was brought up. Transaction expiration is something that I have wanted to see happen in bitcoin for a long, long time. The user experience of unconfirming transactions setting around in limbo is just horrible. Bitcoin software by necessity has gotten better about attaching fees so this sort of behavior is uncommon, but that does not eliminate the problem. Of course, we cannot presume that a transaction will truly disappear -- The Internet Never Forgets -- but given a bit of mempool adjusting, we can achieve the next best thing: the majority of the network "forgets" the transaction and becomes willing to relay a respend of some or all of the inputs. This uses existing client logic where the client must rebroadcast a transaction until it is confirmed. In general, if a transaction has not made it into a block within 144*X blocks, there is _some_ reason it is getting rejected by the miners. The mempool janitor is a garbage collector design. This is inferior to the "superblock" model described at https://github.com/bitcoin/bitcoin/issues/3723 Other models can also achieve similar results. There are a lot of issues tied together here: transaction expiration, the desire to cap the mempool ram usage, scalability, DoS prevention, ... mempool ties a lot together. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ --089e015366822eae5504ffe57711 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Glad this was brought up.

Transaction expiration is something that I have wanted to see happen in bi= tcoin for a long, long time.=C2=A0 The user experience of unconfirming tran= sactions setting around in limbo is just horrible.=C2=A0 Bitcoin software b= y necessity has gotten better about attaching fees so this sort of behavior= is uncommon, but that does not eliminate the problem.

Of course, we cannot presume that a transaction will truly disapp= ear -- The Internet Never Forgets -- but given a bit of mempool adjusting, = we can achieve the next best thing:=C2=A0 the majority of the network "= ;forgets" the transaction and becomes willing to relay a respend of so= me or all of the inputs.=C2=A0 This uses existing client logic where the cl= ient must rebroadcast a transaction until it is confirmed.

In general, if a transaction has not made it into a block within = 144*X blocks, there is _some_ reason it is getting rejected by the miners.<= br>
The mempool janitor is a garbage collector design.=C2=A0 This = is inferior to the "superblock" model described at https://github.com/bitcoin/bit= coin/issues/3723=C2=A0=C2=A0 Other models can also achieve similar resu= lts.

There = are a lot of issues tied together here:=C2=A0 transaction expiration, the d= esire to cap the mempool ram usage, scalability, DoS prevention, ...=C2=A0= =C2=A0 mempool ties a lot together.

--
Jeff Garzik
Bitcoin core developer and open source evangelist=
BitPay, Inc. =C2=A0 =C2=A0 =C2=A0https://bitpay.com/
--089e015366822eae5504ffe57711--