Your keys have to be in memory to receive funds (whether you are online or not), this is a bad feature with respect to security when it comes to storage. It means every donation wallet (many other examples of real-word needs that end up with hot, online wallets), every example you can think of, must remain vulnerable in order to take in funds.
2 Likes
Again, there is more bitcoin wrapped on ethereum than there is on lightningā¦ This isnt coincidence, it is because lightning has massive security and usability issues that bitcoiners do not accept. Literally a single transaction to wBTC is more than the entirety of the LN!
Do you mean that Grin will never be compatible with hardware wallets?
HW could automatically sign receiving transactions and require manual validation for sending ones.
But thatās still a hot wallet. It might be designed to be more secure, but a vulnerability would still risk leaking the private keys. There are all kinds of exploits for hw wallets if you get physical access to them, and putting them online opens them up to further attacks.
2 Likes
We are ok that Grin wonāt be the best solution for receiving-only always-available wallets 
HW wallet that would automatically sign a receiving tx would be both too costly to many (both the hardware and electricity) and 24/7 up-time would be impossible to ensure. If you think this is a solution you are mistaken.
No idea what you mean by āweā because if you have been reading the thread WE are far from any consensus here, which is the point for the conversation.
1 Like
We is you and I here. Keep cool
Totally agree here. Without a trustable and easy-to-use wallet, Grin will never be accepted by regular users.
3 Likes
+1 for grinbox, it has a unique address at least.
Grinbox as a Tor onion hidden service could do it.
I guess some kind of fee would be required to keep it sustainableā¦
1 Like
Some kind of overlay p2p network message storage and relay system (I am sure there is a more savy technical term) has been suggested. Both SBBS-like and grinbox-like burnt into the whole network. It was not deemed the preferred option because of DoS-able (and maybe other reasons as well). I still think it is a good option as well.
If you build grinbox into the p2p layer, it becomes a DoS / spam vector. Just flood the network with messages. Theyāre end-to-end encrypted, so itās not easy to tell whether they are legit or not. Using proof-of-work as a rate limit etc is easier said than done effectively (i.e. to actually stop a motivated attacker, rather than being a nuisance for legitimate users), and if we want clients to broadcast using Tor, then sybil attacks can be tricky to prevent.
If you do not build it into the network, these concerns still apply, but they wonāt affect the p2p network if they occur. Still, it becomes difficult to have this as a default (i.e. see any meaningful adoption) unless you explicitly enforce ONLY grinbox as the accepted method, thatās then run through a federated network of relay servers that are operating at loss. Kind of like how SMTP works today for email.
Youād have gd6p24toTTDj7sxCCM4WGpBVcegVjGi9q5jquq6VWZA1BJroX514@grinbox.io or some other @relay.com address depending on which server you used. If you connect to the relay over Tor, thereās no leakage of IP data.
These relays become critical point of failures for transaction building. So it would be a systemic risk if a lot of users are on grinbox.io for example and the server goes down.
As one of the people working on grinbox, I really wanted this to work. Itās extremely simple compared to other solutions, it can be made to be fairly privacy-preserving, itās reliable, fast, and performant. But for this to be viable for grin as a default, I think weād need to see A LOT of people, companies, organisations running their own federated relays, and users being fairly well distributed between these relays. Then itās decentralised and resilient to shocks. Otherwise itās centralised and sensitive.
Unless the p2p network nodes act as the relays, but then youāre making it more resource intensive to run nodes (which may go against other objectives), and even if we wanted to do that, itās still not clear to me how youād execute that in a simple, reliable, and scaleable way.
2 Likes
I respect all of these concerns. However, the DoS attack is easily solved by the multitude of transaction mechanisms that we already support. Beam solely relies on SBBS and would be screwed if DoSād and they havent been. Tari is also relaying messages in p2p layers built into the tari protocol. A very usable option, that also supports asynchronous txs, with a probable up-time that is extremely high seems worth it to me. Fall back on slatepacks if attacked. If the threat of DoS attacks stopped people from doing things then the whole internet would be very different.
2 Likes
I appreciate your opinion about how to go about this. Weāre all trying our best to come up with something that works. If thereās a slam dunk approach on how to go about this that ticks all our boxes, it seems itās yet to be discovered[1]. Until then, I believe itās a matter of figuring out what trade-offs weāre comfortable making.
Beam solely relies on SBBS and would be screwed if DoSād and they havent been.
āProject X has a DoS vector and they have not been DoSāed yetā is not a strong security guarantee, in my opinion. Still, thereās a real opportunity for us to study and learn from the approach Beam took with SBBS.
Tari is also relaying messages in p2p layers built into the tari protocol.
Tari is not in production yet. Their solution may work well in testnet, but that alone does not directly translate to a production grade solution thatās simple, reliable, and scaleable. But perhaps it will be! Tariās approach is also something we should study and learn from. It seems that their objectives and priorities are different from ours and that they are making different trade-offs as a result.
Fall back on slatepacks if attacked.
If relays are integrated into the grin nodes, it is the p2p network itself that is being disrupted if the relays come under attack. How does falling back on slatepacks help in that scenario?
[1] I believe this comparison table illustrates this quite well Compare transaction-building alternatives Ā· Issue #283 Ā· mimblewimble/grin-pm Ā· GitHub
2 Likes
Yeah, I totally see your point and agree that the SBBS argument doesnt hold water from a security standpoint. I also appreciate security first viewpoint, but even from that viewpoint it should be security first and usability second rather than just security first. I do not believe we have reached the minimum requirements for usability and I believe the situation is dire enough to sacrifice some potential security threats (p2p message storage-relay system) and some of the academic beauty of MW (one-sided/non-interactive txs). In fact, I think a p2p message storage-relay system could be used to increase aggregation and other things that increase privacy/security, which further increases the trade-off benefits.
I am not sure if it is possible, but maybe the event of p2p relay DoS attacks, nodes could detect this and shut this system down and/or ban the malicious nodes (over and over if necessary). Maybe these comms could be over a different port or something. If it could DoS the whole network then it seems like that attack is possible with current comms too but we already either accept that or have sufficient mitigation measures in place.
1 Like
If it could DoS the whole network then it seems like that attack is possible with current comms too but we already either accept that or have sufficient mitigation measures in place.
P2P relays for encrypted transaction slates act as message stores. They have to store arbitrary amounts of data that anyone can send to them, that is difficult to validate to be legit while still preserving privacy, and that can be produced cheaply. An attacker could flood these relays with half built transactions until the hard drives fill up or some limit hits and legit slates stored on the p2p network get crowded out.
I donāt think you can do something similar in the current grin p2p network. You could try to flood the blockchain with finalised transactions, but that will require you to build valid transactions and pay transaction fees.
2 Likes
Could the P2P relays require some fees to be paid to avoid being spammed?
Yeah, makes sense. I didnt consider that the storage part is where the attack is rather than the amount of communication occurring. I think most limit the number and duration of time that messages remain in the relay network and in this case the fall back options of direct p2p (slates or tor) work well.
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 
1 Like