RGB Swaps with presig

[crisdut]

Description

This PR allow the seller sign the PSBT in the create offer step and buyer co-sign and broadcast, without requiring third-party control.

To achievement that, we needed create a new method to construct PSBT file, without the need to have all inputs previously added, reducing the number of interactions between parties (from 2 to 3).

How to works

1. The seller creates an offer
   • The BMC registry the offer in a public orderbook.
2. The seller and co-sign the psbt file.
   • The BMC updates the offer in a public orderbook.
3. The buyer retrieves the offer, create bid and complete and co-sign psbt file.
4. The buyer publish the the swap transaction directly.

Improviments

• Create extension to allow us create partial PSBTs
  • Seller can define the value of the asset without adding inputs to it. Previously, to create a PSBT, even a partial one, it was necessary to add an amount greater than or equal to the amount of output satoshis (this is a bug);
  • This improvement reduced the amount of customizations we needed to make to BP-WG packages. Now just update amplify to 4.0
• Allow update public offer in public orderbook;
• Allow each participant define your sighash condition;

!!! UPDATE https://github.com/diba-io/bitmask-core/pull/385/commits/a4adbce82ff4989489bc751ca500e0e5e4e585f0 !!!

I had problems with balance consistency after swap operations, mainly because according to traditional RGB logic, the seller would be the last to work on the file and, consequently, generate the transaction and store the taptweak.

But how to do this if the buyer will be the last participant involved?

The solution for now without many changes was to share the taptweak via swap file so that the seller can receive it as soon as the transaction is registered.

Another problem encountered is how to guarantee that payments will be asynchronous: I basically use the swap file, where every time the user "goes online", I search the orders (offers/bids) behind pending transactions in monitoring and update them. For BME it is transparent, as this logic is in verify_transfers

Closes #382

[cryptoquick]

Do you think you'll add the changes we discussed to this PR regarding a trusted swap coordinator?

[cryptoquick]

The solution for now without many changes was to share the taptweak via swap file so that the seller can receive it as soon as the transaction is registered.

This is very clever!

Another problem encountered is how to guarantee that payments will be asynchronous: I basically use the swap file, where every time the user "goes online", I search the orders (offers/bids) behind pending transactions in monitoring and update them. For BME it is transparent, as this logic is in verify_transfers

Hopefully this won't be too difficult to integrate into the extension.