CPS-???? | Transaction friction in minUTxO implementation

[nhenin]

This CPS documents application and transaction-builder friction in Cardano's current minUTxO implementation, where the ada required to protect persistent UTxO state is carried as ordinary output value.

It describes seven use cases and their current workarounds, and sets goals for reducing the remaining friction while preserving protection against accumulation of live UTxO state. Four open questions address capacity-price changes, compatibility with deployed contracts, incentives to remove unused outputs, and the organization of explicit deposits if a solution uses them.

Read the rendered CPS.

[rphair]

Thanks @nhenin @willjgould @polinavino for another contribution from your rapidly & significantly evolving Ledger stack. I would look forward to confirming this from Triage at our next CIP meeting (https://hackmd.io/@cip-editors/143) so contributors & editors alike can invite others to review it in parallel with its contemporary & related proposals.

@lehins of course the high-level Ledger view would be welcome at this early stage and would help to confirm it next Tuesday (or perhaps wait if something significant needs to be changed first): with input welcome from @aniketd re: #1264 + @carlostome as its reviewer.

Since the nature of this problem resembles the need for the Account Address Enhancement (CIP-0159) we should seek out review from its own authors, contributors & ongoing reviewers: @fallen-icarus (especially for these business / economic cases) @GeorgeFlerovsky @colll78 @Quantumplation @gitmachtl @mpizenberg + @AlexDochioiu for the wallet perspective.

[rphair]

Suggested change

	Title: Application and transaction-builder friction in the current minUTxO implementation
	Title: Transaction friction in minUTxO implementation

I would set a goal for the upcoming CIP meeting (at the latest) to confirm a more concise title & will make an attempt here. The current phrase has an excellent narrative of the present problem but we need more of a "headline" to attract broad review: it's not (and usually isn't) just about the number of characters.

• The term current is never applicable to CIPs and CPSs, which last forever.
• I don't think there's any point avoiding the word friction since it's used practically everywhere in the document. (I would prefer a more literal term but all synonyms used in software development are generally other metaphors.)
• Please correct me if I'm wrong but the application friction is from transaction handling and therefore this term is redundant to transaction.
• My understanding is that minUTxO is not a "parameter" that would be quoted like minUTxO and so we are talking about a concept rather than a literal value: and so it's proper to leave it unquoted as you already have.

According to usual review workflow I'm trying out this revised title in the PR itself so we can get a better view of how it might work (or not) and of course we'll keep trying updates @nhenin @polinavino @willjgould according to your own view.