0006-payment-proofs.md #31
Conversation
There was a problem hiding this comment.
Nice job @DavidBurkett see minor questions and feedback points.
There was a problem hiding this comment.
Very nice @DavidBurkett. See minor typos and question below.
That was one of my open questions at the bottom. I wasn't real sure of the consequences of an optional sender address, so if you think it might be worth making it mandatory, I'm convinced that's probably the right decision. |
|
Yes, I think making it mandatory is the right approach. So fine to go ahead with this on the understanding that proofs won't be possible for invoice transactions just yet. (They are theoretically possible but would require another workflow involving extra back and forth where the payer is always the last to sign off on the TX.. not great from a UX perspective) |
|
+1 for making sender_address mandatory. Should sender_address use (i.e. address re-use vs new sender address each time) be handled separately from this RFC, or does it make sense to set a default here as part of this effort? |
|
I prefer to leave that as an implementation detail, especially since it's easy and maybe even likely for different wallets to make different choices about that. |
There was a problem hiding this comment.
Nice work on the changes @DavidBurkett - looks really good to me. 👍
|
I fully support adding proof of payment to the grin transaction process but I caution providing an ability to add a message field to the signed portion of a grin transaction. IF sender has the ability to put a message with a payment... AND prove I took the payment... AND prove the message was part of the payment when I took it, "I have this signed receipt stating that CircusDad sold me -Insert Valuable Object Here- for 10 Grin" For reference: Visa and Mastercard have been around the block a few times and, while their transactions do provide a proof of payment record between accounts, they stay out of the proof of message part of things. I do see some value in messages but I suggest the "message" field be a separate PR subject to a separate discussion about implications and details. A solution might be for Grin to support putting a message in the signed portion of the slate... but only if both the sender and the receiver actively add the exact same message to the slate. I strongly support proof of payment portion of this PR. Proof of payment is an important part of electronic transaction and would hate for this comment about the message field to prevent the payment-proofs portion of this PR from being added to the next Grin update. |
|
For completeness, I have thought of another reference that serves as a counterpoint: A bank check has a memo line to be filled out my the sender. The receiver has choice to deposit, or not, or even to cross out/add to the memo field and then deposit. In the latter case it is hopefully clear via hand writing what was written by the sender and what was added by the receiver (perhaps a separate sender and receiver message field for Grin?). I have no affiliation with this website apart from a web search, but for context: https://www.romanolaw.com/2015/11/17/can-writing-on-a-check-create-a-new-contract/ |
|
Thanks @CircusDad for your insights and your warnings about the message field makes sense to me at least. Given this, I think we should leave the message field out for now and come back to it in a later RFC after giving the issue the appropriate consideration. |
|
Message field has been removed. Thanks @CircusDad |
Link to rendered doc