On Tue, Mar 21, 2017 at 05:47:39PM -0400, John Tromp wrote: > > It therefore seems prudent to use a more involved procedure where the > sender need not reveal any blinding factors: > > 1. Sender and recipient agree on amount to be sent. Call this b. > > 2. Both sender and receiver pick a random blinding factor, rS and > rR respectively, and a random nonce, kS and kR respectively, > and share their commitments rS*G, rR*G, kS*G and kR*G > > 3. Both compute the Schnorr signature challenge e=H(kS*G+kR*G). > > 4. Sender computes sS=kS+e*(rS-rI), where rI is the blinding factor > on his input. > Receiver computes sR = kR+e*rR. > sS and sR are shared and verified against step 2 commitments by > multiplication with G. > > 5. The final signature is computed as (s,e) where s = sS + sR. >
John, Thanks. I've been talking to Iddo exploring this and I'm convinced now that this works -- though it requires both parties to keep the original un-cut-through transaction around as proof that the kernel that hits the chain was actually derived from a transfer from sender to receiver. Then the kernel signature proves that all revelant parties agreed to it. I should mention that problems don't even require malicious behaviour: if Alice sends money to Bob who forwards it to Charlie, and Bob's involvement gets cut through, then the result is a block where Alice's money is spent but she can't see or prove where her money went. (jstolfi detailed this at https://www.reddit.com/r/Mimblewimble/comments/56ip3f/can_the_mimblewimble_blokchain_provide_proof_of/ in his usual friendly manner.) The solution that I proposed in the jstolfi thread above involves an intermediary 2-of-2 output that both parties agree off-chain signifies a legal payment, which is inefficient and leaves open some technical problems about how that agreement could be proven in court. Also this solution really sucks because it deliberately throws a wrench into intra-block cutthrough, and then to throw salt on the wound it uses two transactions in place of one. I guess the ultimate lesson here is that *the only thing transacting parties can expect to hit the chain is the kernel*. Everything else might get cut-through and not be committed. In general, (a) Both parties need to agree on the kernel in a provable way (b) The kernel needs to independently evidence that the money was sent from Alice to Bob Signed kernels give us (b) for free; what John's scheme achieves is (a), which Voldemort's scheme lacks (as do multi-kernel schemes, which I've proposed from time to time to get non-interactive transactions). My new understanding is that noninteractive transaction construction is simply incompatible with having a provable recipient.... and I think provable recipients are basically always needed in real life. Note also that John's scheme is totally compatible with ValueShuffle -- indeed, it was already clear that in VS there had to be a multisignature kernel because there was no well-defined "sender" and "recipient" to exchange raw key material. But all participants need to keep the entire transaction around in order to prove that the kernel is really a proof that all parties were involved. Unlike in Bitcoin the blockchain is no longer a proof of the original transaction data. Anyway, we can forget about my answer to jstolfi :) I think that doing a multi-sig kernel as John describes is actually sufficient. *** I had a much longer message that described using pay-to-contract to have the kernel commit to the original transaction, but after some reflection I realized that this actually provides no additional security, because the kernel itself is already a commitment to the essential content of the transaction, i.e., who the transacting parties are. If anybody thinks thinks this -would- actually be helpful, I'd be curious to know why. *** Cheers, Andrew -- Andrew Poelstra Mathematics Department, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew "A goose alone, I suppose, can know the loneliness of geese who can never find their peace, whether north or south or west or east" --Joanna Newsom
signature.asc
Description: PGP signature
-- Mailing list: https://launchpad.net/~mimblewimble Post to : mimblewimble@lists.launchpad.net Unsubscribe : https://launchpad.net/~mimblewimble More help : https://help.launchpad.net/ListHelp
