mimblewimble team mailing list archive
Mailing list archive
Re: defending against malicious transactors
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.
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
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.
(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.
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
"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"
Description: PGP signature