> 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
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
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
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
> 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
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
> 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
> 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
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
>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
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
"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:
>
>
12 matches
Mail list logo