fix little typos

[leishman]

@apoelstra

Awesome paper. I'm trying to digest everything and figured I'd help fix some typos I found along the way.

A few questions: It seems that a sender needs a secure channel through which to transmit the blinding factor to the receiver, right? The receiver then completes the transaction and propagates it to the network? Is my understanding correct?

[apoelstra]

@leishman Sorta, yes. The signatures on the excess values are actually multisignatures between signer and receiver, but I didn't fully realize this when I wrote the paper, so I'm not super clear on this point. But it's a multisignature where it's OK if the sender reveals his half of the key to the recipient (this just lets the recipient change his part of the transaction freely, but not the sender's half).

• With the Voldemort scheme, you can produce this by having the signer send the blinding factor to the receiver (so yes, you need a secure channel)
• Alternately you can do an interactive multisig, but now you need 1.5 rounds of communication instead of 0.5.
• With sinking signatures it's possible to get the best of both worlds, because you can produce multisignatures by just directly adding signatures.

Once the transactions are aggregated and the signatures are aggregated (either by summing, with sinking signatures, or with the expose half of a split-key and sum the exposed halves Voldemort scheme), these sender/receiver multisignatures turn into multisignatures where every sender and receiver is party to the signature.

Does that make sense?

Also thanks, very much for the typo fixes.

[leishman]

Ok that makes sense I think. So in practice a receiver needs to always be online? Or at least have some "inbox" to receive and store any partial transactions sent to him?

The paradigm here throws addresses out the window so we need some identification/authentication layer right? I understand these are higher layers than the consensus protocol but knowing how it will work in practice helps me (and probably others) conceptualize the consensus layer. On Fri, Oct 14, 2016 at 18:11 Andrew Poelstra [email protected] wrote:

@leishman https://github.com/leishman Sorta, yes. The signatures on the excess values are actually multisignatures between signer and receiver, but I didn't fully realize this when I wrote the paper, so I'm not super clear on this point.

• With the Voldemort scheme, you can produce this by having the signer send the blinding factor to the receiver (so yes, you need a secure channel)
• Alternately you can do an interactive multisig, but now you need 1.5 rounds of communication instead of 0.5.
• With sinking signatures it's possible to get the best of both worlds, because you can produce multisignatures by just directly adding signatures.

Once the transactions are aggregated and the signatures are aggregated (either by summing, with sinking signatures, or with the expose half of a split-key and sum the exposed halves https://www.reddit.com/r/Bitcoin/comments/4vub3y/mimblewimble_noninteractive_coinjoin_and_better/d61n7yd Voldemort scheme), these sender/receiver multisignatures turn into multisignatures where every sender and receiver is party to the signature.

Does that make sense?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/apoelstra/mimblewimble-paper/pull/1#issuecomment-253952962, or mute the thread https://github.com/notifications/unsubscribe-auth/ADesahB3h9juRNhzcTinc-TqxghCWjsBks5q0ChJgaJpZM4KXkFY .

[apoelstra]

@leishman Yes, pretty much. (Though note that addresses are neither identification nor authentication, and anyone using them as such are exposed to address substitution attacks.)

Having said that, it's possible for the receiver to create its half of the transaction then go offline, and probably even to create individual outputs and somehow delegate creation/signing of the excess.. but it's definitely the case that the receiver has to (a) create an output with a value tied to it, and (b) be online to create a rangeproof for this output.

[leishman]

@apoelstra Right. I didn't mean to imply addresses were identification or authentication.

Ok I think I have a better understanding of things now. I've got a lot more thinking to do though! This is extremely interesting.

[leishman]

@apoelstra Is the implementation you're working on public? Is this a "competing" implementation: https://github.com/ignopeverell/grin?

[apoelstra]

@leishman grin supercedes my implementation (because Peverell got much further than I had before publishing :P). I've been in contact with him.