Yesterday some conversation happened on keybase regarding 1-sided transactions, by aggregating a commitment with a recipient’s commitment to 0. I have a proposal that appears (to me) to accomplish this. I know David is working on something similar, so hopefully we are on the right track.
Either way, here are my thoughts so far. Maybe one of the crypto experts out there can shoot a hole in the concept
-------- Recieve Address A recieve address will consist of a public key on X, where X = x*G, and a signature from this key, s_X: address = (X, s_X) The public key will be treated as a commitment to 0: X = (x*G + 0*H) The signature will be used later to verify that Bob knows the private key, x, and thus verify the commitment commits to value 0. -------- 1-Sided Transaction 1-sided transaction looks like a classic MW transaction, except that the output is aggregated with the recipient's address key. For example: Bob publishes his receive address: (B, s_B) = (b*G, s_B) Alice wants to send Grin to Bob, by spending a UTXO she controls: In = (ri*G + vi*H) A-1) First, she computes a new temporary output commitment: - Out = (ro*G + vo*H) A-2) Second, she aggregates this with Bob's commitment to 0: - Out' = Out + B = (ro*G + B + vo*H + 0*H) = ((ro + b)*G + vo*H) Notice, this resultant commitment (Out') is blinded by Bob's private key, b, which ony Bob knows. Therefore, if Bob can learn ro, Bob can now own this commitment. To accomplish this, Alice must select ro in a way that Bob can recover. Also, note, step A-1 is identical to a classical MW transaction. Step A-2 is an optional modification to a classic UTXO, to give ownership to Bob. I think of this as "Bob commits to vo 'by proxy' through Alice". There are a few possibilities for Alice to select r0, but I suggest this: B-1) Alice generate ephemeral private key e, and corresponding public key E, where E = e*G. B-2) Alice computes ECDH shared secret with Bob's key: ss = ecdh(e, B) B-3) Alice computes ro as hash of this secret (any strong hash works): ro = hash(ss) B-4) Alice then includes the ephemeral public key, E, in the transaction, so that Bob can also compute ro. Lastly, Bob must learn the value, vo, to be able to control the commitment. Alice can also share this information with Bob, encrypted using a key derived similarly to ro, and also shared with the transaction. Note, this requires Alice to include a lot of data in the transaction kernel, for Bob to recover the output: - 33 bytes -- E as compressed pubkey - 16 bytes -- v0 encrypted (AES256) This exceeds the amount of data that can be stored in a bulletproof, so I am still working on a to reduce the amount of information Alice must share with Bob. -------- Transaction Validation To validate a transaction, a node must perform the following checks: C-1) Verify Out - In = 0 - This check is identical to classic MW. Alice must provide a signature from private key (ro - ri). C-2) Verify all rangeproofs to prevent negative outputs - This check is also identical to current transaction validation. C-3) Verify Bob's address truly commits to zero, given Bob's address (B, s_B) - This holds if s_B is a valid signature from B. Note, this requires Alice to include the intermediate output (Out) and Bob's address (B, s_B) in the transaction. To prevent a miner from mutating the transaction and stealing funds for himself, Alice should sign the entire transaction (including the expected resultant Out') with the signature she provides in step C-1. So the transaction data that must be published to the network is: - Input commitment(s) to be spent (In_0, In_1, ..., In_N) - Output commitment(s) to be created (Out_0, Out_1, ..., Out_N) - Recieve addresses for any 1-sided transaction outputs (addr_0, addr_1, ..., addr_n). Note, these are optional. Any output without a specified receive address can be validated like a classic MW transaction. - Excess signatures for step C-1. Note: these may possibly be aggregated. - Rangeproofs for step C-2. -------- View Only Wallets I will only touch on this quickly, but if the encryption key for the value information is derived appropriately, it is possible a view only wallet could exist, which can detect outputs and view the value field, but not be able to spend the committment. I plan to research this further, but this is not the primary objective. -------- Confidential Addresses I will only touch on this quickly, but it is possible to perform the above transaction on a derived address for Bob, instead of his publicly published address. IE, Alice selects a nonce, n, and send's the transaction to Bob's derived address: (B', s_B'), where B' = B + n*G, and s_B' = s_B + n. This is possible since both fields of an address are homomorphic. Note, this also depends on Bob being able to derive the appropriate address, and thus depends on the shared secret computation mentioned in steps B-2 through B-4. -------- Concluding Thoughts Pros: - Enables 1-sided transactions (duh) - Bacwards compatible with current MW transactions (ie cut-through still possible) - Requires no new security assumptions, only ECDLP assumption which already exists - Transaction authorization and lifetime/finality are the same as classic MW transactions (ie, no re-org can claim this output) Cons: - Still a few unanswered questions (ie, how to more efficiently derive shared secrets for steps B-2 to B-4) - More communication overhead (more data necessary to validate transaction, and more data necessary for Bob to detect the output) - More computations for transaction validators