EIP-41 Stealth address standard

[ross-weir]

No description provided.

[arobsn]

It would be good to describe how to encode a P2SA and make clear that it's a special kind of address, as it's not ErgoTree-based like others.

You can take this comment as the basis for that: #87 (comment)

[aslesarenko]

1. There is no need to use registers to store gr, gy... parameters. Storing in a register of SELF (especially when accessed unconditionally with .get ) is always equivalent to embedding those values in the contract body (i.e. in ErgoTree). This is not only functionally equivalent, but also stored in the same box, just in different register.
2. When registers are not used and parameters are embedded, no need to use special P2SA, because P2S will be enough and different receiverPublicKey will generate different P2S addresses.
3. this will also solve scalability problem
4. this encoding saves some space in box storage also
5. all information necessary for wallet and other off-chain tools can be extracted from p2s address alone.
6. when wallet user want to receive stealth payment, he need to choose the payment type, and then the wallet can generate p2s stealth address.
7. even when gr, gy... parameters embedded in ErgoTree, they still can be segregated into constants array of ErgoTree and serve as paremeters of contract template
8. talking about templates. wallets can adopt EIP-5 to generate parameterised addresses for different use cases. Stealth Address is one such use case, so it is a good application of Contract Template EIP-5

[ross-weir]

1. There is no need to use registers to store gr, gy... parameters. Storing in a register of SELF (especially when accessed unconditionally with .get ) is always equivalent to embedding those values in the contract body (i.e. in ErgoTree). This is not only functionally equivalent, but also stored in the same box, just in different register.
2. When registers are not used and parameters are embedded, no need to use special P2SA, because P2S will be enough and different receiverPublicKey will generate different P2S addresses.
3. this will also solve scalability problem
4. this encoding saves some space in box storage also
5. all information necessary for wallet and other off-chain tools can be extracted from p2s address alone.
6. when wallet user want to receive stealth payment, he need to choose the payment type, and then the wallet can generate p2s stealth address.
7. even when gr, gy... parameters embedded in ErgoTree, they still can be segregated into constants array of ErgoTree and serve as paremeters of contract template
8. talking about templates. wallets can adopt EIP-5 to generate parameterised addresses for different use cases. Stealth Address is one such use case, so it is a good application of Contract Template EIP-5

Thanks a lot for the feedback!

Embedding values is something I thought about but decided against because the parameters (gr, gy...) are created from one-time secrets generated by the sender. Because there's no way for the receiver to know what values the sender used there's no way to know if a P2S address is a stealth payment for them, they'd still need to check all P2S addresses that look like a stealth payment to see if they're spendable - they may even check P2S addresses that look like stealth payments but aren't