Bob pays Alice

[uncomputable]

I was confused that Bob pays Alice in the example. It seemed the wrong way around, even though technically it does not matter. Rewriting the example could make the workshop more approachable, although it is a little bit of work.

[josibake]

Agreed that Alice -> Bob is a more "natural" flow. I'd also like to settle on a notation for the public/private keys that aren't specific to Alice,Bob (e.g avoid using a,A and b,B).

Do you have any suggestions for notation more in line with cryptographer conventions? Specifically:

• Spend and Scan keys for Alice. I've been using A_spend and A_scan
• Bob's input keys. I've been using i,I or b,B
• The shared secret and tweaked public key. I've been using t,T for the tweak and D for the output

Would love to hear your thoughts! I have the BIP draft here if you want to see a more formal version of the notation we are using: https://hackmd.io/@silent-payments/SJN8ewJk3

[uncomputable]

I'm not an expert on notation, but using x for secret keys and P for public keys seems quite common.

One could name the keys according to their function, like x_pay (b), P_pay (B), x_spend (a and a_spend), P_spend (A and A_spend), x_scan (a_scan) and P_scan (A_scan).

I'm not sure about the other stuff. i, I seems good for "input" and t, T for "tweak". Not sure what D stands for. O (for output) is easily confused for zero. You could use multi-letter identifiers like Out, although academic usually sticks to one letter plus subscript. That being said, you already have multi-letter identifiers like inputs in your formal write-up.

Again, I'm not an expert, but I would keep points upper case like Inputs and scalars lowercase like outpoints.