Careful, this will be incorrect as the signatory is missing, which will add bytes (eg the signature)

There’s something wrong with this. The unit tests should be in one folder (usually src) and the integration tests in another (usually tests), like it’s done for ecash-lib.

Then we can use the wildcard.

Otherwise we’ll have to add new tests here every time we add a new file.

IMO you should change this to Recipient (or Output), and add sats and tokenId and isMintBaton, just like Output in my BIP70 diff.

And then we use that as unified interface for where to send tokens and the wallet just handles it.

Remember ALP allows multiple token IDs per send, I think we should enable this by default, that’s why it should be part of the output.

Also, keep in mind that we also need to enable attaching data in the OP_RETURN. For ALP/eMPP, this will be extra eMPP pushdata, and for non-eMPP, this could be OP_RETURN. Either way it would be an UInt8Array[] (which must be empty for SLP btw)

Event is really not a good name IMO. TransactionsConfig (because you want this to be multiple ones). Recipients might work to. Or just SendConfig.

And I think there should be one unified config for sats only, tokens, and OP_RETURN data

I think you just want one interface which handles all three—remember they can overlap in ALP, eg SENDs and MINTs and BURNs can be in 1 tx .

So you want the outputs as I describe above (with the mint baton Booleans), and the burn amount, and the OP_RETURN data.

• outputs/recipients (sats and/or tokens, or mint baton)
• burns (list of tokenId + burn amount)
• opreturn data

And then the function figures out how to build the tx(s) based on that.

Probably want to use Partial here instead of duplicating types

ok -- added P2PKHSignatory and signing with dummy values

we could completely obscure all of the signing and estimating stuff and just build the tx with inputs signed by the wallet. But I think it's a useful static method to be able to just get the utxos for any arbitary tx, and we would have to convert signed inputs back to utxos to do this (well, I guess we could keep utxos as a class property of the built tx?. Mb that is a better approach...but we would still have to track them separately, we would still have to sign more than once. I like preserving the "just get the utxos sync" --> "just the signed tx and info about it, sync" --> "broadcast the tx, async"

good point, re-organized.

went with somethin else but happy to bikeshed on this one a bit...the point of the class is to make things easier for devs but it's a tricky concept to describe succinctly, and I'm not really sure it's at all readily understandable to someone who hasn't been doing this for years