Explore covenants UX

[GBKS]

There's interest in researching design solutions around covenants.

Briefly, if I understand correctly, covenants are changes to bitcoin that would allow for restricting how bitcoin can be spent. So you could define that certain bitcoin can only be spent to a specific list of other addresses. Right now, the only restriction is who can spend them (the person with the private key). There are several technical proposals to achieve this with different properties, with no clear consensus on which one the hive mind wants to move forward with. This feature is surprisingly powerful and can, for example, enable new scaling methods. Maybe we can help this process by evaluating this from a design perspective. Here's a good podcast with an overview.

Origin of this initiative is a post by Alexander Leishman, which was then picked up by Dan in this PR, which led to a discussion in a Bitcoin Design Guide Jam Session.

As far as a process, we could go for the classic 4Ds - discover, define, design, deliver.

1. Discover: learn about covenants (goals, proposals, use cases, risks, history, etc)
2. Define: broadly explore design concepts and approaches
3. Design: narrow in on the most promising solutions and work through the details
4. Deliver: present our findings and discuss broadly

Step 1 could simply be to set up a channel in Discord for conversation, start gathering resources in a Google Doc, and set up a Learning bitcoin & design call to discuss as a group.

How does that sound? Should we go for it?

I set up a first call here.

[yashrajd]

Attaching the google doc here . Please feel free to add guidance, inputs, questions or comments.

[sbddesign]

I'll just deposit this here (and in the google doc)

[GBKS]

@sbddesign thanks for sharing. If I understand correctly, the exchange can do a very efficient batch transaction to many at once. But this is not a simple transaction where the funds arrive in the destination addresses right away, as we are used to. In this one, the recipient has to claim the funds via another transactions. This makes it more cost-efficient for the exchange, and allows for the recipient to claim whenever is good for them. Downside is that there's an extra transaction in the network, and the recipient now also has to pay a fee, and there needs to be extra communication by the exchange to let the recipient know how to claim the funds. Did I get that right?

[sbddesign]

Yeah, that's basically it. I think part of the challenge was similar to lightning state, e.g. the backup doesn't become a simple "store seed phrase", it's seed + lightning channel state or static channel backup. There was some additional data that need to be conveyed. But this is from an older implementation of CTV, and may not be applicable to all types of covenants or use-cases. Shared for funsies.

[owenkemeys]

I've written two threads trying to put covenants (specifically CTV) into more visual language to help people reason through how it works and onto the possibilities.
This thread covers the basic functionality.
The next thread extends onto 3 concrete use cases, which themselves are pretty much the core bulding blocks of most constructs.
I aim to join the call, and if you like I can give a high level walk through of these - with some analogies to concepts we already have to deal with in UX design today.

[moneyball]

Let's discuss the congestion control use case. Let's say an exchange is servicing 100 customer's withdrawals, or, an employer is paying 100 employees their paycheck. These 100 payments can all be packaged up into a single transaction. Great! However, if I understand correctly, to create that transaction requires interactivity from all 100 customers and the exchange (or, 100 employees and their employer). Each customer must create a signature and share it with all other customers, because for any one customer to later claim their funds, they'll need a distribution transaction and 99 other signatures. This sounds like a worse UX to me than trying to deliver a good coinjoin UX. Can this be explored to see how good (or bad) it would be, so we can evaluate whether we think this would be compelling and adopted?

[owenkemeys]

That's not correct. Let's walk through the use case. I am going to interchangeably use the term "batched" and "zipped" which I think helps people understand the compress/decompress type logic we can do.

In a world where covenants are activated (specifically CTV for simplicity right now), exchanges could offer batched withdrawals, yes. For a batch withdrawal, they need to build:

1. The second stage transaction(s) paying to the individuals,
2. The initial covenant transaction, which appears on chain as a payment to a single address. It can only be spent by broadcasting that second stage transaction(s), which spends its output to all the final individuals. Remember, spending conditions are what generate the address itself.

So in practice, all the exchange needs from a user is: a withdrawal address (just as today), and their consent to being included in covenant batched transactions. Because if you haven't consented, then you don't know that batch transaction included any coins for you. It just looks like any other deposit address on chain. "What do you mean you've sent the payment? My wallet isn't showing anything! That's not my address!"

