It would be convenient to be able to construct a p2tr address that was actually a payment channel with some 3rd party. This is the perfect bridging mechanism between layer-1 and layer-2. The key issue with constructing this with existing covenant proposals (iiuc) is that the value that will be sent to the address cannot be known when constructing the script pubkey.

The main use case here is obvious. Anytime anyone is paying to your address it can go into a channel without any kind of cooperation from the sender. Coins can be withdrawn straight from exchanges into layer-2 without exchanges having to support anything more than p2tr.

Less obvious use cases include batch lightning channel opening which requires lightning specific protocols right now [1]. It Would be great if we could just have a batch transaction protocols which were able to open lightning channels without this extra complexity and interaction. -- this could already be achieved by the simpler non-interactive-channels idea with OP_CTV.

To do this the covenant proposal needs to be able to constrain spends out of the address to the first commitment transaction (or however your channel works) whose output value must be proportional to the value at the output being spent.

cc @DanGould @nickfarrow

[1] https://nolooking.chaincase.app/

PS I'm unable to attend the meetings at that time so I'll bring up this for discussion here. Thanks a lot for starting this initiative @ariard.

Hi everyone,
Me, fi3 and Rachel Rybarczyk wrote a proposal for a payout scheme for the miners of a mining pool. We think that this is very important and underestimated problem. Now, the coinbase reward and fees are collected by the pool, that redistributes it to the miners as a payout for the mining. We think that such a centralization is against the spirit of Bitcoin, and it critical for security. Therefore, we tried to build a payout scheme through the concept of payment pools. The mining profits are collected by a payment pool set by the miners and in any phase the pool takes control of them. This makes the pool non custodial. We assume the pool to be centralized, even though our work perhaps can be generalized to decentralized pools. Our scheme uses ANYPREVOUT.
We posted it on bitcoin-dev mailing list
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021610.html
I understand that it could be discouraging to approach a 30 pages long document, but if anyone took a look to it, it would be very important for us to have some feedback. Perhaps the IRC channel #bitcoin-contracting-primitives-wg or #coinpool-dev can be good places to discuss it, but I don't know when you are gonna meet. Any suggestion would be very appreciated.

https://blog.blockstream.com/use-smart-contracts-on-liquid-to-deploy-financial-products/
https://blockstream.com/assets/downloads/pdf/options-whitepaper.pdf

https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md

A generalisation of https://en.bitcoin.it/wiki/Zero_Knowledge_Contingent_Payment

Based on https://www.rfc-editor.org/rfc/rfc3426.html and iterations.

The use-case would be to create millions of Lightning channels with a single on-chain transaction (without having to have a million parties agree on the channel created. Could be done as documented in https://github.com/JohnLaw2/btc-iids/raw/main/iids14.pdf

Where state channels is defined as additional state stored on top of a payment channels. The state channel specifies what are the rules on on how to transition the state updates.

I’ve been working on a draft proposal for aggregating Lightning HTLCs in a single output on the commitment transaction. The idea is to avoid the commitment getting large when forwarding a lot of HTLCs, and making it cheaper to claim them after a force close.

To make this work I need some sort of covenant, and I’m wondering if someone has any opinion on which proposal would be best to pursue.

Let’s say the output script and amount encoding the active HTLCs is on the form [hash1 amt1 … hashn amtn] <script>:sum, where the <script> part can be static as long as you know the number n.

Simple example

Now we want to claim htlc1 on chain, and present the preimage for hash1. We must enforce that the new output script is on the form [hash2 amt2 … hashn amtn] <script>:sum-amt1. (Note that htlc1 and its amount has been removed, everything else stays the same. Since we presented a valid preimage we can do with the subtracted amount whatever we like).

Requirements

First, we need a check for the output amount. This has been discussed in other settings, and we most likely also need a way to do 64 bit math in the script.

Next, we need a way to verify that the new taproot output is based on the remaining hashes. One way to do this is to tweak the taproot internal key with all the hashes and amounts, and that way commit to them. This way we could keep this “dynamic commitment data” in the internal key, while the actual taproot tree can be mostly static (it just commits to the static script). This would need some way of inspecting the key (or verifying arbitrary data against it) when spending. OP_CHECK[INPUT/OUTPUT]COVENANTVERIFY from #25 could be a good candidate for this.

Note: I initially tried to commit to the remaining HTLCs in the taproot tree itself, but found it very hard to verify this from the script, since it required (AFAICT) re-deriving and inspecting the whole taproot tree.

Spending

Having these capabilities a spender would claim the HTLC by presenting the full list of HTLCs and amounts, as well as the preimages for the HTLCs to be claimed.

1. Check that the internal key commits to the list of HTLCs and amounts presented.
2. Verify the preimages and subtract their values from the input amount, as well as from the list of HTLCs.
3. Verify that the output has an internal key committing to the remaining HTLCs, an amount equal to the remaining sum, and the static taproot.

Help wanted

The main question is whether this way of commiting to the HTLCs can be done elegantly with any of the covenant proposals.

Also, any ideas or pointers would be greatly appreciated, as well as any feedback or questions!

Edit: Obsolete, see below for the latest attempt.

Hello, I hope it's fine if I slightly abuse this space to get feedback on my specific proposal - please let me know if this is not appreciated and I'll find a different venue.

I'm trying to formalize the exact opcodes for MATT for the purpose of implementing them for bitcoin-inquisition.

One thing that was left unspecified in the initial sketch (h/t @darosior for pointing that out) is that a way is needed to make "arguments" passed to the covenant non-malleable, if they are passed via the witness.
Building on top of Antoine Riard's PR on the annex format, I think using the annex for this purpose is the best course of action.

I would love if someone more experienced with bitcoin-core would like to help with putting together a good PR.
MATT needs your help! :)

