< intcat>
in bitcoin core, are RBF transactions that are replaced removed entirely from the mempool? or are they kept around until either one confirms?
< Varunram>
intcat: the idea is that if a miner sees a higher tx fee, he is more likely to pick it up, so yeah, they are around until either one confirms
< intcat>
Varunram: im asking about the original (lower fee) tx; replacement implies that this one is removed (to make place for the higher fee tx) but i am not sure if it's possible to do that deterministically
< sipa>
h
< sipa>
intcat: the mempool tries to represent a node's best guess for what will be confirmed
< intcat>
sipa: so only one of the options is kept?
< sipa>
yes
< sipa>
the mempool is always internally consistent
< sipa>
it never contains conflicting transactions
< sipa>
for the purposes of fast block relay (bip 152), the old version is kept around for a short period of time, though
< Varunram>
thanks for correcting my understanding :)
< intcat>
hmm
< intcat>
i see, thanks for answering
< intcat>
i suppose the mempool should just not be expected to be deterministic in the first place :P
< intcat>
sipa: one followup; is an exception made for wallet transactions? listtransactions has an (undocumented) 'walletconflicts' return value
< intcat>
(i am asking in the context of setting up a system that reactively CPFPs to an attempted double-spend via RBF)
< intcat>
(although reading the RBF BIP more closely it seems that this may not work as there is no way to undo a RBF)
< sipa>
intcat: you can have wallet transactions that aren't in the mempool
< intcat>
that makes sense
< sipa>
in general the wallet is independent from the rest of the node
< sipa>
anything else would be a privacy leak
< sipa>
if the node's operation would depend on whether transactions are yours or not
< intcat>
sipa: yes, i am aware of that :) but i had figured it the other way around - node keeps all RBF "alternatives"
< intcat>
will have to think more on this; the problem i am trying to figure out is if there is incoming RBF tx A0, and the sender doublespends as A1, i would want to build a CPFP tx B0 on top of A0 to "RBF back"
< intcat>
i will have to do some testing but from my current reading of RBF policy this doesnt seem possible
< arubi>
what does RBF has to do with it?
< arubi>
rbf doesn't mean "double spending enabled". you might as well run this "cpfp back" thing on any incoming transaction
< intcat>
arubi: i mean if i get an incoming rbf-enabled tx, and later my nodes sees a doublespend using the rbf feature, i want to react to it
< intcat>
i am not saying doublespends are the only use of rbf, but they are something to consider
< arubi>
why only consider double spending of rpf enabled transactions? it can happen even without rbf
< intcat>
arubi: because i wont see them, because they are not usually propagated
< intcat>
can't react to what i can't see, unfortunately
< arubi>
so I don't understand, you said it yourself, by policy A0 has been replaced with A1, now how would B0 build on top of A0 if it's gone?
< intcat>
arubi: because reality is relative and decentralized
< intcat>
A0 is not absolutely gone
< intcat>
just relatively gone from the perspective of rbf-respecting nodes
< arubi>
sure you could relay A0 and B0 again, but these same nodes will be the same ones who will not propagate a double spend at all
< intcat>
my intent is to re-replace A1 with A0 through B0's CPFP
< intcat>
current bitcoin core policy does not facilitate that - i think. i mean to test this but now have to run
< arubi>
right, it shouldn't allow replacing an RBF'ed tx with its previous lower fee version. cheers, later
< intcat>
arubi: one more thought - if A0 and B0 were already propagated, A1 would need to "bid higher" than the accumulated fees of A0 and B0, so in that case, the A1 of my scenario would not replace A0 and B0 because they have higher combined fee
< intcat>
so it's a question of which tx out of A1 and B0 arrives first in rbf-respecting nodes
< intcat>
imho the logic should be more RBAF - replace by accumulative fee
< arubi>
you can assume that if A1 arrived to you, then it arrived to most nodes
< arubi>
rbAf would allow for double spending too, if the double spender cpfp's instead of the defender
< intcat>
sure, but at least the defender is able to defend
< intcat>
it can go back and forth, i guess
< intcat>
but rbf as-is does not have a "defender" at all because they cannot defend
< intcat>
anyway really have to run now! thanks for the discussion :)
< arubi>
I don't think it's realistic to consider such a scenario anyway. it's the reason we wait for confirmations before providing goods
< bitcoin-git>
[bitcoin] jakubtrnka opened pull request #12774: Issue #10542 Signmessage doesn't work with segwit addresses (master...master) https://github.com/bitcoin/bitcoin/pull/12774
< bitcoin-git>
[bitcoin] Christewart opened pull request #12775: Integration of property based testing into Bitcoin Core (master...rapidcheck_build) https://github.com/bitcoin/bitcoin/pull/12775