Jeff Garzik [ARCHIVE] on Nostr: 📅 Original date posted:2014-08-05 📝 Original message:Glad this was brought up. ...
📅 Original date posted:2014-08-05
📝 Original message:Glad this was brought up.
Transaction expiration is something that I have wanted to see happen in
bitcoin for a long, long time. The user experience of unconfirming
transactions setting around in limbo is just horrible. Bitcoin software by
necessity has gotten better about attaching fees so this sort of behavior
is uncommon, but that does not eliminate the problem.
Of course, we cannot presume that a transaction will truly disappear -- The
Internet Never Forgets -- but given a bit of mempool adjusting, we can
achieve the next best thing: the majority of the network "forgets" the
transaction and becomes willing to relay a respend of some or all of the
inputs. This uses existing client logic where the client must rebroadcast
a transaction until it is confirmed.
In general, if a transaction has not made it into a block within 144*X
blocks, there is _some_ reason it is getting rejected by the miners.
The mempool janitor is a garbage collector design. This is inferior to the
"superblock" model described at
https://github.com/bitcoin/bitcoin/issues/3723 Other models can also
achieve similar results.
There are a lot of issues tied together here: transaction expiration, the
desire to cap the mempool ram usage, scalability, DoS prevention, ...
mempool ties a lot together.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140805/a0141ec0/attachment.html>;
📝 Original message:Glad this was brought up.
Transaction expiration is something that I have wanted to see happen in
bitcoin for a long, long time. The user experience of unconfirming
transactions setting around in limbo is just horrible. Bitcoin software by
necessity has gotten better about attaching fees so this sort of behavior
is uncommon, but that does not eliminate the problem.
Of course, we cannot presume that a transaction will truly disappear -- The
Internet Never Forgets -- but given a bit of mempool adjusting, we can
achieve the next best thing: the majority of the network "forgets" the
transaction and becomes willing to relay a respend of some or all of the
inputs. This uses existing client logic where the client must rebroadcast
a transaction until it is confirmed.
In general, if a transaction has not made it into a block within 144*X
blocks, there is _some_ reason it is getting rejected by the miners.
The mempool janitor is a garbage collector design. This is inferior to the
"superblock" model described at
https://github.com/bitcoin/bitcoin/issues/3723 Other models can also
achieve similar results.
There are a lot of issues tied together here: transaction expiration, the
desire to cap the mempool ram usage, scalability, DoS prevention, ...
mempool ties a lot together.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140805/a0141ec0/attachment.html>;