Re: [Lightning-dev] [RFC] Lightning gossip alternative

[Rusty Russell]

ZmnSCPxj  writes:
> Good morning rusty,
>
> If we are going to switch to a new gossip version, should we prepare now for 
> published channels that are backed by channel factories?

This is already true with the new proposal: channels don't have to be
"real".  It's possible to raise the required ratio later, so less UTXO
proof is required (since channels are prioritized by their id, you can
choose which ones older nodes will see.

Cheers,
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

[Jeremy Rubin]

Morning!

>
> For the latter case, CPFP would work and already exists.
> **Unless** you are doing something complicated and offchain-y and involves
> relative locktimes, of course.
>
>
The "usual" design I recommend for Vaults contains something that is like:

{ CSV  CHECKSIG,  CHECKSIG}
or
{ CSV  CHECKSIG,  CHECKSIG)> CTV}


where after an output is created, it has to hit maturity before hot
spendable but can be kicked to recovery any time before (optional: use CTV
to actually transition on chain removing hot wallet, if cold key is hard to
access).


Not that this means if you're waiting for one of these outputs to be
created on chain, you cannot spend from the hot key since it needs to
confirm on chain first. Spending from the cold key for CPFP'ing the hot is
an 'invalid move' (emergency key for non emergency sitch)

Thus in order to CPFP, you would need a separate output just for CPFPing
that is not subject to these restrictions, or some sort of RBF-able addable
input/output. Or, Sponsors.


Jeremy
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

[ZmnSCPxj via Lightning-dev]

Good morning Jeremy,

> opt-in or explicit tagging of fee account is a bad design IMO.
>
> As pointed out by James O'Beirne in the other email, having an explicit key 
> required means you have to pre-plan suppose you're building a vault meant 
> to distribute funds over many years, do you really want a *specific* 
> precommitted key you have to maintain? What happens to your ability to bump 
> should it be compromised (which may be more likely if it's intended to be a 
> hot-wallet function for bumping).
>
> Furthermore, it's quite often the case that someone might do a transaction 
> that pays you that is low fee that you want to bump but they choose to 
> opt-out... then what? It's better that you should always be able to fee bump.

Good point.

For the latter case, CPFP would work and already exists.
**Unless** you are doing something complicated and offchain-y and involves 
relative locktimes, of course.


Once could point out as well that Peter Todd gave just a single example, 
OpenTimeStamps, for this, and OpenTimeStamps is not the only user of the 
Bitcoin blockchain.

So we can consider: who benefits and who suffers, and does the benefit to the 
former outweigh the detriment of the latter?


It seems to me that the necromancing attack mostly can *only* target users of 
RBF that might want to *additionally* add outputs (or in the case of OTS, 
commitments) when RBF-ing.
For example, a large onchain-paying entity might lowball an onchain transaction 
for a few withdrawals, then as more withdrawals come in, bump up their feerate 
and add more withdrawals to the RBF-ed transaction.
Such an entity might prefer to confirm the latest RBF-ed transaction, as if an 
earlier transaction (which does not include some other withdrawals requested 
later) is necromanced, they would need to make an *entire* *other* transaction 
(which may be costlier!) to fulfill pending withdrawal requests.

However, to my knowledge, there is no actual entity that *currently* acts this 
way (I do have some sketches for a wallet that can support this behavior, but 
it gets *complicated* due to having to keep track of reorgs as well... sigh).

In particular, I expect that many users do not really make outgoing payments 
often enough that they would actually benefit from such a wallet feature.
Instead, they will generally make one payment at a time, or plan ahead and pay 
several in a batch at once, and even if they RBF, they would just keep the same 
set of outputs and just reduce their change output.
For such low-scale users, a rando third-party necromancing their old 
transactions could only make them happy, thus this nuisance attack cannot be 
executed.

We could also point out that this is really a nuisance attack and not an 
economic-theft attack.
The attacker cannot gain, and can only pay in order to impose costs on somebody 
else.
Rationally, the only winning move is not to play.


