Could the P2P relays require some fees to be paid to avoid being spammed?
It’s possible, and that would probably help a lot. The question is who is charged the fee, and how it is calculated. It might be quite off putting for an end user to be charged 10 cents (or whatever) each time they want to build a transaction with someone. Especially if that other party fails to respond before the p2p network drops the message.
I’m not sure how paying the fees would be done in practice. I think you could also just send the same thing to 100 nodes which would look like it’s paying the fee and then spend the utxo in a different way, opening the spam vector again.
Regarding known solutions, I don’t see how anything with an easy ddos vector is going to work. You need 1 person to mess everything up and there’s 7 billions of us. I’m also not sure if the attacker needs more than 1 hour of coding to destroy the whole idea. The only scale on which such systems work is when they are barely used. As soon as they get popular, you will encounter that 1 person that will kill it 
I guess. But there are a large number of applications that have dos vectors and they are up and running. Being on a distributed network should make it even more robust. Tari and Beam have their message relay systems sharded as well. There are many solutions, but not being usable doesnt seem like a solution for anything.
Good point, I wonder if they have more expensive attack vectors… I’d expect attacks to happen.
I’d prefer to see an integration for exchanging value through existing services that provide user identities e.g. sending grins over hangouts, slack, facebook messenger, telegram, whatsapp or similar. Drop an encrypted slate to the receiver on private chat, receiver adds to it and sends it back. Confirmation steps are signed with a hardware wallet integration. The UX solution doesn’t have to be built as a part of the network itself, it would likely be more intuitive for users if existing software had functionality like keybase has for Stellar “send X grins to user Y”.
Grin is compatible with keybase but nobody uses it
Agreed 1000% we need more focus on use ability. Security 1st, usability a close second.
Perhaps it would be of interest to some of you that in my country, the most popular payments app by far (both for friends & business payments) utilizes interactive transactions as its only option. The receiving end has a limited time window to confirm the tx for it complete.
That said, reason stands with both sides of the argument.
I appreciate the discussion above and I do think some second layer technology such as LN or something similar to ZK-Rollups would be nice to implement with Grin on the long run. However, for me the usability problem, if any, is more pragmatic. Being both connected/ having an interactive transaction, is not the problem.
Lets say I want to send Grin to someone by phone for my beer on a crypto event. I do not want to send a QR code or file via messaging Apps, have them manually signe the transaction, and send another QR code back again. Simply having a mobile wallet that through a single step can connect over TOR, e.g. after reading a QR code from the receiver, and automatically send, sign and publishebthe transaction, has a higher priority. When the transaction is complete, the wallet should switch tor ID’s for both the sender and receiver. For me, developing something like that would be more pressing than implementing second layer technology since it does not require fundemental changes while greatly improving users experience in making mobile payments.
Optionally, one could generate a receiving QR code with a longer life span, e.g. last for a couple of hourse so it can be printed and used for the whole crypto event. For any end user payments would therefore be the same as any other crypto currency, since the QR with the receivers tor ID feels no different from a QR code with a receivers address. Users of Grin who want to pay can scan the QR code for the whole night and transfer their drinking money and the tor ID of the receiver is only switched when the event is finished. Signing and sending back transactions to your own wallet should be automatic.
Regarding, receiving transactions while being offline. I am not sure it is currently different when signing a transaction for sending and receiving. If one could have a seperate receiving signing key and sending signing key, one could use a simple third party scheme to accept receipt and sign while paying a small fee. Even beter, one could share it to multiple actors, nodes that are willing to sign for offline wallet, which can compete to be the first one to sign your transaction and obtain a small fee. In my opinion this would be better tha Grin box since it is decentralised oposed to how Grin boxes work. Prefarably the origin of such a receiving key would be scrambled when distributed on the node network, similar how send transactions are scrambled for privacy reasons. To protect overflow by an attacker sending fake receiving keys, as somewhere mentioned above, one could put a minimum treshold of e.g. 0.1 Grin on such a receiving wallet. This would only lead to a small loss of privacy, but I think for those who are unwilling to accept the slight inconvenience of needing to be online, this would be an acceptable trade off. The wallet software could generate it as a second receiving only internal wallet, which will be emptied up to the minimum holding amount of 0.1 Grin to the normal offline wallet once it goes online. Since this basically means you have two wallets in one, it would mean the user does have to specifiy to anyone whether to send to the always online wallet, or the normal wallet which needs to be online to receive transactions.
Just a crazy idear:
How about using the camera plus flashlight to ‘BEAM’ the transaction slate back and forth. For a user this would be a simple experience without having to actually connect phones. Just pointing the phone to one another an let them transfer the transaction slate back and forth by light as a binary message (the armored slate will ensure the transaction will not be corrupted). At least for doing a daily payment this would be great. I doubt the transfer speed would be sufficient, about 130 Hrtz/bits per second, camera probably maxed at 60 FP/s so 60 bits per second), but the idear just looks cool to me 
.
Do not put to much value to those numbers in regard to the success of LN. Most lightning nodes do not publish their liquidity. Also LN is ment for smaller payments while Bitcoins locked on Ethereum are for investment and trading (using Ethereums low transaction fees), so a totally diffent purpose than facilitating real payments like LN.
Grin provides by far the most horrible user-experience you can get in crypto.
Last year in April 2019 i bought Grin on Poloniex. Since only http-transfers were supported by the exchange i was forced to utilize this method to get them off the exchange. I took me literally a week (!!!) to get things going (see here). I even had to call my ISP to ask them to enable IP4-adresses for our household (they had already switched to IP6) so i could use port forwarding. I never would have thought that i had to have to call my Internet Provider to get a crypto-wallet going, but there we had it, the rough start of the best bitcoin-challenger, i can take it, no problem. At the time i thought it may have been a rough start but in the end i learned A LOT about IP4, IP6, Ports, Port-Forwarding in general, local IPs, External IPs etc. Having the Grin in my wallet was also rewarding.
A year later when i think about it, i ask myself: How did i not see this as a warning?
I buy different crypto on a regular basis. Usually i buy them on Kraken and transfer them onto my corresponding wallets. Some clicks and its done. Buying Grin is always a bit different. Here i had to transfer BTC to Poloniex, Buy Grin, initiate the transfer to my Grin-Wallet, see the transfer fail for some odd reason nobody knows why (see here), contact the Support, wait until they restore the Grin, which takes usually some days, try again and with some luck i got the Grin into my Wallet. Annoying, but as a believer i just took it as it is.
Buying stuff with Grin - horrible. But after some support from the forum (thanks again) and CLI-magic it worked.
Because Poloniex delisted Grin (at least for GRIN/BTC Pair) i moved to Bittrex. Here i had to learn that their Grin-Wallet is in Maintenence Mode since 7th June (!!!). So no Grin here. I opened an account at Bitforex that was suggested to me as an alternative here in the forum (see here).
I bought some Grin. I withdrawed it to my Grin+±Wallet, which indicated by a green font, that it is connected and up and running, - and It failed. Great, another evening of joy writing a support ticket. In the meantime, several hours after the failed transaction, my Grin+±Wallet changed suddenly from green to orange.
I guess even if they would now try to transfer the amount to my Grin+±Wallet it would fail. My internet-connection works perfectly btw.
This is the tipping point for me. I will leave the Grin on the Exchange and don’t touch it.
From today i consider Grin as broken. You can tell me all day long that it is perfectly fine and working. I can tell you from first hand experience: It works BARELY, if at all.
If you don’t find a way to get the one-sided transactions flying i can guarantee you that this project will be seen as some curiosity in the future. If i’m wrong with my prognosis im fine with it, Grin aims for the right goals so it would be nice to see it succeeding, but i lack the imagination to see this project going anywhere with the glaring issues i am experiencing for over a year now.
@Grundkurs I understand the frustrations, I had to deal with quite a few myself. Relying on tor is easier than http, but mildly at best. Nevertheless, you should take a look at the Slatepack RFC if you haven’t already. It’ll allow you to simply copy-paste a pack of text back and forth and be done with it. It’s much more convenient and impossible to fail over connectivity issues like you experienced.
I hope you stay around long enough to give it a try. But even if you don’t, I wish you good luck on your journey ahead.
My own experiences have been similar. Grin is broken in its current form.
I’m told it’s the exchanges fault - in this case Kucoin but as a user it doesn’t matter. I shouldn’t have to file a ticket every time I want to withdraw from exchange.
We NEED this to be priority number 1!
This is a widely voiced opinion by many. Personally I find the User Experience already good enough to enjoy using Grin although I also still find Grin the most difficult crypto coin I am using. As such using Grin should be made more user friendly (e.g. QR code, sending, signing, and signing the transaction response happening via tor in the back).
It does appear the developers are listening and put much more emphasis on improving the experience of making transactions as you can see from @antioch funding request.
Maybe it is late, but please, if you’re facing issues with Grin++ there is a Telegram Channel here Telegram: Contact @GrinPP where we can help you out. Things are moving really slow for Grin, but there is some progress, not as we all want and I can understand the frustration.
I’m 100% sure the user experience will be better and Exchanges will have enough time to upgrade their Backend.
So true! Many who express their frustration about the User Experience of Grin on this forum totally overlook the work from @joltz and other in the past quarter on Slatepacks. These are not some technical gimmicks or theoretical exercises done for the satisfaction of the core team. Slatepacks are a very beautiful and elegant way to standardize the way Grin transfer information is packaged in a both humans and machines readable format. Additionally slate packs protects against making mistakes and can be encrypted (armor) for the (tor) address they are send to. In other words, slate-packs standardizing how transaction are implemented and how they are presented to the user. This standardization makes it much easier for GUI wallet developers to implement more elegant user friendly transactions User Experiences.
I know all of this can be red from the Slatepack RFC @Paouky posted here. However, I think it is not realistic to assume everyone will spend the time to follow links on this forum and read the full content of every RFC. Personally think it would be good as a community to discuss ‘features’ being implemented and their benefits here in the forum a bit more. In these discussions, we should emphasis and start from the point of view of a user who thinks in use cases, user experience and features. From there on we can dive into the technicalities of how to achieve features and user experience. I noticed this is already being improved in the latest rounds of funding request, which is a good start 
.
Basically when starting a discussion on this forum it would be good to work with the assumption that the information should be clear and interesting to read for a user who never looked on Github, does not know Grin is also discuss on Keybase and who does not read most RFCs, because that is probably the majority of the users on this forum.
Sending reciveing Grin havent been a issue to me, but without one sided transactions (lBeam has it), Grin will most likely not get adopted by many more.
Can we try to find out a solution to this ? from my understanding there is a security issue related to one-sided transaction , but we have solutions and it requires a one-week reorg .
so my question is : why don’t we try to work on something that is more significant to an average user ? core team is doing an amazing job, and thank you for this, but community is also asking for some stuff ?
