Support Auction Swaps

[crisdut]

Description
This PR intent supports sequential swaps and unifies the previous swap operations (now called "strategies").

Now, BMC have three ways to make swap operations:

1. P2P: The strategy allows participants (sellers and buyers) to make swaps without a coordinator. The match engine used is FIFO, i.e., the first bid that arrives with the correct target price.
2. Airdrop: The strategy allows participants (issuers) to make individual or collection airdrops. The airdrop respect the FIFO (First In First Out).
3. Auction: The strategy allows participants (sellers) to make individual or collection offers. The match engine used is the highest price, i.e., after the offer expires (or finished by seller), the coordinator selects the highest price bid and executes. Then, the coordinator updates the next available offer with the new UTXO (in case of the collections). All offers of the collections are publish and allow to receive bids.
4. HotSwap: The strategy allows participants (sellers and buyers) to make swaps without a coordinator. The main difference of the P2P is the sign condition. The sign condition is post-sign, i.e., the seller is the last to sign.

Also, It was necessary to carry out some refactorings to increase the maintainability of the swaps in BMC, according to the checklist below:

Sequential Swaps (epic)

• Choose Swap Strategies
  • Add HotSwap instead of presig=false flag
  • Add P2P instead of presig=true flag
  • Add Auction to allow use coordinator
  • Refactor swap tests
• Allow offer collections
  • Add internal_create_buyer_bid to allow reuse step
  • Add internal_create_seller_offer to allow reuse step
  • Allow vector of offers have the same bundle_id
  • Add create_auction_bid to allow create bid (sequential swaps)
  • Add create_auction_offers to allow create one or more offers (collections in sequential swaps context)
  • The create_auction_offers needs return all offers published in orderbook
• Now Public Orders is first citizen
  • Allow change status orders in public orderbook
  • Use public orderbook to create rgb transfers
  • Use public orderbook to update participants orders(aka. my orders)
• Match Engine based in swap strategies
  • P2P is always FIFO
  • Hotswap is always a seller decision
  • Auctions is always highest bid and timebox.
  • Airdrop is always FIFO
• Remove potential exploits from Public Orders information
  • [Airdrop] Prevent malicious buyers broadcast transactions before the Auction ends
  • [Auction] Prevent malicious buyers broadcast transactions before the Auction ends
  • [HotSwap] Prevent malicious seller broadcast multiple transactions with same UTXO (always force batch operation)
  • [P2P] Prevent malicious buyer broadcast multiple transactions with same UTXO (block use)
  • [All] Storage tapret commits only DH (Diffie–Hellman) carbonado data
  • Create integration tests
• Next Offer (aka. Sequential Offer)
  • Allow coordinator check and publish all transaction auctions (after offer finished)
  • Allow seller finish the offers and launch new offers with remaining assets
  • After confirmation of the previous offer transaction, update all subsequent offers with new UTXO
  • Cancel all bids for offer already filled (executed)
  • Prevents reuse of bitcoin utxos (force update dustless verification)
  • Create integration tests
  • Create integration tests (security)
• Expose endpoints for Bitmask Server
  • Create/Remove Auction Offer
  • Create/Remove Auction Bid
  • Finish Auction Offers
  • Renew Auction Offers
  • Get Offer Collection
  • Get Bids by Offer Collection
• Update Wasm API
  • Update Structs
  • Update Methods
  • Expose new Methods
  • Create wasm tests for seq. swaps

Closes #413
Closes #365
Closes #422

PS: I added #422 here because we can resolve all offers/bids in one "big" L1 transaction.

[josediegorobles]

Hi, could you update the wasm api?

[crisdut]

Hi, could you update the wasm api?

Yes, I think I finishing it today.

[crisdut]

Prevents reuse of bitcoin utxos (force update dustless verification)

Suppose we have a seller who wanted to sell 5 items and wants to sell via sequential swap. Throughout operations, the UTXO related to assets may decrease to smaller fractions until it turns to dust. As the seller no longer changes the PSBTs after the start of the auctions (the coordinator manages it), I thought about making a "minimum satoshis for operation" rule for the RGB20 and RGB21 wallets, what do you think?

[cryptoquick]

Really good work on this! I like the clarification on some of the terminology, like server -> marketplace and presig -> strategy. Also, good catch on realizing we're using PSBTv0. As you might know, there's no PSBTv1... Only v0 and v2.

I just have one issue with code organization in carbonado.rs... It's really making that file quite a bit more complex than it should be. If I had to guess, that logic is being put in the wrong place. Do you agree?

[cryptoquick]

Is there any way to abstract this out so it's not in src/carbonado.rs methods? Ideally this file would be cleaner and simpler, more focused and have less duplication.

[crisdut]

I believe so, but I feel like it will lose some of its purpose. I centralized in this file all the calls that are sometimes made by the client and sometimes made by the server.

But yes, I can carry out another separation.

[crisdut]

Prevents reuse of bitcoin utxos (force update dustless verification)

Suppose we have a seller who wanted to sell 5 items and wants to sell via sequential swap. Throughout operations, the UTXO related to assets may decrease to smaller fractions until it turns to dust. As the seller no longer changes the PSBTs after the start of the auctions (the coordinator manages it), I thought about making a "minimum satoshis for operation" rule for the RGB20 and RGB21 wallets, what do you think?

What do you guys think, @cryptoquick and @josediegorobles ?

[cryptoquick]

@crisdut We should always have an input from the buyer for paying fees and paying for the dust output.

Also, there's no way to batch transfers with auctions because they're separate PSBTs, correct? That's fine so long as multiple sequences can be spent within the same block.

[josediegorobles]

LGTM