MIME-Version: 1.0
Reply-To: DKBryant@gmail.com
From: Dan Bryant <dkbryant@gmail.com>
Date: Thu, 28 Dec 2017 13:55:01 -0600
Message-ID: <CAAUFj12x+kRUkcWECesJJRybDsQWfNL_7-D3wYexr6mOUzBY9g@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c0b77c03d9fe605616be496"
Subject: [bitcoin-dev] Transaction aging to relieve user concerns.
Precedence: list

--94eb2c0b77c03d9fe605616be496
Content-Type: text/plain; charset="UTF-8"

I was considering starting a BIP, but wanted to ask the thread if anything
like this was already done or in the works.  My proposal is to expand the
TXN format to include chain-height (block number) in the TXN.  This would
allow nodes / miners to age the TXN and choose (optionally) not to
rebroadcast it after a certain age threshold.  Currently (as I understand
it), nodes and miners keep effectively a "seen-list" of TXNs and age them
based upon when they were last seen.  This is very effective as it reduces
TXN size and frees the TXN from having to declare its age.  The downside to
this is that those TXNs could be broadcast forever, assuming (big assume)
that the UTXO never got spent.

The goal here is not to enhance the protocol... if anything this would
increase TXN cost as it would add a few bytes to it.  The goal here is to
make it easier for users to know with better certainty when an TXN is going
to age out.  Obviously RBF is a better solution, but there may be some
instances when a user wants to effectively cancel a TXN.

Possible abuse vectors might include:

* Bad party broadcasting a low fee TXN at the edge of the age-out threshold
and trying to get goods, realizing the TXN will age out at the very next
block.

If this proposal might be something that core would entertain in a BIP
proposal I'll start drafting something.  If there are suggestions about
where to place the block number to have minimal impact and ensure backward
compatibility, that would be great to.  If this is simply silly and should
not be entertained, no harm there either.

--94eb2c0b77c03d9fe605616be496
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I was considering starting a BIP, but wanted to ask the th=
read if anything like this was already done or in the works.=C2=A0 My propo=
sal is to expand the TXN format to include chain-height (block number) in t=
he TXN.=C2=A0 This would allow nodes / miners to age the TXN and choose (op=
tionally) not to rebroadcast it after a certain age threshold.=C2=A0 Curren=
tly (as I understand it), nodes and miners keep effectively a &quot;seen-li=
st&quot; of TXNs and age them based upon when they were last seen.=C2=A0 Th=
is is very effective as it reduces TXN size and frees the TXN from having t=
o declare its age.=C2=A0 The downside to this is that those TXNs could be b=
roadcast forever, assuming (big assume) that the UTXO never got spent.<div>=
<br></div><div>The goal here is not to enhance the protocol... if anything =
this would increase TXN cost as it would add a few bytes to it.=C2=A0 The g=
oal here is to make it easier for users to know with better certainty when =
an TXN is going to age out.=C2=A0 Obviously RBF is a better solution, but t=
here may be some instances when a user wants to effectively cancel a TXN.</=
div><div><br></div><div>Possible abuse vectors might include:</div><div><br=
></div><div>* Bad party broadcasting a low fee TXN at the edge of the age-o=
ut threshold and trying to get goods, realizing the TXN will age out at the=
 very next block.</div><div><br></div><div>If this proposal might be someth=
ing that core would entertain in a BIP proposal I&#39;ll start drafting som=
ething.=C2=A0 If there are suggestions about where to place the block numbe=
r to have minimal impact and ensure backward compatibility, that would be g=
reat to.=C2=A0 If this is simply silly and should not be entertained, no ha=
rm there either.</div></div>

--94eb2c0b77c03d9fe605616be496--