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 guarante
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 could
Hey Z-man, Antoine,
Thank you for your feedback, responses inline.
z-man:
> Then if I participate in a batched splice, I can disrupt the batched
> splice by broadcasting the old state and somehow convincing miners to
> confirm it before the batched splice.
Correct, I didn't mention it in my pos
Good morning list,
I've been trying to design a protocol to let users withdraw funds from
exchanges directly into their lightning wallet in an efficient way
(with the smallest on-chain footprint possible).
I've come to the conclusion that this is only possible with some form of
covenants (e.g. `S
. Of course, the
>>>> difference here is that the 25-descendant limit rule is a sensible DoS
>>>> protection, while this 1-descendant limit rule is more of a "help the
>>>> Bitcoin ecosystem" policy, just like CPFP carve-out, dust limi
say we'll always have tricky fingerprints leaking from unilateral LN
> closures such as HTLC/PTLC timelocks...
>
> > I agree with you, this isn't worse than today, unilateral closes will
> probably always be identifiable on-chain.
>
> Great to hear that th
Thanks Gloria for this great post.
This is very valuable work for L2 contracts, and will greatly improve
their security model.
> "Only 1 anchor output? What if I need to bump counterparty's commitment
tx in mempool?"
> You won't need to fee-bump a counterparty's commitment tx using CPFP.
> You wo
n late 2021 (and reviewers of that PR) when they wrote
> the BIP in 2015.
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
>
> --- Original Message ---
> On Mo
Hi AJ, Prayank,
> I think that's backwards: we're trying to discourage people from wasting
> the network's bandwidth, which they would do by publishing transactions
> that will never get confirmed -- if they were to eventually get confirmed
> it wouldn't be a waste of bandwith, after all. But if t
Hi Gloria,
Many thanks for raising awareness on these issues and constantly pushing
towards finding a better model. This work will highly improve the
security of any multi-party contract trying to build on top of bitcoin
(because most multi-party contracts will need to have timeout conditions
and
Hi Jeremy,
Right now, lightning anchor outputs use a 330 sats amount. Each commitment
transaction has two such outputs, and only one of them is spent to help the
transaction get confirmed, so the other stays there and bloats the utxo set.
We allow anyone to spend them after a csv of 16 blocks, in
>
> I think we could restrain package acceptance to only confirmed inputs for
> now and revisit later this point ? For LN-anchor, you can assume that the
> fee-bumping UTXO feeding the CPFP is already
> confirmed. Or are there currently-deployed use-cases which would benefit
> from your proposed Ru
Great, thanks for this clarification!
Can you confirm that this won't be an issue either with your
example 2C (in your first set of diagrams)? If I understand it
correctly it shouldn't, but I'd rather be 100% sure.
A package A + C will be able to replace A' + B regardless of
the weight of A' + B?
Hi Gloria,
> I believe this attack is mitigated as long as we attempt to submit
transactions individually
Unfortunately not, as there exists a pinning scenario in LN where a
different commit tx is pinned, but you actually can't know which one.
Since I really like your diagrams, I made one as wel
Hi Gloria,
Thanks for this detailed post!
The illustrations you provided are very useful for this kind of graph
topology problems.
The rules you lay out for package RBF look good to me at first glance
as there are some subtle improvements compared to BIP 125.
> 1. A package cannot exceed `MAX_P
Great idea, I'll join as well.
Thanks for setting this in motion.
Le ven. 23 avr. 2021 à 17:39, Antoine Riard a
écrit :
> Hi Jeremy,
>
> Yes dates are floating for now. After Bitcoin 2021, sounds a good idea.
>
> Awesome, I'll be really interested to review again an improved version of
> sponsor
Good morning list,
This is an interesting and simple idea, thanks for sharing this paper!
However I think there are a couple of important issues (but it could be me
misunderstanding):
* the assumption that the mempool is a shared resource is flawed: it's
entirely possible
to have very differen
Hey ZmnSCPxj,
I agree that in theory this looks possible, but doing it in practice with
accurate control
of what parts of the network get what tx feels impractical to me (but maybe
I'm wrong!).
It feels to me that an attacker who would be able to do this would break
*any* off-chain
construction t
Thanks for the detailed write-up on how it affects incentives and
centralization,
these are good points. I need to spend more time thinking about them.
This is one reason I suggested using independent pay-to-preimage
> transactions[1]
>
While this works as a technical solution, I think it has som
Hello Dave and list,
Thanks for your quick answers!
The attacker would be broadcasting the latest
> state, so the honest counterparty would only need to send one blind
> child.
>
Exactly, if the attacker submits an outdated transaction he would be
shooting himself in the foot,
as we could claim
Good morning list,
Sorry for being (very) late to the party on that subject, but better late
than never.
A lot of ideas have been thrown at the problem and are scattered across
emails, IRC discussions,
and github issues. I've spent some time putting it all together in one
gist, hoping that it wil
Hi Antoine and list,
Thanks for raising this. There's one step I'd like to understand further:
* Mallory can broadcast its Pinning Preimage Tx on offered HTLC #2 output
> on Alice's transaction,
> feerate is maliciously chosen to get in network mempools but never to
> confirm. Absolute fee must
>
22 matches
Mail list logo
