Re: [Lightning-dev] [bitcoin-dev] Batch exchange withdrawal to lightning requires covenants

2023-10-18 Thread Greg Sanders
> I do not know if existing splice implementations actually perform such a check. Unless all splice implementations do this, then any kind of batched splicing is risky. As long as the implementation decides to splice again at some point when a prior splice isn't confirming, it will self-resolve on

[Lightning-dev] Practical PTLCs, a little more concretely

2023-09-06 Thread Greg Sanders
Hi devs, Since taproot channels are deploying Soon(TM), I think it behooves us to turn some attention to PTLCs as a practical matter, drilling down a bit deeper. I've found it helpful to recap technical topics that have been going on for over half a decade(ala ln-symmetry), and PTLCs fall into tha

Re: [Lightning-dev] "Updates Overflow" Attacks against Two-Party Eltoo ?

2022-12-13 Thread Greg Sanders
Hi Antoine, Nothing you say here(about vanilla eltoo) sounds absurd. > Therefore, transaction RN.0 should fail to punish update transaction 0 as it's double-spent by update transaction 1, transaction RN.1 should fail to punish update transaction 1 as it's double-spent by update transaction 2, tra

Re: [Lightning-dev] Two-party eltoo w/ punishment

2022-12-08 Thread Greg Sanders
Antoine, > While the 2*to_self_delay sounds the maximum time delay in the state publication scenario where the cheating counterparty publishes a old state then the honest counterparty publishes the latest one, there could be the case where the cheating counterparty broadcast chain of old states, u

Re: [Lightning-dev] Splice Pinning Prevention w/o Anchors

2022-09-26 Thread Greg Sanders
> I think this mitigation requires reliable access to the UTXO set In this case, how about just setting nsequence to the value 1? UTXO may not exist, but maybe that's ok since it means it cannot pin the commitment tx. > If this concern is correct, I'm not sure we have a current good solution, the

Re: [Lightning-dev] Splice Pinning Prevention w/o Anchors

2022-08-10 Thread Greg Sanders
t means I'm wrong about the ancestor bulking variant as a > malicious counterparty can put a high feerate splice tx at the bottom of > the mempool, requiring a higher feerate to replace it. > > On Wed, Aug 10, 2022 at 12:31 PM Greg Sanders > wrote: > >> Your reading is correc

Re: [Lightning-dev] Splice Pinning Prevention w/o Anchors

2022-08-10 Thread Greg Sanders
> pay for them? Or maybe your comment was just generally about how it can > matter in certain cases > > On Wed, Aug 10, 2022 at 12:06 PM Greg Sanders > wrote: > >> > I think the ancestor bulking variant of pinning only matters if you are >> trying to add a new descend

Re: [Lightning-dev] Splice Pinning Prevention w/o Anchors

2022-08-10 Thread Greg Sanders
> I think the ancestor bulking variant of pinning only matters if you are trying to add a new descendant and can't due to the ancestor/descendant limits. Not quite. It also matters if you want to RBF that transaction, since low feerate ancestor junk puts the transaction at the bottom of the mempoo

Re: [Lightning-dev] Gossip Propagation, Anti-spam, and Set Reconciliation

2022-04-21 Thread Greg Sanders
I think I mentioned this out of band to Alex, but (b) is what Erlay's proposal is for Bitcoin gossip, so it's worth studying up. On Thu, Apr 21, 2022 at 9:18 AM Matt Corallo wrote: > Instead of trying to make sure everyone’s gossip acceptance matches > exactly, which as you point it seems like a

Re: [Lightning-dev] Scriptless Scripts with ECDSA

2018-05-08 Thread Greg Sanders
>From what I understand talking to folks, the linear properties of these signature tricks are maintained under a number of post-quantum schemes. On Tue, May 8, 2018 at 8:44 AM, Benjamin Mord wrote: > > If I'm not mistaken, the scriptless scripts concept (as currently > formulated) falls to Schor

Re: [Lightning-dev] lightning operation during / following a chain fork (e.g. BIP 50)

2018-01-30 Thread Greg Sanders
worth addressing, as that is the case by >> default with a BIP 50-style accidental fork, and also appeared likely with >> the failed (and poorly named) "segwit2x". But I'm thinking out loud, will >> stop spamming people on the list unless / until I ha

Re: [Lightning-dev] lightning operation during / following a chain fork (e.g. BIP 50)

2018-01-30 Thread Greg Sanders
"Adversarial" forks that rip out segwit, or maliciously do not change their signature algorithm, are basically impossible to defend against. May be best to focus energies on forks that use strong replay protection in the form of FORKID. On Tue, Jan 30, 2018 at 11:26 AM, Benjamin Mord wrote: > >