slate and slatepack about grin-rfcs HOT 2 CLOSED

thank you for replying to me.

Yeah, you remind that the signature is an aggregation from 2 signatures.

from grin-rfcs.

Hi @jackzhp. Let's separate transaction building from sending it to the network. In order to send the transaction to the network, it needs to be first constructed. This includes having the kernel commitment signed by both parties. A signature can be put on the kernel only after both parties have provided their partial excess. Consider Alice sending money to Bob. The steps are:

1. Alice sends her partial excess a_e*G to Bob along with information that Bob can be paid 5 Grin
2. Bob creates an output holding 5 Grin together with a rangeproof and adds partial his excess b_e*G to the existing partial excess making it (a_e + b_e)*G. Bob now signs for this total excess (kernel commitment).
3. Alice receives the total excess and signs for (a_e+b_e)*G making a valid multisig on this kernel.

Once both parties have signed the kernel (step 3. above), the transaction can be broadcasted to the network. These are the 3 essential steps that have to be done in order to produce a safe transaction. Alice can only broadcast the transaction after it has been returned from Bob and she attached her signature to it. We don't know of a way to reduce the number of steps without either switching to a different cryptographic scheme or making a transaction vulnerable to at least some attacks.

Considering this isn't really an issue with an RFC, I'll close this, but let this not discourage you from asking more questions if you're interested. You can continue here, on the forum or on keybase.

P.S. I have omitted kernel offset to simplify things.

from grin-rfcs.