Implement Stealth Address Support
Opened this issue · 0 comments
Stealth Addresses (referred to as Enigma/Cloaking Addresses within the Cloak sphere) are utilised extensively by the Enigma transaction progress. During an Enigma send operation, the sender and participants (Cloakers) exchange stealth addresses in order to send and receive funds.
When a participant agrees to participate in an Enigma send operation, they a current Enigma/Cloaking address [CWallet::GetEnigmaAddress] in the [acceptance] response sent to the sender. This allows the sender to generate one-time payment addresses for the participant on-the-fly, to which the sender has no access to in terms of spending.
The generation of one-time-payment addresses occurs as part of the Enigma transaction generation process [CCloakingRequest::CreateTransactionAndRequestSign -> CCloakingRequest::CreateEnigmaOutputs -> CWallet::GetEnigmaChangeAddresses]. One-time addresses for both the participants (cloakers) and sender are generated and used as the output addresses for the Enigma transaction. This allows the sender to securely transmit the unsigned transaction to the participants, who can verify the presence and validity of one-time payment addresses associated with their Enigma/Cloaking address and ensure that the expected amount of funds [stealth output amounts for the participant in question exceed their input amounts] are paid to their one-time-addresses.
As per standard stealth addresses transactions, both the sender and participants are required to scan incoming transactions [within a newly received block] in order to detect received stealth payments to their Enigma/Cloaking address(es).
The code within Cloak for the current Stealth Address implementation is pretty straightforward and doesn't differ much in terms of detection and receivership from the original implementation in Vertcoin (or similar implementations). The code related to ad-hoc payment address generation is however somewhat bespoke as a single ephemeral public key (randomly generated public key, stored in OP_RETURN) is shared by all Stealth/Enigma outputs for an Enigma transaction.
NOTE: We are currently unaware of a Stealth Address implementation running against the latest Bitcoin codebase. It seems that Vertcoin removed Stealth Address support during their rebasing to a newer version of their codebase with a view to re-implementing it at a later date. As of now, it appears this work is either ongoing or on indefinite hold. There may however be an alternate implementation in a coin based on the latest Bitcoin Core codebase, and if so, this would likely make a good candidate for Stealth Address code migration.
NOTE: It is critical that Cloak/Stealth addresses (and associated keys) are stored safely and securely in the wallet in order to detect any incoming stealth payments. When HD (heirachical determinstic) support is added, Cloak/Stealth addresses should be created (and be able to be recreated) from the HD wallet master key. This will allow stealth payments to be correctly detected during a wallet restore (from a seed word list).