This is what I'm planning right now for an (almost) complete set of opcodes - please let me know if you have any comments or suggestions.

MATT tentative specs

Covenant opcodes: verify or commit to data in the taproot internal key of an input/output

• OP_CHECKINPUTCOVENANTVERIFY: let x, d be the two top elements of the stack; fail if any of x and d is not exactly 32 bytes; otherwise, check that the x is a valid x-only pubkey, and the internal pubkey P of the current input is indeed obtained by tweaking lift_x(x) with d.
• OP_CHECKOUTPUTCOVENANTVERIFY: given a number out_i and three 32-byte hash elements x, d and taptree on top of the stack, verifies that the out_i-th output is a P2TR output with the taproot internal key computed as above, and tweaked with taptree. Fail if if any of x, d or taptree is not exactly 32 bytes.

Data manipulation:

• OP_CAT: pop the top two stack elements, push their concatenation; fail if the concatenation is longer than a predefined limit (256 bytes?).

Additional introspection (compulsory):

• OP_PUSH_ANNEX_RECORD: details TBD; push an annex record onto the stack. To build on top of bitcoin-inquisition/bitcoin#9.

Additional introspection (optional): one can probably do some interesting things without, but these would allow concepts like "pay to a contract" or "withdraw from a contract", where the contract is a covenant-encumbered UTXO.

• OP_INSPECTNUMINPUTS and OP_INSPECTNUMOUTPUTS: push to the stack the number of inputs/outputs.
• OP_INSPECTINPUTVALUE and OP_INSPECTOUTPUTVALUE: given an index i popped from the top of the stack, push to the stack the amount in sats of a certain input/output.

Still unresolved: as pointed out by Anthony Towns, amounts do not fit in 32-bytes; therefore, some way of enabling 64-bit maths would be desirable. It's a technicality, so it might safely be left for later.

Comments

• OP_CHECKINPUTCOVENANTVERIFY and OP_CHECKOUTPUTCOVENANTVERIFY could be replaced with more general opcodes to inspect input/output scriptPubKey, and do some elliptic curve maths. Those are already available in Liquid, see here.

https://bitcoinrollups.org

The use-case would allow millions of (on-chain or off-chain) UTXOs to change ownership with a single on-chain transaction in a trust-fee manner. Could be done as documented in https://github.com/JohnLaw2/btc-iids/raw/main/iids14.pdf

The meeting will take place on Tuesday 2023/04/18 (the third Tuesday of the month) at 6:00 pm UTC on Libera Chat IRC #bitcoin-contracting-primitives-wg.

Primitives Seeking Review

This section contains contracting primitives and protocols waiting reviews.

• BIP 118 - SIGHASH_ANYPREVOUT
• BIP 345 - OP_VAULT

Use-Cases Seeking Review

• vault protocol
• Eltoo channels
• payments pools/channel factories

Feel free to comment to add any subject you would like to be discussed during this upcoming meeting as format is "freewheel".

https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md

The meeting will take place on Tuesday 2023/03/21 (the third Tuesday of the month) at 6:00 pm UTC on Libera Chat IRC #bitcoin-contracting-primitives-wg.

Proposals / Seeking Review

This section contains contracting primitives and protocols waiting reviews.

• ANYPREVOUT / "Eltoo"

Feel free to comment to add any subject you would like to be discussed during this upcoming meeting as format is "freewheel".

If you would like to host the meeting, please comment here or reach out by DM!

We have a number of vaults ideas proposed so far: TLUV-based, OP_VAULT-based, APO-based, CTV_based. Could be valuable to summarize them.

The meeting will take place on Tuesday 2023/02/21 at 6pm UTC on Libera Chat IRC #bitcoin-contracting-primitives-wg. It is open to the public.

Proposals / Seeking Review

This section contains contracting primitives and protocols waiting reviews.

• ANYPREVOUT / "Eltoo"

Community

• Meatspace event in S2 2023 / S1 2024

Feel free to comment to add any subject you would like to be discussed during this upcoming meeting.