Nostr notes by darosior [ARCHIVE]

📅 Original date posted:2022-02-19 📝 Original message: > ...

2023-06-09T13:05:09Z

In reply to nevent1q…gyw0
_________________________

📅 Original date posted:2022-02-19
📝 Original message:
> 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.

------- Original Message -------

Le samedi 19 février 2022 à 10:39 AM, Peter Todd <pete at petertodd.org> a écrit :

> 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.
>
> > 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.
>
> > If you want to call it something else, with a negative connotation, maybe
> >
> > call it "necromancing" (bringing back txns that would otherwise be
> >
> > feerate/fee irrational).
>
> Necromancing might be a reasonable name for attacks that work by getting an
>
> out-of-date version of a tx mined.
>
> > In particular, for the use case you mentioned "Eg a third party could mess
> >
> > up OpenTimestamps calendars at relatively low cost by delaying the mining
> >
> > of timestamp txs.", this is incorrect. A third party can only accelerate
> >
> > the mining on the timestamp transactions, but they can accelerate the
> >
> > mining of any such timestamp transaction. If you have a single output chain
> >
> > that you're RBF'ing per block, then at most they can cause you to shift the
> >
> > calendar commits forward one block. But again, they cannot pin you. If you
> >
> > want to shift it back one block earlier, just offer a higher fee for the
> >
> > later RBF'd calendar. Thus the interference is limited by how much you wish
> >
> > to pay to guarantee your commitment is in this block as opposed to the next.
>
> 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.
>
> 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.
>
> If fee accounts or any similar mechanism get implemented, they absolutely
>
> should be opt-in. Obviously, using a currently non-standard nVersion bit is a
>
> possible approach. Conversely, with CPFP it may be desirable in the settlement
>
> case to be able to prevent outputs from being spent in the same block. Again,
>
> an nVersion bit is a possible approach.
>
> > By the way, you can already do out-of-band transaction fees to a very
> >
> > similar effect, google "BTC transaction accelerator". If the attack were at
> >
> > all valuable to perform, it could happen today.
>
> I just checked: all the BTC transaction accellerator services I could find look
>
> to be either scams, or very expensive. We need compelling reasons to make this
>
> nuisance attack significantly cheaper.
>
> > 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.
>
> ----------------------------------
>
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> Lightning-dev mailing list
>
> Lightning-dev at lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

📅 Original date posted:2020-10-05 📝 Original message: Hi ...

2023-06-09T13:00:59Z

In reply to nevent1q…9lrk
_________________________

📅 Original date posted:2020-10-05
📝 Original message:
Hi Bastien,

