[ERTP] Minimum Built-in ExtentOps

[katelynsills]

Edit

Mark and I talked earlier today and discovered that my plan of merely comparing the ID (handle) values of objects would likely lead to users being easily tricked. For example:

// These would count as equal to the AmountMath but not the user
// allowing for attacks involving changing the human-readable parts of the extent.
const myHandle = harden({});
const extent1 = { handle: myHandle, thing: 'coupon for trip to Hawaii' };
const extent2 = { handle: myHandle, thing: 'coupon for discounted toothpaste' }

We decided that we must then do comparisons with sameStructure recursively checking that every key and value is the same. This means that we can no longer use sets internally to help with performance.

So, we decided the minimum built-in MathHelpers are:

• natMathHelpers (as it is now)
• SetMathHelpers (operations on arrays of elements which may have any keys and any values, but which will be compared by expensively comparing every element with every other element using sameStructure.)
• StrSetMathHelpers (operations on arrays of strings, which will be compared by string identity cheaply using Sets).

Additionally, there was the question of how to handle duplicates. Duplicates could potentially appear in two places: 1) two of the same thing within one of the arguments in the mathHelpers function (such as left), 2) something in left that is equal to something in right. We can't think of a valid use case for having duplicates and think this would mostly be a mistake. So, we are going to try to throw an error if we see a duplicate (and we will check for them) even if it is costly.

Previous content

Let's use this issue to organize the minimum viable built-in extentOps that should be available for use for Zoe Alpha.

I think it should be:

• natExtentOps (as it is now for the most part)
• natListExtentOps (an array of Nat elements, most often sorted)
• handleExtentOps (an array of empty objects used for identity, that we call handles)
• inviteExtentOps (an array of objects describing invites, including unique handles)

Pushed past Zoe Alpha:
strListExtentOps (an array of string elements, most often sorted) #538

We've learned that uniExtentOps are incompatible with Zoe so we're dropping them (#510). We've also learned that having extentOps arguments that are functions won't work in our distributed environment because they aren't pass-by-copy (#385). Lastly, we know that sets aren't yet pass-by-copy and they operate on object equality rather the equality of the contents of the object, so we cannot use sets and must use arrays.

So, I propose that we give up the flexibility for Zoe Alpha and only provide the above extentOps which if they are a collection, are based on arrays. Any additional checking of the extents for business logic reasons (i.e. is the pixel within the bounds of the gallery? is the invoiceNumber below the highest used number?) can be done outside the extentOps.

[DavidBruant]

Mark and I talked earlier today and discovered that my plan of merely comparing the ID (handle) values of objects would likely lead to users being easily tricked.

// These would count as equal to the AmountMath but not the user
// allowing for attacks involving changing the human-readable parts of the extent.
const myHandle = harden({});
const extent1 = { handle: myHandle, thing: 'coupon for trip to Hawaii' };
const extent2 = { handle: myHandle, thing: 'coupon for discounted toothpaste' }

I'm not sure i understand this example. Specifically, i don't understand where the handle property comes from for the extent. It wasn't needed for the ballet ticket tests (btw, the tests pass locally. They failed to pass because of a timezone issue leading to a failed comparison on date strings -_-#)

Such an attack can be prevented by "bundling" the object identity and the data:

const myHandle = harden({thing: 'coupon for trip to Hawaii'});
const extent1 = myHandle;
const extent2 = harden({thing: 'coupon for discounted toothpaste'});

From there, this specific handle can only ever have the data it's been initialized with because it's frozen, no way to change it

My conclusion being that i think that identity-based comparison can work

[DavidBruant]

For my ballet ticket example, it would look like:

const ticketHandles = Array(5).fill().map((_, i) => harden({
  seat: i+1,
  show: 'The Sofa',
  start: startDateString,
}))

const balletTicketPayments = ticketHandles.map(ticketHandle => {
  const amount = amountMath.make(harden([ticketHandle]))
  return balletTicketMint.mintPayment(amount)
})

Compared to

agoric-sdk/packages/ERTP/test/unitTests/test-mintObj.js

Lines 123 to 127 in 4725143

	const balletTicketPayments = ticketDescriptionObjects.map(ticketDescription => {
	const handle = {};
	const amount = amountMath.make(harden([handle]))
	return balletTicketMint.mintPayment(amount, JSON.stringify(ticketDescription))
	})

Being able to use to description object directly as the handle looks really, really elegant

[DavidBruant]

Specifically, i don't understand where the handle property comes from for the extent.

I'm starting to understand that inviteMathHelper was merged into setMathHelpers and consequently, setMathHelpers needs to be viable for (Zoe) invites. Zoe invites carry their identifying handle as a handle property on the extent object

... after reading the zoe.js code, I'm not 100% sure, but i think what i described (using the extent object identity as the handle itself) could also work for Zoe invites

[katelynsills]

Thanks, David. Your opera ballet tickets do not need a handle. Your code (edited below) is almost correct, but we should be shouldn't be calling it a handle or using the extent as a handle. A handle is meant to be a unique identifier, but we already have data that uniquely identifies the seat assets:

const ticketExtents = Array(5).fill().map((_, i) => harden([{
  seat: i+1,
  show: 'The Sofa',
  start: startDateString,
}]))
const balletTicketPayments = ticketExtents.map(amountMath.make).map(balletTicketMint.mintPayment);

Some digital assets, like the opera ballet tickets, are defined entirely by the information in the extent. In other words, there's no need for further identity because the seat, show, and start information together defines a unique seat. That means that to determine whether we get what we wanted, we can just compare the information. So in this case, we want to comparing values not object identity.

But, there will be other kinds of digital assets where distinct assets still have exactly the same information. For example, there will be many identical red 2020 Mustangs, but we still need to distinguish between them, so we have unique vehicle identifiers (VINs). We can either use Strings for these unique ids (as VINs do) (and use strSetMathHelpers), or we can use empty objects to serve as the unique identifiers. This the job that handles are supposed to serve - unique identifiers when there is no other information that is uniquely identifying.

There's the further question of whether handles are improved by adding data to them - they are still used for object identity, but the data is part of the object identity. I'm concerned that there is a social attack here where a user will simply look at the data and see that it matches, but it is actually a different object identity. I don't think we want to add any properties to handles for this reason. They need to stay empty objects so it's clear they are for identity only.

[DavidBruant]

I'm concerned that there is a social attack here where a user will simply look at the data and see that it matches, but it is actually a different object identity.

This the job that handles are supposed to serve - unique identifiers when there is no other information that is uniquely identifying.

I share your concern, and I'm having a hard time conciling these 2 informations. If the handle is an opaque identifier, how would it be displayed on screen in a way a human being cannot be confused about what they're looking at?

I'm starting to think that the concept of opaque handler identifier (whether it's the extent object itself or a property on it) is in a direct opposition of the goal of preventing social attacks

