š
Original date posted:2015-05-26
š Original message:Thanks for the clarification.
So, since RBF applies only to pending transactions in the mempool awaiting
incorporation into a block, there is a window of opportunity in which the
pending tx is incorporated into a block at the same time that the spender
is constructing and publishing a replacement for that pending tx.
The replacement transaction would be rejected by the peer network as a
double spend because it conflicts with the now confirmed original tx, and
the spender will have to go back and create a new stand-alone transaction
to accomplish what they hoped to do with an RBF replacement.
So an implementation that wishes to take advantage of RBF will still need
to have a "plan B" implementation path to handle the corner case of a
replacement tx being rejected as a double spend.
Is this correct?
I'm just trying to get my head around the implementation cost vs benefit of
RBF in the context of my applications.
Thanks,
-Danny
On Tue, May 26, 2015 at 2:27 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> It's just a mempool policy rule.
>
> Allowing the contents of blocks to change (other than by mining a
> competing chain) would be pretty much the largest possible change to
> Bitcoin's design....
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150526/ac340045/attachment.html>;
Danny Thorpe [ARCHIVE] /
npub1q5ā¦3ps87
2023-06-07 15:35:42
in reply to nevent1qā¦644y
Author Public Key
npub1q5sgcakfxhw3ya93tvnpqeacvf32p6lw70hke53rkjnf9lhw9w8s43ps87Published at
2023-06-07 15:35:42Event JSON
{
"id": "672484e5ce1ee7b6e40f01a4123b683d603c46dbecefe2d67bf8cbe2c39b03d1",
"pubkey": "05208c76c935dd1274b15b261067b86262a0ebeef3ef6cd223b4a692feee2b8f",
"created_at": 1686152142,
"kind": 1,
"tags": [
[
"e",
"e6c8eb34d0e86c10ed0d76592650d9925932c212d8ecca31dd7a7a68e753372d",
"",
"root"
],
[
"e",
"e21362eb62720da324aa3e8651424a99f21de912c1d35c0916a1af052635fbfa",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "š
Original date posted:2015-05-26\nš Original message:Thanks for the clarification.\n\nSo, since RBF applies only to pending transactions in the mempool awaiting\nincorporation into a block, there is a window of opportunity in which the\npending tx is incorporated into a block at the same time that the spender\nis constructing and publishing a replacement for that pending tx.\n\nThe replacement transaction would be rejected by the peer network as a\ndouble spend because it conflicts with the now confirmed original tx, and\nthe spender will have to go back and create a new stand-alone transaction\nto accomplish what they hoped to do with an RBF replacement.\n\nSo an implementation that wishes to take advantage of RBF will still need\nto have a \"plan B\" implementation path to handle the corner case of a\nreplacement tx being rejected as a double spend.\n\nIs this correct?\n\nI'm just trying to get my head around the implementation cost vs benefit of\nRBF in the context of my applications.\n\nThanks,\n-Danny\n\nOn Tue, May 26, 2015 at 2:27 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e\nwrote:\n\n\u003e It's just a mempool policy rule.\n\u003e\n\u003e Allowing the contents of blocks to change (other than by mining a\n\u003e competing chain) would be pretty much the largest possible change to\n\u003e Bitcoin's design....\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150526/ac340045/attachment.html\u003e",
"sig": "8b6c308d716391b0efa120bca234100da6c64b46eaf10e1b9aad55cc62c21fd76f28cea3224d2859c54c7f2ccac01c79822abc6afa26ff042939d1f786db2c3a"
}