BRC-0099, BRC-0046, and BRC-0001 Comments on creating transactions and managing UTXOs and locking scripts.

[KarlTheProgrammer]

BRC-0001

Some actions, like exchanging assets, require inputs from other parties. I think a description at a higher level and a partial transaction, encoded with Bitcoin P2P network encoding is the best option. Any context should be at a higher level. There will be payment requests with just outputs, requests to pay with inputs and maybe change outputs, then exchange requests with inputs sending assets and outputs receiving other assets. This should be all the information needed to complete the transaction so long as the wallet has a module that understands all of the protocols involved. We already have all three of these actions supported in the Tokenized platform and externally via the negotiation paymail protocol and have the ability to do that over peer channels too.

BRC-0046 and BRC-0099

I agree that we need to tag outputs (UTXOs) with a "basket". I recently started calling it "purpose". Currently within the Tokenized platform we link a balance ID directly to the UTXO and have a tag on the locking script for administrative actions. I figure for a more modular wallet for Tokenized the purpose for a UTXO that is used to authorize the transfer of a specific instrument (the locking script holds a Tokenized balance) can be tagged with a URL value like "Tokenized://<instrument_id>". And for UTXOs that are used to authorize administrative actions on Tokenized contracts can be something like "Tokenized://<contract_address>". Then when the Tokenized module wants to perform a specific action it requests UTXOS with the specified purpose. Otherwise those UTXOs are not given out.

It might also need to be able to request UTXOs for a specific locking script. And likely even create new UTXOs with a specific locking script. As an example, in Tokenized, and I would guess other systems in the future if not already, locking scripts are given special meaning rather than UTXOs. Any UTXO that has the specified locking script can be used for the specific purpose. So for example if the Tokenized module knows a specific locking script has a balance of a token and it wants to transfer some of that balance then it will request a UTXO for that specific locking script. To be clear most wallets will have several locking scripts holding balances of the same instrument/asset and for privacy they won't be re-used under normal circumstances.

[ty-everett]

In BRC-100, we have the signAction flow. When unlocking scripts are not provided, a signable transaction is returned as a partial Atomic BEEF (BRC-95). This allows the first person to create a transaction (createAction) and then circulate it to others. Once all unlocking scripts are completed, the signAction process completes the transaction, and it can be sent to the network. In the base case (with BRC-46 and normal create / sign flows), all the wallet cares about is that the scripts are Bitcoin-valid, and the transaction is sent to the network for block inclusion. However, if one or more UTXOs come from a p basket (BRC-99), the wallet can perform other actions, authorizations, or interactions with an Issuer's Agent before settlement.

How the applications facilitate the communication process is separate from the wallet's signing process, at least for standard baskets. P-basketed assets may work differently. The foundational interoperability requirement is that all wallets support default behavior, and can extend with behavior for other specific cases as required. As those use-cases gain traction, other wallets may integrate them.

My goal is to get interoperability at the core Bitcoin layer, and be extensible enough to allow other people to build on top. I think we can get there. Even if all "Bitcoin wallets" are not necessarily "Tokenized wallets", it's still a win as long as all "Tokenized wallets" can support the base layer Bitcoin functionality in addition to Tokenized-specific functionality (i.e. Tokenized-style P-baskets). That way, all "Bitcoin apps" can plug into the Tokenized wallet, like they can for any other Bitcoin wallet. The Tokenized app ecosystem becomes a super-set of the Bitcoin app ecosystem.