When SATAN meets TITAN
Recently, core developer Danial Larimer revealed "Secure Payments to Users by Name". He descripes, based on ellyptic
curve cryptography (ECC), how to generate a unique receiving address for a user. The scheme works as follows:
Create TempPrivateKey TEMP.PRIVATE_KEY;
TEMP.PRIVATE_KEY * USER.PUBLIC_KEY => SECRET => ONE_TIME_PRIVATE_KEY => ONE_TIME_ADDRESS
The payee can send his transaction that pays to ONE_TIME_ADDRESS and attaches TEMP.PUBLIC_KEY as message to the transaction.
Every client on the network will be able to perform the following operation:
USER.PRIVATE_KEY * TEMP.PUBLIC_KEY => SECRET => ONE_TIME_PRIVATE_KEY
If ONE_TIME_PRIVATE_KEY is the one that controls ONE_TIME_ADDRESS then user will immediately spend the funds from ONE_TIME_ADDRESS to
a new address because the sender retains the ability to cancel the transaction.
Note:
turns out this crypto technique already existed and was called "stealth addresses". The fact that we re-invented it is good news though!
However as the DPOS blockchain allowes for adding the TEMP.PUBLIC_KEY as a comment to the transaction, the receiver does not need to brute-force test
if a particular transaction can be spent by him. This is the case for stealth-addresses
Pros:
The following features result from his proposal:
no need to exchange addresses, instead a Name can be given
ability to encode a message and 'from' data into the transaction for payment details
the receiver is anonymous to everyone but the sender as for each payment a temporary one-time address is generated
potential to cancel/retract a transfer if it is not accepted in a timely manner, which is impossible for any other transaction. To prevent chargeback the receiver simply wipes his temporary one-time address
simplifies accounting in the wallet
generates higher fees and dividends
Cons:
Daniel also listed the basic drawbacks of his approach which are namly:
Uses more space in the blockchain
Requires two transactions
Results in higher fees
Optimized Algorithm
However the first drawback go resolved quickly by the use of hierachical extended public keys.
The basic approach can be seen from Daniels pseudocode:
dan => DANS_EXT_PUBLIC_KEY
scott => SCOTTS_EXT_PUBLIC_KEY
scott: Generate OneTimePrivateKey & OneTimePublicKey Pair
scott: OneTimePrivateKey * DANS_EXT_PUBLIC_KEY => SECRET
DANS_EXT_PUBLIC_KEY.child( SECRET ) => RECEIVE_PUBLIC_KEY => RECEIVE_ADDRESS
scott: RECEIVE_PUBLIC_KEY * SCOTTS_EXT_PRIVATE_KEY => CHECK_SECRET
=> SHORT_HASH(CHECK_SECRET) == SHORT_SIGNATURE
scott-broadcast: OneTimePublicKey + RECEIVE_ADDRESS + ENCRYPT( from scott + SHORT_SIGNATURE, SECRET )
dan: OneTimePublicKey * DANS_EXT_PRIVATE_KEY => SECRET
DANS_EXT_PRIVATE_KEY.child( SECRET ) => RECEIVE_PRIVATE_KEY =>
=> RECEIVE_PUBLIC_KEY => RECEIVE_ADDRESS
dan: DECRYPT( data, SECRET ) => "from scott" + SHORT_SIGNATURE
dan: SCOTT_EXT_PUBLIC_KEY * RECEIVE_PRIVATE_KEY => CHECK_SECRET => SHORT_HASH(CHECK_SECRET)
This is a variation of stealth addresses (
http://www.coindesk.com/stealth-addresses-secret-bitcoin-privacy ) that leverages the
name system to solve the first part of the problem.
Thus, the protocol allows to
Send Anonymously To Any Name => SATAN
or Transfer Invisibly to Any Name => TITAN
Combining this with well-known techniques like CoinJoin (darkcoin) or ring-signatures allowes to completely send and also receive
anonymous transaction
Furthermore, these recent updates shed light to the power of Keyhotee as then
the use of name@xts can address individuals or DACs.
Mailing Money is within reach!
