< bitcoin-git> [bitcoin] fanquake closed pull request #12412: Enable spectre mitigations when supported by compiler. (master...spectre-mitigation) https://github.com/bitcoin/bitcoin/pull/12412
< midnightmagic> Uh
< midnightmagic> Who was it who built a new block parser? I know of znort's but there was a new one I saw very recently .. was it achow101 ?
< achow101> block parser?
< midnightmagic> yea, a raw interface to dump the contents of on-disk block .dat files.
< achow101> I have one that I use personally, it shouldn't be public
< midnightmagic> oh.
< midnightmagic> In that case, there was one I saw on github-- and I'm presuming it wasn't you, then. :)
< achow101> I recently put it on github and may have accidentally not made it a private repo
< achow101> midnightmagic: maybe you're thinking of https://github.com/alecalve/python-bitcoin-blockchain-parser
< achow101> or blocksci?
< midnightmagic> I believe it was written in C++ or C.
< midnightmagic> -- which is why I was so happy with it, since I'd been relying on znort's for a long time.
< midnightmagic> hrmm.. doesn't look familiar.
< midnightmagic> thanks though!
< midnightmagic> achow101: I think I may have been misremembering this: https://github.com/rustyrussell/bitcoin-iterate/blob/master/doc/bitcoin-iterate.1.txt But thanks for the blocksci pointer!
< midnightmagic> \o
< 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
< arubi> cya :)
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/02b7e8319aef...b43aba89e356
< bitcoin-git> bitcoin/master bc308ba Karl-Johan Alm: [CI]: bump travis timeout for make check to 50m
< bitcoin-git> bitcoin/master b43aba8 MarcoFalke: Merge #12772: [CI]: bump travis timeout for make check to 50m...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12772: [CI]: bump travis timeout for make check to 50m (master...bump_travis_timeout) https://github.com/bitcoin/bitcoin/pull/12772
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b43aba89e356...7466a26cab5d
< bitcoin-git> bitcoin/master 30d1a0a Jim Posen: Docs: Improve documentation on standard communication channels...
< bitcoin-git> bitcoin/master 7466a26 MarcoFalke: Merge #12760: Docs: Improve documentation on standard communication channels...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12760: Docs: Improve documentation on standard communication channels (master...communication-channels) https://github.com/bitcoin/bitcoin/pull/12760
< Chris_Stewart_5> Segwit txs don't require nVersion on the transaction to be set to anything do they?
< Chris_Stewart_5> the two version bytes are after the nVersion on the tx?
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12633: Reserve 16 bits of nversion in blockheader (master...reservedbits) https://github.com/bitcoin/bitcoin/pull/12633
< 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