Receiving BTC for the NFT mint

[whoabuddy]

This issue covers one of the major milestones / protocol design points: we need a way to receive BTC from any wallet (linking #2 as well).

Looking at the normal model for Clarinet, this would be done with an authority address which represents the Bitcoin/Stacks keys running the chainhook.

PROS: simple, single address to send to CONS: no decentralization, no way to get BTC back on failure?

Looking at HTLCs like those used with Magic Bridge, this would be done by creating a deterministic Bitcoin address that locks the funds up for a set amount of time. During that time, the party processing the transaction on the Stacks side can perform the mint action, then claim the BTC as a result.

PROS: single address to send to, deterministic address can be externally verified CONS: difficult to know address to monitor

Combining the two may be a useful approach here, but we want to avoid any unnecessary complexity as well.

Also worth noting - to run a chainhook it requires a Bitcoin + Stacks node (handled by clarinet integrate for devnet), with the chainhook acting as an event observer for the node.

• is this a reasonable requirement for the ones processing the mint?
  • initial reaction: yes for marketplaces, a stretch for artists
  • could be a possible hosted solution in the future?

[whoabuddy]

We found a possible issue in the implementation and could definitely use some feedback.

If we boil this down to the steps in the Miro doc:

User = party sending BTC TX Runner = party processing STX TX to receive BTC (fee implied)

1. User is paired with a transaction runner via the UI (sourced from a contract)
2. HTLC script is generated with OP_DROP indicating runner ID
   • funds can be spent by runner if they are provided the hash (secret)
   • funds can be spent by user after X blocks pass (time lock)
3. Runner creates a chainhook to monitor address of HTLC script (via JSON POST)
4. User funds the HTLC script address in order to mint the NFT
5. Runner processes the mint on the Stacks side for BTC address of input
   • double-check here against examples: can there be more than 1 input address?
6. NFT is minted to an escrow contract and reserved for the BTC address
7. How does the runner then receive the hashed secret from the original sender?

Two options that immediately come to mind:

1. It's sent via a POST to the miner, who then uses that to claim the BTC
2. It requires two transactions, one to "mint" and one to "finalize mint"

Both have some drawbacks, and this will require us to carefully think through the states within the minting process to make sure there are no dead ends.

[whoabuddy]

For option 1, some questions from the technical call:

• what stops someone else from claiming the BTC?
• what happens if the UI sends it early or somewhere else?
• what happens if the UI doesn't send it, or state is lost? (assuming local state)

[radicleart]

Just dropping the nBTC paper for reference. Its different as users create a threshold signature sent to a taproot address but maybe has enough overlap to be helpful.

https://claritylab.notion.site/nBTC-a-concept-for-noncustodial-wrapped-Bitcoin-on-Stacks-6eebcacf2c384adeb306b059ab5ee5d9

[radicleart]

I just set up a testnet node to see if i can deploy the script and get a better understanding.

[whoabuddy]

This has been further simplified by looking at the NFT mint as one half of a Catamaran Swap, where the BTC will go directly to a single address (the artist, charity, etc) and through monitoring that BTC address the subsequent mint can be processed on the Stacks side.

Next up will be handling the ownership piece in #6