MIME-Version: 1.0
In-Reply-To: <CAGQP0AGbLYZYwKGb0AHOPx3BadBQ399A67ntEo98mpm=kKgZ+g@mail.gmail.com>
References: <CA+8xBpc5CZ9Sx4MwPdeS0-5frnV9B+mJ5OwcPoUVrygTawiJBg@mail.gmail.com>
	<CAGQP0AGbLYZYwKGb0AHOPx3BadBQ399A67ntEo98mpm=kKgZ+g@mail.gmail.com>
Date: Sun, 15 Apr 2012 11:17:04 -0400
Message-ID: <CA+8xBpehkZZaJEEnxH0_gzz5n=LNCvDBMS0uD3ErW1p-=uaE6Q@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: jtimonmv@gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic
	behavior
Precedence: list

2012/4/15 Jorge Tim=F3n <timon.elviejo@gmail.com>:
> On 4/12/12, Jeff Garzik <jgarzik@exmulti.com> wrote:
>> 1. =A0N =3D 1 or 2 or whatever the community prefers. =A0Ideally enough =
time
>> 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
>
> Why not just adding a field expiration_block =3D H2?
> It seems more explicit and flexible than using a 144 * N constant.
> You're changing the protocol anyway, right?

No, not changing the protocol.

Further, adding a field to TX would imply the client needed to rewrite
the TX for each retransmit, changing the hash.  Not good at all.

> Another question, aren't different peers going to get different H1 for
> the same tx?

Typically no, because 99.9% of TX's make it throughout the network in
seconds.  But yes it is possible, just like it is possible today to
receive a TX at various times.

--=20
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com