I'm starting to think the social attack is not currently addressed by ERTP

i see 2 cases:

• social attacks are not possible if the user agent (software the user trusts and interacts with and acts on their behalf that includes the UI, but also storage and networking) displays a purse or payment, because the user agent, with access to the issuer, can guarantee the purse/payment is genuine and consequently, the amount/extent inside is genuine. When you're viewing a payment/purse, it has genuinly been minted and there is a trust path from the issuer to the screen.
• however, social attacks remain possible if the user agent visualizes an amount crafted by someone else and not attached to a payment/purse (like in payoutRules). If someone has access to the data portion of an extent, they can craft the corresponding amount.

If you pretend you're selling a red 2020 Mustang, you can send me an amount describing it (regardless of using a string or handler as identifier), but it does not prove me you have it in a payment/purse that you control and can sell it. It only proves you are capable of describing the asset i may want

One way to be sure you have it would be to have access to a payment or purse with the asset, but i could claim-steal it, so that's not an option

Maybe Zoe can help here, though: if i want to be sure that you have the red 2020 Mustang you're describing, i can setup a challenge contract with Zoe (this contract is a variation on automaticRefund)
This contract does one thing: wait for you to prove you have the asset (i put the challenge amount in the terms). You prove it by redeeming the invite. To .redeem, you need to send a payment with the genuine asset. If you do so, the asset is paid out back immediately and i'm told by the contract that you do have the asset you pretend you have. If you send a bogus payment or never answer, i know you don't have the asset

Ok, now i'm convinced that all solutions (pure values extent, handler as extent object or handler as extent property) are equivalent from a security perspective, so i don't care what the chosen solution ends up being

[katelynsills]

Let me try to separate discussion of what you should do next from discussion of the design. Please change the opera ballet ticket example to use setMathHelpers without any opaque identifiers/handles. The code I wrote above should be a good start.

For the design discussion:

If the handle is an opaque identifier, how would it be displayed on screen in a way a human being cannot be confused about what they're looking at?

The wallet UI would need to figure out how to represent this. Oftentimes all you want to know about identity is whether something is the same as something else, in which case, you never need to display an identity itself, just answer questions from the user and display something indicating that differing objects are not the same. For instance, maybe you have 5 swords with unique identity - the display is "5 swords" even though they are non-fungible at a lower level. This is work that we have not done yet (and can't dedicate time to yet), so I'm extrapolating.

however, social attacks remain possible if the user agent visualizes an amount crafted by someone else and not attached to a payment/purse (like in payoutRules). If someone has access to the data portion of an extent, they can craft the corresponding amount.

This is intended. An amount/units should be able to be crafted by anyone so that they can describe the digital assets to someone else without holding them. We would expect the wallet to distinguish between amounts sent by other entities and amounts that are the verified balances of purses and payments.

If you pretend you're selling a red 2020 Mustang, you can send me an amount describing it (regardless of using a string or handler as identifier), but it does not prove me you have it in a payment/purse that you control and can sell it. It only proves you are capable of describing the asset i may want

There may be special cases in which you need to prove ownership of a digital asset (maybe if negotiation is incredibly costly and you only want to deal with people who prove they are worth the negotiation costs) but in most cases, you don't need to do this.

If you use a Zoe contract to do an exchange, the other party can only participate if they escrow their assets with Zoe, meaning that they must transfer ownership to Zoe temporarily. They could not do this unless they previously had ownership. So, this problem is solved completely if Zoe contracts are used.

Your idea about using the automaticRefund example is interesting, but that person could immediately pay someone else, so the "proof" of ownership would only be good for a split second, which might make it useless.