From: Dan Bryant <dkbryant@gmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Transaction aging to relieve user concerns.
Date: Thu, 28 Dec 2017 13:55:01 -0600 [thread overview]
Message-ID: <CAAUFj12x+kRUkcWECesJJRybDsQWfNL_7-D3wYexr6mOUzBY9g@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1717 bytes --]
next reply other threads:[~2017-12-28 19:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-28 19:55 Dan Bryant [this message]
2017-12-28 20:49 ` Mark Friedenbach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAUFj12x+kRUkcWECesJJRybDsQWfNL_7-D3wYexr6mOUzBY9g@mail.gmail.com \
--to=dkbryant@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox