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
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
"David A. Harding via bitcoin-dev"
writes:
> To avoid the excessive wasting of bandwidth. Bitcoin Core's defaults
> require each replacement pay a feerate of 10 nBTC/vbyte over an existing
> transaction or package, and the defaults also allow transactions or
> packages up to 100,000 vbytes in
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 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 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
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
> 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
> 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
> 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
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 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
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
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
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
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 issue, and will also plague any more complex Bitcoin
contracts which rely on nested
27 matches
Mail list logo
