Discussion: Bring your own signing algorithm via XRPL Programmability?

[sappenin]

This discussion point echos some ideas I've been thinking about relating to signature algorithms supported by the ledger. Currently, XRPL supports Ed25519 and Secp256k1-based digital signature algorithms (here's an interesting blog post relating to the introduction long ago of Ed25519 into the XPRL).

One way to think of the purpose of digital signatures (or, more concretely, signed transactions) in the XRPL is to view this as an end-user's primary mechanism to tell the ledger (and the world) that they "approve a transaction." For example, by signing a an XRP payment transaction with one's private key, that person is telling the world, "I approve of paying some XRP from my account." From this lense, it's interesting to imagine other ways for for XRPL users to signal this kind of transaction approval.

For example, what if someone wanted to create an XRPL account that uses a different DSA? I also find it interesting to imagine what other possibilities emerge with this kind of capability.

In any event, the idea here would be something like a Smart Signatures whereby any account can be configured with a WASM program that conforms to a simple ABI indicating whether a particular transaction is validly signed. There are of course many tradeoffs with this idea. I'll list some, but am also curious to hear what anyone else thinks about this.

Pros

• Allows the ledger to extend transaction signing capabilities to user-defined mechanisms.
• Enables new programmability use-cases (e.g., approve a TX based on an Oracle, Credential, etc).
• Might be a way to allow the ledger to stay safe in a PQC world.

Cons

• "Bring your own DSA" means auditing and confidence on any particular implementation could likely be severely reduced.
• Account owners might mess up and accidentally configure an incorrect WASM contract.
• Probably many that I'm not thinking of -- chime in below and I'll update this list with your ideas.

[mvadari]

Should we really be allowing/encouraging people to "roll their own crypto"?

[xVet]

There's a lot to gain in also allowing people to shoot themselves into the foot.

The advantage is in the tradeoff basically.

[sappenin]

Should we really be encouraging people to "roll their own crypto"?

No.

Should we really be allowing people to "roll their own crypto"?

Maybe yes, especially for the sake of innovation.

That idea overall is the beauty of "Smart Features" -- you don't have to use them, but if you want to, you have freedom to choose what you do. (I also expect that if this particular proposal were to ever become reality on Mainnet, there would be a few well-audited, well-supported algo implementations that aren't just "roll your own crypto")

[mvadari]

I'd be concerned about hacks/scams using this for their own benefit.

[shortthefomo]

My idea I voiced on the space, was allowing a different algorithm used by another network to be used. Giving address parity of two accounts, this concept already exists between XRPL and Xahau due to them using the same algorithm.

*extra possibly going off the rails
But theoretically also could allow for signing a tx on XRPL that simply validates the signature and a new transactor type allows a external service to copy/push the signature over to the other network that effectively the attached external service listening to XRPL executes what ever that payload was / pushes the signed tx request across. Call it remote_procedure_call...

Any how nice to see I'm not the only crazy one thinking around this.

Thanks for the thread @sappenin

[shortthefomo]

Another idea here if signatures were 'extensible' one could expend the core signature to include further data. Eg. Only allow signing from a device with MAC address xyz. (Yes know MAC Addresses not safe but it's an example). It's further restrictions on top of existing signature...

Do think even if it's just something that makes it to a POC on a devnet, is worth exploring.

[ximinez]

I don't want to call remote_procedure_call a non-starter, but it's pretty close to one. The reason is that every transaction is executed by every server, validator or not, and they must all come up with the exact same result. Calling an external service makes that nearly impossible, because there's no guarantee that the remote service will give the same answer, plus network conditions can cause all kinds of variance.

Something to consider, though, is pushing that kind of check to the client layer, and having the client provide some kind of proof in the transaction that the "smart account" could then use to validate the transaction is correctly signed.

[shortthefomo]

Bad function name it's not executing anything all it's doing is persisting the RPC of another network it's the job of another service to push that across.

Anyway this example is irrelevant, rather opening up programmability around they key what curve is used, can one extend signature for extra requirements etc... I'm just spit balling ideas at what could be built around having that programmability there.