So --- has anyone actually implemented a Bitcoin wallet that has such a feature 
(i.e. make a lowball send transaction now, then you can add another send later 
and if the previous send transaction is unconfirmed, RBF it with a new 
transaction that has the previous send and the current send) and if so, can you 
open-source the code and show me?


Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

[Jeremy Rubin]

opt-in or explicit tagging of fee account is a bad design IMO.

As pointed out by James O'Beirne in the other email, having an explicit key
required means you have to pre-plan suppose you're building a vault
meant to distribute funds over many years, do you really want a *specific*
precommitted key you have to maintain? What happens to your ability to bump
should it be compromised (which may be more likely if it's intended to be a
hot-wallet function for bumping).

Furthermore, it's quite often the case that someone might do a transaction
that pays you that is low fee that you want to bump but they choose to
opt-out... then what? It's better that you should always be able to fee
bump.


--
@JeremyRubin 


On Sun, Feb 20, 2022 at 6:24 AM ZmnSCPxj  wrote:

> Good morning DA,
>
>
> > Agreed, you cannot rely on a replacement transaction would somehow
> > invalidate a previous version of it, it has been spoken into the gossip
> > and exists there in mempools somewhere if it does, there is no guarantee
> > that anyone has ever heard of the replacement transaction as there is no
> > consensus about either the previous version of the transaction or its
> > replacement until one of them is mined and the block accepted. -DA.
>
> As I understand from the followup from Peter, the point is not "this
> should never happen", rather the point is "this should not happen *more
> often*."
>
> Regards,
> ZmnSCPxj
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

[Jeremy Rubin]

--
@JeremyRubin 


On Sat, Feb 19, 2022 at 1:39 AM Peter Todd  wrote:

> On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote:
> > > As I said, it's a new kind of pinning attack, distinct from other types
> > of pinning attack.
> >
> > I think pinning is "formally defined" as sequences of transactions which
> > prevent or make it less likely for you to make any progress (in terms of
> > units of computation proceeding).
>
> Mentioning "computation" when talking about transactions is misleading:
> blockchain transactions have nothing to do with computation.
>

It is in fact computation. Branding it as "misleading" is misleading... The
relevant literature is https://en.wikipedia.org/wiki/Non-blocking_algorithm,
sponsors helps get rid of deadlocking so that any thread can be guaranteed
to make progress. E.g., this is critical in Eltoo, which is effectively a
coordinated multi-party computation on-chain to compute the highest
sequence number known by any worker.

That transactions are blobs of "verification" (which is also itself a
computation) less so than dynamic computations is irrelevant to the fact
that series of transactions do represent computations.



> > Something that only increases possibility to make progress cannot be
> > pinning.
>
> It is incorrect to say that all use-cases have the property that any
> version of
> a transaction being mined is progress.
>

It is progress, tautologically. Progress is formally definable as a
transaction of any kind getting mined. Pinning prevents progress by an
adversarial worker. Sponsoring enables progress, but it may not be your
preferred interleaving. That's OK, but it's inaccurate to say it is not
progress.

Your understanding of how OpenTimestamps calendars work appears to be
> incorrect. There is no chain of unconfirmed transactions. Rather, OTS
> calendars
> use RBF to _update_ the timestamp tx with a new merkle tip hash for to all
> outstanding per-second commitments once per new block. In high fee
> situations
> it's normal for there to be dozens of versions of that same tx, each with a
> slightly higher feerate.
>

I didn't claim there to be a chain of unconfirmed, I claimed that there
could be single output chain that you're RBF'ing one step per block.

E.g., it could be something like

A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo}}
A_1 -> {A_2 w/ CSV 1 block, OP_RETURN {bar}}

such that A_i provably can't have an unconfirmed descendant. The notion
would be that you're replacing one with another. E.g., if you're updating
the calendar like:


Version 0: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo}}
Version 1: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo, bar}}
Version 2: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo, bar, delta}}

