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 1SIPYY-00039i-Sn for bitcoin-development@lists.sourceforge.net; Thu, 12 Apr 2012 19:19:47 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.175 as permitted sender) client-ip=209.85.212.175; envelope-from=etotheipi@gmail.com; helo=mail-wi0-f175.google.com; Received: from mail-wi0-f175.google.com ([209.85.212.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1SIPYX-0005X6-M0 for bitcoin-development@lists.sourceforge.net; Thu, 12 Apr 2012 19:19:46 +0000 Received: by wibhn6 with SMTP id hn6so5246045wib.10 for ; Thu, 12 Apr 2012 12:19:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.91.10 with SMTP id ca10mr18406695wib.17.1334258379576; Thu, 12 Apr 2012 12:19:39 -0700 (PDT) Received: by 10.180.8.7 with HTTP; Thu, 12 Apr 2012 12:19:39 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Apr 2012 15:19:39 -0400 Message-ID: From: Alan Reiner To: Jeff Garzik Content-Type: multipart/alternative; boundary=f46d043c093ec0d3d504bd803ce4 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (etotheipi[at]gmail.com) -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: 1SIPYX-0005X6-M0 Cc: Bitcoin Development Subject: Re: [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 19:19:47 -0000 --f46d043c093ec0d3d504bd803ce4 Content-Type: text/plain; charset=ISO-8859-1 My one big concern about this that users find a way to exploit this behavior for themselves. If it's too easy for users to create tx they know will get stuck and expire, it's no different than letting them cancel their zero-conf transactions. i.e. I pay 0.5 BTC in a store for a candy bar, so I send it using a combination of inputs and fees that I know will lead to it being stuck and expire. On the other hand, if such conditions are deterministic enough, it could be detected by the recipient and flagged. It's not a huge deal, but it's something to consider. -Alan On Thu, Apr 12, 2012 at 2:38 PM, Jeff Garzik wrote: > 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 > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --f46d043c093ec0d3d504bd803ce4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My one big concern about this that users find a way to exploit this behavio= r for themselves. =A0If it's too easy for users to create tx they know wi= ll get stuck and expire, it's no different than letting them cancel the= ir zero-conf transactions. =A0i.e. I pay 0.5 BTC in a store for a candy bar= , so I send it using a combination of inputs and fees that I know will lead= to it being stuck and expire. =A0

On the other hand, if such conditions are deterministic enou= gh, it could be detected by the recipient and flagged.

I= t's not a huge deal, but it's something to consider. =A0

-Alan



= On Thu, Apr 12, 2012 at 2:38 PM, Jeff Garzik <jgarzik@exmulti.com> wrote:
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. =A0Transactions 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. =A0i.e.

1. =A0N =3D 1 or 2 or whatever the community prefers. =A0Ideally enough tim= e
for a third-tier miner, mining strange TXs, finds a block.
2. =A0H1 =3D height of block chain, when a TX is received
3. =A0H2 =3D H1 + (144 * N)
4. =A0If 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" af= ter 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). =A0Then 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

---------------------------------------------------------------------------= ---
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.= sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--f46d043c093ec0d3d504bd803ce4--