Antoine Riard

There was a number of relevant discussions about this PR during yesterday review club session: https://bitcoincore.reviews/25600 The increased resource (inbound/outbound slots) usage of the new 4 outbound-full-rbf peers was raised...

@1440000bytes > I think I had this idea to spoof before any reviewers although it doesn't matter: https://bitcoin.stackexchange.com/questions/114491/how-does-bitcoin-core-handle-service-flag-spoofing About the non-reliability of the service bit, and the subject of spoofing...

> No correction will happen if your time drifts and you only ever cycle through at most 4 distinct honest outbound connections. Also, no correction will happen if your time...

IMO, one of the most straightforward goal is channel-jamming the channels of your routing competitors, thus redirecting HTLC traffic to your routing channels and earning the fees. @LLFourn I'm not...

W.r.t to path proving, I don't think you can prove in ZKP that's the payment path isn't malicious. Proving A --> B --> C --> D is honest means proving...

> B requires slightly more hold_fees from C than A requires from B. And this is the point where I'm not agree on, timelocks decrease along the payment path. A...

> where the add Alice sends in step 1 gives Bob the max htlcs once locked-in, then is the add that Alice sends in step 7 allowed? That's my understanding...

IMO, points of discussion: 1) ensuring efficiency of `option_gc_preimage` means a good peer selection to avoid LN-eclipse 2) preimage monitoring may introduce a) LN topology vector b) full-node-to-LN mapping vector...

> I don't think any implementer reading this will know how to implement it; it is too loose on requirements, and risks channel breakage as a result. Yes having to...

Finally updated at 0ed8805. The level of dust exposure is recommended to be evaluated against a node-setting `max_dust_htlc_exposure_msat`, instead to introduce a new channel parameter. The prescriptive description of `dust_buffer_feerate`...