CPS-0002 | Pointer Address Removal

[AndrewWestberg]

Not exactly sure of the new process or if it has been approved for usage, but I figured this was a good one to test out creating a CPS document before drafting the CIP. Open for comments please.

[rphair]

thanks @AndrewWestberg - this seems like it could be good material for a CPS, unless your reasoning & a general understanding of the problem end up pointing to only one optimal solution (in that case it should be converted into a CIP for that solution).

[rphair]

@KtorZ I've raised the question before (#372 (comment)) about whether there's a category Core corresponding to protocol changes. I am only thinking that if this CPS remained only in the Wallets category then it might not be linked with the most important open question (at end of current draft): Hardfork and not allow them to be used at all for output utxos?

[AndrewWestberg]

Changed category to Core for now.

[JaredCorduan]

Thank you for writing this @AndrewWestberg , I agree completely with everything in it (and had been planning on writing something similar myself :) ). The original motivation was to have shorter addresses, more for things like paper wallets and the user experience, but I think in practice no one actually cares about them. This was originally given to the design team as a requirement, see 2.4.5 Short Addresses in the Shelley design document.

[JaredCorduan]

I propose this:

At some future hard fork (it is my personal preference to prioritize this):

• disallow the creation of new pointer addresses
• translate the existing pointer addresses in the UTxO to normal addresses at the moment of the hardfork:
  • if the pointer is valid, convert the pointer to the corresponding stake credential (vkey hash)
  • if the pointer in invalid, convert the pointer addresses to an enterprise address (ie only a payment credential)

[AndrewWestberg]

When you say "convert them", won't this cause problems for wallets that are already referencing the pointer addresses?

I think it might make more sense to just leave them as-is, but they no longer count as staked. They can still be referenced as holding input utxos, but they will no longer be allowed to be used for transaction output targets.

I think this would be the most seamless upgrade path, but happy to hear more about the automatic conversion process too.

[JaredCorduan]

When you say "convert them", won't this cause problems for wallets that are already referencing the pointer addresses?

It could, yes (it would depend on what they do). Are you aware of any wallets that support them? I think of the 11 of them in the ledger state, I think less than half of them are even valid.

[JaredCorduan]

I just realized that there are really two cases that the wallets might care about: 1) utxo mysteriously disappearing (ie tracking a pointer address that turns into a normal address), and 2) utxo that are owned by a payment credential that the wallet is unaware of (because they were introduced by the translation).

Provided there isn't a proliferation of pointer addresses between now and when this hard fork event happens, we have to decide if a smooth migration is worth the ~3 UTxO that are effected. I think @SebastienGllmt owns one of them. :) (of course, by drawing attention to this, maybe the situation will get worse, but I guess that ship has sailed :) ).

[KtorZ]

I am proud (or ashamed?) to be one of the member of the 11-VIP-Pointer-Club. For what it's worth, I wouldn't mind this UTxO to be turned into a normal UTxO through the procedure you're describing Jared.

In principle, wallets do discover UTxO by addresses, not by output reference. So in theory, changing the underlying UTxO but preserving the same locking conditions (and if possible, delegation) should work just fine.

Plus, the few users that have created pointer addresses (if they aren't already all in the room) are most likely tech-savvy enough to recover their funds at the target addresses themselves; provided that the credentials owning them remains the same.

[JaredCorduan]

I just realized a potentially huge complication with my proposed plan. It may be very difficult to give the hard fork combinator access to the pointer map (which is needed to resolve pointers into stake credentials). The consensus layer and the ledger currently enjoy a really great logical separation. Getting the pointer map into the translation context may break this abstraction.

If this is indeed prohibitively problematic, I will instead just propose translating all pointer addresses to enterprise addresses.

[AndrewWestberg]

I think enterprise addresses makes sense. There's little reason to go through the extra work of coding the resolver for all the pointer addresses for just 3 valid ones.

[jmhrpr]

What if funds at a Plutus script requires sending funds to a pointer address?

[JaredCorduan]

That's a very good point, @jmhrpr . Not resolving the pointers (as you suggested in the cardano-ledger PR) makes them effectively an enterprise address. I doubt anyone is doing something like this inside a plutus script (since there are only ~11 of them on mainnet), but what you suggest is probably the more proper thing to do. thank you for pointing this out!

[michaelpj]

This seems confused over whether it's a problem statement or a solution proposal. While I think it would be nice to have a separate problem statement, I think in this situation there's really only one plausible solution: remove them. So I think this could just be a CIP.

[dcoutts]

Note that #379 also depends on removing pointer addresses.

[rphair]

@dcoutts @AndrewWestberg if removing pointer addresses is indeed a dependency of implementing Ouroboros Leios then I would recommend (and will bring up during the triage of this proposal in today's CIP meeting) that this be converted into a CIP with a clear Path to Active indicating that dependency.

[SebastienGllmt]

Another problem:
The pointer address format is of undefined length which makes it harder to extend the address format in the future if ever needed (ex: #310)

[JaredCorduan]

I don't understand this point (though I am in full agreement about getting rid of pointer addresses). The difficulty in extending the address format in the future is the fact that we have now committed the first four bits of the address to determining the type. Of these potential sixteen types, we are currently using eleven of them, two of which are for pointer addresses (one for each type of payment credential). I don't see how the variable-length encoding is related to extending the formats.

[KtorZ]

Would it make sense to frame this CPS more as a problem than as an actual solution? The problem being that pointer addresses are unpractical for various reasons, they're also an obstacle to getting Leios implement (@dcoutts I'd by the way appreciate some lights on that, because this doesn't strike me as obvious 🤔?).

One "obvious" solution is to remove them; and the less obvious thing is how and what are the implication for owners of those addresses. This can come as a CIP later on; in the implementation plan of Leios.

[dcoutts]

The problem being that pointer addresses are unpractical for various reasons, they're also an obstacle to getting Leios implement (@dcoutts I'd by the way appreciate some lights on that, because this doesn't strike me as obvious thinking?).

@KtorZ See the report section 4.6 for details. In summary, the correctness of the new "reassembly" operation relies on the ledger having a "determinism" property. We believe the pointer address feature violates this property.

[Ryun1]

Hey @AndrewWestberg, due to lack of author activity I am going to mark this proposal as waiting for author.

Please let us know if you still want to pursue this problem statement 🤓.

[AndrewWestberg]

Hey @AndrewWestberg, due to lack of author activity I am going to mark this proposal as waiting for author.

Please let us know if you still want to pursue this problem statement nerd_face.

I think it doesn't need to be pursued as a problem statement. If the plan is already to remove pointer addresses on the IOG roadmap, we don't really need this.