Hi Peter,
Answering the latest 2 emails.
> Indeed, at this point I strongly suspect had I instead lobbied for a fix
> privately, given that one obvious mitigation is replace-by-fee-rate, I'd
> instead just get accused of nefarious behavior for not doing so openly.
I'll confirm publicly again that transaction-relay bandwidth DoS risks have been
known or suspected by some senior developers for a while, including sometimes
mentioned half-way on the Bitcoin Core GH repository years ago.
> Correct me if I'm wrong. But I don't believe that the `dust_limit_satoshis`
> value can be changed on an existing channel.
> It *should* be possible to change on an existing channel, as the economic dust
> limit is fee-rate dependent. But the protocol does not support that yet IIUC.
This is correct, it cannot be changed once it has been negotiated at opening flow.
Per-BOLT3 "Commitment Transaction Construction", the dust HTLCs are trimmed and
the amount added to the commitment transaction absolute fee.
This ability can let you generate an ascending feerate range of commitment transactions:
- state_1, size 1000 kb, 1 trimmed HTLC ~500 sats absolute fee
- state_2, size 900 kb, 2 trimmed HTLC ~1000 sats absolute fee
- state_3, size 800 kb, 3 trimmed HTLC ~1500 sats absolute fee
- etc
Non-dust HTLC fully materializing on the commitment transaction can be added at wish to
adjust commitment transaction size if you're using a public channel used for routing, without
the "honest interactivity" of your counterparty.
> There's also a convenience aspect to this: large mempools are convenient for
> transaction senders, as it allows them to go off line after sending
> transactions that aren't going to be mined in the near future. If we had a
> world of purely always-online transaction senders, mempools could be smaller.
Yes. This is a good question if a world of common size mempool for hobbyist
full-nodes can still be the network standard in the evolving world of today where
re-broadcasting and pricing the next few blocks become more done by transaction
issuers, evicting transactions without high odds to be mined in the near future.
Said differently, Bitcoin clients with high-timevalue preferences for their use-cases
are out-pricing Bitcoin clients with low-timevalue preferences from network mempools.
> Modulo economic irrationalities with differently sized txs like the Rule #6
> attack, the proof-of-UTXO is almost economically paid even when mempools are
> partitioned because the bandwidth used by a given form of a transaction is
> limited to the % of peers that relay it. Eg if I broadcast TxA to 50% of nodes,
> and TxB to the other 50%, both spending the same txout, the total cost/KB used
> in total would exactly the same... except that nodes have more than one peer.
> This acts as an amplification fator to attacks depending on the exact topology
> as bandwidth is wasted in proportion to the # of peers txs need to be broadcast
> too. Basically, a fan-out factor.
> If the # of peers is reduced, the impact of this type of attack is also
> reduced. Of course, a balance has to be maintained.
Sure, proof-of-UTXO is imperfectly economically charged, however I think you can
re-use the same proof-of-UTXO for each subset of Sybilled transaction-relay peers.
And for sure, # peers and network topology can be leveraged as amplification factors
for this class of "free-relay" attacks. Balance would have to be find compared to worthiness
of carried-on transaction-relay traffic.
> Oh, and to expand on this discussion a bit... Assuming that LN implementations
> did enable this type of attack, I'll point out that it's essentially based on
> having incoming liquidity, which is not free. Either you paid for it by paying
> someone to open channels to you. Or you operated a lightning node that provided
> sufficiently attractive survice that people chose to open channels to you.
> Either way getting that incoming capacity cost you money, probably at similar
> if not worse rates than just borrowing BTC.
Yes, note I used the term "allocated" in one of my previous emails, which I concede
is not well-defined and it's indeed dependent on Lightning channel network dynamics.
I'll leave as an exercise to the reader to find common liquidity management asymmetries
in today's LN implementation to be leveraged as a discount vector for "free-relay" bandwidth
attacks at the transaction-relay network-level.
Best,
Antoine