Withdrawals

[Quantumplation]

Given the prevalence of the "withdraw 0" trick, it'd be nice to be able to tweak the withdrawals field of the script context

[ariady-putra]

Hello @Quantumplation ,

I'm interested about the "withdraw 0" trick, what is it about?

As for your suggestion, what do you think about ariady-putra@0402536
?

I just exposed all ScriptContext.Transaction fields.

For withdrawals there are:

• set_withdrawals (_, withdrawals: Dict)
• insert_withdrawal (_, withdrawal_key, withdrawal_value, withdrawal_compare: fn)
• insert_withdrawal_with (_, withdrawal_key, withdrawal_value, withdrawal_compare: fn, withdrawal_with: fn)
• union_withdrawal (_, withdrawal_key, withdrawal_value, withdrawal_compare: fn)
• union_withdrawal_with (_, withdrawal_key, withdrawal_value, withdrawal_compare: fn, withdrawal_with: fn)
• delete_withdrawal (_, withdrawal_key)

The same goes for redeemers and datums, and added set_id and set_fee as well.

[Quantumplation]

If you want some logic that runs globally for the whole transaction, you can make it a staking script and then "withdraw" the staking rewards. The ledger doesn't care that there are 0 rewards to withdraw, it'll run the script regardless.

So, for example, your spending validator could just check that script X is in the list of withdrawals, and then the staking script can check that globally the whole transaction is valid. It saves a huge amount of execution units, makes it easier to deal with double satisfaction, etc.

And that API looks great to me!

[ariady-putra]

If you want some logic that runs globally for the whole transaction, you can make it a staking script and then "withdraw" the staking rewards. The ledger doesn't care that there are 0 rewards to withdraw, it'll run the script regardless.

So, for example, your spending validator could just check that script X is in the list of withdrawals, and then the staking script can check that globally the whole transaction is valid. It saves a huge amount of execution units, makes it easier to deal with double satisfaction, etc.

Huh, interesting on what people could come up with!

And that API looks great to me!

Cool, I'll push

[ariady-putra]

https://github.com/aiken-extra/tx_util/releases/tag/1.170.202403

[Quantumplation]

@ariady-putra you might also be interested in CIP-0112 which introduces a "proper" mechanism for this.

[ariady-putra]

Hey @Quantumplation ,
thanks for sharing! This is very valuable. There's so much for me to learn

I would also like to have a receiving validator, so that this type of contract must only contain valid UTXOs. It prevents assets being locked in a contract, and also prevent people from spamming a contract's UTXOs. I don't know about the feasibility though

[Quantumplation]

You can do a receiving validator, or close to it, by minting a token and paying it into the script

[ariady-putra]

You can do a receiving validator, or close to it, by minting a token and paying it into the script

Hey, interesting input. It's something for me to consider