Hi Peter,
Answering the latest 2 emails.
> Since this attack is just a relatively minor extension of existing, publicly
> disclosed, attacks, I don't think there was any need for formal disclosure
> timelines. It's interesting that the attack exists; it does not substantially
> change the status quo.
Of course, it's always a matter of appreciation when an attack should get a formal
disclosure process and when it can be publicized with minimal process effort.
Given this class of attacks was already known from some experts, I don't think it
requires a formal process either. Attaching a timeline to a disclosure email doesn't hurt.
> I don't believe the other attacks in this attack class are even possible to
fix. We just have to live with the fact that a degree of free relay is always
going to be possible.
See comments under proof-of-UTXO ownership as plausible mitigations.
In anway, I think this is not the type of fixes we can land in a covert fashion given the
order of magnitude of engineering effort and potential tx-relay network impact.
> Can you explain in more detail how exactly you'd pull that off? Are you aware
of LN implementations that actually create feerate ascending LN states?
I think you can create feerates ascending LN states with today's LN implementations by playing with BOLT2's `dust_limit_satoshis`.
State 1 has 1 dust HTLC trimmed, state 2 has 2 dust HTLCs trimmed, ... State N has N dust HTLCs trimmed.
> Imagine if the mempool size was 1TB, an amount larger than the entire BTC
> blocksize to date. I think that example helps make it obvious that with such an
> enormous mempool, there *must* be free relay attacks, because it's simply
> impossible for all broadcast transactions to even get mined.
I think there is an interesting distinction that can be made between mempool size
ressources dedicated to increase block template efficiency and minimum mempool size
to just ensure you have good BIP152 compact block validation time. Obviously if you're
aiming for the first, you're incentivized to offer "free-relay" bandwidth to your peers and
increase your view of the ongoing transaction traffic.
> All the existing replacement mechanisms _are_ basically a proof-of-UTXO
> ownership, because they're transactions spending UTXOs. The only question is
> the details of how that proof works.
Yeah somehow it's correct that any replacement mechanisms encompass a proof-of-UTXO
ownership mechanism. Yet in a world you can partition mempool like you show with your
for example, it's easy to make this proof-of-UTXO economically unpaid by the attacker. Asking
aged UTXOs attached to a replacement candidate could be make such proof more robust, in
my understanding.
Best,
Antoine