Dumping payment messages

[eriksank]

I am very new to MW/grin. I would like to check what messages/documents exactly the payer and the payee send around.

According to the example in local_net, node1 is the payer who drafts a partial transaction document for 20 000 coins. For some reason, node2 needs to verify the partial document (why?).

Node3 seems to be the payee, who accepts the partial transaction document as input and produces and signs the finalized transaction document as output.

For some reason, node3/payee sends the finalized transaction document back to node1/payer for broadcast to the grin peer-2-peer network. Is this needed? Can't the payee broadcast the final document by himself at that point?

I would like to simulate a situation in which the payer drafts the partial document, sends it by email to the payee, who then finalizes/signs the partial document, resulting in the final document, and then broadcasts it to the testnet. Is it uberhaupt possible to dump these documents at every stage?

[ignopeverell]

It's definitely possible and it would be nice to have email-based transactions. Have you looked at the following diagram:

https://github.com/mimblewimble/grin/blob/master/doc/transaction/grin-transaction.png

And yes, unfortunately a full roundtrip is required.

[eriksank]

Yes, the diagram clarifies a lot. The round tripping is obviously a little inconvenient, but in my own impression, it is certainly not a complete show stopper. Users get more privacy. Therefore, it is not that they are being asked to do that for no good reason. It is a trade-off that can be explained and defended.

It is quite important, however, that the email exchange format is readable and not just some hexadecimal dump. It would be more of a show stopper if users have absolutely no idea of what exactly they are signing.

In my impression, there are 4 documents involved, with the following tentative document titles:

[1] sender: partial transaction document --> to receiver [2] receiver: first receiver-signed document --> back to sender [3] sender: sender-signed document --> back to receiver [4] receiver: final receiver-signed document --> to grin p2p network

I also think collecting explanation for the fields in each document type will help clarifying how it works. Annotated examples would really be nice.

The really important improvement that the optional/additional document-exchange procedure would bring, is to prevent secrets from being exposed to the network.

By the way, another interesting documentation task would be to explain what exactly the grin client stores in its files. What are the secrets? It will help the user with his backup/recovery procedure, if he can neatly separate secrets from public network-supplied data.

I am definitely interested in picking up some tasks in this process, if that would be helpful. I am new to the project, but maybe I can do some minor things that are still considered useful.

[antiochp]

In terms of stored "secrets" the only thing is the contents of the wallet.seed file. This seed is used to derive all private keys (one per wallet output).

[eriksank]

@antiochp Nice. Given the possible extra complexity in comparison with a traditional blockchain, does wallet.seed contain enough information to reconstitute the wallet, or does the user need to backup additional (public) information?

[antiochp]

The recent introduction of Bulletproofs has introduced a temporary breaking change to wallet restore (we need to be able to retrieve the amount from the range proof associated with an output and we cannot currently do this with the Bulletproof impl). But once we can do this we are able to run wallet restore given just wallet.seed.

One thing I forgot earlier - the user can (optionally) specify a password so the seed is actually derived from wallet.seed + password. We don't store the password anywhere.

Note: recovering a wallet requires access to a fully sync'd node. So strictly speaking you need data from a full node (not really a backup). And as you mention this is all public data.

[ignopeverell]

What about having a mode that dumps a big QR code (as png for example) and another that can read the QR code (png again) and tells you how much money you're sending (or receiving) by opening up commitments from that data and also tells you the fees?

There's very little use in exposing actual commitments or kernel values to a user, there's nothing they can do with them. The wallet is needed to open up the commitment and show to ther user what it means regardless.

[yeastplume]

NB the wallet restore shouldn't be broken.. the amount is currently being stored in a message XORed into data and is retrieved via an 'unwind message' function. Should work in the current code, let me know if it doesn't.

[antiochp]

Oh cool @yeastplume - I was under the impression this was not working right now (cannot recall exactly why).

[eriksank]

@ignopeverell Concerning QR codes, the electrum wallet (bitcoin) supports both text-based and QR codes for interchanging signed/unsigned transactions.

The QR code approach is nicely suitable for running a signer app on a mobile phone that is not connected to the network.

A network-disconnected phone is safer than a hardware wallet, because you can verify all its input/output communications, which are then constrained to QR codes only. There is no way that it can surreptitiously transmit a copy of the seed over such QR codes.

I use the text-based mode for coping/pasting transactions between two virtual machines on a laptop. The virtual machine containing the seed (signer) is disconnected from the network.

The text mode is just serialized hexadecimal, but electrum will always show a user-readable version of it after loading the signed/unsigned transaction into the user interface. I always sanity-check/verify amounts and addresses involved.

I hope that there is a way in which the user can verify/sanity-check at least part of the grin messages. The correspondent party (sender/recipient) could otherwise ask him to sign whatever ...

[yeastplume]

Transaction workflow has changed somewhat and the described functionality should be possible with the refactored wallet lib. Closing this for now.