The receiving case then is fairly straightforward UX on the exchange side: a text box for an address as today, and a checkbox approving this to be included in a CTV batch, likely with a fee discount for doing so - because the exchange is only having to mine a very small transaction spending to 1 output, not 100 outputs.

On the recipient wallet side, under the hood there will need to be a data blob provided by the exchange that includes all the spending conditions of their batch withdrawal, with which you can satisfy yourself that your coins are included in there.

The wallet will also monitor the chain to see if anyone else breaks apart the batch first (remember, the only places the coins can go is to the pre-designated recipients and amounts - think of it like unzipping a file). If someone else does it first, then your coins got moved on to your pre-designated address, and the high time preference user paid the fee for everyone.

It's also worth noting that it doesn't have to be "either everyone exits or nobody does" which makes it very expensive for the 1 person who wants to exit, since he has to pay for a transaction with 100 outputs. Wise covenant users will build multiple optional unzip paths to optimise fees for their customers, such as "exit by yourself, keep the rest batched": meaning you only pay for 2 outputs. Or "exit yourself, split the remainder into 2 smaller batches", which is still only 3 outputs, but helps chunk up the big group. These configs will likely be platform policies.

So to circle back onto UX:
Before an "unzip", for the user we can simply include those coins in their simple balance summary, because nobody else can spend them anyway. But whilst still zipped, we have to communicate that those coins are a little more expensive to spend than coins just sitting in private key-controlled addresses, since you have to broadcast an unzip transaction first before your onward spend. Some ideas:

• Keep them in a segregated area of the UI? "Reserves" or something.
• Live estimates of fees alongside each coin, showing you "cost to get this coin to an onward destination" (which is surely all the user cares about)
• Just a little counter alongside to abstract the cost, such as how many layers deep it is, or how many other outputs there are?

[moneyball]

Am I misunderstanding this Optech description or is it wrong?

"Alice wants to pay a set of ten people but transaction fees are currently high so that she doesn’t want to send ten separate transactions or even use payment batching to send one transaction that includes an output for each of the receivers. Instead, she wants to trustlessly commit to paying them in the future without having to pay onchain fees for ten outputs now. So Alice asks each of the receivers for one of their public keys and creates an unsigned and unbroadcast setup transaction that pays those keys using a 10-of-10 multisig script. Then she creates a child transaction that spends from the multisig output to the 10 outputs she originally wanted to create. We’ll call this child transaction the distribution transaction. She asks all the receivers to sign this distribution transaction and she ensures each person receives everyone else’s signatures, then she signs and broadcasts the setup transaction."

https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments

[owenkemeys]

That's a very odd example that may be confusing you. I think that's demonstrating how you could achieve a batching effect without CTV.
Transaction A, the payment into the 10of10 multisig, is a 1-output TX, making it small and thus cheap.
Transaction B, the presigned transaction with all 10 signatures, distributed to all recipients BEFORE Transaction A is broadcast for mining, is their assurance they can all get their money out again.

With CTV you don't need all the signatures. You would get an address from each person (and their consent to being put in a tree), and then build a template.
Transaction A pays into the CTV address.
Transaction B spends the CTV address, only possible if it matches the Template that defines the CTV address. This Template happens to be "pay to these 10 addresses".

Again, the congestion control models are not that compelling on their own especially given the modern times of consistently high fees, but they are the most basic tree/pool structure, and we can do many more interesting things with those. Imagine for example that each of those 10 output addresses is a lightning channel - they can all be used right away as soon as Transaction A is mined, since they are committed now and must happen at some point. But the chain has only seen a single output UTXO.

[owenkemeys]

I built a Figma UX demo of Phoenix wallet with CTV powered Cold Channels, you can check it out here:
https://www.figma.com/proto/o4sxu0rEIR1zmletrxtXRn/Phoenix-CTV?type=design&node-id=2-60&t=A12KsqXSncbdgstk-1&scaling=contain&page-id=0%3A1&starting-point-node-id=2%3A60&mode=design
This is a working document so bear with me if anything is broken.

[moneyball]

That Optech summary is specifically about CTV, formerly called COSHV.