@trab Payment proofs are implemented for SRS (sender first style transactions), not for RSR. Now the project switches to transaction contracts with unified/bi-directional payment proofs. The proofs are a bit different from the previously used payment proofs to make them work no matter the transaction flow. I know that Grin GUI already has unified payment proofs, not sure if the new proofs are also in the latest release of grin-wallet.
Grin++ used the old style payment proofs. That is another thing that need to be addressed in a next funding request.
thatâs why i say coin-swaps should be default and it should be a base layer protocol for maximum privacy
we need some solution for non-interactive payments for grin for necessary adoption
Why isnât the solution slatepacks? We can already do transactions asynchronously that way
Indeed. There are options for non-interactivity, see the discussion on Bulletin Boards, but they come with serious downsides. For example, they cannot be a payjoin, meaning the receiver cannot include an output of his/her own to obfuscate the direction of their transaction. Ideally we keep things as simple and uniform as possible:
All transactions are payjoins (unless the receiver has no funds). All transactions are uniform transaction contracts, with uniform payment proofs. Users can optional use a daily CoinSwap/MWixnet. Transactions also use a uniform format for sharing, slate-packs, to share between users, exchanges and pools. Tor should still be supported in my opinion but it should be clear that slate-packs are the default method.
Perhaps a mobile wallet with Nostr could provide a bulletin board kind of experience in the future. But that really is an ecosystem add on, not a default thing to implement for all wallets. This would allow different wallets to have their own extra advantages while grin-gui aims to be robust and minimal, similar to what bitcoin-core is for Bitcoin.
Perhaps it would be ok for a wallet to exist that also supports non-interactive transactions. This however should not be default and should not be funded/stimulated using community funds. No one can stop anyone from developing a wallet with custom features such s non-interactive transactions. They do however come at a price, e.g. transactions that are different stick out like a sore thumb on the blockchain!. There is just little incentive to develop such a wallet, so I doubt something like that will happen unless the adoption of Grin grows considerably. Perhaps in 10 year or so 
.
1 Like
@trab I m not saying to abandon state-packs
I m saying they alone are not enough for pure non-interactive payments for more grin adoption
we need some more solution to pack pay-join, coin-swaps and non-interactive payments in certain wallets (with no central point of failure or servers) for more Adoption and more Plausible deniability on-chain
1 Like
@Anynomous yea best to discuss those downsides for various non-interactive options
and optimal is to have solutions that meet certain requirements like pay-join properties, native coin-swaps which can be optimally pack inside a wallet architecture so we have both non-interactive payments and grin adoptions with much better privacy and plausible deniability on-chain.
its not only âPerhaps it would be ok for a wallet to exist that also supports non-interactive transactionsâ it need to happen for grin true adoptions to start as a scalability and privacy money.