and version 1 gets mined, then in A_1's spend you simply shift delta to
that (next) calendar.

A_1 -> {A_2 w/ CSV 1 block, OP_RETURN {delta}}

Thus my claim that someone sponsoring a old version only can delay by 1
block the calendar commit.





> OTS calendars can handle any of those versions getting mined. But older
> versions getting mined wastes money, as the remaining commitments still
> need to
> get mined in a subsequent transaction. Those remaining commitments are also
> delayed by the time it takes for the next tx to get mined.
>
> There are many use-cases beyond OTS with this issue. For example, some
> entities
> use "in-place" replacement for update low-time-preference settlement
> transactions by adding new txouts and updating existing ones. Older
> versions of
> those settlement transactions getting mined rather than the newer version
> wastes money and delays settlement for the exact same reason it does in
> OTS.
>
>
> > Lastly, if you do get "necromanced" on an earlier RBF'd transaction by a
> > third party for OTS, you should be relatively happy because it cost you
> > less fees overall, since the undoing of your later RBF surely returned
> some
> > satoshis to your wallet.
>
> As I said above, no it doesn't.
>
>
It does save money since you had to pay to RBF, the N+1st txn will be
paying higher fee than the Nth. So if someone else sponsors an earlier
version, then you save whatever feerate/fee bumps you would have paid and
the funds are again in your change output (or something). You can apply
those change output savings to your next batch, which can include any
entries that have been dropped .
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

[Jeremy]

opt-in or explicit tagging of fee account is a bad design IMO.

As pointed out by James O'Beirne in the other email, having an explicit key
required means you have to pre-plan suppose you're building a vault
meant to distribute funds over many years, do you really want a *specific*
precommitted key you have to maintain? What happens to your ability to bump
should it be compromised (which may be more likely if it's intended to be a
hot-wallet function for bumping).

Furthermore, it's quite often the case that someone might do a transaction
that pays you that is low fee that you want to bump but they choose to
opt-out... then what? It's better that you should always be able to fee
bump.
--
@JeremyRubin 



On Sun, Feb 20, 2022 at 6:24 AM ZmnSCPxj  wrote:

> Good morning DA,
>
>
> > Agreed, you cannot rely on a replacement transaction would somehow
> > invalidate a previous version of it, it has been spoken into the gossip
> > and exists there in mempools somewhere if it does, there is no guarantee
> > that anyone has ever heard of the replacement transaction as there is no
> > consensus about either the previous version of the transaction or its
> > replacement until one of them is mined and the block accepted. -DA.
>
> As I understand from the followup from Peter, the point is not "this
> should never happen", rather the point is "this should not happen *more
> often*."
>
> Regards,
> ZmnSCPxj
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

[ZmnSCPxj via Lightning-dev]

Good morning DA,


> Agreed, you cannot rely on a replacement transaction would somehow
> invalidate a previous version of it, it has been spoken into the gossip
> and exists there in mempools somewhere if it does, there is no guarantee
> that anyone has ever heard of the replacement transaction as there is no
> consensus about either the previous version of the transaction or its
> replacement until one of them is mined and the block accepted. -DA.

As I understand from the followup from Peter, the point is not "this should 
never happen", rather the point is "this should not happen *more often*."

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts

[damian]

Agreed, you cannot rely on a replacement transaction would somehow 
invalidate a previous version of it, it has been spoken into the gossip 
and exists there in mempools somewhere if it does, there is no guarantee 
that anyone has ever heard of the replacement transaction as there is no 
consensus about either the previous version of the transaction or its 
replacement until one of them is mined and the block accepted. -DA.


On 2022-02-20 04:20, darosior via bitcoin-dev wrote:
Necromancing might be a reasonable name for attacks that work by 
getting an

out-of-date version of a tx mined.


It's not an "attack"? There is no such thing as an out-of-date 
transaction, if

you signed and broadcasted it in the first place. You can't rely on
the fact that
a replacement transaction would somehow invalidate a previous version 
of it.

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev