Nostr notes by

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

2023-06-09T15:05:09+02:00

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:2022-05-03 📝 Original message:Hi ...

2023-06-08T01:08:54+02:00

In reply to nevent1q…ej65
_________________________

📅 Original date posted:2022-05-03
📝 Original message:Hi Jacob,

I think you are a bit confused about how CTV and (tweaked) APO covenants compare. Both would commit to the
same template, so one isn't "safer" than the other. Just more efficient in how it commits to the template.
Replies on the specifics inline.

> While I agree with the arguments in favour of (optional ANYONECANPAY) APOAS in lieu of CTV in the short-term (given the additional benefit of enabling Eltoo), there's a point to add in favour of CTV (or similar) in the long-term beyond as an optimisation.

In the long term, we'd hopefully have more powerful covenants to enable more interesting applications. At this
point CTV would be an optimisation for these covenant constructions instead of an APO one.
My request for feedback was more about the short term, where some are requesting the activation of CTV to
start playing with covenants before we settle on the way forward to more useful covenant. Not that i'm in
favour of it, but if it gains sufficient traction then i believe there is a case for instead doing a tweaked
APO that would optionally commit to the input index, nSequences, etc..[0] I think this addresses the technical
debt concerns of CTV once we have more interesting covenants, as no covenant can entirely emulate a signature
hash type.

> With APOAS-based covenants, the signature message algorithm is tied to both the covenant commitment and transaction validation. Coupling these things introduces a trade-off between safety and flexibility with covenant-based applications.

What do you mean "tied to the transaction validation"? To me "transaction validation" is what a node does to
check whether a block is valid, but you probably mean something else here.
With APOAS-based covenants, the signature message *is* the covenant commitment. I don't see how it is coupled
to anything else. I also don't see how it could ever differ in safety or flexibility with another
hashed-template approach (CTV) if the template is the same.

> E.g. the maximally safe and restricted covenant commits to all inputs and outputs of the transaction (using SIGHASH ALL). However, a less restricted covenant commits to, for example, a single input and a single output (using ANYONECANPAY|SINGLE) but opens itself up to attacks making use of transaction malleability and signature replay.

Indeed the APO approach is more flexible as sighash types may be combined. You can opt-in to more
malleability. I don't think it's a bad thing. Now, sure, the commitment may be replayed, but it's inherent to
any commitment that doesn't commit to the prevout (whether it is CTV or APO, or any other type of templated
covenant that you'd place in the ScriptPubKey) otherwise you'd have a circular hash dependency.
If you are talking about the "half spend" by which two coins with the same covenant get spent in the same
transaction, then committing to the input index fixes this. Interestingly the instance you give *does* commit
to the input index without any tweak to the current APO proposal.

> If instead we separate the covenant commitment from the signatures to validate transactions (as with CTV and TXHASH + CHECKSIGFROMSTACK) then we by-pass this trade-off.

CTV doesn't "separate the signature and the commitment", it doesn't need a signature. Sure one can be added to
further restrict a spending path, but it isn't necessary since the transaction is pre-defined and can't be
malleated. It also sounds like you imply the APO covenant is using a "real" signature. It's not. The pubkey
may well be G. The signature is just a roundabout way to access the hash. So if you wanted to have, say, a
covenant only available to a participant you'd go the same way with either CTV or APO covenants:
<covenant sig> <0x01 G> OP_CHECKSIGVERIFY <Alice pubkey> OP_CHECKSIG
<tx hash> OP_CTV OP_VERIFY <Alice pubkey> OP_CHECKSIG

> The flexibility of additional templates with new CTV versions or with the TXHASH primitive seems to me to enable significantly more utility for covenant-based applications.

TXHASH would definitely enable more utility. Additional templates with new CTV versions would require a new
soft fork for new (hardcoded) usecases. But i'm not going to restart the conversation around the benefits of
slightly more general covenant primitives [1]. :-)

Antoine

[0] See the OP for rationale[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html

[0] Cf the OP for the rationale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220503/3644bbb9/attachment.html>;

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

2023-06-08T01:07:57+02:00

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-08T01:07:56+02:00

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-02-19 📝 Original message:> ...

2023-06-08T01:04:01+02:00

In reply to nevent1q…dwlp
_________________________

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

2023-06-08T01:03:28+02:00

In reply to nevent1q…f9xx
_________________________

📅 Original date posted:2022-02-12
📝 Original message:> Such a construct would present dangerous implications to the fungibility of individual UTXOs by introducing a totally different risk model in being paid with such a coin compared to any other coin not encumbered by such a condition

How is that different from being paid in an altcoin?
It seems to me that being able to say "sorry, your money isn't good here" is at the heart of Bitcoin's security (similarly to enforcing the network rules with your node). If someone can coerce you into using another currency, you've already lost.

Now there is left the influence on the system of an user being coerced into using gov coin (on another chain) or an encumbered bit coin. Sure the latter would decrease the supply available, but that's already possible to do today.

------- Original Message -------
Le vendredi 11 février 2022 à 7:12 PM, digital vagabond via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> a écrit :

> This is Shinobi (can verify out of band at @brian_trollz on Twitter, I only signed up to the list with this email to read initially, but feel like I should reply to this as I think I am one of the only people in this space who has voiced concerns with recursive covenants).
>
> My concerns don't really center specifically around recursion itself necessarily, but unbounded recursion in combination with too much generality/flexibility in what types of conditions future UTXOs can be encumbered with based on the restriction of such covenants. Forgive the hand waiving arguments without getting into specific opcodes, but I would summarize my concerns with a hypothetical construct that I believe would be incredibly damaging to fungibility. Imagine a covenant design that was flexible enough to create an encumbrance like this: a script specifies a specific key in a multisig controlled by some authority figure (or a branch in the script that would allow unilateral control by such an authority), and the conditions of the covenant would perpetually require than any spend from the covenant can only be sent to a script involving that key from said authority, preventing by consensus any removal of that central authorities involvement in control over that UTXO. Such a construct would present dangerous implications to the fungibility of individual UTXOs by introducing a totally different risk model in being paid with such a coin compared to any other coin not encumbered by such a condition, and also potentially introduce a shift in the scope of what a 51% attack could accomplish in terms of permanent consequences attempting to coerce coins into such covenants, as opposed to right now only being able to accomplish censorship or temporary network disruption.
>
> I know that such a walled garden could easily be constructed now with multisig and restrictions on where coins can be withdrawn to from exchanges or whatever place they initially purchased from, as is demonstrated by the implementation of the Asset Management Platform by Blockstream for use on Liquid with regulated equity tokens, but I think the important distinction between such non-consensus system designed to enforce such restrictions and a recursive covenant to accomplish the same is that in the case of a multisig/non-consensus based system, exit from that restriction is still possible under the consensus rules of the protocol. If such a construct was possible to build with a recursive covenant enforced by consensus, coins encumbered by such a covenant would literally be incapable of escaping those restrictions without hardforking the protocol, leaving any such UTXOs permanently non-fungible with ones not encumbered by such conditions.
>
> I'm not that deeply familiar with all the working pieces involved in the recent TXHASH + CSFS proposal, and whether such a type of overly (IMO) generalized recursion would be possible to construct, but one of the reasons CTV does not bother me in terms of such concerns is the inability to infinitely recurse in such a generalized way given the requirements to exactly specify the destination of future spends in constructing a chain of CTV encumbrances. I'd very much appreciate any feedback on my concerns, and if this side tracks the discussion I apologize, but I felt given the issue has been mentioned a few times in this thread it was appropriate for me to voice the concerns here so they could be addressed directly.
>
> On Fri, Feb 11, 2022 at 11:42 AM James O'Beirne via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I don't oppose recursive covenants per se, but in prior posts I have expressed uncertainty about proposals that enable more "featureful" covenants by adding more kinds of computation into bitcoin script.
>>
>> Not that anyone here is necessarily saying otherwise, but I am very interested in limiting operations in bitcoin script to "verification" (vs. "computation") to the extent practical, and instead encouraging general computation be done off-chain. This of course isn't a new observation and I think the last few years have been very successful to that effect, e.g. the popularity of the "scriptless scripts" idea and Taproot's emphasis on embedding computational artifacts in key tweaks.
>>
>> My (maybe unfounded?) worry about opcodes like OP_CAT and OP_TX is that more logic will live in script than is necessary, and so the burden to verify the chain may grow and the extra "degrees of freedom" in script may make it harder to reason about. But I guess at this point there aren't alternative means to construct new kinds of sighashes that are necessary for some interesting covenants.
>>
>> One thing I like about CTV is that it buys a lot of functionality without increasing the "surface area" of script's design. In general I think there is a lot to be said for this "jets"-style approach[0] of codifying the script operations that you'd actually want to do into single opcodes. This adds functionality while introducing minimal surface area to script, giving script implementers more flexibility for, say, optimization. But of course this comes at the cost of precluding experimentation, and probably requiring more soft-forking. Though whether the place for script experimentation using more general-purpose opcodes on the main chain is another interesting debate...
>>
>> Sorry for going a little off-topic there.
>>
>> [0]: https://medium.com/blockstream/simplicity-jets-release-803db10fd589
>>
>> On Thu, Feb 10, 2022 at 7:55 PM David A. Harding via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev wrote:
>>>> Whether [recursive covenants] is an issue or not precluding this sort
>>>> of design or not, I defer to others.
>>>
>>> For reference, I believe the last time the merits of allowing recursive
>>> covenants was discussed at length on this list[1], not a single person
>>> replied to say that they were opposed to the idea.
>>>
>>> I would like to suggest that anyone opposed to recursive covenants speak
>>> for themselves (if any intelligent such people exist). Citing the risk
>>> of recursive covenants without presenting a credible argument for the
>>> source of that risk feels to me like (at best) stop energy[2] and (at
>>> worst) FUD.
>>>
>>> -Dave
>>>
>>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019203.html
>>> [2] http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html
>>> (thanks to AJ who told me about stop energy one time when I was
>>> producing it)
>>>
>>> _______________________________________________
>>> 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/20220212/99a82200/attachment.html>;

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

2023-06-08T00:54:28+02:00

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-08T00:54:26+02:00

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>;