On Thu, Nov 2, 2023 at 6:27 AM Peter Todd via bitcoin-dev
wrote:
>
> On Thu, Nov 02, 2023 at 05:24:36AM +, Antoine Riard wrote:
> > Hi Peter,
> >
> > > So, why can't we make the HTLC-preimage path expire? Traditionally, we've
> > tried
> > > to ensure that transactions - once valid - remain va
I think if we apply this presigned fee multiplier idea to HTLC spends,
we can prevent replacement cycles from happening.
We could modify HTLC scripts so that *both* parties can only spend the
HTLC via presigned second-stage transactions, and we can always sign
those with SIGHASH_ALL. This will pr
On Thu, Oct 19, 2023 at 5:22 PM Antoine Riard wrote:
>
> Hi Matt,
>
> This mitigation is mentioned in the attached paper (see subsection 3.4
> defensive fee-rebroadcasting)
> https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf
>
> As soon as you start
On Wed, Oct 18, 2023 at 12:34 AM Matt Corallo via bitcoin-dev
wrote:
>
> There appears to be some confusion about this issue and the mitigations. To
> be clear, the deployed
> mitigations are not expected to fix this issue, its arguable if they provide
> anything more than a PR
> statement.
>
>
On Mon, Oct 16, 2023 at 7:21 PM Peter Todd via bitcoin-dev
wrote:
> I think if you want people to understand this exploit, you need to explain in
> more detail how we have a situation where two different parties can spend the
> same HTLC txout, without the first party having the right to spend i
