Hi Peter,
> Obviously a local replacement cache is a possibility. The whole point of my
> email is to show that a local replacement cache isn't necessarily needed, as
> any alturistic party can implement that cache for all nodes.
Sure, note as soon as you start to introduce an altruistic party rebroadcasting for everyone in the network, we're talking about a different security model for time-sensitive second-layers. And unfortunately, one can expect the same dynamics we're seeing with BIP157 filter servers, a handful of altruistic nodes for a large swarm of clients.
> 1) That is trivially avoided by only broadcasting txs that meet the local
> mempool min fee, plus some buffer. There's no point to broadcasting txs that
> aren't going to get mined any time soon.
>
> 2) BIP-133 feefilter avoids this as well, as Bitcoin Core uses the feefilter
> P2P message to tell peers not to send transactions below a threshold fee rate.
>
>
https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki
I know we can introduce BIP-133 style of filtering here only the top % of the block template is altruistically rebroadcast. I still think this is an open question how a second-layer node would discover the "global" mempool min fee, and note an adversary might inflate the top % of block template to prevent rebroadcast of malicious HTLC-preimage.
> Did you actually read my email? I worked out the budget required in a
> reasonable worst case scenario:
Yes. I think my uncertainty lies in the fact that an adversary can rebroadcast _multiple_ times the same UTXO amount under different txids, occupying all your altruistic bandwidth. Your economic estimation makes an assumption per-block (i.e 3.125 BTC / 10 minutes). Where it might be pernicious is that an adversary should be able to reuse those 3.125 BTC of value for each inter-block time.
Of course, you can introduce an additional rate-limitation per-UTXO, though I think this is very unsure how this rate-limit would not introduce a new pinning vector for "honest" counterparty transaction.
> Here, we're talking about an attacker that has financial resources high enough
> to possibly do 51% attacks. And even in that scenario, storing the entire
> replacement database in RAM costs under $1000
> The reality is such an attack would probably be limited by P2P bandwidth, not
> financial resources, as 2MB/s of tx traffic would likely leave mempools in an
> somewhat inconsistent state across the network due to bandwidth limitations.
> And that is *regardless* of whether or not anyone implements alturistic tx
> broadcasting.
Sure, I think we considered bandwidth limitations in the design of the package relay. Though see my point above, the real difficulty in your proposed design sounds to me in the ability to reuse the same UTXO liquidity for an unbounded number of concurrent replacement transactions exhausting all the altruistic bandwidth.
One can just use a 0.1 BTC UTXO and just fan-out 3.125 BTC of concurrent replacement transactions from then. So I don't think the assumed adversary financial resources are accurate.
I think the best long-term way to fix replacement cycling is still more in the direction of things like:
With the additional constraint of removing package malleability, where all the feerate is coming from package self-contained fee-bumping reserves UTXOs.
Best,
Antoine