Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Jeremy via bitcoin-dev
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

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Matt Corallo via bitcoin-dev
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

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Olaoluwa Osuntokun via bitcoin-dev
> 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

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Matt Corallo via bitcoin-dev
> 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

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Olaoluwa Osuntokun via bitcoin-dev
> 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

Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Olaoluwa Osuntokun via bitcoin-dev
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,

Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Olaoluwa Osuntokun via bitcoin-dev
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

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Matt Corallo via bitcoin-dev
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,

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread David A. Harding via bitcoin-dev
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

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Antoine Riard via bitcoin-dev
> 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

[bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures

2020-04-22 Thread German Luna via bitcoin-dev
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

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread David A. Harding via bitcoin-dev
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

Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Matt Corallo via bitcoin-dev
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

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Matt Corallo via bitcoin-dev
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

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread David A. Harding via bitcoin-dev
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

Re: [bitcoin-dev] Academic research regarding BIP0002

2020-04-22 Thread nopara73 via bitcoin-dev
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

Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Bastien TEINTURIER via bitcoin-dev
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

Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread Antoine Riard via bitcoin-dev
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

Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

2020-04-22 Thread ZmnSCPxj via bitcoin-dev
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