Given transaction relay delays and a network topology that is rather
transparent if you look closely enough, I think this is very real and very
practical (double-digit % success rate, at least, with some trial and error
probably 50+). That said, we all also probably know most of the people who
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
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
Good morning Bastien,
> 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
Good morning again,
> Good morning Dave,
>
> > ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was
> > hoping one of Bitcoin's several inventive cryptographers would come
> > along and describe how someone with an adaptor signature could use that
> > information to create a
Good morning Dave,
> ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was
> hoping one of Bitcoin's several inventive cryptographers would come
> along and describe how someone with an adaptor signature could use that
> information to create a pubkey that could be put into a
On Sat, Jun 20, 2020 at 10:54:03AM +0200, Bastien TEINTURIER wrote:
> We're simply missing information, so it looks like the only good
> solution is to avoid being in that situation by having a foot in
> miners' mempools.
The problem I have with that approach is that the incentive is to
connect
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
On Fri, Jun 19, 2020 at 03:58:46PM -0400, David A. Harding via bitcoin-dev
wrote:
> I think you're assuming here that the attacker broadcast a particular
> state.
Whoops, I managed to confuse myself despite looking at Bastien's
excellent explainer. The attacker would be broadcasting the
On Fri, Jun 19, 2020 at 09:44:11AM +0200, Bastien TEINTURIER via Lightning-dev
wrote:
> The gist is here, and I'd appreciate your feedback if I have wrongly
> interpreted some of the ideas:
> https://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12
Quoted text below is from the gist:
>
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
On 4/23/20 8:46 AM, ZmnSCPxj wrote:
>>> - Miners, being economically rational, accept this proposal and include
>>> this in a block.
>>>
>>> The proposal by Matt is then:
>>>
>>> - The hashlock branch should instead be:
>>> - B and C must agree, and show the preimage of some hash H
Good morning David,
Unfortunately this technique does not look like it is compatible to payment
points rather than hashes, and we would really like to upgrade to payment
points sooner rather than later.
Nobody but B can recognize the signature as revealing the scalar behind a
particular
Good morning Matt,
> > - C directly contacts miners with an out-of-band proposal to replace its
> > transaction with an alternative that is much smaller and has a low fee, but
> > much better feerate.
>
> Or they can just wait. For example in today’s mempool it would not be strange
> for a
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`
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
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,
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
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
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
Good morning Laolu, Matt, and list,
> > * With `SIGHASH_NOINPUT` we can make the C-side signature
> > `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side
> > signature for a higher-fee version of HTLC-Timeout (assuming my cached
> > understanding of `SIGHASH_NOINPUT` still
> So what is needed is to allow B to add fees to HTLC-Timeout:
Indeed, anchors as defined in #lightning-rfc/688 allows this.
> * With `SIGHASH_NOINPUT` we can make the C-side signature
> `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side
> signature for a higher-fee version of
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 that discussion seems to in fact cover
> our
23 matches
Mail list logo
