Repeat mint

[hexley21]

Introduce mint repetition

What is the current behavior?

When a user needs to mint a token X amount of times, it has to be done manually, which takes time

Issue Number: #9

What is the new behavior?

• User can define how many times to mint the token
  
• When user defines amount greater than 1, user is requested to sign multiple PSBT at once
  
• Meanwhile user is waiting to sign a mint, toasts are shown indicating the current minting preparation process:
  
• After user confirms the PSBT sign request, transaction broadcasting progress is shown:
  

Clarifications

I read the comment about avoiding to implement this feature into flur, but since this issue is still open and according to my knowledge how things work, I think that my pull request is valid, and i will explain why

Transaction broadcasting

After all the preparing and signing processes, everything is packed into Transaction objects that are being broadcasted to mempool, which handles the transaction insertion into the chain. This means that as far as the minting process is working, transactions are signed and newly minted tokens are displayed in our wallets, there's no worry for transaction integrity, we can repeat minting process as many times as we want and expect the same result.

the broadcast utility function which uses mempool's api, afaik is an ordinary HTTP service, which has a business logic defined, it can return errors if transactions are invalid, if you are abusing the system, and even it's possible to get status 500, but in error cases, your transaction won't be in chain and your funds won't be transferred, this responsibility is on mempool, and i don't think that by avoiding multiple mints, we do something significant for user's safety

The worst case user can end up with, is actually minting 10%-20% less than defined but without funds being transferred for these unsuccessful transaction

Other internal information

• All api/mint requests are packed into one array and launched at the same time using Promise.all() works well, due to how concurrency works in JS and how much time does a request takes to response, it is less likely to catch status 429 or crash the server, because all the requests are not processed at the same time, as far as i know, 4 tasks can run concurrently
• However mempool's /tx endpoint requests are not packed and launched at the same time as api/mint, this is because broadcast request is significantly faster than api/mint, and we can stumble into http status 429

It didn't take much time or efforts, and I don't think I did something very significant, but I am happy that I can somehow contribute to open source projects I use. Tell me if I am wrong somewhere

[utxo-detective]

Build is failing @hexley21

[utxo-detective]

Also, @hexley21 i really want to get rid of the cloud functions in /api - my preference is to have all the logic run locally on the frontend. Originally i was having issues with the js working as intended on the frontend, but have since found ways to make it work when i was implementing the marketplace.

If we can get this to work in the browser instead of using the api endpoint (which costs money every innvocation) im happy to merge it.

[hexley21]

Hmm, strange, probably something slipped out of my hands when implementing feature, I will deal with this soon

And about the /api, i think the main obstacle here is to migrate the components that depend on nodejs environment to browser, I'm not much sure how the /api endpoint works, but if bitcoinjs is in use, we will stumble into compatibility problems, which actually are solvable, but requires quite time an I think this is a job for another PR 😂

[hexley21]

fixed the issues caused by invalid dependencies in pacakge.json & also converted signed PSBT hexes from Buffer to uint8Array used for instantiating a transaction object for broadcast preparation.