Re-think wallet utxos with datum/script references

[jy14898]

Currently there are two issues I see:

1. We support paying into wallets with datum via mustPayToPubKey(Address)WithDatum, but no way of spending such utxos manually via mustSpendPubKeyOutput, as it checks there is no datum (possibly from legacy models about Ogmios).
2. In the presence of such utxos in the users wallet, the balancer may select them. This is an issue for inline datum, as it will make it impossible to construct the ScriptContext for any PlutusV1 script. We should kick into a PlutusV1 compatible selection mode when necessary, only selecting inputs which will make a valid transaction.

This may also be an issue with script references too

[klntsky]

no way of spending such utxos manually via mustSpendPubKeyOutput, as it checks there is no datum

Can we just remove the check?

[klntsky]

2. Totally agree

[jy14898]

Can we just remove the check?

I think so, that's what I did for my initial testing anyway. We might have to attach the datum for the non-inline case, I'll do some testing

[jy14898]

@klntsky Actually, I'm not sure what the expected behaviour should be in general (for plutus v2). Selecting wallet utxos that have datum/scripts attached will destroy that information, this is likely something the users do not want.

I'm thinking we should only allow spending of these 'rich' utxos when they've been explicitly set to do so via mustSpendPubKeyOutput, never by the balancer when balancing.

[bradley-heather]

It's an interesting point. One of the main use cases for attaching a datum to a pubKeyOutput is to prevent double spending from a validator in which case the user probably has no idea they even have a UTxO with a datum attached or what that means. And as soon as that UTxO enters the wallet the datum becomes useless.

Therefore I think wallet UTxOs with datums should be selectable but perhaps only after all valid UTxOs without a datum have been exhausted. Otherwise a user that's using a protocol that implements the above approach may very soon run into issues of not having any spendable UTxOs and very confusing errors.

[jy14898]

One of the main use cases for attaching a datum to a pubKeyOutput is to prevent double spending from a validator

Can you explain this a bit further? I don't understand how that would be implemented

I think the biggest use for 'rich' utxos in the wallet would be as reference inputs (either for the datum or script), at least for testing purposes.

[jy14898]

I think I get the idea: validator checks n amount is sent to an address, you could run multiple validators to get the same payment to count towards those validators so you tag the output with some specific datum to make it only valid for one payment

[jy14898]

I think we should continue allowing spending wallet utxos with datum/inline datum/script refs (when possible), it seems there's no set expectations for what to do when they exist in a wallet

[bradley-heather]

As an example:

• Say you want to spend 2 inputs from NFT marketplace. To spend each you must pay 100 ADA to some PKH
• Without datums you can pay 100 ADA once, and both inputs will pass validation
• A common way prevent this is to enforce unique datums (eg. tx ref of spent input) to be attached to payment UTxOs

UTxOs as reference inputs can easily be stored at validators or multi-sig wallets that are for that use case only if the protocol doesn't want them being spent.

At the end of the day you have to think about the end user. Who probably doesn't even know what a datum is.