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 to have a bit of a mempool backlog and the defensive
fractional fee
Hi Bastien,
Thanks for your additional comments.
> Yes, they can, and any user could also double-spend the batch using a
> commit tx spending from the previous funding output. Participants must
> expect that this may happen, that's what I mentioned previously that
> you cannot use 0-conf on that
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.
>
>
Thanks Antoine for your work on this issue.
I confirm that eclair v0.9.0 contains the migitations described.
Eclair has been watching the mempool for preimages since its very early
versions (years ago), relying on Bitcoin Core's ZMQ notifications for
incoming transactions. I believe this
Hi Tony, Kulpreet,
> The main concern on the LSP not keeping a reserve is that it's much
> easier for them to steal since the offline concern is on the mobile
> user. We still do not yet have reliable watch tower
> integrations/products to help mitigate this. Yes, there's reputation,
> but how
Hi Antoine,
> If I'm correct, two users can cooperate maliciously against the batch
> withdrawal transactions by re-signing a CPFP from 2-of-2 and
> broadcasting the batch withdrawal as a higher-feerate package / high
> fee package and then evicting out the CPFP.
Yes, they can, and any user
From my nascent understanding this will require differentiating between types
of participants.
Will the above then add complications of participant type into the protocol at
the time of creating commitments, forwarding HTLCs and also finding routes?
-kp
--- Original Message ---
On
We recently removed the reserve for our users in Bitkit (well, down to the
dust limit because it doesn't work currently without it).
After I learned more about it, and the reasoning behind the reserve, I
realized the design is nonsensical.
I fully support Bastien's suggestion for more practical
Hi Bastien,
Thanks for the answer.
If I understand correctly the protocol you're describing you're aiming to
enable batched withdrawals where a list of users are being sent funds from
an exchange directly in a list of channel funding outputs ("splice-out").
Those channels funding outputs are
