CIP-???? | Sign transaction IDs together with guards

[polinavino]

We propose the following change to the ledger signature checking mechanism : instead of signing just the transaction ID, users will now be required to sign the hash of the pair of (i) transaction ID and (ii) the hash of the guards listed in the transaction body. This way, key holders will have no need to inspect the transaction they are signing in
order to be sure that the transaction satisfied its guards (if posted on-chain).

---

(rendered latest proposal version)

[rphair]

thanks @polinavino - new reviewers please refer back to the original submission of this idea & why it's distinct from CIP-0112:

• #1105

@colll78 the CIP editors at this week's meeting were keen to you get your audit / security view of this CIP once prepared. Also @GeorgeFlerovsky you'd expressed an interest and of course @lehins we would look forward to your view on how all this fits together.

[Ryun1]

Suggested change

	This CIP (which depends on CIP-0118) serves both a practical and a conceptual purpose.
	This CIP (which depends on [CIP-0118 | Nested Transactions](https://github.com/cardano-foundation/CIPs/pull/862)) serves both a practical and a conceptual purpose.

[Ryun1]

Suggested change

	** Note ** There are other options for how exactly to compute the final hash of the data that will be signed. E.g.
	**Note** There are other options for how exactly to compute the final hash of the data that will be signed. E.g.

[fallen-icarus]

The motivation for this CIP seems to be that users will remove the fee from a tx built by the service provider. But this doesn't seem to be true in reality. Wallets like Vespr charge fees already and users do not remove this fee. For non-technical users, they don't even have the necessary know-how to remove the fee. Technical users do, but they would likely have their own infrastructure anyway and have the know-how to get around any service fee.

So is this CIP actually solving a real problem? If the target user is the non-technical group, what is wrong with the status quo? Vespr seems to have no issue charging fees.

[polinavino]

@fallen-icarus i thought about this point a bit and the following comes to mind :

• with the feature proposed here, the user does not need to deserialize a transaction. They do need to be able to construct and serialize an observer, and they also need to be able to hash.
• without this feature, the user would need to deserialize the entire transaction just to check that the right guard script is included. This is not only making it more complicated and error-prone for a non-technical user, but also making it way easier to get around the fee (as they have to deserialize the transaction anyways)

[fallen-icarus]

@polinavino I think you are confusing "who is doing what". Wallet software needs to do what you say on behalf of non-technical users.

They do need to be able to construct and serialize an observer, and they also need to be able to hash.

No non-technical user can do this...

So your actual threat model is a malicious wallet provider removing the fees on behalf of its non-technical users. But again, there is no evidence of this happening today on Cardano. Aggregators like SteelSwap add fees into the txs they build for wallets like Vespr, and users keep the fees in the txs.

Sorry, but I really don't think this is solving a real problem. There seems to be nothing wrong with the status quo where a service can add its fees directly to the tx and send that tx to the user's wallet unshielded. There is no evidence of users messing with these transactions to remove fees.

[rphair]

@polinavino @fallen-icarus as per the post- CIP meeting routine I'm updating this thread & the PR status based on our meeting resolutions, and I think the last few comments outline the considerations fairly well.

Since it's still not agreed how weighty these considerations are, I think our resolution not to confirm this CIP as a candidate yet still stands... which I think can be resolved by addressing all the possibilities in the CIP document itself (including manual work for fee avoidance, "malicious" wallet apps, etc.) because it will be likely still serve as a useful CIP even if less necessary to deploy based on social / commercial factors.

[polinavino]

It seems like the architectures/trust models you (@fallen-icarus ) point to are sufficiently different from the design we propose here. They seem to be examples of ways a single provider can design an app such that the provider gets paid when this app is used. I can't tell what exactly is happening, but this is how i understand things

• perhaps the app makes it quite difficult for the user to mess with the transaction the app produces before signing it. This is ok, because the user only needs to trust code they themselves run locally
• the user can check that they are running an authentic version of the app (and therefore trust that code)
• the app queries the chain using blockfrost (trust needed here)

The protocol we propose here is fully decentralized and doesnt not require any trust :

• requires the service provider (could be anyone with a node, not necessarily trusted), run on a different computer, to trust the LC. The step of concealing the transaction body from the LC is to protect one untrusted party from another.
• The signature on the txid ++ guard protects the LC from a malicious SP.
• The thing you have to pay for is not the use of the app, but rather the query answer. As this would be open source, it would be extremely easy for someone to modify the code once so that nobody pays for the tx-construction service ever again (as opposed to, e.g. someone writing an app like VESPR but that doesnt pay VESPR)

The design we propose is very much in line with blockfrost decentralization (e.g. via icebreakers infrastructure). It provides an alternative to icebreakers that is suited for a different purpose.

They do need to be able to construct and serialize an observer, and they also need to be able to hash.

No non-technical user can do this...

Thats the entire design of the client. The workflow is

• user selects intent template from supported ones (eg "purchase a ticket")
• user fills out template (their spending keys, change address, etc.)
• LC outputs serialized guard g
• LC sends it to SP

Once LC receives a txid in response from SP

• LC computes tx_g = hash (txid ++ hash g)
• LC signs tx_g and sends it to SP

[fallen-icarus]

They seem to be examples of ways a single provider can design an app such that the provider gets paid when this app is used.

This is not correct. It is multiple service providers each adding a fee to the user's tx. Consider a DeFi swap:

1. A user of Vespr wants to make a swap so they get an offer from a DEX aggregator like SteelSwap. This offer is effectively a tx that contains a service fee for SteelSwap.
2. Vespr looks at the tx and adds their own service fee to the tx. The tx now has fees from two different service providers.
3. Vespr presents the final tx to the user to sign.
4. The user signs it and Vespr submits it to the network.

This one tx is paying both Vespr and SteelSwap despite neither service fee being enforced by a smart contract.

[fallen-icarus]

The design we propose is very much in line with blockfrost decentralization

So is the status quo! If Vespr added a third service fee (for a decentralized Blockfrost) to the swap tx, you are assuming users will remove this fee. But there is no evidence to support that concern, and I personally do not share that assumption. You are asking to make a change to the Cardano ledger without first proving that removing service fees is actually an issue.

[polinavino]

Ah, i see. Thanks for clarifying how VESPR does things. I am really surprised by the argument that "since a vulnerability has not yet been exploited for social reasons (maybe social pressure, or moral convictions, or laziness?), it is therefore fine to not address it".

VESPR chose to take that risk and it is working fine for now. In our model, we would be forcing every single service provider to take on that risk. The strategy we propose allows a very easy way to eliminate this issue with an extra hash computation. We are working towards creating sustainable economics for blockchain infrastructure services through cryptography rather than trust.

[fallen-icarus]

... "since a vulnerability has not been exploited yet ... it is therefore fine not to address it".

You seem to be missing my point. You are assuming this is a vulnerability! I do not agree with you at all. Don't forget that Ouroboros is based on a 51% honest majority. By your logic, Ouroboros has an unpatched vulnerability. Why is it okay for Ouroboros to rely on an honest majority assumption but not okay for the funding of a decentralized LC?

Instead of relying on an honest majority assumption, you are trying to use cryptography that creates a terrile UI/UX. It is so bad, that I doubt anyone will actually use the LC you are trying to create. You are asking people to be okay with signing txs they can't see inside of with the promise that observer scripts will protect them. But IMHO this is not realistic. Marlowe failed because end-users do not want to write custom smart contracts; making it more user-friendly did not change that. End-users want to use standardized smart contracts. Can general standardized observer scripts be used to protect end-users from all possible malicious behavior? I doubt it.

I strongly believe your LC is better off relying on an honest majority assumption than trying to completely eliminate the need for trust with its current approach. What I keep trying to stress is that this honest majority assumption may actually be safe to make. If it is, we don't need to change anything about Cardano.

[polinavino]

A repercussion-free opportunity for a single user to act dishonestly and gain Ada as a result is not the same thing as 51% agreement that it is ok for them to do the dishonest action.

As for a "script protecting end-users" - is this a general argument against the idea that it is possible to translate a template into write reliable Plutus code? Or that some malicious or poorly written software will do this badly? The latter applies to VESPR too - their software could easily be showing the user a transaction that's different than what they're actually signing. Of course, this needs to be tested and analyzed.

The transaction templates themselves will look mostly like conditions on produced and consumed values. The goal here is much much simpler contracts than marlowe, and automated Plutus code generation from single-expression templates such as this Registration (rather than general-case financial contracts), which the participant needs to fill out with they own PK hashes, etc.,
GetTicket : Participant x EventOrganizer x Price x DREp -> Registration
We are still discussing the details here, but it will be much simpler than Marlowe (in particular, because these contracts are not concerned with the evolution of the state of an on-chain program).

A more general goal of this work is to support intents on Cardano. We already have a way to express an intent - a Plutus script. Now, we need a mechanism that separates intents from their fulfilment, i.e. a way to decouple a transaction from the Plutus script intent.

[fallen-icarus]

@polinavino Let me start over because your reply makes me think there is still a misunderstanding.

Imagine a decentralized Blockfrost needs to make 1,000,000 ADA per year to be financially sustainable. Let's also imagine an average of 5,000,000 txs (that use Blockfrost) per year. Naively, we could just say that every tx needs to pay a Blockfrost fee of 0.2 ADA to be sustainable, but this won't work because free-loaders will avoid the fee.

However, if we assume that at least 51% of txs pay the fee, then charging 0.4 per tx will make Blockfrost financially sustainable: 49% of txs will strip the fee but the other 51% will pay it. The following table shows the relationship between the percent of txs that pay and the required fee/tx for Blockfrost to be financially sustainable:

Honesty	Required Fee/Tx
100%	0.20 ADA
66%	0.31 ADA
51%	0.40 ADA
33%	0.61 ADA

If you expect only 33% of users to respect the fee, then Blockfrost would still be financially sustainable by charging 0.6 ADA without requiring your method of obscuring the tx. I personally expect greater than 51% honesty which means charging 0.3-0.39 ADA would work. I keep pointing out evidence that honesty is currently quite close to 100%.

You are calling the lack of cryptographic enforcement a vulnerability but this is just being cynical of humanity. You think users will eventually start being dishonest. I do not share this cynicism. While free-loaders certainly exist, I believe the majority of people will act collaboratively and honestly. So I do not see the lack of cryptographic enforcement as a vulnerability. I do not think we need to make the UX worse for everyone just to protect against the free-loaders who are a small minority. It is very similar to taxes, some people do evade taxes, but most people are actually in favor of paying taxes; it is the magnitude of the taxes they disagree on.

... is this a general argument against the idea that it is possible to translate a template into write reliable Plutus code?

No. As I said, I don't think users want to create custom plutus scripts for every tx. It doesn't matter how user-friendly you make it - they won't use it.

---

To be clear, I'm not against your LC implementation. But I am against making any changes to Cardano before you prove your LC works and is accepted by users. If we make this change before you validate the idea with the market, what happens if the market rejects your LC like I am predicting it will? We can't easily undo this change. It is significantly better to first prove your model works before making a change to Cardano for it.

If you come back a year from now with proof I'm wrong, I will gladly back this CIP. But until then, I'm against this CIP since its only use case seems to be an LC model that I think will be rejected by the market.

FYI You are not the only person working on financial sustainability of decentralized services. I am also working on it (with CIP-159) and I'm relying on the concepts in the table above. How about we do experiments to see which method is better before we make an irreversible change?