For some services, it might be less usable. I guess you can’t have everything.
I think hardware wallets could automatically sign txs for the receiving side only, so it shouldn’t be a problem.
Which is why we’re trying to discuss ways to support offline transactions…
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.