> I think that *in some cases*, fundees should be paying a portion of the commit-tx on-chain fees,
> otherwise we may end up with a web-of-trust network where channels would only exist between peers
> that trust each other, which is quite limiting (I'm hoping we can do better).

Agreed.
However in an anchor outputs future the funder only pays for the "backbone" fees of the channel and the fees necessary to secure the confirmation of transactions is paid in second stage by each interested party (*). It seems to me to be a reasonable middle-ground.

(*) Credits to ZmnSCPxj for pointing this out to me on IRC.

Darosior
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201005/1f406e21/attachment.html>;

📅 Original date posted:2020-02-11 📝 Original message: Hi ...

2023-06-09T12:58:42Z

In reply to nevent1q…axeg
_________________________

📅 Original date posted:2020-02-11
📝 Original message:
Hi niftynei and list,

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le mardi, février 11, 2020 12:11 AM, lisa neigut <niftynei at gmail.com> a écrit :

> Here's some thoughts I had on PoDLE's and lightning. An enormous tip-of-the-hat is due to ZmnSCPxj for surfacing the work that JoinMarket has done here already.
>

> - The initiating message (in the case of open channel, this would be `open_channel2`) is extended to include an 'H2' field in its TLV, a 32-byte hash commitment to the P2 key.
> - Only one H2 commitment is required.
> - The `tx_add_input` message, as specified previously, is extended to an include a TLV type. This must be present on the input addition that corresponds with the UTXO used for the originally transmitted commitment
> - The non-initiator SHOULD wait to send any `tx_add_input` messages of their own until after receiving a `tx_add_input` message with a valid PoDLE TLV extension.
>

> 1. tlvs: `add_input_tlvs`
> 2. types:
> 1. type: 1 (`proof_of_dle`)
> 2. data:
> *[`64*byte`:`s||e`]
> *[`33*byte`:pubkey`]
> *[`33*byte`:pubkey2`]
>

> - If the proof is incorrect, the non-initiator MAY fail the transaction collaboration or respond with `tx_complete`. There is no need for them to publish the PoDLE.
> - If the proof is correct, the non-initiator verifies that the commitment (hash of pubkey2) has not been communicated to them via gossip.
> - If the proof is not in their gossip store, the transaction collaboration continues. It is considered 'safe' for the non-initiator to send `tx_add_input` to their peer.
> - If the proof IS in their gossip store, the transaction collaboration SHOULD reply with `tx_complete`. It is considered 'unsafe' for the non-initiator to send `tx_add_input`. (This allows errored/erroring initiators to use blacklisted utxos, however it prevents them from privy to any other nodes' UTXO set.)

We could agree on an acceptable number of reuse in case on a non-malicious failure from the initiator after a valid PoDLE exchange ? (credits ZmnSCPxj)

> - The initiator MUST NOT remove the committed to UTXO from the collaboration set.
>

> - If the transaction collaboration fails/is errored by the initiator,
> - the non-initiator SHOULD broadcast the original PoDLE commitment to the gossip network.
> - the non-initiator MAY delay broadcast to allow the initiating node to re-attempt the open.
>

> The gossip message for a PoDLE blacklist entry is as follows:
>

> 1. type: 259 (`podle_blacklist`)
> 2. data:
> *[`signature`:`signature`]
> *[`32*byte`:`H2`]
> *[`point`:`node_id`]
> *[`u32`:`timestamp`]
>

> Note that the `node_id` is the id of the node that signs (and broadcasts) the blacklisted PoDLE. h/t to ZmnSCPxj for the gossip construction.
> The timestamp is added as a convenience for peers to trim/discard blacklist participants as they wish depending on time/staleness.
>

> ## Some Notes:
> - The JoinMarket protocol allows nodes to use any of a range of secondary points for J. Since the lightning version of this allows blacklisted UTXOs to still open channels, albeit without participation from the peer, it seems unnecessary to allow for more than one valid J point. I'd propose fixing the J the same zero-index point used by JoinMarket. This reduces the number of valid H2's that are available for any given utxo set, while also keeping blacklisted H2's compatible with the blacklist set generated by JoinMarket implementations.
> - The blacklist originates from the 'non-initiating' peer, and does not reveal the offending node's id.
> - Assuming that every node honestly participates in the blacklist, only verified H2's will be submitted to the blacklist
> - A malicious non-initiator can only prevent an honest initiator from using the committed UTXO for collaborative transactions; they won't prevent them from successfully initiating a one-sided transaction with honest peers.
> - Only nodes that have at least one public channel will be able to contribute to the public PoDLE blacklist. This means it's possible for a malicious initiator to grief non-public nodes without much consequence, however this requires the ability to send inbound messages to private nodes, i.e. more likely for a close or splice interaction.
> - As ZmnSCPxj has pointed out elsewhere, a malicious peer could broadcast junk H2's; it is acceptable to rate-limit the number of PoDLE blacklists generated by a peer.peer
> - It is possible for a malicious peer to fail to relay their `H2` entries in the blacklisted gossip set.
> - Duplicate H2 gossip should replace older timestamped versions.
> - Elsewhere we've had a discussion/concern over floods of PoDLE blacklist messages. It's possible for gossip message floods to originate from a malicious peer; they also might signal an ongoing probe attempt. Given a timestamp and a rough measure of the number of utxos' currently outstanding in the mempool, however, it should be possible to distinguish the two.

Ok, so knowing where PoDLE originate from mitigates the flood we talked about with ZmnSCPxj.
However I don't see how the number of utxos in the mempool is useful here, as you cannot distinguish which PoDLE is the real one out of the load you are receiving in case of a flood ?

> ## Open Questions:
> - Should PoDLE be required for every collaborative transaction (opens, splices + closes), or only for opens? It seems reasonable to limit them just to opens, as for all others you'll already have a shared UTXO with the peer.
> - Is fixing the generator point too restrictive? JoinMarket allows for a range of acceptable NUMS (J) points (up to 256). The smaller the pool of eligible J's, the smaller the pool of potential blacklisted PoDLE's (up to no. NUMs * current utxo count). One upside to allowing a larger pool of J's means that the same UTXO can be retried on failure. One downside to allowing a pool of J's means that a single UTXO can be validly retried in a probe attack against a variety of peers.
>

> On Thu, Jan 30, 2020 at 5:32 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>

> > Good morning darosior, ariard, niftynei, and list,
> >

> > > We could also consider PoDLE as used in JoinMarket, which solves a similar problem.
> > > https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8#defence-2-committing-to-a-utxo-in-publicplaintext-at-the-start-of-the-handshake
> > > Basically, a PoDLE commits to a UTXO, without being trivially grindable from the UTXO set and also including a proof that the creator of the PoDLE knows the secret key behind it.
> > > It can later be opened to reveal which UTXO the opener allocated.
> > > If the opener aborts (i.e. does not provide its signatures to the funding transaction) then the acceptor can gossip the UTXO and the revealed PoDLE as well to the rest of Lightning, so that the opener at least cannot reuse the same UTXO to probe other potential acceptors.
> > > (though, my understanding, there is no clear way to determine when we can safely delete old PoDLEs: maybe each node can keep it around for a month, which might be good enough to limit the practical ability of a snoop to probe other nodes)
> > > I believe JoinMarket also has solved the issue of allowing a UTXO to be used at most N times (for example due to "honest" failures, such as connectivity interruptions which might cause an abort of the protocol); I think it involves appending a single byte to something that is hashed, and ensuring its value is less than N, so that it can only be used from 0 to N - 1 (and thus allow a UTXO to be used at most N times).
> > >
> > > Getting into contact with waxwing / Adam Gibson for this might be useful to fill out how PoDLE works and so on; basically, I believe this issue is a practically solved problem already for JoinMarket, though waxwing may be able to provide a more nuanced opinion.
> >

> > I communicated with waxwing, and he said:
> >

> > * See also: https://joinmarket.me/blog/blog/poodle \[sic\].
> > * The counter I mentioned is implemented using the second generator point.
> > * The PoDLE construction requires the standard base point `G`, and another generator point `J`.
> > * To create the generator point `J`, JoinMarket appends the counter byte (the one used to limit N number of uses of the same UTXO) to `G`, hashes it, then uses a coerce-to-point.
> > * PoDLE is sometimes called DLEQ elsewhere.
> > * There is no concrete answer on "when to delete old PoDLE"; JoinMarket never deletes (though they might if throughput increases).
> > * Watermarks like `nLockTime`, `nSequence`, `nVersion` are currently fixed values; JoinMarket sees no reason to change this since equal-valued CoinJoins are otherwise obvious to chain analysis anyway.
> > * But note: JoinMarket implements PayJoin, which is not otherwise obvious onchain, and does indeed do anti-fee-sniping emulation for PayJoin.
> > * JoinMarket also strives to make similar feerates across users.
> >

> > In any case, for myself, my thoughts are:
> >

> > * I observe that our use-case is quite similar to a PayJoin:
> > * The opener proposes to make a payment (to a channel between the opener and the acceptor, rather than outright giving control to the acceptor as in PayJoin).
> > * The acceptor adds some UTXOs which will contribute to the payment output (i.e. the channel).
> > * This probably does mean we want to later consider `nLockTime` anti-fee-sniping as well in multi-funded channel opens.
> > * Speaking of multi-funded channel opens, it seems to me this interactive tx construction mechanism as well can be later used for channel factories.
> > * Similarly, PoDLE techniques would be useful as well to multi-funded channel factories.
> > * It would probably be a good idea to share PoDLE format with JoinMarket so we can share PoDLE with them (there could be bridges that share PoDLE between a JoinMarket maker and a Lightning node, and each network already has its own gossip protocols, so LN just needs a gossip protocol for sharing PoDLEs as well).
> > * Probably we can mandate in some BOLT spec to retain PoDLE for at least a year or a month or two weeks or so, which should be enough to slow down probe attempts.
> >

> > Regards,
> > ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200211/32163fb0/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 477 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200211/32163fb0/attachment-0001.sig>;

📅 Original date posted:2020-02-02 📝 Original message: Hi ...

2023-06-09T12:58:30Z

In reply to nevent1q…rg9s
_________________________

📅 Original date posted:2020-02-02
📝 Original message:
Hi Pavol,

> 1) Is c-lightning going to support Sphinx or other form of spontaneous payments?

I think cdecker is working on integrating keysend to his noise plugin (https://github.com/lightningd/plugins/pull/68).

> 2) Can a lightning node (such as lnd or c-lightning) send a push notification (e.g. to a webhook) when it receives or routes a payment? If yes, is this notification cryptographically signed (for example with the node's private key)? Is this documented somewhere?

C-lightning sends notifications (and hooks, but it doesn't seem to be your usecase here) for typical events such as "I received an HTLC !". You can make a plugin which registers to these lightningd notifications sends encrypted push notifs. Doc here https://lightning.readthedocs.io/PLUGINS.html#event-notifications :-).

Darosior

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le dimanche, février 2, 2020 1:39 PM, Pavol Rusnak via Lightning-dev <lightning-dev at lists.linuxfoundation.org> a écrit :

> Hi all!
>

> I have a couple of unrelated questions, hope you can give me some pointers.
>

> 1) Is c-lightning going to support Sphinx or other form of spontaneous payments?
>

> 2) Can a lightning node (such as lnd or c-lightning) send a push notification (e.g. to a webhook) when it receives or routes a payment? If yes, is this notification cryptographically signed (for example with the node's private key)? Is this documented somewhere?
>

> Thanks!
>

> --
> Best Regards / S pozdravom,
>

> Pavol "stick" Rusnak
> CTO, SatoshiLabs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200202/49a4ac78/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 477 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200202/49a4ac78/attachment.sig>;

📅 Original date posted:2020-01-31 📝 Original message: Hi ...

2023-06-09T12:58:28Z

In reply to nevent1q…x5np
_________________________

📅 Original date posted:2020-01-31
📝 Original message:
Hi ZmnSCPxj,

Using joinmarket's PoDLEs is a great idea, and it seems preferable to using a transaction chain with a distinguishable SIGHASH.

Just a naive question, what is described in https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8#defence-2-committing-to-a-utxo-in-publicplaintext-at-the-start-of-the-handshake and https://joinmarket.me/blog/blog/poodle/ uses Schnorr signature. Can we use this protocol with ECDSA ?

I'm now thinking about how this could be integrated into niftynei's work on the dual-funded channel proposal. The PoDLE broadcast protocol seems to be the bigger part.

*Imagining the size of the monster PR if PoDLEs ever get integrated*
Regards,
Darosior

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le vendredi, janvier 31, 2020 12:31 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :

> Good morning darosior, ariard, niftynei, and list,
>

> > We could also consider PoDLE as used in JoinMarket, which solves a similar problem.
> > https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8#defence-2-committing-to-a-utxo-in-publicplaintext-at-the-start-of-the-handshake
> > Basically, a PoDLE commits to a UTXO, without being trivially grindable from the UTXO set and also including a proof that the creator of the PoDLE knows the secret key behind it.
> > It can later be opened to reveal which UTXO the opener allocated.
> > If the opener aborts (i.e. does not provide its signatures to the funding transaction) then the acceptor can gossip the UTXO and the revealed PoDLE as well to the rest of Lightning, so that the opener at least cannot reuse the same UTXO to probe other potential acceptors.
> > (though, my understanding, there is no clear way to determine when we can safely delete old PoDLEs: maybe each node can keep it around for a month, which might be good enough to limit the practical ability of a snoop to probe other nodes)
> > I believe JoinMarket also has solved the issue of allowing a UTXO to be used at most N times (for example due to "honest" failures, such as connectivity interruptions which might cause an abort of the protocol); I think it involves appending a single byte to something that is hashed, and ensuring its value is less than N, so that it can only be used from 0 to N - 1 (and thus allow a UTXO to be used at most N times).
> > Getting into contact with waxwing / Adam Gibson for this might be useful to fill out how PoDLE works and so on; basically, I believe this issue is a practically solved problem already for JoinMarket, though waxwing may be able to provide a more nuanced opinion.
>

> I communicated with waxwing, and he said:
>

> - See also: https://joinmarket.me/blog/blog/poodle \[sic\].
> - The counter I mentioned is implemented using the second generator point.
> - The PoDLE construction requires the standard base point `G`, and another generator point `J`.
> - To create the generator point `J`, JoinMarket appends the counter byte (the one used to limit N number of uses of the same UTXO) to `G`, hashes it, then uses a coerce-to-point.
> - PoDLE is sometimes called DLEQ elsewhere.
> - There is no concrete answer on "when to delete old PoDLE"; JoinMarket never deletes (though they might if throughput increases).
> - Watermarks like `nLockTime`, `nSequence`, `nVersion` are currently fixed values; JoinMarket sees no reason to change this since equal-valued CoinJoins are otherwise obvious to chain analysis anyway.
> - But note: JoinMarket implements PayJoin, which is not otherwise obvious onchain, and does indeed do anti-fee-sniping emulation for PayJoin.
> - JoinMarket also strives to make similar feerates across users.
>

> In any case, for myself, my thoughts are:
>

> - I observe that our use-case is quite similar to a PayJoin:
> - The opener proposes to make a payment (to a channel between the opener and the acceptor, rather than outright giving control to the acceptor as in PayJoin).
> - The acceptor adds some UTXOs which will contribute to the payment output (i.e. the channel).
> - This probably does mean we want to later consider `nLockTime` anti-fee-sniping as well in multi-funded channel opens.
> - Speaking of multi-funded channel opens, it seems to me this interactive tx construction mechanism as well can be later used for channel factories.
> - Similarly, PoDLE techniques would be useful as well to multi-funded channel factories.
> - It would probably be a good idea to share PoDLE format with JoinMarket so we can share PoDLE with them (there could be bridges that share PoDLE between a JoinMarket maker and a Lightning node, and each network already has its own gossip protocols, so LN just needs a gossip protocol for sharing PoDLEs as well).
> - Probably we can mandate in some BOLT spec to retain PoDLE for at least a year or a month or two weeks or so, which should be enough to slow down probe attempts.
>

> Regards,
> ZmnSCPxj
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 477 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200131/4b9c0503/attachment.sig>;

📅 Original date posted:2020-01-30 📝 Original message: Hi ...

2023-06-09T12:58:26Z

In reply to nevent1q…3kzy
_________________________

📅 Original date posted:2020-01-30
📝 Original message:
Hi Lisa and all,

Given the discussion about utxos snooping, I wondered if there was any obvious drawbacks of using a transaction chain construction ?

Since the obvious target of the probing is the accepter, it seems that the opener needs to at least have something at stake in order to be revealed some of the accepter's utxos.
Thus, the opener giving the accepter a signed transaction commited to the channel opening is one way of avoiding the opener to probe gratuitously. I was thinking of something like:

A is opener, B is accepter.
A could sign the first input (and accordingly the 2of2 output) with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY. Unfortunately this doesn't handle A's change, but it can be solved using a chain of transaction.
A creates a first transaction txA1:

txA1 (SIGHASH_ALL)
_________________ __________________________
| A's input 1 | A's channel participation |
|----------------|---------------------------
| A's input 2 | A's change |
|----------------|---------------------------
| A's input n |
|________________|

And then creates /signs the funding transaction out of the first output of txA1:

txA2 (SIGHASH_SINGLE|SIGHASH_ANYONECANPAY)
_________________ _______________
| txA1 vout 0 | 2of2 with B |
|________________|________________

Since txA2 is signed with SINGLE|ANYONECANPAY, B can add inputs to fulfill the value requirement of the 2of2, and add outputs for its own change.

This comes at the cost of more setup fees opener-side, but avoids the accepter to be gratuitously probed, so this is arguably a far lesser evil.
Is there any other downside I'm missing here ?

Antoine

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le mardi, janvier 28, 2020 2:51 AM, lisa neigut <niftynei at gmail.com> a écrit :

> Some of the feedback I received from the check-in for the dual-funding proposal this past Monday was along the lines that we look at simplifying for breaking it into smaller, more manageable chunks.
>

> The biggest piece of the dual-funding protocol update is definitely the move from a single peer constructing a transaction to two participants. We're also going to likely want to reuse this portion of the protocol for batched closings and splicing. To that extent, it seemed useful to highlight it in a separate email.
>

> This is a change from the existing proposal in the dual-funding PR #524 -- it allows for the removal of inputs and outputs.
>

> The set of messages are as follows.
>

> Note that the 'initiation' of this protocol will be different depending on the case of the transaction (open, close or splice):
>

> 1. type: 440 `tx_add_input`
>

> 2. data:
>

>     * [`32*byte`:`channel_identifier`]
>

>     * [`u64`:`sats`]
>

>     * [`sha256`:`prevtx_txid`]
>

>     * [`u32`:`prevtx_vout`]
>

>     * [`u16`:`prevtx_scriptpubkey_len`]
>

>     * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]
>

>     * [`u16`:`max_witness_len`]
>

>     * [`u16`:`scriptlen`]
>

>     * [`scriptlen*byte`:`script`]
>

>     * [`byte`:`signal_rbf`]
>

> 1. type: 442 `tx_add_output`
>

> 2. data:
>

>     * [`32*byte`:`channel_identifier`]
>

>     * [`u64`:`sats`]
>

>     * [`u16`:`scriptlen`]
>

>     * [`scriptlen*byte`:`script`]
>

> 1. type: 444 `tx_remove_input`
>

> 2. data:
>

>     * [`32*byte`:`channel_identifier`]
>

>     * [`sha256`:`prevtx_txid`]
>

>     * [`u32`:`prevtx_vout`]
>

> 1. type: 446 `tx_remove_output`
>

> 2. data:
>

>     * [`32*byte`:`channel_identifier`]
>

>     * [`u64`:`sats`]
>

>     * [`u16`:`scriptlen`]
>

>     * [`scriptlen*byte`:`script`]
>

> 1. type: 448 `tx_complete`
>

> 2. data:
>

>     * [`32*byte`:`channel_identifier`]
>

>     * [`u16`:`num_inputs`]
>

>     * [`u16`:`num_outputs`]
>

> 1. type: 448 `tx_sigs`
>

> 2. data:
>

>     * [`channel_id`:`channel_identifier`]
>

>     * [`u16`:`num_witnesses`]
>

>     * [`num_witnesses*witness_stack`:`witness_stack`]
>

> 1. subtype: `witness_stack`
>

> 2. data:
>

>     * [`sha256`:`prevtx_txid`]
>

>     * [`u32`:`prevtx_vout`]
>

>     * [`u16`:`num_input_witness`]
>

>     * [`num_input_witness*witness_element`:`witness_element`]
>

> 1. subtype: `witness_element`
>

> 2. data:
>

>     * [`u16`:`len`]
>

>     * [`len*byte`:`witness`]
>

> ## General Notes
>

> - Validity of inputs/outputs is not checked until both peers have sent consecutive `tx_complete`  messages.
>

> - Duplicate inputs or outputs is a protocol error.
>

> - Feerate is set by the initiator, or in the case of a closing transaction, negotiated before the transaction construction is initiated.
>

> - Every peer pays fees for the inputs + outputs they contribute, plus enough to cover the maximum estimate of their witnesses. Overpayment of fees is permissible.
>

> - Initiator is responsible for contributing the output/input in question, i.e. the
>

>   funding output in the case of an opening, or the funding input in the case of a close.
>

>   (This means that the opener will pay for the opening output). In the case of a splice,
>

>   the initiator of the splice pays for the funding tx's inclusion as an input and the
>

>   new 'funding tx' output.
>

> - Any contributor may signal that their input is RBF'able. The nSequence for this input should be set to 0xFEFF FFFF, 0xFFFFFFFF otherwise.
>

> - The initiating peer is understood to be paying the fee for the shared transaction fields (nVersion [4], segwit marker + flag [2], input + output counts [2-18], witness count [1-9], nLocktime [4]; total [13-40bytes])
>

> - Inputs MUST be segwit compatible (PW* or P2SH-PW*)
>

> - All output scripts must be standard
>

> - nLocktime is always set to 0x00000000.
>

> - The `num_inputs` and `num_outputs` in `tx_complete` is a count of that peer’s final input and output contributions, net any removals.
>

> - Either peer may add or remove inputs and outputs until both peers have successfully
>

>   exchanged a `tx_complete` message in succession.
>

> - Either peer may only add or remove their own input or output.
>

> - In the case that a `tx_complete` agreement cannot be reached, either peer may
>

>   fail the channel or open protocol (whatever is reasonable for the particular case)
>

>   - In the case of a splice, this would be a soft error (channel returns to normal operation until
>

>     otherwise failed or closed.)
>

>   - In the case of an open, this would be a failure to open the channel.
>

>   - In the case of a close, a failed collaborative close would result in an error and a unilateral close.
>

> ### Considering the Simple Open case (2 parties)
>

> - Both peers signal `opt_dual_fund`
>

> - Opener initiates a channel open with `open_channel2` message, indicating the feerate for the opening transaction
>

> - Accepter signals acceptance of channel open as proposed, including proposed feerate, via `accept_channel2`
>

> - Opener sends `tx_add_output`, with the funding output for the sum of both peer’s funding_amount
>

> - Opener sends `tx_add_input` for each input the wish to add to the funding transaction
>

> - Opener sends `tx_add_output` for their change
>

> - Opener sends `tx_complete`
>

> - Accepter sends `tx_add_input` for each input they wish to add to the funding transaction
>

> - Accepter sends `tx_add_output` for their change.
>

> - Accepter sends `tx_complete`
>

> - Opener sends `tx_complete`
>

> - Opener and accepter exchange commitment signatures; etc.
>

> ### Considering the Splice case:
>

> - Both peers signal `opt_splice_ok`
>

> - One peer initiates a splice, also signaling the feerate for the transaction. Exact protocol unspecified herein.
>

> - Initiator sends `tx_add_input` with the original funding output
>

> - Initiator sends `tx_add_output` with the new, post-splice funding output
>

> - Initiator sends `tx_add_input/output` as needed to add all desired inputs + outputs
>

> - Initiator sends `tx_complete`
>

> - Peer sends `tx_add_input/output` as needed to add all desired inputs + outputs
>

> - Initiator sends `tx_complete`
>

> - Peer sends `tx_complete`
>

> - Initiator + peer exchange commitment signatures, etc.
>

> ### Considering the Close case:
>

> - Both peers signal `opt_collaborative_close` in their `node_announcement`.
>

> - A peer initiates a close sending a `shutdown`, as per usual.
>

> - A feerate is negotiated. Out of band for this particular portion of the protocol.
>

> -The closing initiator (peer which first sent `shutdown`), sends `tx_add_input` to spend the funding output and `tx_add_output` to add their output for the channel closure.
>

> - The peer responds with `tx_add_output`, adding their output to the close transaction.
>

> - If `option_upfront_shutdown_script` is flagged but no such output with a value at or within a reasonable feerate gap of the peer's funding output is present, then the peer must fail the channel.
>

> ## Updating a collaborative transaction with RBF:
>

> - If any input is flagged as RBF’able, then the transaction is considered eligible for RBF
>

> - RBF can be initiated by either party, and serves as an initiation for another round of transaction composition, as outlined above.
>

> - Note that this section has been cribbed and re-purposed from the original RBF proposal for splicing, see https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001621.html
>

> 1. type: 45 (`init_rbf`) (`option_collaborative_rbf`)
>

> 2. data:
>

>    * [`32`:`channel_id`]
>

>    * [`4`:`fee_step`]
>

> Each `fee_step` adds 1/4 (rounded down) to the initial
>

> transaction feerate. eg. if the initial feerate was 512 satoshis per kiloweight, `fee_step` 1
>

> is 512 + 512 / 4 = 640, `fee_step` 2 is 640 + 640 / 4 = 800.
>

> The sender:
>

>   - MUST set `fee_step` greater than zero and greater than any prior `fee_step`.
>

> The recipient:
>

>   - if the new fee exceeds the sender's current balance minus reserve
>

>     after it is applied to the splice transaction:
>

>     - MUST error.
>

> NOTES:
>

> 1. 1/4 is a reasonable minimal RBF, but as each one requires more
>

>    tracking by the recipient, serves to limit the number you can create.
>

> 2. Rule 4 of BIP125 requires a feerate increase to at least surpass the minimum transaction relay setting. Ratcheting by 25% should satisfy this requirement
>

> 3. An additional rule will be added to the checks of an RBF transaction that it must include at least one identical, replaceable input as the original transaction.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200130/d137558a/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 477 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200130/d137558a/attachment-0001.sig>;

📅 Original date posted:2020-01-30 📝 Original message: > ...

2023-06-09T12:58:24Z

In reply to nevent1q…57sg
_________________________

📅 Original date posted:2020-01-30
📝 Original message:
> Yes that's the reason I wrote the initiator can just announce its own and receiver use it to sign the funding tx, even if receiver tip is backward. Funding tx won't propagate from receiver mempool but that's fine if it does from the initiator one.

Ah, then we are back to my first response where niftynei proposed to accord on setting it to tip-6 so that reorg is not a problem (or if it is, there are bigger).
\-------- Original Message --------
On Jan 30, 2020, 19:45, Antoine Riard < antoine.riard at gmail.com> wrote:

>
>
>
> > The funding transaction sig would actually fail verification if tip differs between funder and fundee
>
>
>
> Yes that's the reason I wrote the initiator can just
>
>
> announce its own and receiver use it to sign the funding tx,
>
>
> even if receiver tip is backward. Funding tx won't propagate
>
>
> from receiver mempool but that's fine if it does from the initiator
>
> one.
>
>
>
> Or are you talking about the commitment tx (different issue and there is
>
>
> broader privacy leaks there) ?
>
> > Darosior ( i'll stick with my pseudo, first names definitely don't have enough entropy :-) )
>
>
>
> Ahaha yeah this pseudo-random-name-generator is definitely not trustworthy :p
>
>
>
>
>
>
>
>
> Le jeu. 30 janv. 2020 à 13:19, darosior <[darosior at protonmail.com][darosior_protonmail.com]> a écrit :
>
>
> > Sorry I wasn't clear enough in the \`(cdecker)\` paragraph.
> >
> >
> >
> >
> >
> >
> >
> > The funding transaction sig would actually fail verification if tip differs between funder and fundee.
> >
> >
> >
> >
> >
> >
> >
> > Darosior ( i'll stick with my pseudo, first names definitely don't have enough entropy :-) )
> > \-------- Original Message --------
> > On Jan 30, 2020, 19:09, Antoine Riard < [antoine.riard at gmail.com][antoine.riard_gmail.com]> wrote:
> >
> > >
> > >
> > >
> > > Hey Darosior,
> > >
> > >
> > >
> > > You don't need a strict synchronization between both peers,
> > >
> > >
> > > just let nLocktime picked up by initiator and announce it at
> > >
> > >
> > > same time than feerate or at \`tx\_complete\`. Worst-case,
> > >
> > >
> > > a slow-block-processing receiver may not be able to get
> > >
> > >
> > > the transaction accepted by its local mempool, but IMO that's
> > > fine if at least the initiator is able to do so. We are requiring peers
> > >
> > >
> > > to be weakly in sync before operating channel anyway (\`funding\_locked\`
> > >
> > >
> > > exchange).
> > >
> > >
> > >
> > >
> > >
> > > Funding\_tx can already be drop from mempool for others
> > >
> > >
> > > reasons like mempool shrinks or expiry so broadcaster
> > >
> > >
> > > should always be ready to re-send it or bump feerate.
> > >
> > >
> > >
> > > Or are you describing another issue ?
> > >
> > >
> > >
> > >
> > >
> > > Le jeu. 30 janv. 2020 à 04:06, darosior <[darosior at protonmail.com][darosior_protonmail.com]> a écrit :
> > >
> > >
> > > > Hi Antoine and all,
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > About nLockTime fun thing is Lisa, Cdecker and I had this conversation to integrate it to C-lightning just yesterday.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Unfortunately you need to add a "My tip is xxxx" to the openchannel msg, otherwise if you set nLockTime to tip. (cdecker)
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Moreover in case of reorg the funding tx (now non-final) would be dropped from mempool ? But you could set nLockTime to, say, tip - 6. (niftynei)
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Antoine
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > \-------- Original Message --------
> > > > On Jan 30, 2020, 01:21, Antoine Riard < [antoine.riard at gmail.com][antoine.riard_gmail.com]> wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > > Hey thanks for this proposal!
> > > > >
> > > > >
> > > > >
> > > > > 2 high-level questions:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > What about multi-party tx construction ? By multi-party, let's define
> > > > >
> > > > > Alice initiate a tx construction to Bob and then Bob announce a
> > > > >
> > > > >
> > > > > construction to Caroll and "bridge" all inputs/outputs additions/substractions
> > > > >
> > > > >
> > > > > in both directions. I think the current proposal hold, if you are a bit more
> > > > >
> > > > >
> > > > > tolerant and bridge peer don't send a tx\_complete before receiving ones
> > > > >
> > > > >
> > > > > from all its peers.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > What about transactions format ? I think we should coordinate with Coinjoin
> > > > >
> > > > >
> > > > > people to converge to a common one to avoid leaking protocol usage when
> > > > > we can hinder under Taproot. Like setting the nLocktime or sorting inputs
> > > > >
> > > > >
> > > > > in some protocol-specific fashion. Ideally we should have a BIP for format
> > > > >
> > > > >
> > > > > but every layer 2 protocols its own set of messages concerning the construction.
> > > > >
> > > > > > nLocktime is always set to 0x000000
> > > > > Maybe we can implement anti-fee sniping and mask among wallet core
> > > > > txn set: [https://github.com/bitcoin/bitcoin/blob/aabec94541e23a67a9f30dc2c80dab3383a01737/src/wallet/wallet.cpp\#L2519][https_github.com_bitcoin_bitcoin_blob_aabec94541e23a67a9f30dc2c80dab3383a01737_src_wallet_wallet.cpp_L2519] ?
> > > > >
> > > > > > In the case of a close, a failed collaborative close would result in an error and a uninlateral close"
> > > > > Or can we do first a mutual closing tx, hold tx broadcast for a bit if "opt\_dual\_fund"
> > > > > is signaled to see if a tx\_construction + add\_funding\_input for the channel is received
> > > > > soon ? At least that would be a dual opt-in to know than one party can submit a funding-outpoint
> > > > > as part of a composed tx ?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Antoine
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Le lun. 27 janv. 2020 à 20:51, lisa neigut <[niftynei at gmail.com][niftynei_gmail.com]> a écrit :
> > > > >
> > > > >
> > > > > > Some of the feedback I received from the check-in for the dual-funding proposal this past Monday was along the lines that we look at simplifying for breaking it into smaller, more manageable chunks.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > The biggest piece of the dual-funding protocol update is definitely the move from a single peer constructing a transaction to two participants. We're also going to likely want to reuse this portion of the protocol for batched closings and splicing. To that extent, it seemed useful to highlight it in a separate email.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > This is a change from the existing proposal in the dual-funding [PR \#524][PR _524] \-- it allows for the removal of inputs and outputs.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > The set of messages are as follows.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Note that the 'initiation' of this protocol will be different depending on the case of the transaction (open, close or splice):
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 1. type: 440 \`tx\_add\_input\`
> > > > > >
> > > > > > 2. data:
> > > > > >
> > > > > >     \* \[\`32\*byte\`:\`channel\_identifier\`\]
> > > > > >
> > > > > >     \* \[\`u64\`:\`sats\`\]
> > > > > >
> > > > > >     \* \[\`sha256\`:\`prevtx\_txid\`\]
> > > > > >
> > > > > >     \* \[\`u32\`:\`prevtx\_vout\`\]
> > > > > >
> > > > > >     \* \[\`u16\`:\`prevtx\_scriptpubkey\_len\`\]
> > > > > >
> > > > > >     \* \[\`prevtx\_scriptpubkey\_len\*byte\`:\`prevtx\_scriptpubkey\`\]
> > > > > >
> > > > > >     \* \[\`u16\`:\`max\_witness\_len\`\]
> > > > > >
> > > > > >     \* \[\`u16\`:\`scriptlen\`\]
> > > > > >
> > > > > >     \* \[\`scriptlen\*byte\`:\`script\`\]
> > > > > >
> > > > > >     \* \[\`byte\`:\`signal\_rbf\`\]
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 1. type: 442 \`tx\_add\_output\`
> > > > > >
> > > > > > 2. data:
> > > > > >
> > > > > >     \* \[\`32\*byte\`:\`channel\_identifier\`\]
> > > > > >
> > > > > >     \* \[\`u64\`:\`sats\`\]
> > > > > >
> > > > > >     \* \[\`u16\`:\`scriptlen\`\]
> > > > > >
> > > > > >     \* \[\`scriptlen\*byte\`:\`script\`\]
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 1. type: 444 \`tx\_remove\_input\`
> > > > > >
> > > > > > 2. data:
> > > > > >
> > > > > >     \* \[\`32\*byte\`:\`channel\_identifier\`\]
> > > > > >
> > > > > >     \* \[\`sha256\`:\`prevtx\_txid\`\]
> > > > > >
> > > > > >     \* \[\`u32\`:\`prevtx\_vout\`\]
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 1. type: 446 \`tx\_remove\_output\`
> > > > > >
> > > > > > 2. data:
> > > > > >
> > > > > >     \* \[\`32\*byte\`:\`channel\_identifier\`\]
> > > > > >
> > > > > >     \* \[\`u64\`:\`sats\`\]
> > > > > >
> > > > > >     \* \[\`u16\`:\`scriptlen\`\]
> > > > > >
> > > > > >     \* \[\`scriptlen\*byte\`:\`script\`\]
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 1. type: 448 \`tx\_complete\`
> > > > > >
> > > > > > 2. data:
> > > > > >
> > > > > >     \* \[\`32\*byte\`:\`channel\_identifier\`\]
> > > > > >
> > > > > >     \* \[\`u16\`:\`num\_inputs\`\]
> > > > > >
> > > > > >     \* \[\`u16\`:\`num\_outputs\`\]
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 1. type: 448 \`tx\_sigs\`
> > > > > >
> > > > > > 2. data:
> > > > > >
> > > > > >     \* \[\`channel\_id\`:\`channel\_identifier\`\]
> > > > > >
> > > > > >     \* \[\`u16\`:\`num\_witnesses\`\]
> > > > > >
> > > > > >     \* \[\`num\_witnesses\*witness\_stack\`:\`witness\_stack\`\]
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 1. subtype: \`witness\_stack\`
> > > > > >
> > > > > > 2. data:
> > > > > >
> > > > > >     \* \[\`sha256\`:\`prevtx\_txid\`\]
> > > > > >
> > > > > >     \* \[\`u32\`:\`prevtx\_vout\`\]
> > > > > >
> > > > > >     \* \[\`u16\`:\`num\_input\_witness\`\]
> > > > > >
> > > > > >     \* \[\`num\_input\_witness\*witness\_element\`:\`witness\_element\`\]
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 1. subtype: \`witness\_element\`
> > > > > >
> > > > > > 2. data:
> > > > > >
> > > > > >     \* \[\`u16\`:\`len\`\]
> > > > > >
> > > > > >     \* \[\`len\*byte\`:\`witness\`\]
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > \#\# General Notes
> > > > > >
> > > > > > \- Validity of inputs/outputs is not checked until both peers have sent consecutive \`tx\_complete\`  messages.
> > > > > >
> > > > > > \- Duplicate inputs or outputs is a protocol error.
> > > > > >
> > > > > > \- Feerate is set by the initiator, or in the case of a closing transaction, negotiated before the transaction construction is initiated.
> > > > > >
> > > > > > \- Every peer pays fees for the inputs + outputs they contribute, plus enough to cover the maximum estimate of their witnesses. Overpayment of fees is permissible.
> > > > > >
> > > > > > \- Initiator is responsible for contributing the output/input in question, i.e. the
> > > > > >
> > > > > >   funding output in the case of an opening, or the funding input in the case of a close.
> > > > > >
> > > > > >   (This means that the opener will pay for the opening output). In the case of a splice,
> > > > > >
> > > > > >   the initiator of the splice pays for the funding tx's inclusion as an input and the
> > > > > >
> > > > > >   new 'funding tx' output.
> > > > > >
> > > > > > \- Any contributor may signal that their input is RBF'able. The nSequence for this input should be set to 0xFEFF FFFF, 0xFFFFFFFF otherwise.
> > > > > >
> > > > > > \- The initiating peer is understood to be paying the fee for the shared transaction fields (nVersion \[4\], segwit marker + flag \[2\], input + output counts \[2-18\], witness count \[1-9\], nLocktime \[4\]; total \[13-40bytes\])
> > > > > >
> > > > > > \- Inputs MUST be segwit compatible (PW\* or P2SH-PW\*)
> > > > > >
> > > > > > \- All output scripts must be standard
> > > > > >
> > > > > > \- nLocktime is always set to 0x00000000.
> > > > > >
> > > > > > \- The \`num\_inputs\` and \`num\_outputs\` in \`tx\_complete\` is a count of that peer’s final input and output contributions, net any removals.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > \- Either peer may add or remove inputs and outputs until both peers have successfully
> > > > > >
> > > > > >   exchanged a \`tx\_complete\` message in succession.
> > > > > >
> > > > > > \- Either peer may only add or remove their own input or output.
> > > > > >
> > > > > > \- In the case that a \`tx\_complete\` agreement cannot be reached, either peer may
> > > > > >
> > > > > >   fail the channel or open protocol (whatever is reasonable for the particular case)
> > > > > >
> > > > > >   - In the case of a splice, this would be a soft error (channel returns to normal operation until
> > > > > >
> > > > > >     otherwise failed or closed.)
> > > > > >
> > > > > >   - In the case of an open, this would be a failure to open the channel.
> > > > > >
> > > > > >   - In the case of a close, a failed collaborative close would result in an error and a unilateral close.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > \#\#\# Considering the Simple Open case (2 parties)
> > > > > >
> > > > > > \- Both peers signal \`opt\_dual\_fund\`
> > > > > >
> > > > > > \- Opener initiates a channel open with \`open\_channel2\` message, indicating the feerate for the opening transaction
> > > > > >
> > > > > > \- Accepter signals acceptance of channel open as proposed, including proposed feerate, via \`accept\_channel2\`
> > > > > >
> > > > > > \- Opener sends \`tx\_add\_output\`, with the funding output for the sum of both peer’s funding\_amount
> > > > > >
> > > > > > \- Opener sends \`tx\_add\_input\` for each input the wish to add to the funding transaction
> > > > > >
> > > > > > \- Opener sends \`tx\_add\_output\` for their change
> > > > > >
> > > > > > \- Opener sends \`tx\_complete\`
> > > > > >
> > > > > > \- Accepter sends \`tx\_add\_input\` for each input they wish to add to the funding transaction
> > > > > >
> > > > > > \- Accepter sends \`tx\_add\_output\` for their change.
> > > > > >
> > > > > > \- Accepter sends \`tx\_complete\`
> > > > > >
> > > > > > \- Opener sends \`tx\_complete\`
> > > > > >
> > > > > > \- Opener and accepter exchange commitment signatures; etc.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > \#\#\# Considering the Splice case:
> > > > > >
> > > > > > \- Both peers signal \`opt\_splice\_ok\`
> > > > > >
> > > > > > \- One peer initiates a splice, also signaling the feerate for the transaction. Exact protocol unspecified herein.
> > > > > >
> > > > > > \- Initiator sends \`tx\_add\_input\` with the original funding output
> > > > > >
> > > > > > \- Initiator sends \`tx\_add\_output\` with the new, post-splice funding output
> > > > > >
> > > > > > \- Initiator sends \`tx\_add\_input/output\` as needed to add all desired inputs + outputs
> > > > > >
> > > > > > \- Initiator sends \`tx\_complete\`
> > > > > >
> > > > > > \- Peer sends \`tx\_add\_input/output\` as needed to add all desired inputs + outputs
> > > > > >
> > > > > > \- Initiator sends \`tx\_complete\`
> > > > > >
> > > > > > \- Peer sends \`tx\_complete\`
> > > > > >
> > > > > > \- Initiator + peer exchange commitment signatures, etc.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > \#\#\# Considering the Close case:
> > > > > >
> > > > > > \- Both peers signal \`opt\_collaborative\_close\` in their \`node\_announcement\`.
> > > > > >
> > > > > > \- A peer initiates a close sending a \`shutdown\`, as per usual.
> > > > > >
> > > > > > \- A feerate is negotiated. Out of band for this particular portion of the protocol.
> > > > > >
> > > > > > \-The closing initiator (peer which first sent \`shutdown\`), sends \`tx\_add\_input\` to spend the funding output and \`tx\_add\_output\` to add their output for the channel closure.
> > > > > >
> > > > > > \- The peer responds with \`tx\_add\_output\`, adding their output to the close transaction.
> > > > > >
> > > > > > \- If \`option\_upfront\_shutdown\_script\` is flagged but no such output with a value at or within a reasonable feerate gap of the peer's funding output is present, then the peer must fail the channel.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > \#\# Updating a collaborative transaction with RBF:
> > > > > >
> > > > > > \- If any input is flagged as RBF’able, then the transaction is considered eligible for RBF
> > > > > >
> > > > > > \- RBF can be initiated by either party, and serves as an initiation for another round of transaction composition, as outlined above.
> > > > > >
> > > > > > \- Note that this section has been cribbed and re-purposed from the original RBF proposal for splicing, see https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001621.html
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 1. type: 45 (\`init\_rbf\`) (\`option\_collaborative\_rbf\`)
> > > > > >
> > > > > > 2. data:
> > > > > >
> > > > > >    \* \[\`32\`:\`channel\_id\`\]
> > > > > >
> > > > > >    \* \[\`4\`:\`fee\_step\`\]
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Each \`fee\_step\` adds 1/4 (rounded down) to the initial
> > > > > >
> > > > > > transaction feerate. eg. if the initial feerate was 512 satoshis per kiloweight, \`fee\_step\` 1
> > > > > >
> > > > > > is 512 + 512 / 4 = 640, \`fee\_step\` 2 is 640 + 640 / 4 = 800.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > The sender:
> > > > > >
> > > > > >   - MUST set \`fee\_step\` greater than zero and greater than any prior \`fee\_step\`.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > The recipient:
> > > > > >
> > > > > >   - if the new fee exceeds the sender's current balance minus reserve
> > > > > >
> > > > > >     after it is applied to the splice transaction:
> > > > > >
> > > > > >     - MUST error.
> > > > > >
> > > > > >
> > > > > >
> > > > > > NOTES:
> > > > > >
> > > > > > 1. 1/4 is a reasonable minimal RBF, but as each one requires more
> > > > > >
> > > > > >    tracking by the recipient, serves to limit the number you can create.
> > > > > >
> > > > > > 2. Rule 4 of BIP125 requires a feerate increase to at least surpass the minimum transaction relay setting. Ratcheting by 25% should satisfy this requirement
> > > > > >
> > > > > > 3. An additional rule will be added to the checks of an RBF transaction that it must include at least one identical, replaceable input as the original transaction.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
> > > > > > Lightning-dev mailing list
> > > > > > [Lightning-dev at lists.linuxfoundation.org][Lightning-dev_lists.linuxfoundation.org]
> > > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> > > > > >

[darosior_protonmail.com]: mailto:darosior at protonmail.com
[antoine.riard_gmail.com]: mailto:antoine.riard at gmail.com
[https_github.com_bitcoin_bitcoin_blob_aabec94541e23a67a9f30dc2c80dab3383a01737_src_wallet_wallet.cpp_L2519]: https://github.com/bitcoin/bitcoin/blob/aabec94541e23a67a9f30dc2c80dab3383a01737/src/wallet/wallet.cpp#L2519
[niftynei_gmail.com]: mailto:niftynei at gmail.com
[PR _524]: https://github.com/lightningnetwork/lightning-rfc/pull/524
[Lightning-dev_lists.linuxfoundation.org]: mailto:Lightning-dev at lists.linuxfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200130/3aac971c/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200130/3aac971c/attachment-0001.sig>;

📅 Original date posted:2020-01-30 📝 Original message: Sorry ...

2023-06-09T12:58:22Z

In reply to nevent1q…h6ua
_________________________

📅 Original date posted:2020-01-30
📝 Original message:
Sorry I wasn't clear enough in the \`(cdecker)\` paragraph.

The funding transaction sig would actually fail verification if tip differs between funder and fundee.

Darosior ( i'll stick with my pseudo, first names definitely don't have enough entropy :-) )
\-------- Original Message --------
On Jan 30, 2020, 19:09, Antoine Riard < antoine.riard at gmail.com> wrote:

>
>
>
> Hey Darosior,
>
>
>
> You don't need a strict synchronization between both peers,
>
>
> just let nLocktime picked up by initiator and announce it at
>
>
> same time than feerate or at \`tx\_complete\`. Worst-case,
>
>
> a slow-block-processing receiver may not be able to get
>
>
> the transaction accepted by its local mempool, but IMO that's
> fine if at least the initiator is able to do so. We are requiring peers
>
>
> to be weakly in sync before operating channel anyway (\`funding\_locked\`
>
>
> exchange).
>
>
>
>
>
> Funding\_tx can already be drop from mempool for others
>
>
> reasons like mempool shrinks or expiry so broadcaster
>
>
> should always be ready to re-send it or bump feerate.
>
>
>
> Or are you describing another issue ?
>
>
>
>
>
> Le jeu. 30 janv. 2020 à 04:06, darosior <[darosior at protonmail.com][darosior_protonmail.com]> a écrit :
>
>
> > Hi Antoine and all,
> >
> >
> >
> >
> >
> >
> >
> > About nLockTime fun thing is Lisa, Cdecker and I had this conversation to integrate it to C-lightning just yesterday.
> >
> >
> >
> >
> >
> >
> >
> > Unfortunately you need to add a "My tip is xxxx" to the openchannel msg, otherwise if you set nLockTime to tip. (cdecker)
> >
> >
> >
> >
> >
> >
> >
> > Moreover in case of reorg the funding tx (now non-final) would be dropped from mempool ? But you could set nLockTime to, say, tip - 6. (niftynei)
> >
> >
> >
> >
> >
> >
> >
> > Antoine
> >
> >
> >
> >
> >
> > \-------- Original Message --------
> > On Jan 30, 2020, 01:21, Antoine Riard < [antoine.riard at gmail.com][antoine.riard_gmail.com]> wrote:
> >
> > >
> > >
> > >
> > > Hey thanks for this proposal!
> > >
> > >
> > >
> > > 2 high-level questions:
> > >
> > >
> > >
> > >
> > >
> > > What about multi-party tx construction ? By multi-party, let's define
> > >
> > > Alice initiate a tx construction to Bob and then Bob announce a
> > >
> > >
> > > construction to Caroll and "bridge" all inputs/outputs additions/substractions
> > >
> > >
> > > in both directions. I think the current proposal hold, if you are a bit more
> > >
> > >
> > > tolerant and bridge peer don't send a tx\_complete before receiving ones
> > >
> > >
> > > from all its peers.
> > >
> > >
> > >
> > >
> > >
> > > What about transactions format ? I think we should coordinate with Coinjoin
> > >
> > >
> > > people to converge to a common one to avoid leaking protocol usage when
> > > we can hinder under Taproot. Like setting the nLocktime or sorting inputs
> > >
> > >
> > > in some protocol-specific fashion. Ideally we should have a BIP for format
> > >
> > >
> > > but every layer 2 protocols its own set of messages concerning the construction.
> > >
> > > > nLocktime is always set to 0x000000
> > > Maybe we can implement anti-fee sniping and mask among wallet core
> > > txn set: [https://github.com/bitcoin/bitcoin/blob/aabec94541e23a67a9f30dc2c80dab3383a01737/src/wallet/wallet.cpp\#L2519][https_github.com_bitcoin_bitcoin_blob_aabec94541e23a67a9f30dc2c80dab3383a01737_src_wallet_wallet.cpp_L2519] ?
> > >
> > > > In the case of a close, a failed collaborative close would result in an error and a uninlateral close"
> > > Or can we do first a mutual closing tx, hold tx broadcast for a bit if "opt\_dual\_fund"
> > > is signaled to see if a tx\_construction + add\_funding\_input for the channel is received
> > > soon ? At least that would be a dual opt-in to know than one party can submit a funding-outpoint
> > > as part of a composed tx ?
> > >
> > >
> > >
> > >
> > > Antoine
> > >
> > >
> > >
> > >
> > >
> > > Le lun. 27 janv. 2020 à 20:51, lisa neigut <[niftynei at gmail.com][niftynei_gmail.com]> a écrit :
> > >
> > >
> > > > Some of the feedback I received from the check-in for the dual-funding proposal this past Monday was along the lines that we look at simplifying for breaking it into smaller, more manageable chunks.
> > > >
> > > >
> > > >
> > > >
> > > > The biggest piece of the dual-funding protocol update is definitely the move from a single peer constructing a transaction to two participants. We're also going to likely want to reuse this portion of the protocol for batched closings and splicing. To that extent, it seemed useful to highlight it in a separate email.
> > > >
> > > >
> > > >
> > > >
> > > > This is a change from the existing proposal in the dual-funding [PR \#524][PR _524] \-- it allows for the removal of inputs and outputs.
> > > >
> > > >
> > > >
> > > >
> > > > The set of messages are as follows.
> > > >
> > > >
> > > >
> > > >
> > > > Note that the 'initiation' of this protocol will be different depending on the case of the transaction (open, close or splice):
> > > >
> > > >
> > > >
> > > >
> > > > 1. type: 440 \`tx\_add\_input\`
> > > >
> > > > 2. data:
> > > >
> > > >     \* \[\`32\*byte\`:\`channel\_identifier\`\]
> > > >
> > > >     \* \[\`u64\`:\`sats\`\]
> > > >
> > > >     \* \[\`sha256\`:\`prevtx\_txid\`\]
> > > >
> > > >     \* \[\`u32\`:\`prevtx\_vout\`\]
> > > >
> > > >     \* \[\`u16\`:\`prevtx\_scriptpubkey\_len\`\]
> > > >
> > > >     \* \[\`prevtx\_scriptpubkey\_len\*byte\`:\`prevtx\_scriptpubkey\`\]
> > > >
> > > >     \* \[\`u16\`:\`max\_witness\_len\`\]
> > > >
> > > >     \* \[\`u16\`:\`scriptlen\`\]
> > > >
> > > >     \* \[\`scriptlen\*byte\`:\`script\`\]
> > > >
> > > >     \* \[\`byte\`:\`signal\_rbf\`\]
> > > >
> > > >
> > > >
> > > >
> > > > 1. type: 442 \`tx\_add\_output\`
> > > >
> > > > 2. data:
> > > >
> > > >     \* \[\`32\*byte\`:\`channel\_identifier\`\]
> > > >
> > > >     \* \[\`u64\`:\`sats\`\]
> > > >
> > > >     \* \[\`u16\`:\`scriptlen\`\]
> > > >
> > > >     \* \[\`scriptlen\*byte\`:\`script\`\]
> > > >
> > > >
> > > >
> > > >
> > > > 1. type: 444 \`tx\_remove\_input\`
> > > >
> > > > 2. data:
> > > >
> > > >     \* \[\`32\*byte\`:\`channel\_identifier\`\]
> > > >
> > > >     \* \[\`sha256\`:\`prevtx\_txid\`\]
> > > >
> > > >     \* \[\`u32\`:\`prevtx\_vout\`\]
> > > >
> > > >
> > > >
> > > >
> > > > 1. type: 446 \`tx\_remove\_output\`
> > > >
> > > > 2. data:
> > > >
> > > >     \* \[\`32\*byte\`:\`channel\_identifier\`\]
> > > >
> > > >     \* \[\`u64\`:\`sats\`\]
> > > >
> > > >     \* \[\`u16\`:\`scriptlen\`\]
> > > >
> > > >     \* \[\`scriptlen\*byte\`:\`script\`\]
> > > >
> > > >
> > > >
> > > >
> > > > 1. type: 448 \`tx\_complete\`
> > > >
> > > > 2. data:
> > > >
> > > >     \* \[\`32\*byte\`:\`channel\_identifier\`\]
> > > >
> > > >     \* \[\`u16\`:\`num\_inputs\`\]
> > > >
> > > >     \* \[\`u16\`:\`num\_outputs\`\]
> > > >
> > > >
> > > >
> > > >
> > > > 1. type: 448 \`tx\_sigs\`
> > > >
> > > > 2. data:
> > > >
> > > >     \* \[\`channel\_id\`:\`channel\_identifier\`\]
> > > >
> > > >     \* \[\`u16\`:\`num\_witnesses\`\]
> > > >
> > > >     \* \[\`num\_witnesses\*witness\_stack\`:\`witness\_stack\`\]
> > > >
> > > >
> > > >
> > > >
> > > > 1. subtype: \`witness\_stack\`
> > > >
> > > > 2. data:
> > > >
> > > >     \* \[\`sha256\`:\`prevtx\_txid\`\]
> > > >
> > > >     \* \[\`u32\`:\`prevtx\_vout\`\]
> > > >
> > > >     \* \[\`u16\`:\`num\_input\_witness\`\]
> > > >
> > > >     \* \[\`num\_input\_witness\*witness\_element\`:\`witness\_element\`\]
> > > >
> > > >
> > > >
> > > >
> > > > 1. subtype: \`witness\_element\`
> > > >
> > > > 2. data:
> > > >
> > > >     \* \[\`u16\`:\`len\`\]
> > > >
> > > >     \* \[\`len\*byte\`:\`witness\`\]
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > \#\# General Notes
> > > >
> > > > \- Validity of inputs/outputs is not checked until both peers have sent consecutive \`tx\_complete\`  messages.
> > > >
> > > > \- Duplicate inputs or outputs is a protocol error.
> > > >
> > > > \- Feerate is set by the initiator, or in the case of a closing transaction, negotiated before the transaction construction is initiated.
> > > >
> > > > \- Every peer pays fees for the inputs + outputs they contribute, plus enough to cover the maximum estimate of their witnesses. Overpayment of fees is permissible.
> > > >
> > > > \- Initiator is responsible for contributing the output/input in question, i.e. the
> > > >
> > > >   funding output in the case of an opening, or the funding input in the case of a close.
> > > >
> > > >   (This means that the opener will pay for the opening output). In the case of a splice,
> > > >
> > > >   the initiator of the splice pays for the funding tx's inclusion as an input and the
> > > >
> > > >   new 'funding tx' output.
> > > >
> > > > \- Any contributor may signal that their input is RBF'able. The nSequence for this input should be set to 0xFEFF FFFF, 0xFFFFFFFF otherwise.
> > > >
> > > > \- The initiating peer is understood to be paying the fee for the shared transaction fields (nVersion \[4\], segwit marker + flag \[2\], input + output counts \[2-18\], witness count \[1-9\], nLocktime \[4\]; total \[13-40bytes\])
> > > >
> > > > \- Inputs MUST be segwit compatible (PW\* or P2SH-PW\*)
> > > >
> > > > \- All output scripts must be standard
> > > >
> > > > \- nLocktime is always set to 0x00000000.
> > > >
> > > > \- The \`num\_inputs\` and \`num\_outputs\` in \`tx\_complete\` is a count of that peer’s final input and output contributions, net any removals.
> > > >
> > > >
> > > >
> > > >
> > > > \- Either peer may add or remove inputs and outputs until both peers have successfully
> > > >
> > > >   exchanged a \`tx\_complete\` message in succession.
> > > >
> > > > \- Either peer may only add or remove their own input or output.
> > > >
> > > > \- In the case that a \`tx\_complete\` agreement cannot be reached, either peer may
> > > >
> > > >   fail the channel or open protocol (whatever is reasonable for the particular case)
> > > >
> > > >   - In the case of a splice, this would be a soft error (channel returns to normal operation until
> > > >
> > > >     otherwise failed or closed.)
> > > >
> > > >   - In the case of an open, this would be a failure to open the channel.
> > > >
> > > >   - In the case of a close, a failed collaborative close would result in an error and a unilateral close.
> > > >
> > > >
> > > >
> > > >
> > > > \#\#\# Considering the Simple Open case (2 parties)
> > > >
> > > > \- Both peers signal \`opt\_dual\_fund\`
> > > >
> > > > \- Opener initiates a channel open with \`open\_channel2\` message, indicating the feerate for the opening transaction
> > > >
> > > > \- Accepter signals acceptance of channel open as proposed, including proposed feerate, via \`accept\_channel2\`
> > > >
> > > > \- Opener sends \`tx\_add\_output\`, with the funding output for the sum of both peer’s funding\_amount
> > > >
> > > > \- Opener sends \`tx\_add\_input\` for each input the wish to add to the funding transaction
> > > >
> > > > \- Opener sends \`tx\_add\_output\` for their change
> > > >
> > > > \- Opener sends \`tx\_complete\`
> > > >
> > > > \- Accepter sends \`tx\_add\_input\` for each input they wish to add to the funding transaction
> > > >
> > > > \- Accepter sends \`tx\_add\_output\` for their change.
> > > >
> > > > \- Accepter sends \`tx\_complete\`
> > > >
> > > > \- Opener sends \`tx\_complete\`
> > > >
> > > > \- Opener and accepter exchange commitment signatures; etc.
> > > >
> > > >
> > > >
> > > >
> > > > \#\#\# Considering the Splice case:
> > > >
> > > > \- Both peers signal \`opt\_splice\_ok\`
> > > >
> > > > \- One peer initiates a splice, also signaling the feerate for the transaction. Exact protocol unspecified herein.
> > > >
> > > > \- Initiator sends \`tx\_add\_input\` with the original funding output
> > > >
> > > > \- Initiator sends \`tx\_add\_output\` with the new, post-splice funding output
> > > >
> > > > \- Initiator sends \`tx\_add\_input/output\` as needed to add all desired inputs + outputs
> > > >
> > > > \- Initiator sends \`tx\_complete\`
> > > >
> > > > \- Peer sends \`tx\_add\_input/output\` as needed to add all desired inputs + outputs
> > > >
> > > > \- Initiator sends \`tx\_complete\`
> > > >
> > > > \- Peer sends \`tx\_complete\`
> > > >
> > > > \- Initiator + peer exchange commitment signatures, etc.
> > > >
> > > >
> > > >
> > > >
> > > > \#\#\# Considering the Close case:
> > > >
> > > > \- Both peers signal \`opt\_collaborative\_close\` in their \`node\_announcement\`.
> > > >
> > > > \- A peer initiates a close sending a \`shutdown\`, as per usual.
> > > >
> > > > \- A feerate is negotiated. Out of band for this particular portion of the protocol.
> > > >
> > > > \-The closing initiator (peer which first sent \`shutdown\`), sends \`tx\_add\_input\` to spend the funding output and \`tx\_add\_output\` to add their output for the channel closure.
> > > >
> > > > \- The peer responds with \`tx\_add\_output\`, adding their output to the close transaction.
> > > >
> > > > \- If \`option\_upfront\_shutdown\_script\` is flagged but no such output with a value at or within a reasonable feerate gap of the peer's funding output is present, then the peer must fail the channel.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > \#\# Updating a collaborative transaction with RBF:
> > > >
> > > > \- If any input is flagged as RBF’able, then the transaction is considered eligible for RBF
> > > >
> > > > \- RBF can be initiated by either party, and serves as an initiation for another round of transaction composition, as outlined above.
> > > >
> > > > \- Note that this section has been cribbed and re-purposed from the original RBF proposal for splicing, see https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001621.html
> > > >
> > > >
> > > >
> > > >
> > > > 1. type: 45 (\`init\_rbf\`) (\`option\_collaborative\_rbf\`)
> > > >
> > > > 2. data:
> > > >
> > > >    \* \[\`32\`:\`channel\_id\`\]
> > > >
> > > >    \* \[\`4\`:\`fee\_step\`\]
> > > >
> > > >
> > > >
> > > >
> > > > Each \`fee\_step\` adds 1/4 (rounded down) to the initial
> > > >
> > > > transaction feerate. eg. if the initial feerate was 512 satoshis per kiloweight, \`fee\_step\` 1
> > > >
> > > > is 512 + 512 / 4 = 640, \`fee\_step\` 2 is 640 + 640 / 4 = 800.
> > > >
> > > >
> > > >
> > > >
> > > > The sender:
> > > >
> > > >   - MUST set \`fee\_step\` greater than zero and greater than any prior \`fee\_step\`.
> > > >
> > > >
> > > >
> > > >
> > > > The recipient:
> > > >
> > > >   - if the new fee exceeds the sender's current balance minus reserve
> > > >
> > > >     after it is applied to the splice transaction:
> > > >
> > > >     - MUST error.
> > > >
> > > >
> > > >
> > > > NOTES:
> > > >
> > > > 1. 1/4 is a reasonable minimal RBF, but as each one requires more
> > > >
> > > >    tracking by the recipient, serves to limit the number you can create.
> > > >
> > > > 2. Rule 4 of BIP125 requires a feerate increase to at least surpass the minimum transaction relay setting. Ratcheting by 25% should satisfy this requirement
> > > >
> > > > 3. An additional rule will be added to the checks of an RBF transaction that it must include at least one identical, replaceable input as the original transaction.
> > > >
> > > >
> > > >
> > > >
> > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
> > > > Lightning-dev mailing list
> > > > [Lightning-dev at lists.linuxfoundation.org][Lightning-dev_lists.linuxfoundation.org]
> > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> > > >

[darosior_protonmail.com]: mailto:darosior at protonmail.com
[antoine.riard_gmail.com]: mailto:antoine.riard at gmail.com
[https_github.com_bitcoin_bitcoin_blob_aabec94541e23a67a9f30dc2c80dab3383a01737_src_wallet_wallet.cpp_L2519]: https://github.com/bitcoin/bitcoin/blob/aabec94541e23a67a9f30dc2c80dab3383a01737/src/wallet/wallet.cpp#L2519
[niftynei_gmail.com]: mailto:niftynei at gmail.com
[PR _524]: https://github.com/lightningnetwork/lightning-rfc/pull/524
[Lightning-dev_lists.linuxfoundation.org]: mailto:Lightning-dev at lists.linuxfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200130/462dc521/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200130/462dc521/attachment-0001.sig>;

📅 Original date posted:2020-01-02 📝 Original message: Hi ...

2023-06-09T12:57:54Z

In reply to nevent1q…ltph
_________________________

📅 Original date posted:2020-01-02
📝 Original message:
Hi ZmnSCPxj,

Just a nit to add for reference to this great writeup.

> - Add random tweaks to your channel traversal costs.
> - This is done currently by the C-Lightning route randomization feature, but note that it is currently set to up to a +/-5% tweak.
> - [This paper](https://arxiv.org/pdf/1909.06890) evaluates the C-Lightning route randomization as well.
> It suggest adding random tweaks to the costs of entire routes instead, though it may not be easy for normal pathfinding algorithms to implement this.

Since the authors made this analysis, the total fuzzing has been replaced by a tweak of both the base and proportional fees, added along the CTLV during the shadow route random walk.
https://github.com/ElementsProject/lightning/blob/8c387932c0095ffbe7314a73004337f5cc15ece0/plugins/pay.c#L827

Regards,
Darosior
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 477 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200102/91b4ba7b/attachment-0001.sig>;

📅 Original date posted:2021-06-01 📝 Original message: Hi ...

2023-06-09T12:40:07Z

In reply to nevent1q…km9q
_________________________

📅 Original date posted:2021-06-01
📝 Original message:
Hi all,

It's been almost 9 months since Tor v2 hidden services have been deprecated.
The Tor project will drop v2 support in about a month in the latest release. It will then be entirely be dropped from all supported releases by October.
More at https://blog.torproject.org/v2-deprecation-timeline .

Bitcoin Core defaults to v3 since 0.21.0 (https://bitcoincore.org/en/releases/0.21.0/) and is planning to drop the v2 support for 0.22 (https://github.com/bitcoin/bitcoin/pull/22050), which means that v2 onions will gradually stop being gossiped on the Bitcoin network.

I think we should do the same for the Lightning network, and the timeline is rather tight. Also, the configuration is user-facing (as opposed to Bitcoin Core, which generates ephemeral services) which i expect to make the transition trickier.
C-lightning is deprecating the configuration of Tor v2 services starting next release, according to our deprecation policy we should be able to entirely drop its support 3 releases after this one, which should be not so far from the October deadline.

Opinions? What is the state of other implementations with regard to Tor v2 support?

Antoine

📅 Original date posted:2023-01-26 🗒️ Summary of this ...

2023-06-07T23:18:41Z

In reply to nevent1q…hte9
_________________________

📅 Original date posted:2023-01-26
🗒️ Summary of this message: The email discusses a simple instantiation of Revault, which has advantages but two major issues that can be solved with covenants.
📝 Original message:Hello Billy,

Yes it's basically a (simple) instantiation of Revault. You can find more at [https://github.com/revault](https://github.com/revault/) (you most likely want the `practical-revault` repo). There is a description of the concept, the specification of a communication protocol between the participants as well as the implementation of the whole.

Such a design presents some advantages, but it has two major issues:

- You need to make sure all your watchtowers received the Cancel signature before you sign the Unvault transaction. But how can you get this guarantee in the usual (and reasonable) model of an untrusted laptop?
- You can only have policies on the Unvault transaction (eg "You can only Unvault up to X BTC during working hours"), not on the Spend transaction (eg "You can only send coins to a Script with pubkey Y required in all spending paths"). Revault allows to use cosigning servers that act as anti-replay oracles to have policies on the spend, but this is obviously *very* suboptimal.

Both issues are solvable with covenants.

Antoine Poinsot
------- Original Message -------
Le lundi 23 janvier 2023 à 6:39 PM, Billy Tetrud via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> a écrit :

> In the discussion around James' OP_VAULT proposal, it was implied that precomputed vaults must use ephemeral keys that must be deleted as part of the vaulting protocol, like [Bryan Bishop's proposal](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017229.html). Looking around, I haven't been able to find any wallet vault proposal that doesn't require ephemeral keys, so at the risk of posting something that's obvious to everyone, I wanted to share a simple way to do a wallet vault without requiring any key deletion.
>
> The basic idea is to create an N-of-N multisig address, and pre-sign some transactions from it with N-1 keys to an address with several timelocked spend paths. This has the fallback that funds can always be spent immediately if you use all the keys, just like a normal N-of-N multisig address (since that's what it is at its core), but the usage of any of the pre-signed transactions leads to an address that guarantees a clawback within a time window. Here's a 3-of-3 example:
>
> Vault Initialization:
> 1. Create 3 of 3 Vault Address
> 2. Create an Interim Address that can send with:
> * 1 of 3 keys after a timelock of 1 month
> * 2 of 3 keys after a timelock of 1 week
> * 3 of 3 keys with no timelock
>
> Vaulting:
> 1. Create a transaction sending an output to the Vault Address
> 2. Create a transaction spending that Vault Address output to the Interim Address
> 3. Presign one copy of the step-2 transaction for each of the three combinations of two keys.
> 4. Store seeds separately, store the wallet config as well as the three presigned transactions with each seed.
>
> Unvaulting:
> 1. Sign one of the pre-signed transactions with the missing signature.
> 2. Broadcast
> 3. Wait the appropriate timelock for the number of keys you want to sign with.
> 4. Create a transaction sending from the Interim Address.
> 5. Broadcast
> Recovering (after unvaulting step 2 after the broadcasted transaction to the Interim Address has been mined):
> 1. Sign the utxo with all three keys to any destination. Alternatively sign with two keys, wait 1 week.
> 2. Broadcast it
>
> This has the usual downsides of pre-signed vaults that you need to backup these transactions for each vaulting, complications involving the flexibility (or lack thereof) of fees, and inflexibility in how much to unvault (must be the whole utxo, no change). This could of course be augmented with various techniques to make fee handling more flexible (anchor outputs, multiple versions of the presigned transactions with different fees, etc). More complicated presigning schemes could allow for some flexibility in unvaulting amount (eg by sending change back into the vault, and creating additional pre-signed transactions for that new output).
>
> It also has the same downside that OP_CTV vaults have, where a stolen key can steal funds from the interim address by racing the owner with their own transaction once the necessary delay has passed. Note that James' OP_VAULT opcode wouldn't have this problem.
>
> But not requiring any toxic waste keys seems like a pretty good benefit over Bryan Bishop's original proposal.
>
> Anyways sorry if this was already on people's radar and just too obvious to post about.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230126/01be3f93/attachment.html>;

📅 Original date posted:2022-04-29 📝 Original message:Hi ...

2023-06-07T23:08:03Z

In reply to nevent1q…fnuj
_________________________

📅 Original date posted:2022-04-29
📝 Original message:Hi Shesek,

> 1. The resulting txids are not stable.

This is *literally* what the post you are replying to is proposing to solve.

> This property could be important for some of the proposed CTV use-cases, like channel factories.

Hmm? You can't have channel factories without Eltoo. (Well, you can in theory but good luck.)
Maybe you are refering to non-interactive channel creation? The case for stable txids is less strong if wehave APO (and therefore Eltoo). [0]

> 2. APO will only be available on Taproot, which some people might prefer to avoid for long-term multi-decade vault storage due to QC concerns. (also see my previous post on this thread [0])

This has been addressed over and over and over again. If a QC is able overnight to spend a large fraction of
the supply, your coins in your super non-QC-vulnerable-bare-CTV-covenant (that would eventually become
vulnerable when trying to use it) are worthless.[1]

Sorry for being sarcastic, but at this point it's not fair to use quantum-computer FUD to justify theactivation of CTV over APO, or encourage the use of legacy transactions over Taproot ones.

> 3. Higher witness satisfaction cost of roughly 3x vbytes vs CTV-in-Taproot (plus 33 extra vbytes vs CTV-in-segwitv0 in the case of a single CTV branch, for the taproot control block. with more branches CTV-in-taproot eventually becomes preferable).

Again, this is what my post discusses. Here are the arguments from my post about why i don't think it's a big deal:

1. You can in this case see CTV as an optimization of (tweaked) APOAS. A lot of us are doubtful about CTV
usecases for real people. So much that it was even proposed to temporarily activate it to see if it would
ever have any real traction! [2]
My point with this post was: what if we do (a slightly tweaked) BIP118, that is otherwise useful. And
if this use of covenants is really getting traction then we can roll out an optimization in the form of
CTV (or better covenants, as we'd have had more research put into it by this time).
2. CTV is mainly sold for its usage inside vaults. While i'm not convinced, a few more vbytes should not
matter for this usecase.

Also, it's not 33 extra vbytes vs CTV-in-segwitv0, but 33 extra * witness units* (8.25 vbytes).
Aside, you can also use the internal key optimization with APO. But i don't think it's desirable just to save32 WU, as you can't have NUMS-ness then. [3]

> 4. Higher network-wide full-node validation costs (checking a signature is quite more expensive than hashing, and the hashing is done in both cases).

Are APO signatures more expensive to verify? If not i don't think this should be a reason to constrain us to a
much less useful construction, as the cost for the network of validating signatures already exists today. Evenif it didn't, the tradeoff of cost/usefulness needs to be considered.

> 5. As APO is currently spec'd, it would suffer from the half-spend problem: if you have multiple outputs encumbered under an APO covenant that requires the same tx sigmsg hash, it becomes possible to spend all of them together as multiple inputs in a single transaction and burn the extra to mining fees.
>
> If I'm not mistaken, I believe this makes the simple-apo-vault implementation [1] vulnerable to spending multiple vaulted outputs of the same denomination together and burning all but the first one. I asked the author for a more definitive answer on twitter [2].
>
> Fixing this requires amending BIP 118 with some new sigmsg flags (making the ANYONECANPAY behaviour optional, as mentioned in the OP).

Yes! And as i mentioned on Twitter also committing to the input index which i forgot to add in the OP here.

While i don't think the specific points are valid, i appreciate your reply and your efforts to explore the
tradeoffs between the two approaches.

Thanks,
Antoine

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html

[1] https://bitcoin.stackexchange.com/a/91050/101498
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020242.html
[3] https://twitter.com/darosior/status/1518979155362254849?s=20&t=mGkw7K8mcyQwdLImFvdebw

> This is definitely possible but also means that APO as-is isn't a CTV-replacement candidate, without first going through some more design and review iterations.
>
> shesek
>
> [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020326.html
>
> [1] https://github.com/darosior/simple-anyprevout-vault
> [2] https://twitter.com/shesek/status/1519874493434544128
>
> On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I would like to know people's sentiment about doing (a very slightly tweaked version of) BIP118 in place of
>> (or before doing) BIP119.
>>
>> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for over 6 years. It presents proven and
>> implemented usecases, that are demanded and (please someone correct me if i'm wrong) more widely accepted than
>> CTV's.
>>
>> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made optional [0], can emulate CTV just fine.
>> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more expensive to use. But we can consider CTV
>> an optimization of APO-AS covenants.
>>
>> CTV advocates have been presenting vaults as the flagship usecase. Although as someone who've been trying to
>> implement practical vaults for the past 2 years i doubt CTV is necessary nor sufficient for this (but still
>> useful!), using APO-AS covers it. And it's not a couple dozen more virtual bytes that are going to matter for
>> a potential vault user.
>>
>> If after some time all of us who are currently dubious about CTV's stated usecases are proven wrong by onchain
>> usage of a less efficient construction to achieve the same goal, we could roll-out CTV as an optimization. In
>> the meantime others will have been able to deploy new applications leveraging ANYPREVOUT (Eltoo, blind
>> statechains, etc..[1]).
>>
>> Given the interest in, and demand for, both simple covenants and better offchain protocols it seems to me that
>> BIP118 is a soft fork candidate that could benefit more (if not most of) Bitcoin users.
>> Actually i'd also be interested in knowing if people would oppose the APO-AS part of BIP118, since it enables
>> CTV's features, for the same reason they'd oppose BIP119.
>>
>> [0] That is, to not commit to the other inputs of the transaction (via `sha_sequences` and maybe also
>> `sha_amounts`). Cf https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message.
>>
>> [1] https://anyprevout.xyz/ "Use Cases" section
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220429/54863559/attachment-0001.html>;

📅 Original date posted:2022-04-25 📝 Original message:Hi ...

2023-06-07T23:08:00Z

In reply to nevent1q…xc2h
_________________________

📅 Original date posted:2022-04-25
📝 Original message:Hi Richard,

> Sounds good to me. Although from an activation perspective it may not be either/or, both proposals do
compete for scarce reviewer time

Yes, of course. Let's say i was more interested in knowing if people who oppose CTV would oppose
SIGHASH_ANYPREVOUT too. I think talking about activation of anything at this point is premature.

> For someone not as versed in CTV, why is it necessary that ANYONECANPAY be optional to emulate CTV? Is there
a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?

I'm not aware of any specific to CTV. It's just that the fields covered in the CTV hash are very close to what
ANYPREVOUT_ANYSCRIPT's signature hash covers [0]. The two things that CTV commits to that APO_AS does not are
the number of inputs and the hash of the inputs' sequences [1].
Not committing to the number of inputs and other inputs' data is today's behaviour of ANYONECANPAY that can
be combined with other signature hash types [1]. Thus APO_AS makes ACP mandatory, and to emulate CTV
completely it should be optional.

Antoine

[0] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Detailed_Specification
[1] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
[2] https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cpp#L1327, https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cpp#L1517-L1522

------- Original Message -------
Le dimanche 24 avril 2022 à 10:41 PM, Richard Myers <remyers at yakshaver.org> a écrit :

> Hi darosior,
>
> Thanks for sharing your thoughts on this.
>
> > I would like to know people's sentiment about doing (a very slightly tweaked version of) BIP118 in place of
> > (or before doing) BIP119.
>
>
> Sounds good to me. Although from an activation perspective it may not be either/or, both proposals do compete for scarce reviewer time so their ordering will necessarily be driven by reviewer's priorities. My priority is eltoo which is why I focus on BIP-118.
>
> > SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made optional [0], can emulate CTV just fine.
>
>
> For someone not as versed in CTV, why is it necessary that ANYONECANPAY be optional to emulate CTV? Is there a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?
>
> In the case of eltoo commit txs, we use bring-your-own-fee (BYOF) to late-bind fees; that means ANYONECANPAY will always be paired with APO-AS for eltoo. Settlement txs in eltoo use just APO and do not necessarily need to be paired with ANYONECANPAY.
>
> I would guess making ANYONECANPAY the default for APO-AS was a way to squeeze in one more sighash flag. Perhaps there's another way to do it?
>
> Including SIGHASH_GROUP with APO for eltoo is also tempting. Specifically so the counter-party who commits a settlement tx can use for fees their settled to_self balance. How to rejigger the sighash flags to accommodate both APO and GROUP may be worth some discussion.
>
> The BIP-118 proposal will certainly benefit from having input from reviewers looking at other protocols than eltoo.
>
> -- Richard

📅 Original date posted:2022-04-25 📝 Original message:Just a ...

2023-06-07T23:08:00Z

In reply to nevent1q…763k
_________________________

📅 Original date posted:2022-04-25
📝 Original message:Just a correction to my previous mail. Sorry for the non-attribution, i didn't recall APO covenants had been discussed in the context of CTV.

> > a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?
>
> I'm not aware of any specific to CTV. It's just that the fields covered in the CTV hash are very close to what

The comparison was already done by Anthony Towns.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017036.html

Jeremy Rubin already pointed out that it missed committing to the nSequences hash and number of inputs (and optionally scriptSigs).
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017038.html

------- Original Message -------
Le lundi 25 avril 2022 à 3:35 PM, darosior via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> a écrit :

> Hi Richard,
>
> > Sounds good to me. Although from an activation perspective it may not be either/or, both proposals do
>
> compete for scarce reviewer time
>
> Yes, of course. Let's say i was more interested in knowing if people who oppose CTV would oppose
> SIGHASH_ANYPREVOUT too. I think talking about activation of anything at this point is premature.
>
> > For someone not as versed in CTV, why is it necessary that ANYONECANPAY be optional to emulate CTV? Is there
>
> a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?
>
> I'm not aware of any specific to CTV. It's just that the fields covered in the CTV hash are very close to what
> ANYPREVOUT_ANYSCRIPT's signature hash covers [0]. The two things that CTV commits to that APO_AS does not are
> the number of inputs and the hash of the inputs' sequences [1].
> Not committing to the number of inputs and other inputs' data is today's behaviour of ANYONECANPAY that can
> be combined with other signature hash types [1]. Thus APO_AS makes ACP mandatory, and to emulate CTV
> completely it should be optional.
>
>
> Antoine
>
> [0] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Detailed_Specification
> [1] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
> [2] https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cpp#L1327, https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cpp#L1517-L1522
>
>
> ------- Original Message -------
> Le dimanche 24 avril 2022 à 10:41 PM, Richard Myers remyers at yakshaver.org a écrit :
>
>
>
> > Hi darosior,
> >
> > Thanks for sharing your thoughts on this.
> >
> > > I would like to know people's sentiment about doing (a very slightly tweaked version of) BIP118 in place of
> > > (or before doing) BIP119.
> >
> > Sounds good to me. Although from an activation perspective it may not be either/or, both proposals do compete for scarce reviewer time so their ordering will necessarily be driven by reviewer's priorities. My priority is eltoo which is why I focus on BIP-118.
> >
> > > SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made optional [0], can emulate CTV just fine.
> >
> > For someone not as versed in CTV, why is it necessary that ANYONECANPAY be optional to emulate CTV? Is there a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?
> >
> > In the case of eltoo commit txs, we use bring-your-own-fee (BYOF) to late-bind fees; that means ANYONECANPAY will always be paired with APO-AS for eltoo. Settlement txs in eltoo use just APO and do not necessarily need to be paired with ANYONECANPAY.
> >
> > I would guess making ANYONECANPAY the default for APO-AS was a way to squeeze in one more sighash flag. Perhaps there's another way to do it?
> >
> > Including SIGHASH_GROUP with APO for eltoo is also tempting. Specifically so the counter-party who commits a settlement tx can use for fees their settled to_self balance. How to rejigger the sighash flags to accommodate both APO and GROUP may be worth some discussion.
> >
> > The BIP-118 proposal will certainly benefit from having input from reviewers looking at other protocols than eltoo.
> >
> > -- Richard
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-04-22 📝 Original message:Hi, ...

2023-06-07T23:07:57Z

In reply to nevent1q…jgs7
_________________________

📅 Original date posted:2022-04-22
📝 Original message:Hi,

Richard Myers has an implementation of Eltoo using Bitcoin Core's functional test framework: https://github.com/remyers/bitcoin/blob/eltoo-anyprevout/test/functional/simulate_eltoo.py.
He blogged about it, too. https://yakshaver.org/2021/07/26/first.html

He seems to have something similar for covenants, but it's WIP: https://github.com/remyers/bitcoin/blob/covenant-anyprevout/test/functional/feature_apocovenant.py. https://yakshaver.org/2021/11/18/covenants.html.

His APO page looks like a good reference on the topic: https://yakshaver.org/bitcoin/#anyprevout.

------- Original Message -------
Le vendredi 22 avril 2022 à 1:44 PM, rot13maxi <rot13maxi at protonmail.com> a écrit :

> Good morning darosior,
>
> Do you know if there is a working implementation of APO somewhere that people can use to try out some of the proposed usecases? For example, it would be great to see what eltoo would actually look like on an APO signet. Or to see some working code for a vault using covenants in an APO world.
>
> I haven’t seen much in the way of APO implementations recently, but I also haven’t gone looking, so would appreciate any links!
>
> Thanks
>
> On Fri, Apr 22, 2022 at 7:11 AM, darosior via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I would like to know people's sentiment about doing (a very slightly tweaked version of) BIP118 in place of
>> (or before doing) BIP119.
>>
>> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for over 6 years. It presents proven and
>> implemented usecases, that are demanded and (please someone correct me if i'm wrong) more widely accepted than
>> CTV's.
>>
>> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made optional [0], can emulate CTV just fine.
>> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more expensive to use. But we can consider CTV
>> an optimization of APO-AS covenants.
>>
>> CTV advocates have been presenting vaults as the flagship usecase. Although as someone who've been trying to
>> implement practical vaults for the past 2 years i doubt CTV is necessary nor sufficient for this (but still
>> useful!), using APO-AS covers it. And it's not a couple dozen more virtual bytes that are going to matter for
>> a potential vault user.
>>
>> If after some time all of us who are currently dubious about CTV's stated usecases are proven wrong by onchain
>> usage of a less efficient construction to achieve the same goal, we could roll-out CTV as an optimization. In
>> the meantime others will have been able to deploy new applications leveraging ANYPREVOUT (Eltoo, blind
>> statechains, etc..[1]).
>>
>> Given the interest in, and demand for, both simple covenants and better offchain protocols it seems to me that
>> BIP118 is a soft fork candidate that could benefit more (if not most of) Bitcoin users.
>> Actually i'd also be interested in knowing if people would oppose the APO-AS part of BIP118, since it enables
>> CTV's features, for the same reason they'd oppose BIP119.
>>
>> [0] That is, to not commit to the other inputs of the transaction (via `sha_sequences` and maybe also
>> `sha_amounts`). Cf https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message.
>>
>> [1] https://anyprevout.xyz/ "Use Cases" section
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220422/424bbc72/attachment.html>;

📅 Original date posted:2022-04-22 📝 Original message:I ...

2023-06-07T23:07:56Z

In reply to nevent1q…pawz
_________________________

📅 Original date posted:2022-04-22
📝 Original message:I would like to know people's sentiment about doing (a very slightly tweaked version of) BIP118 in place of
(or before doing) BIP119.

SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for over 6 years. It presents proven and
implemented usecases, that are demanded and (please someone correct me if i'm wrong) more widely accepted than
CTV's.

SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made optional [0], can emulate CTV just fine.
Sure then you can't have bare or Segwit v0 CTV, and it's a bit more expensive to use. But we can consider CTV
an optimization of APO-AS covenants.

CTV advocates have been presenting vaults as the flagship usecase. Although as someone who've been trying to
implement practical vaults for the past 2 years i doubt CTV is necessary nor sufficient for this (but still
useful!), using APO-AS covers it. And it's not a couple dozen more virtual bytes that are going to matter for
a potential vault user.

If after some time all of us who are currently dubious about CTV's stated usecases are proven wrong by onchain
usage of a less efficient construction to achieve the same goal, we could roll-out CTV as an optimization. In
the meantime others will have been able to deploy new applications leveraging ANYPREVOUT (Eltoo, blind
statechains, etc..[1]).

Given the interest in, and demand for, both simple covenants and better offchain protocols it seems to me that
BIP118 is a soft fork candidate that could benefit more (if not most of) Bitcoin users.
Actually i'd also be interested in knowing if people would oppose the APO-AS part of BIP118, since it enables
CTV's features, for the same reason they'd oppose BIP119.

[0] That is, to not commit to the other inputs of the transaction (via `sha_sequences` and maybe also
`sha_amounts`). Cf https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message.

[1] https://anyprevout.xyz/ "Use Cases" section

📅 Original date posted:2022-03-21 📝 Original message:Hi ...

2023-06-07T23:06:28Z

In reply to nevent1q…qmps
_________________________

📅 Original date posted:2022-03-21
📝 Original message:Hi ZmnSCPxj,

Thanks for the feedback. The DLC idea is interesting but you are centralizing the liveness requirements,
effectively creating a SPOF: in order to bypass the revocation clause no need to make sure to down each and
every watchtower anymore, just down the oracle and you are sure no revocation transaction can be pushed.

> Okay, let me see if I understand your concern correctly.
> When using a signature challenge, the concern is that you need to presign multiple versions of a transaction with varying feerates.

I was thinking of having a hot key (in this case probably shared amongst the monitors) where they would sign
the right fee level at broadcast time. Pre-signing makes it quickly too many signatures (and kills the purpose
of having covenants in the first place).

> And you have a set of network monitors / watchtowers that are supposed to watch the chain on your behalf in case your ISP suddenly hates you for no reason.
> The more monitors there are, the more likely that one of them will be corrupted by a miner and jump to the highest-feerate version, overpaying fees and making miners very happy.
> Such is third-party trust.
> Is my understanding correct?

Your understanding of the tradeoff is correct.

------- Original Message -------

Le jeudi 17 mars 2022 à 12:29 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :

> Good morning Antoine,
>
> > For "hot contracts" a signature challenge is used to achieve the same. I know the latter is imperfect, since
> >
> > the lower the uptime risk (increase the number of network monitors) the higher the DOS risk (as you duplicate
> >
> > the key).. That's why i asked if anybody had some thoughts about this and if there was a cleverer way of doing
> >
> > it.
>
> Okay, let me see if I understand your concern correctly.
>
> When using a signature challenge, the concern is that you need to presign multiple versions of a transaction with varying feerates.
>
> And you have a set of network monitors / watchtowers that are supposed to watch the chain on your behalf in case your ISP suddenly hates you for no reason.
>
> The more monitors there are, the more likely that one of them will be corrupted by a miner and jump to the highest-feerate version, overpaying fees and making miners very happy.
>
> Such is third-party trust.
>
> Is my understanding correct?
>
> A cleverer way, which requires consolidating (but is unable to eliminate) third-party trust, would be to use a DLC oracle.
>
> The DLC oracle provides a set of points corresponding to a set of feerate ranges, and commits to publishing the scalar of one of those points at some particular future block height.
>
> Ostensibly, the scalar it publishes is the one of the point that corresponds to the feerate range found at that future block height.
>
> You then create adaptor signatures for each feerate version, corresponding to the feerate ranges the DLC oracle could eventually publish.
>
> The adaptor signatures can only be completed if the DLC oracle publishes the corresponding scalar for that feerate range.
>
> You can then send the adaptor signatures to multiple watchtowers, who can only publish one of the feerate versions, unless the DLC oracle is hacked and publishes multiple scalars (at which point the DLC oracle protocol reveals a privkey of the DLC oracle, which should be usable for slashing some bond of the DLC oracle).
>
> This prevents any of them from publishing the highest-feerate version, as the adaptor signature cannot be completed unless that is what the oracle published.
>
> There are still drawbacks:
>
> * Third-party trust risk: the oracle can still lie.
>
> * DLC oracles are prevented from publishing multiple scalars; they cannot be prevented from publishing a single wrong scalar.
>
> * DLCs must be time bound.
>
> * DLC oracles commit to publishing a particular point at a particular fixed time.
>
> * For "hot" dynamic protocols, you need the ability to invoke the oracle at any time, not a particular fixed time.
>
> The latter probably makes this unusable for hot protocols anyway, so maybe not so clever.
>
> Regards,
>
> ZmnSCPxj

📅 Original date posted:2022-03-14 📝 Original message:Hi ...

2023-06-07T23:06:27Z

In reply to nevent1q…4zgu
_________________________

📅 Original date posted:2022-03-14
📝 Original message:Hi Jeremy,

Thanks for the feedback. I indeed only compared it to existing fee-bumping methods. But sponsors are pretty
similar to CPFP in usage anyways, they 'just' get rid of the complexity of managing transaction chains in the
mempool. That's great, don't get me wrong, just it's much less ideal than a solution not requiring additional
UTxOs to be reserved, managed, and additional onchain transactions.

Regarding chain efficiency. First, you wrote:
> As you've noted, an approach like precomitted different fee levels might work, but has substantial costs.

Well, i noted that it *does* work (at least for vaults). And it does incur a cost, but it's inferior to the
other solutions. Then, sure sponsors' -like CPFP's- cost can be amortized. The chain usage would still likely
be superior (depends on a case by case basis i'd say), but even then the "direct" chain usage cost isn't what
matters most. As mentioned, the cost of using funds not internal to the contract really is.

Regarding capital efficiency, again as noted in the post, it's the entire point to use funds internal to the
contract ("pre-committed"). Sure external funding (by the means of sponsors or any other technique) allows you
to allocate funds later on, or never. But we want contracts that are actually enforceable, i guess?
On the other hand, pre-committing to all the possible fee-bumped levels prevents you to dynamically add more
fees eventually. That's why you need to pre-commit to levels up to your assumed "max feerate before i close
the contract". For "cold contracts" (vaults), timelocks prevent the DOS of immediately using a large feerate.
For "hot contracts" a signature challenge is used to achieve the same. I know the latter is imperfect, since
the lower the uptime risk (increase the number of network monitors) the higher the DOS risk (as you duplicate
the key).. That's why i asked if anybody had some thoughts about this and if there was a cleverer way of doing
it.

> This is also true for vaults where you know you only want to open 1 per month let's say, and not
> your vaults> per month, which pre-committing requires.

Huh? Pre-committing here is to pre-commit to levels of the revocation ("Cancel") transaction. It has nothing
to do with "activating" (using Revault's terminology) a vault, done by sharing a signature for the Unvault
transaction.
You might have another vault design in mind whereby any deposited fund is unvault-able. In this case, and as
with any other active contract, i think you need to have funds ready to pay for the fees for the contract to
be enforceable. Whether these funds come from the contract's funds or from externally-reserved UTxOs.

> you don't need a salt, you just need a unique payout addr (e.g. hardened derivation) per revocation txn and
> you cannot guess the branch.

Yeah, i preferred to go with 8 more vbytes. First because relying on never reusing a derivation index is
brittle and also because it would make rescan much harder. Imagine having 256 fee levels, making 5 payments a
day for 200 days in a year. You'd have 256000 derivation indexes per year to scan for if restoring frombackup.

------- Original Message -------
Le dimanche 13 mars 2022 à 3:33 AM, Jeremy Rubin <jeremy.l.rubin at gmail.com> a écrit :

> Hi Antoine,
>
> I have a few high level thoughts on your post comparing these types of primitive to an explicit soft fork approach:
>
> 1) Transaction sponsors *is* a type of covenant. Precisely, it is very similar to an "Impossible Input" covenant in conjunction with a "IUTXO" I defined in my 2017 workshophttps://rubin.io/public/pdfs/multi-txn-contracts.pdf(I know, I know... self citation, not cool, but helps with context).
>
> However, for Sponsors itself we optimize the properties of how it works & is represented, as well as "tighten the hatches" on binding to specific TX vs merely spend of the outputs (which wouldn't work as well with APO).
>
> Perhaps thinking of something like sponsors as a form of covenant, rather than a special purpose thing, is helpful?
>
> There's a lot you could do with a general "observe other txns in {this block, the chain}" primitive. The catch is that for sponsors we don't *care* to enable people to use this as a "smart contracting primitive", we want to use it for fee bumping. So we don't care about programmability, we care about being able to use the covenant to bump fees.
>
> 2) On Chain Efficiency.
>
> A) Precommitted Levels
> As you've noted, an approach like precomitted different fee levels might work, but has substantial costs.
>
> However, with sponsors, the minimum viable version of this (not quite what is spec'd in my prior email, but it could be done this way if we care to optimize for bytes) would require 1 in and 1 out with only 32 bytes extra. So that's around 40 bytes outpoint + 64 bytes signature + 40 bytes output + 32 bytes metadata = 174 bytes per bump. Bumps in this way can also amortize, so bumping >1 txn at the same time would hit the limit of 32 bytes + 144/n bytes to bump more than one thing. You can imagine cases where this might be popular, like "close >1 of my LN channels" or "start withdrawals for 5 of my JamesOB vaulted coins"
>
> B) Fancy(er) Covenants
>
> We might also have something with OP_CAT and CSFS where bumps are done as some sort of covenant-y thing that lets you arbitrarily rewrite transactions.
>
> Not too much to say other than that it is difficult to get these down in size as the scripts become more complex, not to mention the (hotly discussed of late) ramifications of those covenants more generally.
>
> Absent a concrete fancy covenant with fee bumping, I can't comment.
>
> 3) On Capital Efficiency
>
> Something like a precommitted or covenant fee bump requires the fee capital to be pre-committed inside the UTXO, whereas for something like Sponsors you can use capital you get sometime later. In certain models -- e.g., channels -- where you might expect only log(N) of your channels to fail in a given epoch, you don't need to allocate as much capital as if you were to have to do it in-band. This is also true for vaults where you know you only want to open 1 per month let's say, and not <all of your vaults> per month, which pre-committing requires.
>
> 4) On Protocol Design
>
> It's nice that you can abstract away your protocol design concerns as a "second tier composition check" v.s. having to modify your protocol to work with a fee bumping thing.
>
> There are a myriad of ways dynamic txns (e.g. for Eltoo) can lead to RBF pinning and similar, Sponsor type things allow you to design such protocols to not have any native way of paying for fees inside the actual "Transaction Intents" and use an external system to create the intended effect. It seems (to me) more robust that we can prove that a Sponsors mechanism allows any transaction -- regardless of covenant stuff, bugs, pinning, etc -- to move forward.
>
> Still... careful protocol design may permit the use of optimized constructions! For example, in a vault rather than assigning *no fee* maybe you can have a single branch with a reasonable estimated fee. If you are correct or overshot (let's say 50% chance?) then you don't need to add a sponsor. If you undershot, not to worry, just add a sponsor. Adopted broadly, this would cut the expected value of using sponsors by <however good you are at estimating future fees>. This basically enables all protocols to try to be more efficient, but backstop that with a guaranteed to work safe mechanism.
>
> There was something else I was going to say but I forgot about it... if it comes to me I'll send a follow up email.
>
> Cheers,
>
> Jeremy
>
> p.s.
>
>>
>
>> Of course this makes for a perfect DoS: it would be trivial for a miner to infer that you are usinga specific vault standard and guess other leaves and replace the witness to use the highest-feeratespending path. You could require a signature from any of the participants. Or, at the cost of anadditional depth, in the tree you could "salt" each leaf by pairing it with -say- an OP_RETURN leaf.
>
> you don't need a salt, you just need a unique payout addr (e.g. hardened derivation) per revocation txn and you cannot guess the branch.
>
> --
> [@JeremyRubin](https://twitter.com/JeremyRubin)
>
> On Sat, Mar 12, 2022 at 10:34 AM darosior via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> The idea of a soft fork to fix dynamic fee bumping was recently put back on the table. It might
>> sound radical, as what prevents today reasonable fee bumping for contracts with presigned
>> transactions (pinning) has to do with nodes' relay policy. But the frustration is understandable
>> given the complexity of designing fee bumping with today's primitives. [0]
>> Recently too, there was a lot of discussions around covenants. Covenants (conceptually, not talking
>> about any specific proposal) seem to open lots of new use cases and to be desired by (some?) Bitcoin
>> application developers and users.
>> I think that fee bumping using covenants has attractive properties, and it requires a soft fork that
>> is already desirable beyond (trying) to fix fee bumping. However i could not come up with a solution
>> as neat for other protocols than vaults. I'd like to hear from others about 1) taking this route for
>> fee bumping 2) better ideas on applying this to other protocols.
>>
>> In a vault construction you have a UTxO which can only be spent by an Unvaulting transaction, whose
>> output triggers a timelock before the expiration of which a revocation transaction may be confirmed.
>> The revocation transaction being signed in advance (typically before sharing the signature for the
>> Unvault transaction) you need fee bumping in order for the contract to actually be enforceable.
>>
>> Now, with a covenant you could commit to the revocation tx instead of presigning it. And using a
>> Taproot tree you could commit to different versions of it with increasing feerate. Any network
>> monitor (the brooadcaster, a watchtower, ..) would be able to RBF the revocation transaction if it
>> doesn't confirm by spending using a leaf with a higher-feerate transaction being committed to.
>>
>> Of course this makes for a perfect DoS: it would be trivial for a miner to infer that you are using
>> a specific vault standard and guess other leaves and replace the witness to use the highest-feerate
>> spending path. You could require a signature from any of the participants. Or, at the cost of an
>> additional depth, in the tree you could "salt" each leaf by pairing it with -say- an OP_RETURN leaf.
>> But this leaves you with a possible internal blackmail for multi-party contracts (although it's less
>> of an issue for vaults, and not one for single-party vaults).
>> What you could do instead is attaching an increasing relative timelock to each leaf (as the committed
>> revocation feerate increases, so does the timelock). You need to be careful to note wreck miner
>> incentives here (see [0], [1], [2] on "miner harvesting"), but this enables the nice property of a
>> feerate which "adapts" to the block space market. Another nice property of this approach is the
>> integrated anti fee sniping protection if the revocation transaction pays a non-trivial amount of
>> fees.
>>
>> Paying fees from "shared" funds instead of a per-watchtower fee-bumping wallet opened up the
>> blackmail from the previous section, but the benefits of paying from internal funds shouldn't be
>> understated.
>> No need to decide on an amount to be refilled. No need to bother the user to refill the fee-bumping
>> wallet (before they can participate in more contracts, or worse before a deadline at which all
>> contracts are closed). No need for a potentially large amount of funds to just sit on a hot wallet
>> "just in case". No need to duplicate this amount as you replicate the number of network monitors
>> (which is critical to the security of such contracts).
>> In addition, note how modifying the feerate of the revocation transaction in place is less expensive
>> than adding a (pair of) new input (and output), let alone adding an entire new transaction to CPFP.
>> Aside, and less importantly, it can be made to work with today's relay rules (just use fee thresholds
>> adapted to the current RBF thresholds, potentially with some leeway to account for policy changes).
>> Paying from shared funds (in addition to paying from internal funds) also prevents pervert
>> incentives for contracts with more than 2 parties. In case one of the parties breaches it, all
>> remaining parties have an incentive to enforce the contract.. But only one would otherwise pay for
>> it! It would open up the door to some potential sneaky techniques to wait for another party to pay
>> for the fees, which is at odd with the reactive security model.
>>
>> Let's examine how it could be concretely designed. Say you have a vault wallet software for a setup
>> with 5 participants. The revocation delay is 144 blocks. You assume revocation to be infrequent (if
>> one happens it's probably a misconfigured watchtower that needs be fixed before the next
>> unvaulting), so you can afford infrequent overpayments and larger fee thresholds. Participants
>> assume the vault will be spent within a year and assume a maximum possible feerate for this year of
>> 10ksat/vb.
>> They create a Taproot tree of depth 7. First leaf is the spending path (open to whomever the vault
>> pays after the 144 blocks). Then the leaf `i` for `i` in `[1, 127]` is a covenant to the revocation
>> transaction with a feerate `i * 79` sats/vb and a relative timelock of `i - 1` blocks.
>> Assuming the covenant to the revocation transaction is 33 bytes [3], that's a witness of:
>> 1 + 33 + 1 + 33 + 7 * 32 = 292 WU (73 vb)
>> ^^^^^^ ^^^^^^^^^^^^^^
>> witscript control block
>> for any of the revocation paths. The revocation transaction is 1-input 1-output, so in total it's
>> 10.5 + 41 + 73 + 43 = 167.5 vb
>> ^^^^ ^^^^^^^^^^^ ^^^^
>> header input|witness output
>> The transaction size is not what you'd necessarily want to optimize for first, still, it is smaller
>> in this case than using other feebumping primitives and has a smaller footprint on the UTxO set. For
>> instance for adding a feebumping input and change output assuming all Taproot inputs and outputs
>> (CPFP is necessarily even larger):
>> 5 * 64 + 1 + 5 * (32 + 1) + 1 + 33 = 520 WU (105 vb)
>> ^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^
>> witness witscript control
>> 10.5 + 41 + 105 + 41 + 16.5 + 2 * 43 = 300 vb
>> ^^^^ ^^^^^^^^ ^^^^^^^^^ ^^^^^^
>> header input|witness fb input|witness outputs
>> From there, you can afford more depths at the tiny cost of 8 more vbytes each. You might want them
>> for:
>> - more granularity (if you can afford large enough timelocks)
>> - optimizing for the spending path rather than the revocation one
>> - adding a hashlock to prevent nuisance (with the above script a third party could malleate a
>> spending path into a revocation one). You can use the OP_RETURN trick from above to prevent that.
>>
>> Unfortunately, the timelocked-covenant approach to feebumping only applies to bumping the first
>> transaction of a chain (you can't pay for the parent with a timelock) so for instance it's not
>> usable for HTLC transactions in Lightning to bump the parent commitment tx. The same goes for
>> bumping the update tx in Coinpool.
>> It could be worked around by having a different covenant per participant (paying the fee from either
>> of the participants' output) behind a signature check. Of course it requires funds to already be in
>> the contract (HTLC, Coinpool leaf) to pay for your own unilateral close, but if you don't have any
>> fund in the contract it doesn't make sense to try to feebump it in the first place. The same goes
>> for small amounts: you'd only allocate up to the value of the contract (minus a dust preference) in
>> fees in order to enforce it.
>> This is less nice for external monitors as it requires a private key (or another secret) to be
>> committed to in advance) to be able to bump [4] and does not get rid of the "who's gonna pay for the
>> enforcement" issue in >2-parties contracts. Still, it's more optimal and usable than CPFP or adding
>> a pair of input/output for all the reasons mentioned above.
>>
>> Thoughts?
>> Antoine
>>
>> [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019614.html
>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019615.html
>> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019627.html
>> [3] That's obviously close to the CTV construction. But using another more flexible (and therefore
>> less optimized) construction would not be a big deal. It might in fact be necessary for more
>> elaborated (realistic?) usecases than the simple one detailed here.
>> [4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220314/dd75a8cb/attachment-0001.html>;

📅 Original date posted:2022-03-12 📝 Original message:The ...

2023-06-07T23:06:25Z

In reply to nevent1q…4ryx
_________________________

📅 Original date posted:2022-03-12
📝 Original message:The idea of a soft fork to fix dynamic fee bumping was recently put back on the table. It might
sound radical, as what prevents today reasonable fee bumping for contracts with presigned
transactions (pinning) has to do with nodes' relay policy. But the frustration is understandable
given the complexity of designing fee bumping with today's primitives. [0]
Recently too, there was a lot of discussions around covenants. Covenants (conceptually, not talking
about any specific proposal) seem to open lots of new use cases and to be desired by (some?) Bitcoin
application developers and users.
I think that fee bumping using covenants has attractive properties, and it requires a soft fork that
is already desirable beyond (trying) to fix fee bumping. However i could not come up with a solution
as neat for other protocols than vaults. I'd like to hear from others about 1) taking this route for
fee bumping 2) better ideas on applying this to other protocols.

In a vault construction you have a UTxO which can only be spent by an Unvaulting transaction, whose
output triggers a timelock before the expiration of which a revocation transaction may be confirmed.
The revocation transaction being signed in advance (typically before sharing the signature for the
Unvault transaction) you need fee bumping in order for the contract to actually be enforceable.

Now, with a covenant you could commit to the revocation tx instead of presigning it. And using a
Taproot tree you could commit to different versions of it with increasing feerate. Any network
monitor (the brooadcaster, a watchtower, ..) would be able to RBF the revocation transaction if it
doesn't confirm by spending using a leaf with a higher-feerate transaction being committed to.

Of course this makes for a perfect DoS: it would be trivial for a miner to infer that you are using
a specific vault standard and guess other leaves and replace the witness to use the highest-feerate
spending path. You could require a signature from any of the participants. Or, at the cost of an
additional depth, in the tree you could "salt" each leaf by pairing it with -say- an OP_RETURN leaf.
But this leaves you with a possible internal blackmail for multi-party contracts (although it's less
of an issue for vaults, and not one for single-party vaults).
What you could do instead is attaching an increasing relative timelock to each leaf (as the committed
revocation feerate increases, so does the timelock). You need to be careful to note wreck miner
incentives here (see [0], [1], [2] on "miner harvesting"), but this enables the nice property of a
feerate which "adapts" to the block space market. Another nice property of this approach is the
integrated anti fee sniping protection if the revocation transaction pays a non-trivial amount of
fees.

Paying fees from "shared" funds instead of a per-watchtower fee-bumping wallet opened up the
blackmail from the previous section, but the benefits of paying from internal funds shouldn't be
understated.
No need to decide on an amount to be refilled. No need to bother the user to refill the fee-bumping
wallet (before they can participate in more contracts, or worse before a deadline at which all
contracts are closed). No need for a potentially large amount of funds to just sit on a hot wallet
"just in case". No need to duplicate this amount as you replicate the number of network monitors
(which is critical to the security of such contracts).
In addition, note how modifying the feerate of the revocation transaction in place is less expensive
than adding a (pair of) new input (and output), let alone adding an entire new transaction to CPFP.
Aside, and less importantly, it can be made to work with today's relay rules (just use fee thresholds
adapted to the current RBF thresholds, potentially with some leeway to account for policy changes).
Paying from shared funds (in addition to paying from internal funds) also prevents pervert
incentives for contracts with more than 2 parties. In case one of the parties breaches it, all
remaining parties have an incentive to enforce the contract.. But only one would otherwise pay for
it! It would open up the door to some potential sneaky techniques to wait for another party to pay
for the fees, which is at odd with the reactive security model.

Let's examine how it could be concretely designed. Say you have a vault wallet software for a setup
with 5 participants. The revocation delay is 144 blocks. You assume revocation to be infrequent (if
one happens it's probably a misconfigured watchtower that needs be fixed before the next
unvaulting), so you can afford infrequent overpayments and larger fee thresholds. Participants
assume the vault will be spent within a year and assume a maximum possible feerate for this year of
10ksat/vb.
They create a Taproot tree of depth 7. First leaf is the spending path (open to whomever the vault
pays after the 144 blocks). Then the leaf `i` for `i` in `[1, 127]` is a covenant to the revocation
transaction with a feerate `i * 79` sats/vb and a relative timelock of `i - 1` blocks.
Assuming the covenant to the revocation transaction is 33 bytes [3], that's a witness of:
1 + 33 + 1 + 33 + 7 * 32 = 292 WU (73 vb)
^^^^^^ ^^^^^^^^^^^^^^
witscript control block
for any of the revocation paths. The revocation transaction is 1-input 1-output, so in total it's
10.5 + 41 + 73 + 43 = 167.5 vb
^^^^ ^^^^^^^^^^^ ^^^^
header input|witness output
The transaction size is not what you'd necessarily want to optimize for first, still, it is smaller
in this case than using other feebumping primitives and has a smaller footprint on the UTxO set. For
instance for adding a feebumping input and change output assuming all Taproot inputs and outputs
(CPFP is necessarily even larger):
5 * 64 + 1 + 5 * (32 + 1) + 1 + 33 = 520 WU (105 vb)
^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^
witness witscript control
10.5 + 41 + 105 + 41 + 16.5 + 2 * 43 = 300 vb
^^^^ ^^^^^^^^ ^^^^^^^^^ ^^^^^^
header input|witness fb input|witness outputs
>From there, you can afford more depths at the tiny cost of 8 more vbytes each. You might want them
for:
- more granularity (if you can afford large enough timelocks)
- optimizing for the spending path rather than the revocation one
- adding a hashlock to prevent nuisance (with the above script a third party could malleate a
spending path into a revocation one). You can use the OP_RETURN trick from above to prevent that.

Unfortunately, the timelocked-covenant approach to feebumping only applies to bumping the first
transaction of a chain (you can't pay for the parent with a timelock) so for instance it's not
usable for HTLC transactions in Lightning to bump the parent commitment tx. The same goes for
bumping the update tx in Coinpool.
It could be worked around by having a different covenant per participant (paying the fee from either
of the participants' output) behind a signature check. Of course it requires funds to already be in
the contract (HTLC, Coinpool leaf) to pay for your own unilateral close, but if you don't have any
fund in the contract it doesn't make sense to try to feebump it in the first place. The same goes
for small amounts: you'd only allocate up to the value of the contract (minus a dust preference) in
fees in order to enforce it.
This is less nice for external monitors as it requires a private key (or another secret) to be
committed to in advance) to be able to bump [4] and does not get rid of the "who's gonna pay for the
enforcement" issue in >2-parties contracts. Still, it's more optimal and usable than CPFP or adding
a pair of input/output for all the reasons mentioned above.

Thoughts?
Antoine

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019614.html
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019615.html
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019627.html
[3] That's obviously close to the CTV construction. But using another more flexible (and therefore
less optimized) construction would not be a big deal. It might in fact be necessary for more
elaborated (realistic?) usecases than the simple one detailed here.
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html

📅 Original date posted:2022-02-11 📝 Original message:Well ...

2023-06-07T23:04:13Z

In reply to nevent1q…85a9
_________________________

📅 Original date posted:2022-02-11
📝 Original message:Well because in the example i gave you this decreases the miner's reward. The rule of increasing feerate you stated isn't always economically rationale.

Note how it can also be extended, for instance if the miner only has 1.5vMB of txs and is not assured to receive enough transactions to fill 2 blocks he might be interested in maximizing absolute fees, not feerate.

Sure, we could make the argument that long term we need a large backlog of transactions anyways.. But that'd be unfortunately not in phase with today's reality.

-------- Original Message --------
On Feb 11, 2022, 00:51, James O'Beirne wrote:

>> It's not that simple. As a miner, if i have less than 1vMB of transactions in my mempool. I don't want a 10sats/vb transaction paying 100000sats by a 100sats/vb transaction paying only 10000sats.
>
> I don't understand why the "<1vMB in the mempool" case is even worth consideration because the miner will just include the entire mempool in the next block regardless of feerate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220211/82a07832/attachment.html>;

📅 Original date posted:2022-02-18 📝 Original message:James, ...

2023-06-07T23:04:11Z

In reply to nevent1q…yatq
_________________________

📅 Original date posted:2022-02-18
📝 Original message:James,

You seem to imply that the scenario described isn't prevented today. It is. The mempool acceptance for a replacement not only
depend on the transaction feerate but also the transaction fee [0]. That's why i raised it in the first place...

Antoine

[0] https://github.com/bitcoin/bitcoin/blob/66636ca438cb65fb18bcaa4540856cef0cee2029/src/validation.cpp#L944-L947

Of course if you are evicting transactions then you don't have the issue i mentioned, so it's fine doing so.
-------- Original Message --------
On Feb 17, 2022, 19:18, James O'Beirne < james.obeirne at gmail.com> wrote:

>> Is it really true that miners do/should care about that?
>
> De facto, any miner running an unmodified version of bitcoind doesn't
> care about anything aside from ancestor fee rate, given that the
> BlockAssembler as-written orders transactions for inclusion by
> descending ancestor fee-rate and then greedily adds them to the block
> template. [0]
>
> If anyone has any indication that there are miners running forks of
> bitcoind that change this behavior, I'd be curious to know it.
>
> Along the lines of what AJ wrote, optimal transaction selection is
> NP-hard (knapsack problem). Any time that a miner spends deciding how
> to assemble the next block is time not spent grinding on the nonce, and
> so I'm skeptical that miners in practice are currently doing anything
> that isn't fast and simple like the default implementation: sorting
> fee-rate in descending order and then greedily packing.
>
> But it would be interesting to hear evidence to the contrary.
>
> ---
>
> You can make the argument that transaction selection is just a function
> of mempool contents, and so mempool maintenance criteria might be the
> thing to look at. Mempool acceptance is gated based on a minimum
> feerate[1]. Mempool eviction (when running low on space) happens on
> the basis of max(self_feerate, descendant_feerate) [2]. So even in the
> mempool we're still talking in terms of fee rates, not absolute fees.
>
> That presents us with the "is/ought" problem: just because the mempool
> *is* currently gating only on fee rate doesn't mean that's optimal. But
> if the whole point of the mempool is to hold transactions that will be
> mined, and if there's good reason that txns are chosen for mining based
> on fee rate (it's quick and good enough), then it seems like fee rate
> is the approximation that should ultimately prevail for txn
> replacement.
>
> [0]:
> https://github.com/bitcoin/bitcoin/blob/master/src/node/miner.cpp#L310-L320
> [1]:
> https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.cpp#L1106
> [2]:
> https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.cpp#L1138-L1144
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220218/1da83193/attachment.html>;

📅 Original date posted:2022-02-10 📝 Original message:(I ...

2023-06-07T23:04:09Z

In reply to nevent1q…c5fs
_________________________

📅 Original date posted:2022-02-10
📝 Original message:(I have not yet read the recent posts on RBF but i wanted to react on the "additive feerate".)

> # Purely additive feerate bumps should never be impossible

It's not that simple. As a miner, if i have less than 1vMB of transactions in my mempool. I don't want a 10sats/vb transaction paying 100000sats by a 100sats/vb transaction paying only 10000sats.

Apart from that i very much agree with the approach of taking a step back and reframing, with CPFP being inadapted long term (wasteful, not useful for delegating fee bumping (i'm surprised i didn't mention it publicly but it makes it unsuitable for Revault for instance), and the current carve-out rule makes it only suitable for 2-party protocols), and the `diff` approach.

All that again with the caveat that i need to update myself on the recent proposals.

-------- Original Message --------
On Feb 10, 2022, 20:40, James O'Beirne via bitcoin-dev wrote:

> There's been much talk about fee-bumping lately, and for good reason -
> dynamic fee management is going to be a central part of bitcoin use as
> the mempool fills up (lord willing) and right now fee-bumping is
> fraught with difficulty and pinning peril.
>
> Gloria's recent post on the topic[0] was very lucid and highlights a
> lot of the current issues, as well as some proposals to improve the
> situation.
>
> As others have noted, the post was great. But throughout the course
> of reading it and the ensuing discussion, I became troubled by the
> increasing complexity of both the status quo and some of the
> proposed remedies.
>
> Layering on special cases, more carve-outs, and X and Y percentage
> thresholds is going to make reasoning about the mempool harder than it
> already is. Special consideration for "what should be in the next
> block" and/or the caching of block templates seems like an imposing
> dependency, dragging in a bunch of state and infrastructure to a
> question that should be solely limited to mempool feerate aggregates
> and the feerate of the particular txn package a wallet is concerned
> with.
>
> This is bad enough for protocol designers and Core developers, but
> making the situation any more intractable for "end-users" and wallet
> developers feels wrong.
>
> I thought it might be useful to step back and reframe. Here are a few
> aims that are motivated chiefly by the quality of end-user experience,
> constrained to obey incentive compatibility (i.e. miner reward, DoS
> avoidance). Forgive the abstract dalliance for a moment; I'll talk
> through concretes afterwards.
>
> # Purely additive feerate bumps should never be impossible
>
> Any user should always be able to add to the incentive to mine any
> transaction in a purely additive way. The countervailing force here
> ends up being spam prevention (a la min-relay-fee) to prevent someone
> from consuming bandwidth and mempool space with a long series of
> infinitesimal fee-bumps.
>
> A fee bump, naturally, should be given the same per-byte consideration
> as a normal Bitcoin transaction in terms of relay and block space,
> although it would be nice to come up with a more succinct
> representation. This leads to another design principle:
>
> # The bandwidth and chain space consumed by a fee-bump should be minimal
>
> Instead of prompting a rebroadcast of the original transaction for
> replacement, which contains a lot of data not new to the network, it
> makes more sense to broadcast the "diff" which is the additive
> contribution towards some txn's feerate.
>
> This dovetails with the idea that...
>
> # Special transaction structure should not be required to bump fees
>
> In an ideal design, special structural foresight would not be needed
> in order for a txn's feerate to be improved after broadcast.
>
> Anchor outputs specified solely for CPFP, which amount to many bytes of
> wasted chainspace, are a hack. It's probably uncontroversial at this
> point to say that even RBF itself is kind of a hack - a special
> sequence number should not be necessary for post-broadcast contribution
> toward feerate. Not to mention RBF's seemingly wasteful consumption of
> bandwidth due to the rebroadcast of data the network has already seen.
>
> In a sane design, no structural foresight - and certainly no wasted
> bytes in the form of unused anchor outputs - should be needed in order
> to add to a miner's reward for confirming a given transaction.
>
> Planning for fee-bumps explicitly in transaction structure also often
> winds up locking in which keys are required to bump fees, at odds
> with the idea that...
>
> # Feerate bumps should be able to come from anywhere
>
> One of the practical downsides of CPFP that I haven't seen discussed in
> this conversation is that it requires the transaction to pre-specify the
> keys needed to sign for fee bumps. This is problematic if you're, for
> example, using a vault structure that makes use of pre-signed
> transactions.
>
> What if the key you specified n the anchor outputs for a bunch of
> pre-signed txns is compromised? What if you'd like to be able to
> dynamically select the wallet that bumps fees? CPFP does you no favors
> here.
>
> There is of course a tension between allowing fee bumps to come from
> anywhere and the threat of pinning-like attacks. So we should venture
> to remove pinning as a possibility, in line with the first design
> principle I discuss.
>
> ---
>
> Coming down to earth, the "tabula rasa" thought experiment above has led
> me to favor an approach like the transaction sponsors design that Jeremy
> proposed in a prior discussion back in 2020[1].
>
> Transaction sponsors allow feerates to be bumped after a transaction's
> broadcast, regardless of the structure of the original transaction.
> No rebroadcast (wasted bandwidth) is required for the original txn data.
> No wasted chainspace on only-maybe-used prophylactic anchor outputs.
>
> The interface for end-users is very straightforward: if you want to bump
> fees, specify a transaction that contributes incrementally to package
> feerate for some txid. Simple.
>
> In the original discussion, there were a few main objections that I noted:
>
> 1. In Jeremy's original proposal, only one sponsor txn per txid is
> allowed by policy. A malicious actor could execute a pinning-like
> attack by specifying an only-slightly-helpful feerate sponsor that
> then precludes other larger bumps.
>
> I think there are some ways around this shortcoming. For example: what
> if, by policy, sponsor txns had additional constraints that
>
> - each input must be signed {SIGHASH_SINGLE,SIGHASH_NONE}|ANYONECANPAY,
> - the txn must be specified RBFable,
> - a replacement for the sponsor txn must raise the sponsor feerate,
> including ancestors (maybe this is inherent in "is RBFable," but
> I don't want to conflate absolute feerates into this).
>
> That way, there is still at most a single sponsor txn per txid in the
> mempool, but anyone can "mix in" inputs which bump the effective
> feerate of the sponsor.
>
> This may not be the exact solution we want, but I think it demonstrates
> that the sponsors design has some flexibility and merits some thinking.
>
> The second objection about sponsors was
>
> 2. (from Suhas) sponsors break the classic invariant: "once a valid
> transaction is created, it should not become invalid later on unless
> the inputs are double-spent."
>
> This doesn't seem like a huge concern to me if you consider the txid
> being sponsored as a sort of spiritual input to the sponsor. While the
> theoretical objection against broadening where one has to look in a txn
> to determine its dependencies is understandable, I don't see what the
> practical cost here is.
>
> Reorg complexity seems comparable if not identical, especially if we
> broaden sponsor rules to allow blocks to contain sponsor txns that are
> both for txids in the same block _or_ already included in the chain.
>
> This theoretical concession seems preferable to heaping more rules onto
> an already labyrinthine mempool policy that is difficult for both
> implementers and users to reason about practically and conceptually.
>
> A third objection that wasn't posed, IIRC, but almost certainly would
> be:
>
> 3. Transaction sponsors requires a soft-fork.
>
> Soft-forks are no fun, but I'll tell you what also isn't fun: being on
> the hook to model (and sometimes implement) a dizzying potpourri of
> mempool policies and special-cases. Expecting wallet implementers to
> abide by a maze of rules faithfully in order to ensure txn broadcast and
> fee management invites bugs for perpetuity and network behavior that is
> difficult to reason about a priori. Use of CPFP in the long-term also
> risks needless chain waste.
>
> If a soft-fork is the cost of cleaning up this essential process,
> consideration should be given to paying it as a one-time cost. This
> topic merits a separate post, but consider that in the 5 years leading
> up to the 2017 SegWit drama, we averaged about a soft-fork a year.
> Uncontroversial, "safe" changes to the consensus protocol shouldn't be
> out of the question when significant practical benefit is plain to see.
>
> ---
>
> I hope this message has added some framing to the discussion on fees,
> as well prompting other participants to go back and give the
> transaction sponsor proposal a serious look. The sponsors interface is
> about the simplest I can imagine for wallets, and it seems easy to
> reason about for implementers on Core and elsewhere.
>
> I'm not out to propose soft-forks lightly, but the current complexity
> in fee management feels untenable, and as evidenced by all the
> discussion lately, fees are an increasingly crucial part of the system.
>
> [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html
> [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220210/b9a80bc9/attachment-0001.html>;

📅 Original date posted:2021-12-08 📝 Original message:Hi ...

2023-06-07T23:00:55Z

In reply to nevent1q…8rre
_________________________

📅 Original date posted:2021-12-08
📝 Original message:Hi Gloria,

I agree with regard to the RBF changes. To me, we should (obviously?) do ancestor feerate instead of requiring confirmed inputs (#23121).
However, we are yet to come with a reasonable policy-only fix to "rule 3 pinning".

Responses inline!

>> The part of Revault we are interested in for this study is the delegation process, and more
>> specifically the application of spending policies by network monitors (watchtowers).
>
> I'd like to better understand how fee-bumping would be used, i.e. how the watchtower model works:
> - Do all of the vault parties both deposit to the vault and a refill/fee to the watchtower, is there a reward the watchtower collects for a successful Cancel, or something else? (Apologies if there's a thorough explanation somewhere that I haven't already seen).
> - Do we expect watchtowers tracking multiple vaults to be batching multiple Cancel transaction fee-bumps?
> - Do we expect vault users to be using multiple watchtowers for a better trust model? If so, and we're expecting batched fee-bumps, won't those conflict?

Grossly, it could be described as "enforce spending policied on 10BTC worth of delegated coins by allocating 5mBTC to 3 different watchtowers".
Each participant that will be delegating coins is expected to run a number of watchtowers. They should ideally be replicated (for full disclosure if
it wasn't obvious providing replication is the business model of the company behind the Revault project :p).
You can't batch fee-bumps as you *could* (maybe not *would*) do with anchor outputs channels, since the latter use CPFP and we "sponsor"
(or whatever the name of "supplementing the fees of a transaction by adding inputs" is).
In the current model, watchtowers enforcing the same policy do compete in that they broadcast conflicting transactions since they attach different
fee-bumping inputs. Ideally we could sign the added feebumping inputs themselves with ACP so they are allowed to cooperate. However doing that
would allow anyone on the network to snip the added fees to perform a "RBF rule-3 pinning".
Finally, there could be concerns around game theory of letting others' watchtowers feebump for you. I'm convinced however that in our case the fee
is completely dwarfed by the value at stake. Trying to delay your own WT's fee-bump reaction to hope someone else will pay the 10k sats for enforcing
a 1BTC contract, hmmm, i wouldn't do that.

>> For Revault we can afford to introduce malleability in the Cancel transaction since there is no
>> second-stage transaction depending on its txid. Therefore it is pre-signed with ANYONECANPAY. We
>> can't use ANYONECANPAY|SINGLE since it would open a pinning vector [3]. Note how we can't leverage
>> the carve out rule, and neither can any other more-than-two-parties contract.
>
> We've already talked about this offline, but I'd like to point out here that even transactions signed with ANYONECANPAY|ALL can be pinned by RBF unless we add an ancestor score rule. [0], [1] (numbers are inaccurate, Cancel Tx feerates wouldn't be that low, but just to illustrate what the attack would look like)

Thanks for expliciting that, i should have mentioned it. For everyone reading the PR is at https://github.com/bitcoin/bitcoin/pull/23121 .

>> can't use ANYONECANPAY|SINGLE since it would open a pinning vector [3]. Note how we can't leverage
>> the carve out rule, and neither can any other more-than-two-parties contract.
>
> Well stated about CPFP carve out. I suppose the generalization is that allowing n extra ancestorcount=2 descendants to a transaction means it can help contracts with <=n+1 parties (more accurately, outputs)? I wonder if it's possible to devise a different approach for limiting ancestors/descendants, e.g. by height/width/branching factor of the family instead of count... :shrug:

I don't think so, because you want any party involved in the contract to be able to unilaterally enforce it. With >2 anchor outputs any 2-parties can
collude against the other one(s) by pinning the transaction using the first party's output to hit the descendant chain limit and the second one to trigger
the carve-out.

Ideally i think it'd be better that all contracts move toward using sponsoring ("tx malleation") when we can (ie for all transactions that are at the end of
the chain, or post-ANYPREVOUT any transaction really) instead of CPFP for fee-bumping because:
1. It's way easier to reason about wrt mempool DOS protections (the fees don't depend on a chain of childs, it's just a function of the transaction alone)
2. It's more space efficient (and thereby economical): you don't need to create a new transaction (or a set of new txs) to bump your fees.

Unfortunately, having to use ACP instead of ACP|SINGLE is a showstopper. Managing a fee-bumping UTxO pool is a massive burden.
On a side note, thinking back about ACP|SINGLE vs ACP i'm not so sure anymore the latter opens up more pinning vectors than the former..

> IIUC, a Cancel transaction can be generalized as a 1-in-1-out where the input is presigned with counterparties, SIGHASH_ANYONECANPAY. The fan-out UTXO pool approach is a clever solution. I also think this smells like a case where improving lower-level RBF rules is more appropriate than requiring applications to write workarounds and generate extra transactions. Seeing that the BIP125#2 (no new unconfirmed inputs) restriction really hurts in this case, if that rule were removed, would you be able to simply keep the 1 big UTXO per vault and cut out the exact nValue you need to fee-bump Cancel transactions? Would that feel less like "burning" for the sake of fee-bumping?

I am not sure. It's a question i raised when i was made aware of your finding of the "no unconfirmed" rule defect and your proposal to move to ancestor
score instead. Without further consideration i'd say yes, but this needs more research. I'm also biased as i really want to get rid of this coin pool for both
the complexity and the social cost..

>> First of all, when to fee-bump? At fixed time intervals? At each block connection? It sounds like,
>> given a large enough timelock, you could try to greed by "trying your luck" at a lower feerate and
>> only re-bumping every N blocks. You would then start aggressively bumping at every block after M
>> blocks have passed.
>
> I'm wondering if you also considered other questions like:
> - Should a fee-bumping strategy be dependent upon the rate of incoming transactions? To me, it seems like the two components are (1) what's in the mempool and (2) what's going to trickle into the mempool between now and the target block. The first component is best-effort keeping incentive-compatible mempool; historical data and crystal ball look like the only options for incorporating the 2nd component.
> - Should the fee-bumping strategy depend on how close you are to your timelock expiry? (though this seems like a potential privacy leak, and the game theory could get weird as you mentioned).
> - As long as you have a good fee estimator (i.e. given a current mempool, can get an accurate feerate given a % probability of getting into target block n), is there any reason to devise a fee-bumping strategy beyond picking a time interval?

I think (again, ideally) applications should take `estimatesmarfee` as a black box, and not look into the mempool by themselves. Now whether we should
take into account the mempool data for short target estimation, i don't know. The first issue that comes to mind is how to measure whether your mempool
is "up-to-date" (i mean if you have most of the current unconfirmed transactions). Weak blocks were mentionned elsewhere, and i think they can help for
this (you don't influence your estimate by the rate of new unconfirmed transactions you hear about, but what miners are currently working on). Now, sure,
the expected time before the next block would be 10min. But for a short target estimate it still seems better to base your estimate on the most up-to-date
data you can get? (maybe not? Can a statistician chime in?)

This section was about arguing that it doesn't make sense to start low and get to next-block feerate as you approach your timelock expiration. Is your
question about whether it makes sense to start, as you get closer to timelock maturation, feebumping not on the basis of what your fee estimator gives
you but blindly i don't believe it does. If all you have is a fee-bumping method, all confirmation problems look like a fee-paying one :p.
You are already assuming your fee estimator is working and isn't being manipulated. If it does, and you don't get confirmed after X blocks and as many
re-bumping attempts the problem is elsewhere imo.

> It would be interesting to see stats on the spread of feerates in blocks during periods of fee fluctuation.
>
>> > In the event that you notice a consequent portion of the block is filled with transactions paying
>> > less than your own, you might want to start panicking and bump your transaction fees by a certain
>> > percentage with no consideration for your fee estimator. You might skew miners incentives in doing
>> > so: if you increase the fees by a factor of N, any miner with a fraction larger than 1/N of the
>> > network hashrate now has an incentive to censor your transaction at first to get you to panic.
>
>> Yes I think miner-harvesting attacks should be weighed carefully in the design of offchain contracts fee-bumping strategies, at least in the future when the mining reward exhausts further.
>
> Miner-harvesting (such cool naming!) is interesting, but I want to clarify the value of N - I don't think it's the factor by which you increase the fees on just your transaction.
> To codify: your transaction pays a fee of `f1` right now and might pay a fee of `f2` in a later block that the miner expects to mine with 1/N probability. The economically rational miner isn't incentivized if simply `f2 = N * f1` unless their mempool is otherwise empty.
> By omitting your transaction in this block, the miner can include another transaction/package paying `g1` fees instead, so they lose `f1-g1` in fees right now. In the future block, they have the choice between collecting `f2` or `g2` (from another transaction/package) in fees, so their gain is `max(f2-g2, 0)`.
> So the equation is more like: a miner with 1/N of the hashrate, employing this censorship strategy, gains only if `max(f2-g2, 0) > N * (f1-g1)`. More broadly, the miner only profits if `f2` is significantly higher than `g2` and `f1` is about the same feerate as everything else in your mempool: it seems like they're betting on how much you _overshoot_, not how much you bump.

Right. I was talking in the worst case where they don't have a replacement package with a feerate of `g1`. They are even more incentivized to try that if they do.
Since `f1` is already expected to be the next block feerate, by how much you bump is technically by how much your overshoot. So much for dismissing your fee
estimator!

> Slightly related question: in contracts, generally, the timelock deadline is revealed in the script, so the miner knows how "desperate" we are right?

For P2WSH, yes.

> Is that a problem?

I don't think so. As long as we don't bump the feerate by the N factor mentioned above, they have an incentive to try to take the fees while they still can (or someone else will).

> For Revault, if your Cancel transaction is a keypath spend (I think I remember reading that somewhere?) and you don't reveal the script, they don't see your timelock deadline yes?

It *could* be once we move to Taproot (2weeks). Yep! They would only know about it on a successful spend which would reveal the branch with the timelock. It's
a good point in that the attack above could be made impractical through privacy. Although i don't think it's realistic: due to the necessary script-path spends it would
be trivial to cluster coins managed by a Revault setup and deduce whether a given transaction is a Cancel with very high accuracy.

> Again, thanks for the digging and sharing. :)

Thanks for the interest and getting me to re-think through this!

Best,
Antoine

> Best,
> Gloria
>
> On Tue, Nov 30, 2021 at 3:27 PM darosior via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi Antoine,
>>
>> Thanks for your comment. I believe for Lightning it's simpler with regard to the management of the UTxO pool, but harder with regard to choosing
>> a threat model.
>> Responses inline.
>>
>>> For any opened channel, ensure the confirmation of a Commitment transaction and the children HTLC-Success/HTLC-Timeout transactions. Note, in the Lightning security game you have to consider (at least) 4 types of players moves and incentives : your node, your channel counterparties, the miners, the crowd of bitcoin users. The number of the last type of players is unknown from your node, however it should not be forgotten you're in competition for block space, therefore their block demands bids should be anticipated and reacted to in consequence. With that remark in mind, implications for your LN fee-bumping strategy will be raised afterwards.
>>>
>>> For a LN service provider, on-chain overpayments are bearing on your operational costs, thus downgrading your economic competitiveness. For the average LN user, overpayment might price out outside a LN non-custodial deployment, as you don't have the minimal security budget to be on your own.
>>
>> I think this problem statement can be easily generalised to any offchain contract. And your points stand for all of them.
>> "For any opened contract, ensure at any point the confirmation of a (set of) transaction(s) in a given number of blocks"
>>
>>> Same issue with Lightning, we can be pinned today on the basis of replace-by-fee rule 3. We can be also blinded by network mempool partitions, a pinning counterparty can segregate all the full-nodes in as many subsets by broadcasting a revoked Commitment transaction different for each. For Revault, I think you can also do unlimited partitions by mutating the ANYONECANPAY-input of the Cancel.
>>
>> Well you can already do unlimited partitions by adding different inputs to it. You could malleate the witness, but since we are using Miniscript i'm confident you would only be able in a marginal way.
>>
>>> That said, if you have a distributed towers deployment, spread across the p2p network topology, and they can't be clustered together through cross-layers or intra-layer heuristics, you should be able to reliably observe such partitions. I think such distributed monitors are deployed by few L1 merchants accepting 0-conf to detect naive double-spend.
>>
>> We should aim to more than 0-conf (in)security level..
>> It seems to me the only policy-level mitigation for RBF pinning around the "don't decrease the abolute fees of a less-than-a-block mempool" would be to drop the requirement on increasing absolute fees if the mempool is "full enough" (and the feerate increases exponentially, of course).
>> Another approach could be by introducing new consensus rules as proposed by Jeremy last year [0]. If we go in the realm of new consensus rules, then i think that simply committing to a maximum tx size would fix pinning by RBF rule 3. Could be in the annex, or in the unused sequence bits (although they currently are by Lightning, meh). You could also check in the output script that the input commits to this.
>>
>> [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
>>
>>> Have we already discussed a fee-bumping "shared cache", a CPFP variation ? Strawman idea: Alice and Bob commit collateral inputs to a separate UTXO from the main "offchain contract" one. This UTXO is locked by a multi-sig. For any Commitment transaction pre-signed, also counter-sign a CPFP with top mempool feerate included, spending a Commitment anchor output and the shared-cache UTXO. If the fees spike, you can re-sign a high-feerate CPFP, assuming interactivity. As the CPFP is counter-signed by everyone, the outputs can be CSV-1 encumbered to prevent pinnings. If the share-cache is feeded at parity, there shouldn't be an incentive to waste or maliciously inflate the feerate. I think this solution can be easily generalized to more than 2 counterparties by using a multi-signature scheme. Big issue, if the feerate is short due to fee spikes and you need to re-sign a higher-feerate CPFP, you're trusting your counterparty to interact, though arguably not worse than the current update fee mechanism.
>>
>> It really looks just like `update_fee`. Except maybe with the property that you have the channel liquidity not depend on the onchain feerate.
>> In any case, for Lightning i think it's a bad idea to re-introduce trust on this side post anchor outputs. For Revault it's clearly out of the question to introduce trust in your counterparties (why would you bother having a fee-bumping mechanism in the first place then?). Probably the same holds for all offchain contracts.
>>
>>>> For Lightning, it'd mean keeping an equivalent amount of funds as the sum of all your
>>> channels balances sitting there unallocated "just in case". This is not reasonable.
>>>
>>> Agree, game-theory wise, you would like to keep a full fee-bumping reserve, ready to burn as much in fees as the contested HTLC value, as it's the maximum gain of your counterparty. Though perfect equilibrium is hard to achieve because your malicious counterparty might have an edge pushing you to broadcast your Commitment first by witholding HTLC resolution.
>>>
>>> Fractional fee-bumping reserves are much more realistic to expect in the LN network. Lower fee-bumping reserve, higher liquidity deployed, in theory higher routing fees. By observing historical feerates, average offchain balances at risk and routing fees expected gains, you should be able to discover an equilibrium where higher levels of reserve aren't worth the opportunity cost. I guess this equilibrium could be your LN fee-bumping reserve max feerate.
>>>
>>> Note, I think the LN approach is a bit different from what suits a custody protocol like Revault, as you compute a direct return of the frozen fee-bumping liquidity. With Revault, if you have numerous bitcoins protected, it's might be more interesting to adopt a "buy the mempool, stupid" strategy than risking fund safety for few percentages of interest returns.
>>
>> True for routing nodes. For wallets (if receiving funds), it's not about an investment: just users expectations to being able to transact without risking to lose their funds (ie being able to enforce their contract onchain). Although wallets they are much less at risk.
>>
>>> This is where the "anticipate the crowd of bitcoin users move" point can be laid out. As the crowd of bitcoin users' fee-bumping reserves are ultimately unknown from your node knowledge, you should be ready to be a bit more conservative than the vanilla fee-bumping strategies shipped by default. In case of massive mempool congestion, your additional conservatism might get your time-sensitive transactions and game on the crowd of bitcoin users. First Problem: if all offchain bitcoin software adopt that strategy we might inflate the worst-case feerate rate at the benefit of the miners, without holistically improving block throughput. Second problem : your class of offchain bitcoin softwares might have ridiculous fee-bumping reserve compared
>>> to other classes of offchain bitcoin softwares (Revault > Lightning) and just be priced out bydesign in case of mempool congestion. Third problem : as the number of offchain bitcoin applications should go up with time, your fee-bumping reserve levels based from historical data might be always late by one "bank-run" scenario.
>>
>> Black swan event 2.0? Just rule n°3 is inherent to any kind of fee estimation.
>>
>>> For Lightning, if you're short in fee-bumping reserves you might still do preemptive channel closures, either cooperatively or unilaterally and get back the off-chain liquidity to protect the more economically interesting channels. Though again, that kind of automatic behavior might be compelling at the individual node-level, but make the mempol congestion worse holistically.
>>
>> Yeah so we are back to the "fractional reserve" model: you can only enforce X% of the offchain contracts your participate in.. Actually it's even an added assumption: that you still have operating contracts, with honest counterparties.
>>
>>> In case of massive mempool congestion, you might try to front-run the crowd of bitcoin users relying on block connections for fee-bumping, and thus start your fee-bumping as soon as you observe feerate groups fluctuations in your local mempool(s).
>>
>> I don't think any kind of mempool-based estimate generalizes well, since at any point the expected time before the next block is 10 minutes (and a lot can happen in 10min).
>>
>>> Also you might proceed your fee-bumping ticks on a local clock instead of block connections in case of time-dilation or deeper eclipse attacks of your local node. Your view of the chain might be compromised but not your ability to broadcast transactions thanks to emergency channels (in the non-LN sense...though in fact quid of txn wrapped in onions ?) of communication.
>>
>> Oh, yeah, i didn't explicit "not getting eclipsed" (or more generally "data availability") as an assumption since it's generally one made by participants of any offchain contract. In this case you can't even have decent fee estimation, so you are screwed anyways.
>>
>>> Yes, stay open the question on how you enforce this block insurance market. Reputation, which might be to avoid due to the latent centralization effect, might be hard to stack and audit reliably for an emergency mechanism running, hopefully, once in a halvening period. Maybe maybe some cryptographic or economically based mechanism on slashing or swaps could be found...
>>
>> Unfortunately, given current mining centralisation, pools are in a very good position to offer pretty decent SLAs around that. With a block space insurance, you of course don't need all these convoluted fee-bumping hacks.
>> I'm very concerned that large stakeholders of the "offchain contracts ecosystem" would just go this (easier) way and further increase mining centralisation pressure.
>>
>> I agree that a cryptography-based scheme around this type of insurance services would be the best way out.
>>
>>> Antoine
>>>
>>> Le lun. 29 nov. 2021 à 09:34, darosior via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> a écrit :
>>>
>>>> Hi everyone,
>>>>
>>>> Fee-bumping is paramount to the security of many protocols building on Bitcoin, as they require the
>>>> confirmation of a transaction (which might be presigned) before the expiration of a timelock at any
>>>> point after the establishment of the contract.
>>>>
>>>> The part of Revault using presigned transactions (the delegation from a large to a smaller multisig)
>>>> is no exception. We have been working on how to approach this for a while now and i'd like to share
>>>> what we have in order to open a discussion on this problem so central to what seem to be The Right
>>>> Way [0] to build on Bitcoin but which has yet to be discussed in details (at least publicly).
>>>>
>>>> I'll discuss what we came up with for Revault (at least for what will be its first iteration) but my
>>>> intent with posting to the mailing list is more to frame the questions to this problem we are all
>>>> going to face rather than present the results of our study tailored to the Revault usecase.
>>>> The discussion is still pretty Revault-centric (as it's the case study) but hopefully this can help
>>>> future protocol designers and/or start a discussion around what everyone's doing for existing ones.
>>>>
>>>> ## 1. Reminder about Revault
>>>>
>>>> The part of Revault we are interested in for this study is the delegation process, and more
>>>> specifically the application of spending policies by network monitors (watchtowers).
>>>> Coins are received on a large multisig. Participants of this large multisig create 2 [1]
>>>> transactions. The Unvault, spending a deposit UTxO, creates an output paying either to the small
>>>> multisig after a timelock or to the large multisig immediately. The Cancel, spending the Unvault
>>>> output through the non-timelocked path, creates a new deposit UTxO.
>>>> Participants regularly exchange the Cancel transaction signatures for each deposit, sharing the
>>>> signatures with the watchtowers they operate. They then optionally [2] sign the Unvault transaction
>>>> and share the signatures with the small multisig participants who can in turn use them to proceed
>>>> with a spending. Watchtowers can enforce spending policies (say, can't Unvault outside of business
>>>> hours) by having the Cancel transaction be confirmed before the expiration of the timelock.
>>>>
>>>> ## 2. Problem statement
>>>>
>>>> For any delegated vault, ensure the confirmation of a Cancel transaction in a configured number of
>>>> blocks at any point. In so doing, minimize the overpayments and the UTxO set footprint. Overpayments
>>>> increase the burden on the watchtower operator by increasing the required frequency of refills of the
>>>> fee-bumping wallet, which is already the worst user experience. You are likely to manage a number of
>>>> UTxOs with your number of vaults, which comes at a cost for you as well as everyone running a full
>>>> node.
>>>>
>>>> Note that this assumes miners are economically rationale, are incentivized by *public* fees and that
>>>> you have a way to propagate your fee-bumped transaction to them. We also don't consider the block
>>>> space bounds.
>>>>
>>>> In the previous paragraph and the following text, "vault" can generally be replaced with "offchain
>>>> contract".
>>>>
>>>> ## 3. With presigned transactions
>>>>
>>>> As you all know, the first difficulty is to get to be able to unilaterally enforce your contract
>>>> onchain. That is, any participant must be able to unilaterally bump the fees of a transaction even
>>>> if it was co-signed by other participants.
>>>>
>>>> For Revault we can afford to introduce malleability in the Cancel transaction since there is no
>>>> second-stage transaction depending on its txid. Therefore it is pre-signed with ANYONECANPAY. We
>>>> can't use ANYONECANPAY|SINGLE since it would open a pinning vector [3]. Note how we can't leverage
>>>> the carve out rule, and neither can any other more-than-two-parties contract.
>>>> This has a significant implication for the rest, as we are entirely burning fee-bumping UTxOs.
>>>>
>>>> This opens up a pinning vector, or at least a significant nuisance: any other party can largely
>>>> increase the absolute fee without increasing the feerate, leveraging the RBF rules to prevent you
>>>> from replacing it without paying an insane fee. And you might not see it in your own mempool and
>>>> could only suppose it's happening by receiving non-full blocks or with transactions paying a lower
>>>> feerate.
>>>> Unfortunately i know of no other primitive that can be used by multi-party (i mean, >2) presigned
>>>> transactions protocols for fee-bumping that aren't (more) vulnerable to pinning.
>>>>
>>>> ## 4. We are still betting on future feerate
>>>>
>>>> The problem is still missing one more constraint. "Ensuring confirmation at any time" involves ensuring
>>>> confirmation at *any* feerate, which you *cannot* do. So what's the limit? In theory you should be ready
>>>> to burn as much in fees as the value of the funds you want to get out of the contract. So... For us
>>>> it'd mean keeping for each vault an equivalent amount of funds sitting there on the watchtower's hot
>>>> wallet. For Lightning, it'd mean keeping an equivalent amount of funds as the sum of all your
>>>> channels balances sitting there unallocated "just in case". This is not reasonable.
>>>>
>>>> So you need to keep a maximum feerate, above which you won't be able to ensure the enforcement of
>>>> all your contracts onchain at the same time. We call that the "reserve feerate" and you can have
>>>> different strategies for choosing it, for instance:
>>>> - The 85th percentile over the last year of transactions feerates
>>>> - The maximum historical feerate
>>>> - The maximum historical feerate adjusted in dollars (makes more sense but introduces a (set of?)
>>>> trusted oracle(s) in a security-critical component)
>>>> - Picking a random high feerate (why not? It's an arbitrary assumption anyways)
>>>>
>>>> Therefore, even if we don't have to bet on the broadcast-time feerate market at signing time anymore
>>>> (since we can unilaterally bump), we still need some kind of prediction in preparation of making
>>>> funds available to bump the fees at broadcast time.
>>>> Apart from judging that 500sat/vb is probably more reasonable than 10sat/vbyte, this unfortunately
>>>> sounds pretty much crystal-ball-driven.
>>>>
>>>> We currently use the maximum of the 95th percentiles over 90-days windows over historical block chain
>>>> feerates. [4]
>>>>
>>>> ## 5. How much funds does my watchtower need?
>>>>
>>>> That's what we call the "reserve". Depending on your reserve feerate strategy it might vary over
>>>> time. This is easier to reason about with a per-contract reserve. For Revault it's pretty
>>>> straightforward since the Cancel transaction size is static: `reserve_feerate * cancel_size`. For
>>>> other protocols with dynamic transaction sizes (or even packages of transactions) it's less so. For
>>>> your Lightning channel you would probably take the maximum size of your commitment transaction
>>>> according to your HTLC exposure settings + the size of as many `htlc_success` transaction?
>>>>
>>>> Then you either have your software or your user guesstimate how many offchain contracts the
>>>> watchtower will have to watch, time that by the per-contract reserve and refill this amount (plus
>>>> some slack in practice). Once again, a UX tradeoff (not even mentioning the guesstimation UX):
>>>> overestimating leads to too many unallocated funds sitting on a hot wallet, underestimating means
>>>> (at best) inability to participate in new contracts or being "at risk" (not being able to enforce
>>>> all your contracts onchain at your reserve feerate) before a new refill.
>>>>
>>>> For vaults you likely have large-value UTxOs and small transactions (the Cancel is one-in one-out in
>>>> Revault). For some other applications with large transactions and lower-value UTxOs on average it's
>>>> likely that only part of the offchain contracts might be enforceable at a reasonable feerate. Is it
>>>> reasonable?
>>>>
>>>> ## 6. UTxO pool layout
>>>>
>>>> Now that you somehow managed to settle on a refill amount, how are you going to use these funds?
>>>> Also, you'll need to manage your pool across time (consolidating small coins, and probably fanning
>>>> out large ones).
>>>>
>>>> You could keep a single large UTxO and peel it as you need to sponsor transactions. But this means
>>>> that you need to create a coin of a specific value according to your need at the current feerate
>>>> estimation, hope to have it confirmed in a few blocks (at least for now! [5]), and hope that the
>>>> value won't be obsolete by the time it confirmed. Also, you'd have to do that for any number of
>>>> Cancel, chaining feebump coin creation transactions off the change of the previous ones or replacing
>>>> them with more outputs. Both seem to become really un-manageable (and expensive) in many edge-cases,
>>>> shortening the time you have to confirm the actual Cancel transaction and creating uncertainty about
>>>> the reserve (how much is my just-in-time fanout going to cost me in fees that i need to refill in
>>>> advance on my watchtower wallet?).
>>>> This is less of a concern for protocols using CPFP to sponsor transactions, but they rely on a
>>>> policy rule specific to 2-parties contracts.
>>>>
>>>> Therefore for Revault we fan-out the coins per-vault in advance. We do so at refill time so the
>>>> refiller can give an excess to pay for the fees of the fanout transaction (which is reasonable since
>>>> it will occur just after the refilling transaction confirms). When the watchtower is asked to watch
>>>> for a new delegated vault it will allocate coins from the pool of fanned-out UTxOs to it (failing
>>>> that, it would refuse the delegation).
>>>> What is a good distribution of UTxOs amounts per vault? We want to minimize the number of coins,
>>>> still have coins small enough to not overpay (remember, we can't have change) and be able to bump a
>>>> Cancel up to the reserve feerate using these coins. The two latter constraints are directly in
>>>> contradiction as the minimal value of a coin usable at the reserve feerate (paying for its own input
>>>> fee + bumping the feerate by, say, 5sat/vb) is already pretty high. Therefore we decided to go with
>>>> two distributions per vault. The "reserve distribution" alone ensures that we can bump up to the
>>>> reserve feerate and is usable for high feerates. The "bonus distribution" is not, but contains
>>>> smaller coins useful to prevent overpayments during low and medium fee periods (which is most of the
>>>> time).
>>>> Both distributions are based on a basic geometric suite [6]. Each value is half the previous one.
>>>> This exponentially decreases the value, limiting the number of coins. But this also allows for
>>>> pretty small coins to exist and each coin's value is equal to the sum of the smaller coins,
>>>> or smaller by at most the value of the smallest coin. Therefore bounding the maximum overpayment to
>>>> the smallest coin's value [7].
>>>>
>>>> For the management of the UTxO pool across time we merged the consolidation with the fanout. When
>>>> fanning out a refilled UTxO, we scan the pool for coins that need to be consolidated according to a
>>>> heuristic. An instance of a heuristic is "the coin isn't allocated and would not have been able to
>>>> increase the fee at the median feerate over the past 90 days of blocks".
>>>> We had this assumption that feerate would tend to go up with time and therefore discarded having to
>>>> split some UTxOs from the pool. We however overlooked that a large increase in the exchange price of
>>>> BTC as we've seen during the past year could invalidate this assumption and that should arguably be
>>>> reconsidered.
>>>>
>>>> ## 7. Bumping and re-bumping
>>>>
>>>> First of all, when to fee-bump? At fixed time intervals? At each block connection? It sounds like,
>>>> given a large enough timelock, you could try to greed by "trying your luck" at a lower feerate and
>>>> only re-bumping every N blocks. You would then start aggressively bumping at every block after M
>>>> blocks have passed. But that's actually a bet (in disguised?) that the next block feerate in M blocks
>>>> will be lower than the current one. In the absence of any predictive model it is more reasonable to
>>>> just start being aggressive immediately.
>>>> You probably want to base your estimates on `estimatesmartfee` and as a consequence you would re-bump
>>>> (if needed )after each block connection, when your estimates get updated and you notice your
>>>> transaction was not included in the block.
>>>>
>>>> In the event that you notice a consequent portion of the block is filled with transactions paying
>>>> less than your own, you might want to start panicking and bump your transaction fees by a certain
>>>> percentage with no consideration for your fee estimator. You might skew miners incentives in doing
>>>> so: if you increase the fees by a factor of N, any miner with a fraction larger than 1/N of the
>>>> network hashrate now has an incentive to censor your transaction at first to get you to panic. Also
>>>> note this can happen if you want to pay the absolute fees for the 'pinning' attack mentioned in
>>>> section #2, and that might actually incentivize miners to perform it themselves..
>>>>
>>>> The gist is that the most effective way to bump and rebump (RBF the Cancel tx) seems to just be to
>>>> consider the `estimatesmartfee 2 CONSERVATIVE` feerate at every block your tx isn't included in, and
>>>> to RBF it if the feerate is higher.
>>>> In addition, we fallback to a block chain based estimation when estimates aren't available (eg if
>>>> the user stopped their WT for say a hour and we come back up): we use the 85th percentile over the
>>>> feerates in the last 6 blocks. Sure, miners can try to have an influence on that by stuffing their
>>>> blocks with large fee self-paying transactions, but they would need to:
>>>> 1. Be sure to catch a significant portion of the 6 blocks (at least 2, actually)
>>>> 2. Give up on 25% of the highest fee-paying transactions (assuming they got the 6 blocks, it's
>>>> proportionally larger and incertain as they get less of them)
>>>> 3. Hope that our estimator will fail and we need to fall back to the chain-based estimation
>>>>
>>>> ## 8. Our study
>>>>
>>>> We essentially replayed the historical data with different deployment configurations (number of
>>>> participants and timelock) and probability of an event occurring (event being say an Unvault, an
>>>> invalid Unvault, a new delegation, ..). We then observed different metrics such as the time at risk
>>>> (when we can't enforce all our contracts at the reserve feerate at the same time), or the
>>>> operational cost.
>>>> We got the historical fee estimates data from Statoshi [9], Txstats [10] and the historical chain
>>>> data from Riccardo Casatta's `blocks_iterator` [11]. Thanks!
>>>>
>>>> The (research-quality..) code can be found at https://github.com/revault/research under the section
>>>> "Fee bumping". Again it's very Revault specific, but at least the data can probably be reused for
>>>> studying other protocols.
>>>>
>>>> ## 9. Insurances
>>>>
>>>> Of course, given it's all hacks and workarounds and there is no good answer to "what is a reasonable
>>>> feerate up to which we need to make contracts enforceable onchain?", there is definitely room for an
>>>> insurance market. But this enters the realm of opinions. Although i do have some (having discussed
>>>> this topic for the past years with different people), i would like to keep this post focused on the
>>>> technical aspects of this problem.
>>>>
>>>> [0] As far as i can tell, having offchain contracts be enforceable onchain by confirming a
>>>> transaction before the expiration of a timelock is a widely agreed-upon approach. And i don't think
>>>> we can opt for any other fundamentally different one, as you want to know you can claim back your
>>>> coins from a contract after a deadline before taking part in it.
>>>>
>>>> [1] The Real Revault (tm) involves more transactions, but for the sake of conciseness i only
>>>> detailed a minimum instance of the problem.
>>>>
>>>> [2] Only presigning part of the Unvault transactions allows to only delegate part of the coins,
>>>> which can be abstracted as "delegate x% of your stash" in the user interface.
>>>>
>>>> [3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017835.html
>>>>
>>>> [4] https://github.com/revault/research/blob/1df953813708287c32a15e771ba74957ec44f354/feebumping/model/statemachine.py#L323-L329
>>>>
>>>> [5] https://github.com/bitcoin/bitcoin/pull/23121
>>>>
>>>> [6] https://github.com/revault/research/blob/1df953813708287c32a15e771ba74957ec44f354/feebumping/model/statemachine.py#L494-L507
>>>>
>>>> [7] Of course this assumes a combinatorial coin selection, but i believe it's ok given we limit the
>>>> number of coins beforehand.
>>>>
>>>> [8] Although there is the argument to outbid a censorship, anyone censoring you isn't necessarily a
>>>> miner.
>>>>
>>>> [9] https://www.statoshi.info/
>>>>
>>>> [10] https://www.statoshi.info/
>>>>
>>>> [11] https://github.com/RCasatta/blocks_iterator
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211208/06c111d0/attachment-0001.html>;

📅 Original date posted:2021-11-30 📝 Original message:Hi ...

2023-06-07T23:00:46Z

In reply to nevent1q…jufx
_________________________

📅 Original date posted:2021-11-30
📝 Original message:Hi Antoine,

Thanks for your comment. I believe for Lightning it's simpler with regard to the management of the UTxO pool, but harder with regard to choosing
a threat model.
Responses inline.

> For any opened channel, ensure the confirmation of a Commitment transaction and the children HTLC-Success/HTLC-Timeout transactions. Note, in the Lightning security game you have to consider (at least) 4 types of players moves and incentives : your node, your channel counterparties, the miners, the crowd of bitcoin users. The number of the last type of players is unknown from your node, however it should not be forgotten you're in competition for block space, therefore their block demands bids should be anticipated and reacted to in consequence. With that remark in mind, implications for your LN fee-bumping strategy will be raised afterwards.
>
> For a LN service provider, on-chain overpayments are bearing on your operational costs, thus downgrading your economic competitiveness. For the average LN user, overpayment might price out outside a LN non-custodial deployment, as you don't have the minimal security budget to be on your own.

I think this problem statement can be easily generalised to any offchain contract. And your points stand for all of them.
"For any opened contract, ensure at any point the confirmation of a (set of) transaction(s) in a given number of blocks"

> Same issue with Lightning, we can be pinned today on the basis of replace-by-fee rule 3. We can be also blinded by network mempool partitions, a pinning counterparty can segregate all the full-nodes in as many subsets by broadcasting a revoked Commitment transaction different for each. For Revault, I think you can also do unlimited partitions by mutating the ANYONECANPAY-input of the Cancel.

Well you can already do unlimited partitions by adding different inputs to it. You could malleate the witness, but since we are using Miniscript i'm confident you would only be able in a marginal way.

> That said, if you have a distributed towers deployment, spread across the p2p network topology, and they can't be clustered together through cross-layers or intra-layer heuristics, you should be able to reliably observe such partitions. I think such distributed monitors are deployed by few L1 merchants accepting 0-conf to detect naive double-spend.

We should aim to more than 0-conf (in)security level..
It seems to me the only policy-level mitigation for RBF pinning around the "don't decrease the abolute fees of a less-than-a-block mempool" would be to drop the requirement on increasing absolute fees if the mempool is "full enough" (and the feerate increases exponentially, of course).
Another approach could be by introducing new consensus rules as proposed by Jeremy last year [0]. If we go in the realm of new consensus rules, then i think that simply committing to a maximum tx size would fix pinning by RBF rule 3. Could be in the annex, or in the unused sequence bits (although they currently are by Lightning, meh). You could also check in the output script that the input commits to this.

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html

> Have we already discussed a fee-bumping "shared cache", a CPFP variation ? Strawman idea: Alice and Bob commit collateral inputs to a separate UTXO from the main "offchain contract" one. This UTXO is locked by a multi-sig. For any Commitment transaction pre-signed, also counter-sign a CPFP with top mempool feerate included, spending a Commitment anchor output and the shared-cache UTXO. If the fees spike, you can re-sign a high-feerate CPFP, assuming interactivity. As the CPFP is counter-signed by everyone, the outputs can be CSV-1 encumbered to prevent pinnings. If the share-cache is feeded at parity, there shouldn't be an incentive to waste or maliciously inflate the feerate. I think this solution can be easily generalized to more than 2 counterparties by using a multi-signature scheme. Big issue, if the feerate is short due to fee spikes and you need to re-sign a higher-feerate CPFP, you're trusting your counterparty to interact, though arguably not worse than the current update fee mechanism.

It really looks just like `update_fee`. Except maybe with the property that you have the channel liquidity not depend on the onchain feerate.
In any case, for Lightning i think it's a bad idea to re-introduce trust on this side post anchor outputs. For Revault it's clearly out of the question to introduce trust in your counterparties (why would you bother having a fee-bumping mechanism in the first place then?). Probably the same holds for all offchain contracts.

>> For Lightning, it'd mean keeping an equivalent amount of funds as the sum of all your
> channels balances sitting there unallocated "just in case". This is not reasonable.
>
> Agree, game-theory wise, you would like to keep a full fee-bumping reserve, ready to burn as much in fees as the contested HTLC value, as it's the maximum gain of your counterparty. Though perfect equilibrium is hard to achieve because your malicious counterparty might have an edge pushing you to broadcast your Commitment first by witholding HTLC resolution.
>
> Fractional fee-bumping reserves are much more realistic to expect in the LN network. Lower fee-bumping reserve, higher liquidity deployed, in theory higher routing fees. By observing historical feerates, average offchain balances at risk and routing fees expected gains, you should be able to discover an equilibrium where higher levels of reserve aren't worth the opportunity cost. I guess this equilibrium could be your LN fee-bumping reserve max feerate.
>
> Note, I think the LN approach is a bit different from what suits a custody protocol like Revault, as you compute a direct return of the frozen fee-bumping liquidity. With Revault, if you have numerous bitcoins protected, it's might be more interesting to adopt a "buy the mempool, stupid" strategy than risking fund safety for few percentages of interest returns.

True for routing nodes. For wallets (if receiving funds), it's not about an investment: just users expectations to being able to transact without risking to lose their funds (ie being able to enforce their contract onchain). Although wallets they are much less at risk.

> This is where the "anticipate the crowd of bitcoin users move" point can be laid out. As the crowd of bitcoin users' fee-bumping reserves are ultimately unknown from your node knowledge, you should be ready to be a bit more conservative than the vanilla fee-bumping strategies shipped by default. In case of massive mempool congestion, your additional conservatism might get your time-sensitive transactions and game on the crowd of bitcoin users. First Problem: if all offchain bitcoin software adopt that strategy we might inflate the worst-case feerate rate at the benefit of the miners, without holistically improving block throughput. Second problem : your class of offchain bitcoin softwares might have ridiculous fee-bumping reserve compared
> to other classes of offchain bitcoin softwares (Revault > Lightning) and just be priced out bydesign in case of mempool congestion. Third problem : as the number of offchain bitcoin applications should go up with time, your fee-bumping reserve levels based from historical data might be always late by one "bank-run" scenario.

Black swan event 2.0? Just rule n°3 is inherent to any kind of fee estimation.

> For Lightning, if you're short in fee-bumping reserves you might still do preemptive channel closures, either cooperatively or unilaterally and get back the off-chain liquidity to protect the more economically interesting channels. Though again, that kind of automatic behavior might be compelling at the individual node-level, but make the mempol congestion worse holistically.

Yeah so we are back to the "fractional reserve" model: you can only enforce X% of the offchain contracts your participate in.. Actually it's even an added assumption: that you still have operating contracts, with honest counterparties.

> In case of massive mempool congestion, you might try to front-run the crowd of bitcoin users relying on block connections for fee-bumping, and thus start your fee-bumping as soon as you observe feerate groups fluctuations in your local mempool(s).

I don't think any kind of mempool-based estimate generalizes well, since at any point the expected time before the next block is 10 minutes (and a lot can happen in 10min).

> Also you might proceed your fee-bumping ticks on a local clock instead of block connections in case of time-dilation or deeper eclipse attacks of your local node. Your view of the chain might be compromised but not your ability to broadcast transactions thanks to emergency channels (in the non-LN sense...though in fact quid of txn wrapped in onions ?) of communication.

Oh, yeah, i didn't explicit "not getting eclipsed" (or more generally "data availability") as an assumption since it's generally one made by participants of any offchain contract. In this case you can't even have decent fee estimation, so you are screwed anyways.

> Yes, stay open the question on how you enforce this block insurance market. Reputation, which might be to avoid due to the latent centralization effect, might be hard to stack and audit reliably for an emergency mechanism running, hopefully, once in a halvening period. Maybe maybe some cryptographic or economically based mechanism on slashing or swaps could be found...

Unfortunately, given current mining centralisation, pools are in a very good position to offer pretty decent SLAs around that. With a block space insurance, you of course don't need all these convoluted fee-bumping hacks.
I'm very concerned that large stakeholders of the "offchain contracts ecosystem" would just go this (easier) way and further increase mining centralisation pressure.

I agree that a cryptography-based scheme around this type of insurance services would be the best way out.

> Antoine
>
> Le lun. 29 nov. 2021 à 09:34, darosior via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> a écrit :
>
>> Hi everyone,
>>
>> Fee-bumping is paramount to the security of many protocols building on Bitcoin, as they require the
>> confirmation of a transaction (which might be presigned) before the expiration of a timelock at any
>> point after the establishment of the contract.
>>
>> The part of Revault using presigned transactions (the delegation from a large to a smaller multisig)
>> is no exception. We have been working on how to approach this for a while now and i'd like to share
>> what we have in order to open a discussion on this problem so central to what seem to be The Right
>> Way [0] to build on Bitcoin but which has yet to be discussed in details (at least publicly).
>>
>> I'll discuss what we came up with for Revault (at least for what will be its first iteration) but my
>> intent with posting to the mailing list is more to frame the questions to this problem we are all
>> going to face rather than present the results of our study tailored to the Revault usecase.
>> The discussion is still pretty Revault-centric (as it's the case study) but hopefully this can help
>> future protocol designers and/or start a discussion around what everyone's doing for existing ones.
>>
>> ## 1. Reminder about Revault
>>
>> The part of Revault we are interested in for this study is the delegation process, and more
>> specifically the application of spending policies by network monitors (watchtowers).
>> Coins are received on a large multisig. Participants of this large multisig create 2 [1]
>> transactions. The Unvault, spending a deposit UTxO, creates an output paying either to the small
>> multisig after a timelock or to the large multisig immediately. The Cancel, spending the Unvault
>> output through the non-timelocked path, creates a new deposit UTxO.
>> Participants regularly exchange the Cancel transaction signatures for each deposit, sharing the
>> signatures with the watchtowers they operate. They then optionally [2] sign the Unvault transaction
>> and share the signatures with the small multisig participants who can in turn use them to proceed
>> with a spending. Watchtowers can enforce spending policies (say, can't Unvault outside of business
>> hours) by having the Cancel transaction be confirmed before the expiration of the timelock.
>>
>> ## 2. Problem statement
>>
>> For any delegated vault, ensure the confirmation of a Cancel transaction in a configured number of
>> blocks at any point. In so doing, minimize the overpayments and the UTxO set footprint. Overpayments
>> increase the burden on the watchtower operator by increasing the required frequency of refills of the
>> fee-bumping wallet, which is already the worst user experience. You are likely to manage a number of
>> UTxOs with your number of vaults, which comes at a cost for you as well as everyone running a full
>> node.
>>
>> Note that this assumes miners are economically rationale, are incentivized by *public* fees and that
>> you have a way to propagate your fee-bumped transaction to them. We also don't consider the block
>> space bounds.
>>
>> In the previous paragraph and the following text, "vault" can generally be replaced with "offchain
>> contract".
>>
>> ## 3. With presigned transactions
>>
>> As you all know, the first difficulty is to get to be able to unilaterally enforce your contract
>> onchain. That is, any participant must be able to unilaterally bump the fees of a transaction even
>> if it was co-signed by other participants.
>>
>> For Revault we can afford to introduce malleability in the Cancel transaction since there is no
>> second-stage transaction depending on its txid. Therefore it is pre-signed with ANYONECANPAY. We
>> can't use ANYONECANPAY|SINGLE since it would open a pinning vector [3]. Note how we can't leverage
>> the carve out rule, and neither can any other more-than-two-parties contract.
>> This has a significant implication for the rest, as we are entirely burning fee-bumping UTxOs.
>>
>> This opens up a pinning vector, or at least a significant nuisance: any other party can largely
>> increase the absolute fee without increasing the feerate, leveraging the RBF rules to prevent you
>> from replacing it without paying an insane fee. And you might not see it in your own mempool and
>> could only suppose it's happening by receiving non-full blocks or with transactions paying a lower
>> feerate.
>> Unfortunately i know of no other primitive that can be used by multi-party (i mean, >2) presigned
>> transactions protocols for fee-bumping that aren't (more) vulnerable to pinning.
>>
>> ## 4. We are still betting on future feerate
>>
>> The problem is still missing one more constraint. "Ensuring confirmation at any time" involves ensuring
>> confirmation at *any* feerate, which you *cannot* do. So what's the limit? In theory you should be ready
>> to burn as much in fees as the value of the funds you want to get out of the contract. So... For us
>> it'd mean keeping for each vault an equivalent amount of funds sitting there on the watchtower's hot
>> wallet. For Lightning, it'd mean keeping an equivalent amount of funds as the sum of all your
>> channels balances sitting there unallocated "just in case". This is not reasonable.
>>
>> So you need to keep a maximum feerate, above which you won't be able to ensure the enforcement of
>> all your contracts onchain at the same time. We call that the "reserve feerate" and you can have
>> different strategies for choosing it, for instance:
>> - The 85th percentile over the last year of transactions feerates
>> - The maximum historical feerate
>> - The maximum historical feerate adjusted in dollars (makes more sense but introduces a (set of?)
>> trusted oracle(s) in a security-critical component)
>> - Picking a random high feerate (why not? It's an arbitrary assumption anyways)
>>
>> Therefore, even if we don't have to bet on the broadcast-time feerate market at signing time anymore
>> (since we can unilaterally bump), we still need some kind of prediction in preparation of making
>> funds available to bump the fees at broadcast time.
>> Apart from judging that 500sat/vb is probably more reasonable than 10sat/vbyte, this unfortunately
>> sounds pretty much crystal-ball-driven.
>>
>> We currently use the maximum of the 95th percentiles over 90-days windows over historical block chain
>> feerates. [4]
>>
>> ## 5. How much funds does my watchtower need?
>>
>> That's what we call the "reserve". Depending on your reserve feerate strategy it might vary over
>> time. This is easier to reason about with a per-contract reserve. For Revault it's pretty
>> straightforward since the Cancel transaction size is static: `reserve_feerate * cancel_size`. For
>> other protocols with dynamic transaction sizes (or even packages of transactions) it's less so. For
>> your Lightning channel you would probably take the maximum size of your commitment transaction
>> according to your HTLC exposure settings + the size of as many `htlc_success` transaction?
>>
>> Then you either have your software or your user guesstimate how many offchain contracts the
>> watchtower will have to watch, time that by the per-contract reserve and refill this amount (plus
>> some slack in practice). Once again, a UX tradeoff (not even mentioning the guesstimation UX):
>> overestimating leads to too many unallocated funds sitting on a hot wallet, underestimating means
>> (at best) inability to participate in new contracts or being "at risk" (not being able to enforce
>> all your contracts onchain at your reserve feerate) before a new refill.
>>
>> For vaults you likely have large-value UTxOs and small transactions (the Cancel is one-in one-out in
>> Revault). For some other applications with large transactions and lower-value UTxOs on average it's
>> likely that only part of the offchain contracts might be enforceable at a reasonable feerate. Is it
>> reasonable?
>>
>> ## 6. UTxO pool layout
>>
>> Now that you somehow managed to settle on a refill amount, how are you going to use these funds?
>> Also, you'll need to manage your pool across time (consolidating small coins, and probably fanning
>> out large ones).
>>
>> You could keep a single large UTxO and peel it as you need to sponsor transactions. But this means
>> that you need to create a coin of a specific value according to your need at the current feerate
>> estimation, hope to have it confirmed in a few blocks (at least for now! [5]), and hope that the
>> value won't be obsolete by the time it confirmed. Also, you'd have to do that for any number of
>> Cancel, chaining feebump coin creation transactions off the change of the previous ones or replacing
>> them with more outputs. Both seem to become really un-manageable (and expensive) in many edge-cases,
>> shortening the time you have to confirm the actual Cancel transaction and creating uncertainty about
>> the reserve (how much is my just-in-time fanout going to cost me in fees that i need to refill in
>> advance on my watchtower wallet?).
>> This is less of a concern for protocols using CPFP to sponsor transactions, but they rely on a
>> policy rule specific to 2-parties contracts.
>>
>> Therefore for Revault we fan-out the coins per-vault in advance. We do so at refill time so the
>> refiller can give an excess to pay for the fees of the fanout transaction (which is reasonable since
>> it will occur just after the refilling transaction confirms). When the watchtower is asked to watch
>> for a new delegated vault it will allocate coins from the pool of fanned-out UTxOs to it (failing
>> that, it would refuse the delegation).
>> What is a good distribution of UTxOs amounts per vault? We want to minimize the number of coins,
>> still have coins small enough to not overpay (remember, we can't have change) and be able to bump a
>> Cancel up to the reserve feerate using these coins. The two latter constraints are directly in
>> contradiction as the minimal value of a coin usable at the reserve feerate (paying for its own input
>> fee + bumping the feerate by, say, 5sat/vb) is already pretty high. Therefore we decided to go with
>> two distributions per vault. The "reserve distribution" alone ensures that we can bump up to the
>> reserve feerate and is usable for high feerates. The "bonus distribution" is not, but contains
>> smaller coins useful to prevent overpayments during low and medium fee periods (which is most of the
>> time).
>> Both distributions are based on a basic geometric suite [6]. Each value is half the previous one.
>> This exponentially decreases the value, limiting the number of coins. But this also allows for
>> pretty small coins to exist and each coin's value is equal to the sum of the smaller coins,
>> or smaller by at most the value of the smallest coin. Therefore bounding the maximum overpayment to
>> the smallest coin's value [7].
>>
>> For the management of the UTxO pool across time we merged the consolidation with the fanout. When
>> fanning out a refilled UTxO, we scan the pool for coins that need to be consolidated according to a
>> heuristic. An instance of a heuristic is "the coin isn't allocated and would not have been able to
>> increase the fee at the median feerate over the past 90 days of blocks".
>> We had this assumption that feerate would tend to go up with time and therefore discarded having to
>> split some UTxOs from the pool. We however overlooked that a large increase in the exchange price of
>> BTC as we've seen during the past year could invalidate this assumption and that should arguably be
>> reconsidered.
>>
>> ## 7. Bumping and re-bumping
>>
>> First of all, when to fee-bump? At fixed time intervals? At each block connection? It sounds like,
>> given a large enough timelock, you could try to greed by "trying your luck" at a lower feerate and
>> only re-bumping every N blocks. You would then start aggressively bumping at every block after M
>> blocks have passed. But that's actually a bet (in disguised?) that the next block feerate in M blocks
>> will be lower than the current one. In the absence of any predictive model it is more reasonable to
>> just start being aggressive immediately.
>> You probably want to base your estimates on `estimatesmartfee` and as a consequence you would re-bump
>> (if needed )after each block connection, when your estimates get updated and you notice your
>> transaction was not included in the block.
>>
>> In the event that you notice a consequent portion of the block is filled with transactions paying
>> less than your own, you might want to start panicking and bump your transaction fees by a certain
>> percentage with no consideration for your fee estimator. You might skew miners incentives in doing
>> so: if you increase the fees by a factor of N, any miner with a fraction larger than 1/N of the
>> network hashrate now has an incentive to censor your transaction at first to get you to panic. Also
>> note this can happen if you want to pay the absolute fees for the 'pinning' attack mentioned in
>> section #2, and that might actually incentivize miners to perform it themselves..
>>
>> The gist is that the most effective way to bump and rebump (RBF the Cancel tx) seems to just be to
>> consider the `estimatesmartfee 2 CONSERVATIVE` feerate at every block your tx isn't included in, and
>> to RBF it if the feerate is higher.
>> In addition, we fallback to a block chain based estimation when estimates aren't available (eg if
>> the user stopped their WT for say a hour and we come back up): we use the 85th percentile over the
>> feerates in the last 6 blocks. Sure, miners can try to have an influence on that by stuffing their
>> blocks with large fee self-paying transactions, but they would need to:
>> 1. Be sure to catch a significant portion of the 6 blocks (at least 2, actually)
>> 2. Give up on 25% of the highest fee-paying transactions (assuming they got the 6 blocks, it's
>> proportionally larger and incertain as they get less of them)
>> 3. Hope that our estimator will fail and we need to fall back to the chain-based estimation
>>
>> ## 8. Our study
>>
>> We essentially replayed the historical data with different deployment configurations (number of
>> participants and timelock) and probability of an event occurring (event being say an Unvault, an
>> invalid Unvault, a new delegation, ..). We then observed different metrics such as the time at risk
>> (when we can't enforce all our contracts at the reserve feerate at the same time), or the
>> operational cost.
>> We got the historical fee estimates data from Statoshi [9], Txstats [10] and the historical chain
>> data from Riccardo Casatta's `blocks_iterator` [11]. Thanks!
>>
>> The (research-quality..) code can be found at https://github.com/revault/research under the section
>> "Fee bumping". Again it's very Revault specific, but at least the data can probably be reused for
>> studying other protocols.
>>
>> ## 9. Insurances
>>
>> Of course, given it's all hacks and workarounds and there is no good answer to "what is a reasonable
>> feerate up to which we need to make contracts enforceable onchain?", there is definitely room for an
>> insurance market. But this enters the realm of opinions. Although i do have some (having discussed
>> this topic for the past years with different people), i would like to keep this post focused on the
>> technical aspects of this problem.
>>
>> [0] As far as i can tell, having offchain contracts be enforceable onchain by confirming a
>> transaction before the expiration of a timelock is a widely agreed-upon approach. And i don't think
>> we can opt for any other fundamentally different one, as you want to know you can claim back your
>> coins from a contract after a deadline before taking part in it.
>>
>> [1] The Real Revault (tm) involves more transactions, but for the sake of conciseness i only
>> detailed a minimum instance of the problem.
>>
>> [2] Only presigning part of the Unvault transactions allows to only delegate part of the coins,
>> which can be abstracted as "delegate x% of your stash" in the user interface.
>>
>> [3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017835.html
>>
>> [4] https://github.com/revault/research/blob/1df953813708287c32a15e771ba74957ec44f354/feebumping/model/statemachine.py#L323-L329
>>
>> [5] https://github.com/bitcoin/bitcoin/pull/23121
>>
>> [6] https://github.com/revault/research/blob/1df953813708287c32a15e771ba74957ec44f354/feebumping/model/statemachine.py#L494-L507
>>
>> [7] Of course this assumes a combinatorial coin selection, but i believe it's ok given we limit the
>> number of coins beforehand.
>>
>> [8] Although there is the argument to outbid a censorship, anyone censoring you isn't necessarily a
>> miner.
>>
>> [9] https://www.statoshi.info/
>>
>> [10] https://www.statoshi.info/
>>
>> [11] https://github.com/RCasatta/blocks_iterator
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211130/79715fe8/attachment-0001.html>;

📅 Original date posted:2021-11-29 📝 Original message:Hi ...

2023-06-07T23:00:43Z

In reply to nevent1q…tvkp
_________________________

📅 Original date posted:2021-11-29
📝 Original message:Hi everyone,

Fee-bumping is paramount to the security of many protocols building on Bitcoin, as they require the
confirmation of a transaction (which might be presigned) before the expiration of a timelock at any
point after the establishment of the contract.

The part of Revault using presigned transactions (the delegation from a large to a smaller multisig)
is no exception. We have been working on how to approach this for a while now and i'd like to share
what we have in order to open a discussion on this problem so central to what seem to be The Right
Way [0] to build on Bitcoin but which has yet to be discussed in details (at least publicly).

I'll discuss what we came up with for Revault (at least for what will be its first iteration) but my
intent with posting to the mailing list is more to frame the questions to this problem we are all
going to face rather than present the results of our study tailored to the Revault usecase.
The discussion is still pretty Revault-centric (as it's the case study) but hopefully this can help
future protocol designers and/or start a discussion around what everyone's doing for existing ones.

## 1. Reminder about Revault

The part of Revault we are interested in for this study is the delegation process, and more
specifically the application of spending policies by network monitors (watchtowers).
Coins are received on a large multisig. Participants of this large multisig create 2 [1]
transactions. The Unvault, spending a deposit UTxO, creates an output paying either to the small
multisig after a timelock or to the large multisig immediately. The Cancel, spending the Unvault
output through the non-timelocked path, creates a new deposit UTxO.
Participants regularly exchange the Cancel transaction signatures for each deposit, sharing the
signatures with the watchtowers they operate. They then optionally [2] sign the Unvault transaction
and share the signatures with the small multisig participants who can in turn use them to proceed
with a spending. Watchtowers can enforce spending policies (say, can't Unvault outside of business
hours) by having the Cancel transaction be confirmed before the expiration of the timelock.

## 2. Problem statement

For any delegated vault, ensure the confirmation of a Cancel transaction in a configured number of
blocks at any point. In so doing, minimize the overpayments and the UTxO set footprint. Overpayments
increase the burden on the watchtower operator by increasing the required frequency of refills of the
fee-bumping wallet, which is already the worst user experience. You are likely to manage a number of
UTxOs with your number of vaults, which comes at a cost for you as well as everyone running a full
node.

Note that this assumes miners are economically rationale, are incentivized by *public* fees and that
you have a way to propagate your fee-bumped transaction to them. We also don't consider the block
space bounds.

In the previous paragraph and the following text, "vault" can generally be replaced with "offchain
contract".

## 3. With presigned transactions

As you all know, the first difficulty is to get to be able to unilaterally enforce your contract
onchain. That is, any participant must be able to unilaterally bump the fees of a transaction even
if it was co-signed by other participants.

For Revault we can afford to introduce malleability in the Cancel transaction since there is no
second-stage transaction depending on its txid. Therefore it is pre-signed with ANYONECANPAY. We
can't use ANYONECANPAY|SINGLE since it would open a pinning vector [3]. Note how we can't leverage
the carve out rule, and neither can any other more-than-two-parties contract.
This has a significant implication for the rest, as we are entirely burning fee-bumping UTxOs.

This opens up a pinning vector, or at least a significant nuisance: any other party can largely
increase the absolute fee without increasing the feerate, leveraging the RBF rules to prevent you
from replacing it without paying an insane fee. And you might not see it in your own mempool and
could only suppose it's happening by receiving non-full blocks or with transactions paying a lower
feerate.
Unfortunately i know of no other primitive that can be used by multi-party (i mean, >2) presigned
transactions protocols for fee-bumping that aren't (more) vulnerable to pinning.

## 4. We are still betting on future feerate

The problem is still missing one more constraint. "Ensuring confirmation at any time" involves ensuring
confirmation at *any* feerate, which you *cannot* do. So what's the limit? In theory you should be ready
to burn as much in fees as the value of the funds you want to get out of the contract. So... For us
it'd mean keeping for each vault an equivalent amount of funds sitting there on the watchtower's hot
wallet. For Lightning, it'd mean keeping an equivalent amount of funds as the sum of all your
channels balances sitting there unallocated "just in case". This is not reasonable.

So you need to keep a maximum feerate, above which you won't be able to ensure the enforcement of
all your contracts onchain at the same time. We call that the "reserve feerate" and you can have
different strategies for choosing it, for instance:
- The 85th percentile over the last year of transactions feerates
- The maximum historical feerate
- The maximum historical feerate adjusted in dollars (makes more sense but introduces a (set of?)
trusted oracle(s) in a security-critical component)
- Picking a random high feerate (why not? It's an arbitrary assumption anyways)

Therefore, even if we don't have to bet on the broadcast-time feerate market at signing time anymore
(since we can unilaterally bump), we still need some kind of prediction in preparation of making
funds available to bump the fees at broadcast time.
Apart from judging that 500sat/vb is probably more reasonable than 10sat/vbyte, this unfortunately
sounds pretty much crystal-ball-driven.

We currently use the maximum of the 95th percentiles over 90-days windows over historical block chain
feerates. [4]

## 5. How much funds does my watchtower need?

That's what we call the "reserve". Depending on your reserve feerate strategy it might vary over
time. This is easier to reason about with a per-contract reserve. For Revault it's pretty
straightforward since the Cancel transaction size is static: `reserve_feerate * cancel_size`. For
other protocols with dynamic transaction sizes (or even packages of transactions) it's less so. For
your Lightning channel you would probably take the maximum size of your commitment transaction
according to your HTLC exposure settings + the size of as many `htlc_success` transaction?

Then you either have your software or your user guesstimate how many offchain contracts the
watchtower will have to watch, time that by the per-contract reserve and refill this amount (plus
some slack in practice). Once again, a UX tradeoff (not even mentioning the guesstimation UX):
overestimating leads to too many unallocated funds sitting on a hot wallet, underestimating means
(at best) inability to participate in new contracts or being "at risk" (not being able to enforce
all your contracts onchain at your reserve feerate) before a new refill.

For vaults you likely have large-value UTxOs and small transactions (the Cancel is one-in one-out in
Revault). For some other applications with large transactions and lower-value UTxOs on average it's
likely that only part of the offchain contracts might be enforceable at a reasonable feerate. Is it
reasonable?

## 6. UTxO pool layout

Now that you somehow managed to settle on a refill amount, how are you going to use these funds?
Also, you'll need to manage your pool across time (consolidating small coins, and probably fanning
out large ones).

You could keep a single large UTxO and peel it as you need to sponsor transactions. But this means
that you need to create a coin of a specific value according to your need at the current feerate
estimation, hope to have it confirmed in a few blocks (at least for now! [5]), and hope that the
value won't be obsolete by the time it confirmed. Also, you'd have to do that for any number of
Cancel, chaining feebump coin creation transactions off the change of the previous ones or replacing
them with more outputs. Both seem to become really un-manageable (and expensive) in many edge-cases,
shortening the time you have to confirm the actual Cancel transaction and creating uncertainty about
the reserve (how much is my just-in-time fanout going to cost me in fees that i need to refill in
advance on my watchtower wallet?).
This is less of a concern for protocols using CPFP to sponsor transactions, but they rely on a
policy rule specific to 2-parties contracts.

Therefore for Revault we fan-out the coins per-vault in advance. We do so at refill time so the
refiller can give an excess to pay for the fees of the fanout transaction (which is reasonable since
it will occur just after the refilling transaction confirms). When the watchtower is asked to watch
for a new delegated vault it will allocate coins from the pool of fanned-out UTxOs to it (failing
that, it would refuse the delegation).
What is a good distribution of UTxOs amounts per vault? We want to minimize the number of coins,
still have coins small enough to not overpay (remember, we can't have change) and be able to bump a
Cancel up to the reserve feerate using these coins. The two latter constraints are directly in
contradiction as the minimal value of a coin usable at the reserve feerate (paying for its own input
fee + bumping the feerate by, say, 5sat/vb) is already pretty high. Therefore we decided to go with
two distributions per vault. The "reserve distribution" alone ensures that we can bump up to the
reserve feerate and is usable for high feerates. The "bonus distribution" is not, but contains
smaller coins useful to prevent overpayments during low and medium fee periods (which is most of the
time).
Both distributions are based on a basic geometric suite [6]. Each value is half the previous one.
This exponentially decreases the value, limiting the number of coins. But this also allows for
pretty small coins to exist and each coin's value is equal to the sum of the smaller coins,
or smaller by at most the value of the smallest coin. Therefore bounding the maximum overpayment to
the smallest coin's value [7].

For the management of the UTxO pool across time we merged the consolidation with the fanout. When
fanning out a refilled UTxO, we scan the pool for coins that need to be consolidated according to a
heuristic. An instance of a heuristic is "the coin isn't allocated and would not have been able to
increase the fee at the median feerate over the past 90 days of blocks".
We had this assumption that feerate would tend to go up with time and therefore discarded having to
split some UTxOs from the pool. We however overlooked that a large increase in the exchange price of
BTC as we've seen during the past year could invalidate this assumption and that should arguably be
reconsidered.

## 7. Bumping and re-bumping

First of all, when to fee-bump? At fixed time intervals? At each block connection? It sounds like,
given a large enough timelock, you could try to greed by "trying your luck" at a lower feerate and
only re-bumping every N blocks. You would then start aggressively bumping at every block after M
blocks have passed. But that's actually a bet (in disguised?) that the next block feerate in M blocks
will be lower than the current one. In the absence of any predictive model it is more reasonable to
just start being aggressive immediately.
You probably want to base your estimates on `estimatesmartfee` and as a consequence you would re-bump
(if needed )after each block connection, when your estimates get updated and you notice your
transaction was not included in the block.

In the event that you notice a consequent portion of the block is filled with transactions paying
less than your own, you might want to start panicking and bump your transaction fees by a certain
percentage with no consideration for your fee estimator. You might skew miners incentives in doing
so: if you increase the fees by a factor of N, any miner with a fraction larger than 1/N of the
network hashrate now has an incentive to censor your transaction at first to get you to panic. Also
note this can happen if you want to pay the absolute fees for the 'pinning' attack mentioned in
section #2, and that might actually incentivize miners to perform it themselves..

The gist is that the most effective way to bump and rebump (RBF the Cancel tx) seems to just be to
consider the `estimatesmartfee 2 CONSERVATIVE` feerate at every block your tx isn't included in, and
to RBF it if the feerate is higher.
In addition, we fallback to a block chain based estimation when estimates aren't available (eg if
the user stopped their WT for say a hour and we come back up): we use the 85th percentile over the
feerates in the last 6 blocks. Sure, miners can try to have an influence on that by stuffing their
blocks with large fee self-paying transactions, but they would need to:
1. Be sure to catch a significant portion of the 6 blocks (at least 2, actually)
2. Give up on 25% of the highest fee-paying transactions (assuming they got the 6 blocks, it's
proportionally larger and incertain as they get less of them)
3. Hope that our estimator will fail and we need to fall back to the chain-based estimation

## 8. Our study

We essentially replayed the historical data with different deployment configurations (number of
participants and timelock) and probability of an event occurring (event being say an Unvault, an
invalid Unvault, a new delegation, ..). We then observed different metrics such as the time at risk
(when we can't enforce all our contracts at the reserve feerate at the same time), or the
operational cost.
We got the historical fee estimates data from Statoshi [9], Txstats [10] and the historical chain
data from Riccardo Casatta's `blocks_iterator` [11]. Thanks!

The (research-quality..) code can be found at https://github.com/revault/research under the section
"Fee bumping". Again it's very Revault specific, but at least the data can probably be reused for
studying other protocols.

## 9. Insurances

Of course, given it's all hacks and workarounds and there is no good answer to "what is a reasonable
feerate up to which we need to make contracts enforceable onchain?", there is definitely room for an
insurance market. But this enters the realm of opinions. Although i do have some (having discussed
this topic for the past years with different people), i would like to keep this post focused on the
technical aspects of this problem.

[0] As far as i can tell, having offchain contracts be enforceable onchain by confirming a
transaction before the expiration of a timelock is a widely agreed-upon approach. And i don't think
we can opt for any other fundamentally different one, as you want to know you can claim back your
coins from a contract after a deadline before taking part in it.

[1] The Real Revault (tm) involves more transactions, but for the sake of conciseness i only
detailed a minimum instance of the problem.

[2] Only presigning part of the Unvault transactions allows to only delegate part of the coins,
which can be abstracted as "delegate x% of your stash" in the user interface.

[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017835.html

[4] https://github.com/revault/research/blob/1df953813708287c32a15e771ba74957ec44f354/feebumping/model/statemachine.py#L323-L329

[5] https://github.com/bitcoin/bitcoin/pull/23121

[6] https://github.com/revault/research/blob/1df953813708287c32a15e771ba74957ec44f354/feebumping/model/statemachine.py#L494-L507

[7] Of course this assumes a combinatorial coin selection, but i believe it's ok given we limit the
number of coins beforehand.

[8] Although there is the argument to outbid a censorship, anyone censoring you isn't necessarily a
miner.

[9] https://www.statoshi.info/

[10] https://www.statoshi.info/

[11] https://github.com/RCasatta/blocks_iterator

📅 Original date posted:2021-10-26 📝 Original message:Hi ...

2023-06-07T23:00:19Z

In reply to nevent1q…lk7s
_________________________

📅 Original date posted:2021-10-26
📝 Original message:Hi Niftynei,

I share the concerns raised about direct connections to mining pools being a centralization pressure: de-anonymization and an inevitable higher barrier to entry. Making it more difficult to reach smaller miners is another one.
Regarding fee estimation you state:
> Initial feerate estimation would need to be based on published blocks, not pending transactions (as this information would no longer be available)
The current fee estimation algorithm uses both, not only the pending transactions (game-able). Although i agree that past-block(s) based fee estimation isn't that bad, it's worth mentioning that not tracking the confirmation time of relayed transactions drops the ability to have a target in the estimation. That is it's good enough for time-sensitive transactions where you always target the next block but not for other usages which usually target a few dozen of blocks in the future.

However, as we discussed recently, i do believe their is a failure mode here. On one hand, directly connecting to pools is already possible today and pretty effective given the current mining centralization. On the other hand, it's not possible for most pre-signed txs protocols to reliably (securely) use the Bitcoin tx relay network today to propagate time-sensitive transactions. Furthermore, even if these are fixed (eg via package-relay for (today's) Lightning Network) it seems like there is a stark contrast between what "L2 [0] protocols" need and what regular node operators can reasonably offer. A node operator is incentivized to relay transactions to:
- have more privacy *if* they use their node to broadcast transactions (make it less distinguishable which relayed transaction comes from the wallet)
- provide fee estimates *if* they need them
- avoid bandwidth spikes on block connection (compact block relay)

L2s would ideally need the tx relaying nodes to do more computation and lift their DOS mitigations for all miner-incentive-compatible transactions to eventually be relayed to most of the miners. One obvious instance of such a dilemma is the RBF rules.
Such protocols getting increasingly developed and used create a strong incentive for their users/stakeholders to directly connect to mining pools [1], with all the consequences for the network mentioned in the replies to your mail and elsewhere.
Before we get to this, i think there is a strong case for an opt-in and publicly accessible "overlay" network to relay miner-incentive compatible transactions with higher DOS limits. This way the cost is not imposed to L1 node runners, and L2s can operate with more safety assumptions without (entirely) falling for centralization.

Thanks for publicly starting this discussion,
Antoine

[0] Using "L2s" for the sake of brevety, whatever it means i mean "protocols using pre-signed Bitcoin transactions which timely confirmation might be a security requirement".
[1] Wen block space insurance contracts

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le mardi 26 octobre 2021 à 4:56 AM, lisa neigut via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> a écrit :

> Hi all,
>
> In a recent conversation with @glozow, I had the realization that the mempool is obsolete and should be eliminated.
>
> Instead, users should submit their transactions directly to mining pools, preferably over an anonymous communication network such as tor. This can easily be achieved by mining pools running a tor onion node for this express purpose (or via a lightning network extension etc)
>
> Mempools make sense in a world where mining is done by a large number of participating nodes, eg where the block template is constructed by a majority of the participants on the network. In this case, it is necessary to socialize pending transaction data to all participants, as you don’t know which participant will be constructing the winning block template.
>
> In reality however, mempool relay is unnecessary where the majority of hashpower and thus block template creation is concentrated in a semi-restricted set.
>
> Removing the mempool would greatly reduce the bandwidth requirement for running a node, keep intentionality of transactions private until confirmed/irrevocable, and naturally resolve all current issues inherent in package relay and rbf rules. It also resolves the recent minimum relay questions, as relay is no longer a concern for unmined transactions.
>
> Provided the number of block template producing actors remains beneath, say 1000, it’d be quite feasible to publish a list of tor endpoints that nodes can independently + directly submit their transactions to. In fact, merely allowing users to select their own list of endpoints to use alternatively to the mempool would be a low effort starting point for the eventual replacement.
>
> On the other hand, removing the mempool would greatly complicate solo mining and would also make BetterHash proposals, which move the block template construction away from a centralized mining pool back to the individual miner, much more difficult. It also makes explicit the target for DoS attacks.
>
> A direct communication channel between block template construction venues and transaction proposers also provides a venue for direct feedback wrt acceptable feerates at the time, which both makes transaction confirmation timelines less variable as well as provides block producers a mechanism for (independently) enforcing their own minimum security budget. In other words, expressing a minimum acceptable feerate for continued operation.
>
> Initial feerate estimation would need to be based on published blocks, not pending transactions (as this information would no longer be available), or from direct interactions with block producers.
>
> ~niftynei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211026/d151987f/attachment.html>;

📅 Original date posted:2021-09-06 📝 Original message:Hi ...

2023-06-07T22:58:41Z

In reply to nevent1q…h6vm
_________________________

📅 Original date posted:2021-09-06
📝 Original message:Hi Jeremy,

I think it would be nice to have and suggested something similar (enforce minimality) in the context of
Miniscript a few months ago [0].

However your code:

const bool seq_is_reserved = (txin.nSequence < CTxIn::SEQUENCE_FINAL-2) && (
// when sequence is set to disabled, it is reserved for future use
((txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0) ||
// when sequence has bits set outside of the type flag and locktime mask,
// it is reserved for future use.
((~(CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG | CTxIn::SEQUENCE_LOCKTIME_MASK) &
txin.nSequence) != 0)
);

Would effectively prevent Lightning Network commitment transactions from relaying. The protocol uses
a hack encoding the commitment transaction numbering in the part of nSequence (and nLockTime)
without consensus meaning. This both sets the LOCKTIME_DISABLE_FLAG and uses bits outside of
the mask.

[0] https://github.com/rust-bitcoin/rust-miniscript/pull/246#issue-671512626
[1] https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#commitment-transaction
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le lundi 6 septembre 2021 à 5:17 AM, Jeremy via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> a écrit :

> BIP 68 says >= 2:This specification defines the meaning of sequence numbers for transactions with an nVersion greater than or equal to 2 for which the rest of this specification relies on.
> BIP-112 says not < 2
> // Fail if the transaction's version number is not set high
> // enough to trigger BIP 68 rules.
> if (static_cast<uint32_t>(txTo->nVersion) < 2) return false;
>
> A further proof that this needs fix: the flawed upgradable semantic exists in script as well as in the transaction nSeqeunce. we can't really control the transaction version an output will be spent with in the future, so it would be weird/bad to change the semantic in transaction version 3.
>
> --
> [@JeremyRubin](https://twitter.com/JeremyRubin)https://twitter.com/JeremyRubin
>
> On Sun, Sep 5, 2021 at 7:36 PM David A. Harding <dave at dtrt.org> wrote:
>
>> On Fri, Sep 03, 2021 at 08:32:19PM -0700, Jeremy via bitcoin-dev wrote:
>>> Hi Bitcoin Devs,
>>>
>>> I recently noticed a flaw in the Sequence lock implementation with respect
>>> to upgradability. It might be the case that this is protected against by
>>> some transaction level policy (didn't see any in policy.cpp, but if not,
>>> I've put up a blogpost explaining the defect and patching it
>>> https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/
>>
>> Isn't this why BIP68 requires using tx.version=2? Wouldn't we just
>> deploy any new nSequence rules with tx.version>2?
>>
>> -Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210906/ff395880/attachment.html>;

📅 Original date posted:2021-06-10 📝 Original message:> ...

2023-06-07T22:54:28Z

In reply to nevent1q…388l
_________________________

📅 Original date posted:2021-06-10
📝 Original message:> Note, I think that the tx mutation proposal relies on interactivity in the worst-case scenario where a counterparty wants to increase its fee-bumping output from the contract balance. This interactivity may lure a counterparty to alway lock the worst-case fee-bumping reserve in the output. I believe anchor output enables more "real-time" fee-bumping reserve adjustment ?

Anchor outputs / malleability allow for real-time adjustment of long-lived contracts (for which the today worst case is much larger than the worst case
estimated at the contract creation time). However it's a really interested for vaults, as you have multiple parties with the same goal (getting this Cancel
transaction confirmed). Therefore you have this slight "tragedy of the commons" of whose fee-bumping wallet is going to pay for sponsoring the next
Cancel (and it's exacerbated by / for external redundancy providers). With this approach, fees are taxed from the shared coins, so there is no pernicious
incentive to delay the broadcast of your revocation transaction in the hope that another watchtower will pay the fee instead of you. I think this applies to
multi-party channels too, by having some kind of a shared budget.

You would also have a large UX improvement with regard to the fee-bumping wallet: no need to have one (fb wallet refills are really *really* poor UX)
one and maintain a nice laid-out UTXO pool.
In the end, both approaches seem desirable: the output for paying most of the fees from shared coins, therefore dwarfing the "tragedy of the common"
concerns, and the malleability to still be able to dynamically allocate more funds to feebump in case of a black swan event (but essentially needs a single
refill at startup as it's never spent from).

As a side note, this can "just" be implemented by exchanging N (varying depending on the granularity) signatures with increasing feerates. Again, this
might be reasonable in some usecases but not others (eg if you are already generating tons of sigs, or have longer chain of unconfirmed transactions).

> Cheers,
> Antoine
>
> [0] Incautious sighash alleability is unsafe. Be careful, otherwise kitties will perish by the thousands :
> https://github.com/revault/practical-revault/pull/83
>
> Le dim. 6 juin 2021 à 22:28, Lloyd Fournier <lloyd.fourn at gmail.com> a écrit :
>
>> Hi Antione,
>>
>> Thanks for bringing up this important topic. I think there might be another class of solutions over input based, CPFP and sponsorship. I'll call them tx mutation schemes. The idea is that you can set a key that can increase the fee by lowering a particular output after the tx is signed without invalidating the signature. The premise is that anytime you need to bump the fee of a transaction you must necessarily have funds in an output that are going to you and therefore you can sacrifice some of them to increase the fee. This is obviously destructive to txids so child presigned transactions will have to use ANYPREVOUT as in your proposal. The advantage is that it does not require keeping extra inputs around to bump the fee.
>>
>> So imagine a new opcode OP_CHECKSIG_MUTATED <output index> <publickey> <value> <signature>.
>> This would check that <signature> is valid against <publickey> if the current transaction had the output at <output index> reduced by <value>. To make this more efficient, if the public key is one byte: 0x02 it references the taproot *external key* (similar to how ANYPREVOUT uses 0x01 to refer to internal key[1]).
>> Now for our protocol we want both parties (p1 and p2) to be able to fee bump a commitment transaction. They use MuSig to sign the commitment tx under the external key with a decent fee for the current conditions. But in case it proves insufficient they have added the following two leaves to their key in the funding output as a backup so that p1 and p2 can unilaterally bump the fee of anything they sign spending from the funding output:
>>
>> 1. OP_CHECKSIG_MUTATED(0, 0x02, <fee-bump-value>, <original-signature>) OP_CHECKSIGADD(p1-fee-bump-key, <p1-fee-bump-signature>) OP_2 OP_NUMEQUALVERIFY
>> 2. OP_CHECKSIG_MUTATED(1, 0x02, <fee-bump-value>, <original-signature>) OP_CHECKSIGADD(p2-fee-bump-key, <p2-fee-bump-signature>) OP_2 OP_NUMEQUALVERIFY
>>
>> where <...> indicates the thing comes from the witness stack.
>> So to bump the fee of the commit tx after it has been signed either party takes the <original-signature> and adds a signature under their fee-bump-key for the new tx and reveals their fee bump leaf. <original-signature> is checked against the old transaction while the fee bumped transaction is checked against the fee bump key.
>>
>> I know I have left out how to change mempool eviction rules to accommodate this kind of fee bumping without DoS or pinning attacks but hopefully I have demonstrated that this class of solutions also exists.
>>
>> [1] https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki
>>
>> Cheers,
>>
>> LL
>>
>> On Fri, 28 May 2021 at 07:13, Antoine Riard via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi,
>>>
>>> This post is pursuing a wider discussion around better fee-bumping strategies for second-layer protocols. It draws out a comparison between input-based and CPFP fee-bumping techniques, and their apparent trade-offs in terms of onchain footprint, tx-relay bandwidth rebroadcast, batching opportunity and mempool flexibility.
>>>
>>> Thanks to Darosior for reviews, ideas and discussions.
>>>
>>> ## Child-Pay-For-Parent
>>>
>>> CPFP is a mature fee-bumping technique, known and used for a while in the Bitcoin ecosystem. However, its usage in contract protocols with distrusting counterparties raised some security issues. As mempool's chain of unconfirmed transactions are limited in size, if any output is spendable by any contract participant, it can be leveraged as a pinning vector to downgrade odds of transaction confirmation [0].
>>>
>>> That said, contract transactions interested to be protected under the carve-out logic require to add a new output for any contract participant, even if ultimately only one of them serves as an anchor to attach a CPFP.
>>>
>>> ## Input-Based
>>>
>>> I think input-based fee-bumping has been less studied as fee-bumping primitive for L2s [1]. One variant of input-based fee-bumping usable today is the leverage of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability flags. If the transaction is the latest stage of the contract, a bumping input can be attached just-in-time, thus increasing the feerate of the whole package.
>>>
>>> However, as of today, input-based fee-bumping doesn't work to bump first stages of contract transactions as it's destructive of the txid, and as such breaks chain of pre-signed transactions. A first improvement would be the deployment of the SIGHASH_ANYPREVOUT softfork proposal. This new malleability flag allows a transaction to be signed without reference to any specific previous output. That way, spent transactions can be fee-bumped without altering validity of the chain of transactions.
>>>
>>> Even assuming SIGHASH_ANYPREVOUT, if the first stage contract transaction includes multiple outputs (e.g the LN's commitment tx has multiple HTLC outputs), SIGHASH_SINGLE can't be used and the fee-bumping input value might be wasted. This edge can be smoothed by broadcasting a preliminary fan-out transaction with a set of outputs providing a range of feerate points for the bumped transaction.
>>>
>>> This overhead could be smoothed even further in the future with more advanced sighash malleability flags like SIGHASH_IOMAP, allowing transaction signers to commit to a map of inputs/outputs [2]. In the context of input-based, the overflowed fee value could be redirected to an outgoing output.
>>>
>>> ## Onchain Footprint
>>>
>>> CPFP: One anchor output per participant must be included in the commitment transaction. To this anchor must be attached a child transaction with 2 inputs (one for the commitment, one for the bumping utxo) and 1 output. Onchain footprint: 2 inputs + 3 outputs.
>>>
>>> Input-based (today): If the bumping utxo is offering an adequate feerate point in function of network mempools congestion at time of broadcast, only 1 input. If a preliminary fan-out transaction to adjust feerate point must be broadcasted first, 1 input and 2 outputs more must be accounted for. Onchain footprint: 2 inputs + 3 outputs.
>>>
>>> Input-based (SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): As long as the bumping utxo's value is wide enough to cover the worst-case of mempools congestion, the bumped transaction can be attached 1 input and 1 output. Onchain footprint: 1 input + 1 output.
>>>
>>> ## Tx-Relay Bandwidth Rebroadcast
>>>
>>> CPFP: In the context of multi-party protocols, we should assume bounded rationality of the participants w.r.t to an unconfirmed spend of the contract utxo across network mempools. Under this assumption, the bumped transaction might have been replaced by a concurrent state. To guarantee efficiency of the CPFP the whole chain of transactions should be rebroadcast, perhaps wasting bandwidth consumption for a still-identical bumped transaction [3]. Rebroadcast footprint: the whole chain of transactions.
>>>
>>> Input-based (today): In case of rebroadcast, the fee-bumping input is attached to the root of the chain of transactions and as such breaks the chain validity in itself. Beyond the rebroadcast of the updated root under replacement policy, the remaining transactions must be updated and rebroadcast. Rebroadcast footprint: the whole chain of transactions.
>>>
>>> Input-based(SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): In case of rebroadcast, the fee-bumping is attached to the root of the chain of transactions but it doesn't break the chain validity in itself. Assuming a future mempool acceptance logic to authorize in-place substitution, the rest of the chain could be preserved. Rebroadcast footprint: the root of the chain of transactions.
>>>
>>> ## Fee-Bumping Batching
>>>
>>> CPFP: In the context of multi-party protocols, in optimistic scenarios, we can assume aggregation of multiple chains of transactions. For e.g, a LN operator is desirous to non-cooperatively close multiple channels at the same time and would like to combine their fee-bumping. With CPFP, one anchor output and one bumping input must be consumed per aggregated chain, even if the child transaction fields can be shared. Batching perf: 1 input/1 output per aggregated chain.
>>>
>>> Input-based (today): Unless the contract allows interactivity, multiple chains of transactions cannot be aggregated. One bumping input must be attached per chain, though if a preliminary fan-out transaction is relied on to offer multiple feerate points, transaction fields can be shared. Batching perf: 1 input/1 output per aggregated chain.
>>>
>>> Input-based (SIGHASH_ANYPREVOUT+SIGHASH_IOMAP): Multiple chains of transactions might be aggregated together *non-interactively*. One bumping input and outgoing output can be attached to the aggregated root. Batching perf: 1 input/1 output per aggregation.
>>>
>>> ## Fee-Bumping Mempool Flexibility
>>>
>>> CPFP: In the context of multi-party protocols, one of your counterparties might build a branch of transactions from one of the root outputs thus saturating the in-mempool package limits. To avoid these shenanigans, LN channels are relying on the carve-out mechanism. Though, the carve-out mechanism includes its own limitation and doesn't scale beyond 2 contract participants.
>>>
>>> Input-based: The root of the chain of transaction is the package's oldest ancestor, so package limits don't restrain its acceptance and it works whatever the number of contract participants.
>>>
>>> To conclude, this post scores 2 fee-bumping primitives for multi-party protocols on a range of factors. It hopes to unravel the ground for a real feerate performance framework of second-layers protocols .
>>>
>>> Beyond that, few points can be highlighted a) future soft forks allow significant onchain footprint savings, especially in case of batching, b) future package relay bandwidth efficiency should account for rebroadcast frequency of CPFPing multi-party protocols. On this latter point one follow-up might be to evaluate differing package relay *announcement* schemes in function of odds of non-cooperative protocol broadcast/odds of concurrent broadcast/rebroadcast frequencies.
>>>
>>> Thoughts ?
>>>
>>> Cheers,
>>> Antoine
>>>
>>> [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html
>>> [1] Beyond the revault architecture : https://github.com/revault/practical-revault/blob/master/revault.pdf
>>> [2] Already proposed a while back : https://bitcointalk.org/index.php?topic=252960.0
>>> [3] In theory, an already-relayed transaction shouldn't pass Core's `filterInventoryKnown`. In practice, if the transaction is announced as part of a package_id, the child might have changed, not the parent, leading to a redundant relay of the latter.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210610/71c247b4/attachment-0001.html>;

📅 Original date posted:2021-06-10 📝 Original message:Hi, ...

2023-06-07T22:54:26Z

In reply to nevent1q…jmvn
_________________________

📅 Original date posted:2021-06-10
📝 Original message:Hi,

Another thing to consider when comparing these two techniques is anti-fee sniping protection. If you are going to feebump directly
your revocation transaction by adding inputs to it, the nLockTime has already been signed in advance. Therefore your are sponsoring
a transaction that could be included in any reorged block.

This is not a big deal for now but i'm concerned it may become one, especially since this type of transaction might be the highest fee-paying
ones on the network (there is a lot at stake). Having a new sighash type not masking the nLockTime so that it can be set by the feebumper
could help with this, even though the presumably low pre-signed fee can still be snipped (since the ALL signature is added to the feebump inputs).

The recent BIP proposal by Chris Belcher [0] also just uncovered (to me) a new hack: if the feebumping coins are less than 65,535 blocks old, we
could also set the nSequence of these coins to achieve the same purpose [1]. And this can be done with today's Bitcoin!

Antoine P.

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019048.html
[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002412.html
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le vendredi 28 mai 2021 à 6:13 AM, Antoine Riard <antoine.riard at gmail.com> a écrit :

>> Unfortunately, ACP | SINGLE is trivially pinable [0] (TL;DR: i can just attach an output paying immediately to me, and construct a tx chain spending it). We are using ACP | ALL for Revault,
>> which is the reason why we need a well laid-out pool of fee-bumping UTXOs (as you need to consume them entirely).
>
> Oh yes, I should have mentioned this pinning vector. The witnessScript I've in mind to make secure that type of chain of transactions would be one MuSig key for all contract participants, where signature are committed with SIGHASH_ANYPREVOUT | SIGHASH_IOMAP, one pubkey per participant to lockdown the transaction with SIGHASH_ALL. I think it works and prevents malicious in-flight attachment of input/output to a multi-party transaction ?
>
>> I believe that it's better to broadcast a single fan-out transaction creating your entire UTXO pool in advance. You could create one coin per contract you are watching which value would be
>> used to bump your transaction feerate from the presigned one to -say- the average feerate over the past month, and then have smaller coins that you could attach to any transaction to bump
>> by a certain threshold (say, 10sat/vbyte). You would create as many small coin as your reserve algorithm tells you (which could be "i need to be able, worst case, to close all my contracts
>> with the worst historical feerate." or (fractional reserve version) "i need to be able, worst case, to close 10% of my contracts at the average feerate of the past year, the remaining ones sorry
>> for my loss"). [1]
>
>> This method is both much more optimal (though you need to sometimes incur the cost of many small additional inputs) and also makes sure that your feebump does not depend on the confirmation of a first stage transaction (as you can only RBF with new inputs if they are confirmed).
>
> I see, so you spread your bumping UTXO pool in two ranges : at least one bumping utxo per contract, and a subpool of emergency smaller coins, ready to be attached on any contract. I think this strategy makes sense for vaults as you can afford a bunch of small coins at different feerates, spending the ones not used afterwards. And higher cells of feerate reserve as the worst historical feerate are relatively not that much compared to locked-in vaults value. That said, I'm more dubious about LN, where node operators might not keep the worst-case fee-bumping reserve, as the time value of the coins aren't worth the channel liquidity at stake.
>
>> Why not just attaching it at the tail of the chain? Bumping the last child with additional input would effectively be a CPFP for the entire chain in this case.
>
> Yes, input-based bumping targeting the tail of the chain works at the transaction level. But if you assume bounded visibility of network mempools, one of your counterparties might have broadcast a concurrent state, thus making your CPFP irrelevant for propagation. Though smarter tx-relay techniques such as "attach-on-contract-utxo-root" CPFP (or also known as "blinded CPFP") might solve this issue.
>
> Le jeu. 27 mai 2021 à 17:45, darosior <darosior at protonmail.com> a écrit :
>
>> Hi,
>>
>>> ## Input-Based
>>>
>>> I think input-based fee-bumping has been less studied as fee-bumping primitive for L2s [1]. One variant of input-based fee-bumping usable today is the leverage of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability flags. If the transaction is the latest stage of the contract, a bumping input can be attached just-in-time, thus increasing the feerate of the whole package.
>>
>> Unfortunately, ACP | SINGLE is trivially pinable [0] (TL;DR: i can just attach an output paying immediately to me, and construct a tx chain spending it). We are using ACP | ALL for Revault,
>> which is the reason why we need a well laid-out pool of fee-bumping UTXOs (as you need to consume them entirely).
>>
>>> Input-based (today): If the bumping utxo is offering an adequate feerate point in function of network mempools congestion at time of broadcast, only 1 input. If a preliminary fan-out transaction to adjust feerate point must be broadcasted first, 1 input and 2 outputs more must be accounted for. Onchain footprint: 2 inputs + 3 outputs.
>>
>> I believe that it's better to broadcast a single fan-out transaction creating your entire UTXO pool in advance. You could create one coin per contract you are watching which value would be
>> used to bump your transaction feerate from the presigned one to -say- the average feerate over the past month, and then have smaller coins that you could attach to any transaction to bump
>> by a certain threshold (say, 10sat/vbyte). You would create as many small coin as your reserve algorithm tells you (which could be "i need to be able, worst case, to close all my contracts
>> with the worst historical feerate." or (fractional reserve version) "i need to be able, worst case, to close 10% of my contracts at the average feerate of the past year, the remaining ones sorry
>> for my loss"). [1]
>>
>> This method is both much more optimal (though you need to sometimes incur the cost of many small additional inputs) and also makes sure that your feebump does not depend on the confirmation
>> of a first stage transaction (as you can only RBF with new inputs if they are confirmed).
>>
>>> Input-based (today): In case of rebroadcast, the fee-bumping input is attached to the root of the chain of transactions and as such breaks the chain validity in itself. Beyond the rebroadcast of the updated root under replacement policy, the remaining transactions must be updated and rebroadcast. Rebroadcast footprint: the whole chain of transactions.
>>
>> Why not just attaching it at the tail of the chain? Bumping the last child with additional input would effectively be a CPFP for the entire chain in this case.
>>
>> Thanks for starting this discussion :)
>> Antoine
>>
>> [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017835.html
>> [1] Credits to Jacob Swambo, who came up with the single fan-out transaction and with whom i'm discussing how to practically apply these ideas to Revault.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210610/f17a3b66/attachment-0001.html>;

📅 Original date posted:2021-05-28 📝 Original message:> ...

2023-06-07T22:54:10Z

In reply to nevent1q…a4un
_________________________

📅 Original date posted:2021-05-28
📝 Original message:> Oh yes, I should have mentioned this pinning vector. The witnessScript I've in mind to make secure that type of chain of transactions would be one MuSig key for all contract participants, where signature are committed with SIGHASH_ANYPREVOUT | SIGHASH_IOMAP, one pubkey per participant to lockdown the transaction with SIGHASH_ALL. I think it works and prevents malicious in-flight attachment of input/output to a multi-party transaction ?

So something like `or(and(pk(FB),pk(A)),and(pk(FB),pk(B)),and(pk(FB),pk(C)))` with each `or` in their own leaf? I think it works, but only if the keys `A`, `B`, `C` are "hot", as in available to the
fee-bumper. For Revault it means introducing a key for each watchtower in the vaults descriptors, which is meh but technically feasible since they are identified. This kinda break our replication
model though. On the other end for Lightning... You'd need to know what watchtower (or your node) is going to be willing to feebump? The descriptor can very quickly get very convoluted:
`or(and(pk(FB),pk(A_NODE)),and(pk(FB),pk(A_WT1)),and(pk(FB),pk(A_WT2)),and(pk(FB),pk(B_NODE)),and(pk(FB),pk(B_WT1)),and(pk(FB),pk(B_WT2)))` for only 2 participants in a channel
where one of either the node or two watchtowers (identified beforehand !!) can feebump.

> I see, so you spread your bumping UTXO pool in two ranges : at least one bumping utxo per contract, and a subpool of emergency smaller coins, ready to be attached on any contract. I think this strategy makes sense for vaults as you can afford a bunch of small coins at different feerates, spending the ones not used afterwards. And higher cells of feerate reserve as the worst historical feerate are relatively not that much compared to locked-in vaults value. That said, I'm more dubious about LN, where node operators might not keep the worst-case fee-bumping reserve, as the time value of the coins aren't worth the channel liquidity at stake.

Yes. That's a bit concerning, but i guess it's a tradeoff. Amusingly the incentive is at odds with routing: you want to keep your channels unbalanced if you run on fractional fee-bumping reserves
so that if things go south you can still salvage most of your funds by focusing your fee-bumping on the unbalanced (to you) channels :p .

> Yes, input-based bumping targeting the tail of the chain works at the transaction level. But if you assume bounded visibility of network mempools, one of your counterparties might have broadcast a concurrent state, thus making your CPFP irrelevant for propagation. Though smarter tx-relay techniques such as "attach-on-contract-utxo-root" CPFP (or also known as "blinded CPFP") might solve this issue.

Oh, yes, good point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210528/e838d90f/attachment.html>;

📅 Original date posted:2021-05-27 📝 Original message:Hi, ...

2023-06-07T22:54:09Z

In reply to nevent1q…qg59
_________________________

📅 Original date posted:2021-05-27
📝 Original message:Hi,

> ## Input-Based
>
> I think input-based fee-bumping has been less studied as fee-bumping primitive for L2s [1]. One variant of input-based fee-bumping usable today is the leverage of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability flags. If the transaction is the latest stage of the contract, a bumping input can be attached just-in-time, thus increasing the feerate of the whole package.

Unfortunately, ACP | SINGLE is trivially pinable [0] (TL;DR: i can just attach an output paying immediately to me, and construct a tx chain spending it). We are using ACP | ALL for Revault,
which is the reason why we need a well laid-out pool of fee-bumping UTXOs (as you need to consume them entirely).

> Input-based (today): If the bumping utxo is offering an adequate feerate point in function of network mempools congestion at time of broadcast, only 1 input. If a preliminary fan-out transaction to adjust feerate point must be broadcasted first, 1 input and 2 outputs more must be accounted for. Onchain footprint: 2 inputs + 3 outputs.

I believe that it's better to broadcast a single fan-out transaction creating your entire UTXO pool in advance. You could create one coin per contract you are watching which value would be
used to bump your transaction feerate from the presigned one to -say- the average feerate over the past month, and then have smaller coins that you could attach to any transaction to bump
by a certain threshold (say, 10sat/vbyte). You would create as many small coin as your reserve algorithm tells you (which could be "i need to be able, worst case, to close all my contracts
with the worst historical feerate." or (fractional reserve version) "i need to be able, worst case, to close 10% of my contracts at the average feerate of the past year, the remaining ones sorry
for my loss"). [1]

This method is both much more optimal (though you need to sometimes incur the cost of many small additional inputs) and also makes sure that your feebump does not depend on the confirmation
of a first stage transaction (as you can only RBF with new inputs if they are confirmed).

> Input-based (today): In case of rebroadcast, the fee-bumping input is attached to the root of the chain of transactions and as such breaks the chain validity in itself. Beyond the rebroadcast of the updated root under replacement policy, the remaining transactions must be updated and rebroadcast. Rebroadcast footprint: the whole chain of transactions.

Why not just attaching it at the tail of the chain? Bumping the last child with additional input would effectively be a CPFP for the entire chain in this case.

Thanks for starting this discussion :)
Antoine

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017835.html
[1] Credits to Jacob Swambo, who came up with the single fan-out transaction and with whom i'm discussing how to practically apply these ideas to Revault.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210527/a0939895/attachment-0001.html>;

📅 Original date posted:2021-05-09 📝 Original message:Hi ...

2023-06-07T22:52:31Z

In reply to nevent1q…nhj4
_________________________

📅 Original date posted:2021-05-09
📝 Original message:Hi Antoine,

Thank you for the disclosure.

> * Onchain DLC/Coinswap/Vault : Those contract protocols have also multiple stages of execution with time-sensitive transactions opening the way to pinning attacks. Those protocols being non-deployed or in early phase, I would recommend that any in-protocol competing transactions explicitly signal RBF.

For what it's worth, Revault isn't vulnerable as all transactions signal RBF and there is no way to sneak a non-signaling competing transaction (as long as the CSV isn't matured yet).

Thanks,

Antoine (the other one)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210509/73a6d27f/attachment-0001.html>;

📅 Original date posted:2021-01-17 📝 Original message:Hi ...

2023-06-07T18:28:14Z

In reply to nevent1q…mflj
_________________________

📅 Original date posted:2021-01-17
📝 Original message:Hi Antoine, and Kevin,

>> * Proposed improvement: The HW should display the Bitcoin Script itself when possible (including the unlock conditions).
>
> What level of script literacy are you assuming on your users ? I can see enterprise/hobbyist folks to know enough of Script to understand the intended behavior but I don't think that's a reasonable assumption for your average user. Of course, Miniscript Policy makes things easier, but IMHO, I still hope to see some mature, higher-level language (e.g Ivy) to ease script semantic understanding and thus widen the crowd of users.

No Script literacy should be assumed. I believe with Miniscript Policy (with possibly alias instead of pubkeys, see below) we are to the highest possible level of abstraction
without loss of meaning for user verification. I don't think Ivy would be helpful here.
Also, as Kevin mentioned, anything would be better than an address anyways.

> Further, I would do a bit on UX research on the correctness model expected by your users. I.e if they fail to verify accordingly, are they losing funds, transaction doesn't confirm, transaction doesn't even propagate, etc. You should also make assumptions on the mental resources you're required from them. Time-sensitive L2 protocols have a wide scope to check, e.g not verifying the nSequence/nLocktime fields can provoke funds failures.

Regarding the correctness, with the OP threat model (laptop compromised), for any transaction: if they fail to verify the locking policy, fund loss.
Re nSeq: If we trust the HM, and the HM support Miniscript, it must be able to satisfy inputs in a sa[n,f]e way.

>> This applies to pre-signed transaction protocols especially well as the template of these transactions could be known
> and recognized by the HW. Typically for Revault, the HW could display: "Unvault Transaction, all expected pubkeys
> present in the script".
>
> In the future, I would expect templates of high-security protocols like vaults to be part of the trusted computing base of any decent HW. I think good standards there would avoid HW vendors to come with some kind of certified-templates scheme and thus having to bless custom scripts of every vaults implementations.

+1

>> Then there is PSBT support and the maximum transaction size limit for
> these: we need more transparency from HW manufacturers on their li
> mitations.
>
> I understand them, Script is full of subtleties, taproot is likely to have more of them and if you take sighash malleability that's not something you want your average user to play with. Maybe it
> would be better to come up with a first wave of script features on which you expect transparency ? For sure, OP_CSV is a good candidate.

I agree that rather than supporting all of Script it would be better to support a "safe", analyzable subset of Script: that's Miniscript :p
I also believe supporting any new Script capabilities without Miniscript would be a huge footgun. It would also ease the upgrade to Tapscript.

>> Once any input of a (pre-signed)transaction is
> spent, this transaction isn't valid anymore. Most pre-signed transactions protocols are used today as a form of defense
> mechanism, spending any input would mean incapacitating the entire defense mechanism.
>
> I don't see the exact issue here. E.g in Lightning, even if you pre-sign a justice transaction punishing every revokeable outputs on counterparty transaction, and one input is spent, will current HWs prevent you to-resign an updated justice transaction ?

That's because in Revault we don't require HMs for watchtowers. Funds holders are expected to have a routine signing of cancel / deterrent / unvault transactions
and share them with the watchtowers. The attack Kevin is talking about is a (expected-to-be-stateless) HM will happily sign a cancel of deterrent transaction that
spends an already-signed input. So let's say a fund holder sends a signature for an Unvault tx and a Cancel tx that does not spend this Unvault to their watchtower.
The watchtower would cringe (in our v0 protocol, send an NACK): but the NACK isn't handled by the HM therefore at the end of the day the already-compromised laptop
is ensuring the (statefull) validity of the signature.

Thanks,
Antoine

> Le jeu. 14 janv. 2021 à 13:46, Kevin Loaec via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> a écrit :
>
>> Hello everyone,
>>
>> I would like to start a discussion on improving Hardware Wallets.
>>
>> My approach to this right now is from a vault protocol we are developing (Revault, [1]), and its Hardware Wallet
>> requirements. I started working on a Github Issue in our repo [2], other people recommended us to do a more general
>> discussion on the mailing list instead as it could benefit many other protocols and users.
>> This email discusses improvements that would benefit everyone, and some that are more suitable for "layer 2" or pre-
>> signed transactions protocols.
>> The goal is to spark discussions and hopefully iterate to a more secure and more usable hardware ecosystem for all
>> bitcoiners.
>> While I mainly foresee issues/improvements that may affect Revault, I would be really happy to see people joining this
>> thread with any other ideas and remarks that would benefit some parts of Bitcoin that I overlooked.
>>
>> Prior work on similar problematics:
>> ===================================
>> - ZmnSCPx
>> j: [Lightning-dev] Speculations on hardware wallet support for Lightning [3]
>> - mflaxman: Known Issues: Verifying a Receive Address [4]
>> - ksedgwic and devrandom01: Lightning-signer [5]
>> - benma: How nearly all personal hardware wallet multisig setups are insecure [6]
>>
>> The postulate we start from is that Hardware Wallets (HW) are useful to mitigate the compromission of the day-to-day
>> device of a user. They mainly prevent private-key extraction today, and aren't very suitable against an attack on the
>> transaction being signed, as explained further.
>> To make this discussion security-focused, let's assume the general purpose device (laptop, for example) is compromised
>> with a malware implanted by an attacker, capable of modifying PSBTs, displayed addresses, etc.
>>
>> Our study so far:
>>
>> Output Script Parsing:
>> ======================
>> Problem: A typical HW today would display the "destination" of a transaction in the form of a bitcoin address. A user
>> would generally compare this wit
>> h the address displayed on his laptop screen... which might have been compromised
>> already. The correct usage would be for a user to verify this address on a third device (mobile phone, for example).
>> This is weak security and bad user experience.
>> Proposed improvement: The HW should display the Bitcoin Script itself when possible (including the unlock conditions).
>> The best way to do so would be to lift this Script to a more user-friendly format such as a MiniScript Policy display,
>> but anything would be better than an "address".
>> This applies to pre-signed transaction protocols especially well as the template of these transactions could be known
>> and recognized by the HW. Typically for Revault, the HW could display: "Unvault Transaction, all expected pubkeys
>> present in the script".
>>
>> Pubkey Interpretation:
>> ======================
>> Problem: currently HW cannot "identify" addresses or keys.
>> Proposed improvement: The HW could know pubkeys or xpubs it does not hold the private keys
>> for, and display a label (or
>> understand it for logic reasons, such as "expected pubkeys" as the previous example). Going further, the xpubs could be
>> aliased the first time they are entered/verified (as part of, say, an initial setup ceremony) for instance with the
>> previously mentioned Miniscript policy: or(pk(Alice), and(pk(Bob), after(42))).
>> This should be done in the Secure Element if possible to avoid physical compromission, but would be a strong improvement
>> versus a day-to-day laptop in any case.
>>
>> Better Bitcoin Compatibility:
>> =============================
>> Problem: most HW cannot interpret some Script OPs such as OP_CSV, or any conditional outputs. This is a major issue for
>> anyone using Bitcoin "advanced" features. Related to this are the Sighash flags: most HW do not support most Sighash
>> flags. Kind of annoying for a signing device. Then there is PSBT support and the maximum transaction size limit for
>> these: we need more transparency from HW manufacturers on their li
>> mitations.
>> Solution: Make Bitcoin HW actually compatible with Bitcoin :D
>>
>> Inputs (mainly for pre-signed Tx):
>> ==================================
>> Problem: Poisoned inputs are a major risk for HW as they don't know the UTXO set. While this can be exploited for fee
>> attacks, it is a bigger threat to pre-signed transactions protocols. Once any input of a (pre-signed)transaction is
>> spent, this transaction isn't valid anymore. Most pre-signed transactions protocols are used today as a form of defense
>> mechanism, spending any input would mean incapacitating the entire defense mechanism.
>> Proposed improvement: for protocols that requires it, keeping track of inputs already signed once would be extremely
>> helpful. Going further, most of these protocols require to follow a specific signing order (typically the "clawback"
>> first, then the regular spend path) so adding a way to check that a "clawback" has been signed first, with the same
>> input, would be very helpful. All of this on the dev
>> ice itself.
>>
>> I understand some of these changes may be very difficult, especially given the low memory and computational power of
>> secure elements. However I truly believe most of these points are a MUST have for any decent security. If you don't
>> assume the computer on which the transaction is crafted is compromised, then you don't need a hardware wallet. If you
>> assume it may be compromised, then the HW needs to be able to defend against those.
>>
>> Revault does not plan on building hardware wallets, we hope existing and upcoming manufacturers will implement a strong
>> security that we could use for the Revault protocol users. Vault users will likely hold very large sums and would be
>> happy to pay a high premium for more secure HW. This will hopefully encourage existing players to keep on improving
>> their devices and that will ultimately benefit us all.
>>
>> Feel free to reply with your comments or adding suggestions, I am not a hardware wallet expert and would take criticism
>> wit
>> hout being offended.
>>
>> Kind Regards,
>> Kevin Loaec
>>
>> [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017835.html
>> [2]: https://github.com/re-vault/practical-revault/issues/59
>> [3]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002425.html
>> [4]: https://btcguide.github.io/known-issues/verify-receive-address
>> [5]: https://gitlab.com/lightning-signer/docs
>> [6]: https://shiftcrypto.ch/blog/how-nearly-all-personal-hardware-wallet-multisig-setups-are-insecure/
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210117/8d1d6722/attachment-0001.html>;

📅 Original date posted:2020-05-08 📝 Original message:The ...

2023-06-07T18:24:31Z

In reply to nevent1q…uhns
_________________________

📅 Original date posted:2020-05-08
📝 Original message:The fee bumping construction I described in the previous post is potentially vulnerable
to transaction pinning.

We shared a SINGLE | ANYONECANPAY signature for the first (and only) input of revaulting
transactions to allow any party to append an input and an output in order to bump the
transaction fees.
An user would either append an input signed with ALL, or replace their SINGLE | ANYONECANPAY
signature with one using ALL before broadcasting the transaction.

This allowed one party to decrease the transaction fees down to the minimum relay fees,
and possibly pin the transaction by spending their added single-pubkey output.

We now exchange ALL | ANYONECANPAY signatures for revaulting transactions to restrict the creation
of a new output only spendable by one party.
The fee bumping is now done in two stages (to avoid consuming an entire utxo) :

Unvaulting transaction
--------------------------------
| vault prevout | unvault output |------------------
-------------------------------- \
\ Revaulting transaction
\ ---------------------------------------
| unvault prevout | new vault output |
---------------------------------------
| fee bump prevout |
/ --------------------
Single-party wallet transaction /
----------------------------------------- /
| wallet prevout | fee bump output |----------
-----------------------------------------
| wallet change output |
------------------------

This construction isn't perfect as a malicious party could still pin its fee bumping transaction
and prevent the other stakeholders from **immediatly** replacing this input, because of the second
rule of BIP125 :
> The replacement transaction may only include an unconfirmed input if that input was included
> in one of the original transactions.

However, I think it's preferable as :
- Depending on the unvault CSV, the honest party might pay a high fee to have the fee-bumping
transaction confirm in one of the next two blocks, and then use this now confirmed output as an
additional input of the revaulting transaction.
- If the amount is consequent, the honest party may sacrifice an entire confirmed utxo from its
wallet (effectively skipping the fee bumping transaction).
- It's realistic to expect, for such an application, users' wallets to have a pool of confirmed
utxo that might be sacrificed if the amount is consequent AND the CSV is so small (which is
anyway a bad idea in the first place) that you are not sure to have the fee bumping transaction
to be confirmed before its maturity, ).

Thanks,
Antoine / Darosior

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le vendredi, avril 24, 2020 5:00 PM, darosior <darosior at protonmail.com> a écrit :

> Hi all,
>
> Kevin Loaec and I have been working on a new multiparty vault architecture and I think it reached the point where we’d welcome some feedback.
>
> Intended usage and limitations
>
> ===============================
>
> The aim is to secure the shared storage of coins without relying on a trusted third party and by disincentivizing theft attempts, while not restricting the usage of the funds for day-to-day operations.
>
> Revault uses N-of-N multisigs and thus does not protect against intentional locking of funds (such as refusal to sign, or key erasure). Therefore it assumes its users (likely companies with already on-going agreements between shareholders) to be able to solve intentional blockage outside the Bitcoin network (such as through legal contracts).
>
> The actual architecture
>
> ========================
>
> We called it revault as it relies on pre-signed and revocable (revaultable) transactions.
> The users pre-sign a transaction chain as the only used way to spend from a vault output.
> They would have signed a set of transactions to either cancel a spend attempt or lock the funds for some time beforehand. The funds are always better locked for a long time than stolen.
>
> The transactions
>
> ----------------
>
> The system is composed of mainly 6 transaction types (with N the number of stakeholders) :
>
> - The “vault” transaction which pays to a N-of-N, by which funds are received.
> - The “emergency” transaction, which spends the vault output and pays to a [here goes a
> high value]-days timelocked N-of-N (with N differents but statics keys, assumed to be physically stored in hard(/long) to access locations).
>
> - The “unvault” transaction, which spends the vault output and pays to [either the vault’s N-of-N, or after X blocks to a subset of the stakeholders AND a co-signing server].
> - The “unvault emergency” transaction, which spends the unvault output and pays to the
> same script as the first emergency transaction.
>
> - The “cancel” transaction, which spends the unvault output and pays back to a new vault utxo.
> - The “spend” transaction, which spends the unvault output and pays to an external address (potentially contained in a list of destinations previously agreed-upon by all the stakeholders).
>
> The process
>
>
> The stakeholders would exchange the signatures of all the revaulting transactions after the reception of a new vault utxo, and then exchange the signatures of the unvaulting transaction. Before doing so, the coins are not available to be spent.
>
> In order to spend a vault, the subset of the stakeholders who manages the funds (for example, the traders of an investment fund) would make the cosigning server (which only signs a transaction once) sign the spend transaction.
> They would then present it to the other watchers which would ACK the spend (if paying to an authorized address), and broadcast the "unvault" transaction. Finally, and after X blocks have passed they would be able to broadcast the spend transaction.
> If a stakeholder's watcher detects an unvaulting transaction without knowing about its child “spend” transaction, it triggers an automatic “cancel” transaction (not encumbered by the timelock).
>
> At any point -even in the middle of a spend- any of the stakeholder can trigger an emergency transaction if anything nasty is happening.
> Any network watcher noticing the broadcast of an emergency transaction would also broadcast all other vaults’ emergency transactions.
>
> This network watching and revaulting power can be replicated (watchtowers) to further decrease the reliance on a single machine or internet access.
>
> Pre-signed transactions fun
>
> ---------------------------
>
> In order to avoid our security assumptions to be as weak as betting on the value of the feerate in the future, stakeholders exchange SINGLE | ANYONECANPAY signatures for the revaulting transactions and append their own as SIGHASH_ALL before broadcasting.
> They can add another input (and potentially output) in order to bump the fees before doing so.
>
> We protect ourselves from the bug by leveraging the fact the revaulting (namely the "emergency", "unvault emergency", and "cancel" transactions) only have strictly one input and one output. The change being part of the spend transaction.
>
> In addition, revaulting transactions may signal for RBF to cover a feerate increase after the broadcast. Anyhow, a significant breathing room can be added to the feerate as these transactions are not intended to be used under normal circumstances.
>
> Worth mentioning
>
> ================
>
> The original draft of this architecture was first designed by Kevin Loaec who was hired by NOIA to do so. It was inspired by Bryan Bishop’s single-party vault architecture (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017229.html), who published a demo implementation of it last week (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017755.html, https://github.com/kanzure/python-vaults).
> Kevin and I since detailed and reworked our new architecture together.
>
> A WIP draft / demo / PoC / [enter adjective with “insecure” meaning] implementation is available at https://github.com/re-vault/revault-demo, which uses 4 stakeholders, 2 or 3 traders (doing the day-to-day moves) a CSV of 6 blocks for the unvault script and a CSV of ~1 month for the emergency scripts.
> The transactions used are detailed in the doc/ directory of the same repo, and are coded in the revault/transactions/ module.
>
> The “revault” name was coined by Lea Thiebaut (Lexyon).
>
> Thanks for reading,
> Antoine / Darosior