📅 Original date posted:2012-04-12
📝 Original message: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 at exmulti.com
Jeff Garzik [ARCHIVE] /
npub1kf…f3f58
2023-06-07 10:03:57
in reply to nevent1q…8s3c
Author Public Key
npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58Published at
2023-06-07 10:03:57Event JSON
{
"id": "cb0c838645128d4591c646644627bb18c6fc65069c22fc00713dfd9f49cc8e44",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686132237,
"kind": 1,
"tags": [
[
"e",
"5f0cc6578a9ca4b7b0857c070ede1826db3227f161e70524c04566da5c5a56a8",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2012-04-12\n📝 Original message:Not sure whether this rises to the level of a BIP or not, as it is\nlargely an implementation change.\n\nOne of my From-Day-One complaints about bitcoin is that transactions\nbehavior could be far more deterministic (predictable), from a user\nstandpoint. Transactions in the current system can easily remain in\nlimbo forever.\n\nOne big step in making transactions behave more predictably would be\nto remove transactions from the memory pool, if they have not made it\ninto a block for a couple days. i.e.\n\n1. N = 1 or 2 or whatever the community prefers. Ideally enough time\nfor a third-tier miner, mining strange TXs, finds a block.\n2. H1 = height of block chain, when a TX is received\n3. H2 = H1 + (144 * N)\n4. If block chain height reaches H2, and TX has not made it into a\nblock, drop TX from memory pool\n\nAlthough this only impacts a small amount of TX's ultimately, what it\ndoes do is give us the ability -- once miners have upgraded to this\nrule -- to tell bitcoin users that their transactions \"expire\" after N\ndays.\n\nBackwards compatibility should not be an issue; clients are free to\nretransmit their TX at any time, as usual, thereby \"resetting the\nclock\" for all peers who have forgotten the TX in question.\n\nOnce in place, clients may then implement code that notices a TX has\nexpired (read: likely to have been forgotten by the network, assuming\nthey themselves have stopped retransmitting it). Then you can start\nworking on wallet/coin recovery, perhaps resending with a higher fee\netc.\n\nThe above change is not really \"fill-or-kill\" but it should be a big\nstep, opening the door to deterministic TX behavior.\n\n-- \nJeff Garzik\nexMULTI, Inc.\njgarzik at exmulti.com",
"sig": "92dc9029322a0ac31acd3ae6834673d6222f612f9785cd71eeb17a1b7a41ed4c9704a1a638c9e7a848c923e704b28edf025df3f3adc887df143094f9c8b1cb47"
}