I’m not so sure if they won’t need to know, they probably will need to. When creating a new tx they would pick either payment or invoice, so imo it would be best if they understand both flows (no magic since it’s not needed imo)
I think as a fan, what Grin needs is a simple goal, at first, which is a unique private transaction, A sends to B and both of them must be online. From this simple rule, there will be many supporting facilities for transactions either on wallets, or special types of exchangers that can support them and so on, making it even more complex. Grin should be built in this way, and in addition to that Grin ambition is to replace fiat, must interact with fiat not interact with other cryptos, well unless stablecoins.
The play scenario in RSR where the receiver doesn’t broadcast should be obvious when thinking of a transaction as a contract that you have signed.
I think this can largely mitigated either by using a (multiparty?) timelock to the transaction, where the sender is able to reclaim funds after a certain number of blocks (10?). Will write something up on @tromp’s PR to see what they think.
I’m not sure I understand correctly what you mean. The case I mentioned is prior to the tx landing on the chain, which means that the sender can always just spend the input they provided in a new transaction which invalidates the one the receiver did not broadcast - this is the solution in safe-cancel RFC.
If you mean solving this by making 2 transactions instead of just 1, then I believe this may have 2 possible problems:
- Uses 2 kernels which doubles the size of the chain
- Payment proofs might be an issue
No, you’re right, I was thinking of a situation where the tx was already on-chain.
The safe-cancel RFC would also require the user to:
- monitor the chain to ensure the tx posted
- use some kind of watchtower to watch the chain for them, automatically notifying the wallet the next time it is online to do a self-spend
I still think I agree with those in this thread that suggest having one standardized tx flow (SRS), and making exchanges/pools build on that.
For example, the exchange could put a form for “please create a transaction for X Grin, and post here”. The exchange’s wallet does its part of the tx, and instructs the user “please import the tx to your wallet, verify everything is correct, and finalize”.
The above flow would work for exchanges / pools / stores that do not want to implement TOR sending for whatever reason.
For those implementing TOR sends, the flow is even simpler “please send X GRN to this Slatepack address.”
Just reposting what i’ve posted on keybase some time ago, so that it doesn’t get lost.
let’s say amazon integrates grin. You have a cart with items in it and then click “checkout”. Now you have 2 different flows:
- user copies the total amount of his cart and also copies amazon’s grin address to create step1 slatepack
- user enters the generated slatepack on the amazon page, amazon generates next slatepack
- user copies this new slatepack and finalizes the transaction
Here amazon doesn’t know if the user has signed the tx or if the transaction didn’t reach the chain etc.
User had to copy the amount, amazon’s grin address, create the first slatepack, copy next slatepack and finalize.
- user enters his grin address (so that exchange can encrypt for him), amazon generates the new slatepack which the user copies
- user generates the next slatepack through the “pay” subcommand
- user pastes slatepack on the amazon page
Here amazon knows exactly the state of the transaction.
User had to paste his grin address, copy slatepack, pay to create the second slatepack and paste it
From my understand of early payment proofs, memo would need to be created in the first step of SRS (well at least that makes sense to me although it might be possible to push it to step 3 but it makes less sense), which means the user would also need to take care of the memo, instead of letting amazon automate this process - amazon has the digital cart data, so it can either populate the memo with it or generate hash of it and send you the receipt or smth. I might be wrong, but i don’t see real services being happy with the SRS flow integration
Here’s how bitcoin developers advertize the advantages of interactive (payjoin) transactions:
Interactivity in building payments, what a brilliant idea. How come this sounds somewhat familiar
Having the input’s and output’s amount blinded makes life much easier for Grin. Only need to adopt the part where both parties contribute inputs and the total amount of outputs equals the number of inputs to obfuscate direction to have our own privacy enhancing, blockchain bloat avoiding special payjoin.
next they will say they fixed the ‘‘sending btc to wrong adress problem’’
let’s say amazon integrates grin. You have a cart with items in it and then click “checkout”. Now you have 2 different flows:
From my understand of early payment proofs, memo would need to be created in the first step of SRS (well at least that makes sense to me although it might be possible to push it to step 3 but it makes less sense), which means the user would also need to take care of the memo, instead of letting amazon automate this process - amazon has the digital cart data, so it can either populate the memo with it or generate hash of it and send you the receipt or smth.
Fair enough. I’m still wrapping my head around how a receiver could block payment in the second round of SRS. At that point the receiver doesn’t have a fully signed tx, do they? How does spamming an unsigned output block anything? Anyway, still reading through the papers and code to figure this out.
To me the two flows are about shifting responsibility for tx finality from one party to another. RSR flow is like handing a signed check over to Amazon, saying “I hope you cash this.” Then having to constantly monitor your bank account until the check clears. If users already struggle getting used to SRS flow, RSR seems much more complex when things go wrong.
On the other hand, when things go right, I agree that RSR is a simpler flow for the sender, and potentially the receiver. Like I said, I still have more research to do.
Thanks for looking into it. Here’s an example of how you could block it. Suppose the sender and the receiver create a transaction
T through SRS. Receiver in step 2 added his output
O1. Receiver creates a new self-spend transaction
T' which also creates
O1. If they are able to push
T' to the mempool/chain before
T gets there, then
T is invalid because it would create the same output
O1. Consensus rules say that UTXO set can’t have the same output twice in it.
And this is why custodial wallets currently offer the best user experience on Bitcoin Lightning Network. Obviously that’s not great for a decentralized currency. Admittedly always online wallets are a bigger issue for Lightning because of the whole channel closing fee.
In general the comparisons of MW and Lightning are quite apt, as others here have pointed out already, they struggle with very similar UX issues. But as far as I’m aware those hurdles haven’t been overcome on the Lightning side either and I’d imagine they have a lot more People working on it.
After having some discussions today on discord, I decided to write things up in a document in case anyone wants to read what I was trying to explain. Here’s one of the big tradeoffs that the current NITX proposals make (both David’s and Gary’s).
Trustless node sync. While it’s true that Mimblewimble has a weaker model than Bitcoin, it preserves these two properties. Proof of authentication is preserved because there cannot exist any state transition in the past for which a party that owns any input/output of the state transition did not inject their blinding factor into the kernel. Replay attacks are bad and should be addressed, but they don’t break this property as the owner signed the transition for the original transaction prior to replay.
A good explanation of this problem is also in the Introduction section of MingleJingle which addresses this problem but introduces many more tradeoffs.
I see how non-inflation is a verifiable property of a grin history, but I
don’t see how proof of authentication is a separate property. How would you have the former without the latter?
I may be wrong about this, but I’ll share my current understanding. The two are separate also in Bitcoin. In Bitcoin you can prove chain noninflation at the tip of the chain by summing the amounts of the outputs in the utxo set. This alone doesn’t tell the historical authentications are valid. The MW equivalent is by checking the grand balance oneliner formula. In Bitcoin you can get proof of authentication by replaying the whole history. In MW this is again verified with the grand formula. But this doesn’t mean they are the same thing, it’s just a “coincidental elegance” of MW that both properties are achieved with a signed kernel because one is proven with the
H part being 0 and the other with the
G part. I believe the nitx proposals (apart from @tevador MingleJingle whose main purpose I believe is to fix this issue that both David’s and Gary’s proposals have) have only trustless non-inflation verification. My understanding is that trustless proof of authentication gets lost because a new node can only verify (in a trustless manner) the transactions that are in the last week of blocks (I think). It cannot tell with only mathematical assumption (as is today in MW) that any other NITX had a valid state transition as would be defined if you were processing it live (due to the reorg problem mentioned in the nitx spec). It can only tell that the receiver or the sender spent it which doesn’t prove the receiver signed the transition. This means that a new node must trust people that no shady stuff happened in the past. So you have the former and don’t have the latter. And the issue comes from pruning a part of the authentication proof. This may sound like only a practical concern, but afaict it’s a really important property of the blockchains if we aim to be trustless/trust-minimized.
Perhaps another example of having proof of non-inflation but not proof of authentication would also be the original CT where blinding factors are not authentication keys. If you pruned the signatures in a pure CT setting, you can prove non-inflation of a transaction, but you can’t prove authentication without the signatures. The NITX proposals as I understand, like original CT, require external signatures for authentication but then prune these.
P.S. yes, in Bitcoin a full replay also proves noninflation, but that’s besides the point.
P.S.2. I have not read Gary’s proposal, so I’m trusting the MingleJingle proposal that this one loses this property as well.
Ok; so you’re saying that currently, the non-inflation proof (the single Grin equation) also serves as authentication proof, but if we adopt nitx, then the new recipient signatures become a part of the authentication proof that must be preserved beyond one week to make for trustless historical verification?!
That’s my current understanding, yes. The current grin equation captures all the authentication keys because they’re just blinding factors. This is no longer true for NITX because the blinding factors are only a part of the authentication key. I think it weakens the model of trustless historical transaction validation of tx authentication from “I know the receivers correctly signed all the past transitions” to “I know that either the receiver or the sender correctly signed all the past transitions” because both of them know the blinding factors. To get to the same verification you need to trust people telling you no funny things happened in the past.
P.S. Perhaps this is also good to have to avoid any FUD from competing chains saying that we had such an event or something. With the current model, we can simply prove that this could not have happened. Just like Bitcoin.
It seems Pieter Wuille (as well as fiatjaf) also prefers interactive transactions on chain and calls them out for having a better UX than the “send to address” transactions https://twitter.com/pwuille/status/1475173933334859781
i wonder if that’s because (imo) vast majority of transactions are “pay to service” where invoices are preferred and with itx invoices are more natural
Today I spent some time thinking about scripting and made some writeup. I don’t guarantee it works, and am not motivated enough to research this further because as mentioned in the document, I don’t think it’s a good fit for Grin - perhaps other projects would find it interesting. The reason for it being mentioned in this topic is because I want to document a different path for anyone that may be interested in this and because this may allow getting NITX (and other spending conditions) while preserving the MW/Bitcoin security model. Again, I don’t think we want this, we want interactive transactions made simpler because they are, in my opinion, the bread and butter of MW.