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
>
Personally, I would have wait a bit before to go public on this, like
letting some implementations
increasing their CLTV deltas, but anyway, it's here now.
Mempool-pinning attacks were already discussed on this list [0], but what
we found is you
can _reverse_ the scenario, where it's not the malic
Just a tip: if you'd like to get feedback on your work, then share your
work as well, since not many people are willing to commit to helping unless
they know how large the work is.
On Tue, Apr 21, 2020 at 10:51 PM Shiva Jairam via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi a
On Tue, Apr 21, 2020 at 09:13:34PM -0700, Olaoluwa Osuntokun wrote:
> On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev
> wrote:
> > While this is somewhat unintuitive, there are any number of good anti-DoS
> > reasons for this, eg:
>
> None of these really strikes me as "g
A few replies inline.
On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote:
> Hi Matt,
>
>
>> While this is somewhat unintuitive, there are any number of good anti-DoS
>> reasons for this, eg:
>
> None of these really strikes me as "good" reasons for this limitation, which
> is at the root of this iss
On 4/22/20 12:12 AM, ZmnSCPxj wrote:
> Good morning Matt, and list,
>
>
>
>> RBF Pinning HTLC Transactions (aka "Oh, wait, I can steal funds, how,
>> now?")
>> =
>>
>> You'll note that in the discussion of RBF pinning we were pretty broad,
>> and that
On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev wrote:
> A lightning counterparty (C, who received the HTLC from B, who
> received it from A) today could, if B broadcasts the commitment
> transaction, spend an HTLC using the preimage with a low-fee,
> RBF-disabled transacti
Hello All,
## Objective
* Make atomic swaps within the same chain possible in a traceless way
* Achieving traceless same-chain atomic-swaps effectively turns an entire
chain into a (P2PKH) mixer by default
## Proposed solution
Similar to the way that atomic swaps would work with schnorr signatur
> In that case, would it be worth re-implementing something like a BIP61
reject message but with an extension that returns the txids of any
conflicts?
That's an interesting idea, but an attacker can create a local conflict in
your mempool
and then send the preimage tx to make hit recentRejects unt
On Wed, Apr 22, 2020 at 03:03:29PM -0400, Antoine Riard wrote:
> > In that case, would it be worth re-implementing something like a BIP61
> reject message but with an extension that returns the txids of any
> conflicts?
>
> That's an interesting idea, but an attacker can create a local conflict in
Hmm, that's an interesting suggestion, it definitely raises the bar for attack
execution rather significantly. Because lightning (and other second-layer
systems) already relies heavily on uncensored access to blockchain data, its
reasonable to extend the "if you don't have enough blocks, aggres
Hi Z,
> It seems to me that, if my cached understanding that `<0>
> OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then adding
> that to the hashlock branch (2 witness bytes, 0.5 weight) would be a
pretty
> low-weight mitigation against this attack.
I think this works...so they're
Hi z,
Actually, the current anchors proposal already does this, since it enforces
a
CSV of 1 block before the HTLCs can be spent (the block after
confirmation). So
I think we already do this, meaning the malicious node is already forced to
use
an RBF-replaceable transaction.
-- Laolu
On Wed, Ap
> This seems like a somewhat unnecessary drive-by insult of a project you
> don't contribute to, but feel free to start with a concrete suggestion
> here :).
This wasn't intended as an insult at all. I'm simply saying if there's
concern about worst case eviction/replacement, optimizations likely e
> On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun wrote:
>
> > Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to
> > braodcasted transactions, but instead to CPFP a maybe-broadcasted
> > transaction by sending a transaction which spends it and seeing if it is
> > accepted
> Indeed, that is what I’m suggesting
Gotcha, if this is indeed what you're suggesting (all HTLC spends are now
2-of-2 multi-sig), then I think the modifications to the state machine I
sketched out in an earlier email are required. An exact construction which
achieves the requirements of "you can'
On 4/22/20 7:27 PM, Olaoluwa Osuntokun wrote:
>
>> Indeed, that is what I’m suggesting
>
> Gotcha, if this is indeed what you're suggesting (all HTLC spends are now
> 2-of-2 multi-sig), then I think the modifications to the state machine I
> sketched out in an earlier email are required. An exa
Hi everyone,
Sorry to just be getting to a response here. Hadn't noticed it till now.
*(Plug: If anyone or their organizations would like to assist in funding
the work described below for a group of developers, I've been working to
put resources together for funding the above for a few months now
Good morning lists et al,
Let me try to summarize things a little:
* Suppose we have a forwarding payment A->B->C.
* Suppose B does not want to maintain a mempool and is running in `blocksonly`
mode to reduce operational costs.
* C triggers B somehow dropping the B<->C channel, such as by sendin
Great summary, a few notes inline.
> On Apr 22, 2020, at 21:50, ZmnSCPxj wrote:
>
> Good morning lists et al,
>
> Let me try to summarize things a little:
>
> * Suppose we have a forwarding payment A->B->C.
> * Suppose B does not want to maintain a mempool and is running in
> `blocksonly` mo
20 matches
Mail list logo
