Let’s wait for @mav who may know a bit more, but my understanding is that validation is optional - i.e. not part of a transaction, hence transfer can be offline. I may have read too much into what can be done offline, but AFAIK you can receive a DBC on a USB drive without the network being involved, and it is up to you whether you take it on trust or ask the network to validate it. So two separate operations, one NOT involving the network, and one involving it.
2 Likes
I think this is not enough unfortunately though.
Consider that a single node needs to handle requests from x clients.
If it handles requests from 2 clients, and is of same specs, then it will be maxxed out when those two max out.
But it’s more likely that it will handle requests from… 100 or 1000 clients… concurrently.
If it has same specs, it will max out when each client is between 0.2 % and 2 % (1/500 - 1/50) of maxxing out.
We can see already that it is very easy to multithread requests (most of all queries) on a client and send them off to the network and cause a massive amplification. This needs more attention IMO, introducing hashcash or whatev. necessary.
Also, there is a need for the network to be able to be dynamic with all its critical resources, not only disk space.
12 Likes
What sort of measures are there to ensure the client does not lie in the spend book? Will there be a PUT charge to do so?
You can also add in the lag time the client has to endure for sending requests to mint nodes and receiving from the mint nodes. This increases the elapsed time the client requires to build the DBC. It could do multiple DBCs at once to reduce that though. But there are limits to this in a client
2 Likes
Exactly. Your reply highlighted my concerns precisely. It makes the “nasty neighbors attack” much worse and/or easier to perform. I could see putting this issue on the back burner for a few testnets, but we will need to deal with nasty neighbors eventually imo.
4 Likes
Mostly yes.
You can create a new dbc from an existing one you own, and sign it with your key, all offline. This would be a ‘prepared but not spent’ dbc.
You can give that new dbc to somebody, but it won’t have a mint signature so they don’t know if you’ll double spend the parent dbc, so they probably won’t / shouldn’t accept it. But they could.
To get the mint sig for the new dbc it needs to be submitted to the network. The mint signature allows the recipient to know the new dbc has a valid parent and the parent has now been spent to this new dbc (ie the parent can’t be / hasn’t been spent a second time to some other dbc).
This is a good way of putting it.
The client commits to spending their dbc one particular way, writes that commitment to the network, then after the commitment is saved the mint will check and sign the tx they committed to (and only that particular tx). So in a sense, the dbc is spent before the mint signs it.
Think of it like every dbc has one unique and deterministic ‘spent’ location on the network. The owner of the dbc must write to that location with details of how they want to spend it. If they try to write two different things to that location it would fail.
There’s no way for the client to trick the mints with race conditions etc, since the client is the one writing the spend. The mint just puts their stamp of approval that the spend has been done by the client correctly.
11 Likes
Are there any things you can’t do in terms of taking DBCs you own and using them to create a new DBC without network involvement or is it only validation which requires the network (as my earlier posts are saying)?
I understand that in most situations someone will not take a DBC on trust, but will want to validate it (by asking the network) but I want to know if there are things other than that which could be used to spam the network, as inferred in the OP.
The following could be the client which is issueing, or a client which is validating, a DBC. This seems relevant to my question above…
2 Likes
Just a random thought…
Can it spend to itself? Imagining a virus that creates a botnet running Safe, the bots wouldn’t need to send to each other and risk losing the SNT.
@digipl suggested that you maybe could split up a DBC into millions or billions of smaller DBC’s. If a client can run these ops in parallel splitting and remerging, while it would be a huge amount of work for the client, could it be possible (early on when the network is small at the least) for a botnet to create a significant drag?
Botnet incurs no cost to the creator except discovery and loss of seed SNT. It would make more sense financially for a net like that to lay low and send SNT to creator, but if it’s a gov. or corporate attacker, they may just want to render the network useless.
If you can’t send DBC’s back to yourself then this sort of attack might be hard or impossible as you’d have to trust the receiver to return it to you.
Wondering if perhaps a fee could be used in the early days of the network and repeatedly halved as the network grows. The early days of the network are when it will be at it’s weakest.
And/Or perhaps a proof of work that decreases in work as the network grows?
5 Likes
Wwwwhhaat? I missed your post earlier …
Even if a huge number of elders, doesn’t this open them up to simple ddos attack? At worst it means governments know where top nodes are … and opens us up to direct attack. It sounds like there is no way someone in China would be able to run a node at all … we are leaving out a huge chunk of the global population + things in other countries look to be getting worse on this front. If governments put out a ban on the network how do we hide the nodes?
This makes zero sense … we’d all have to use VPN’s to use the network and then hope the VPN isn’t working with the gov.
Am I missing something here? This doesn’t seem to be the network as described originally.
3 Likes
Not all nodes are Elders, and not all participants can as things stand become Elders due to router issues, though that may ease in time. Anyone can therefore still participate as an Adult (earning) node.
Being able to identify Elders is a big vulnerability though - blocking by ISPs, the Great Firewall etc so I don’t think this is likely to survive as an approach, but to get things going for stable testnets it is probably fine.
7 Likes
Excuse my networking ignorance but if I am in China my ip is scrubbed on the first hop still right? So how does the firewall prevent me from accessing an elder if they don’t know where I am connecting from?
Also I assume elders will continually be created so it would be a constant task to keep tabs on?
1 Like
You’re correct that Elders that fail for whatever reason will be replaced but that doesn’t solve the problem.
If China track and prevent access to Elders inside and outside China your client won’t be able to connect to them (anything on the blacklist), so if direct connection is required you won’t be able to do anything that necessitates that. How likely that is I don’t know but it is a concern.
DDoS is a less extreme worry, but still could be a problem if targetting particular sections can cause widespread disruption.
4 Likes
I can see clearly now 
Do VPNs work for the Chinese people? Not that I would want them to be reliant on them to participate and it really shouldn’t be required.
I understand that … but is promotion from adult to elder automatic? Or can you specifically set yourself to only advance as high as an adult? Because in China at least, it could be more than simply being cut off from the net that you’d have to worry about here. So there is a huge amount of deterrence built into the threat of being caught.
Yes. But you can’t know for certain that the VPN isn’t compromised.
1 Like
The vast majority of SNT transactions will need to generate new DBCs which will need to be confirmed by the network. If the customer pays for these DBCs, transactions will, for the most part, no longer be free of charge.
You’ve hit upon what I call the “nasty neighbor attack”. There are various subtleties to it. Giving clients direct access to section many elder ips makes it worse. Before, only rougue elders really had the capability to map the network ips and do an out of band attack of any consequence. This is an issue that will need to be addressed in beta imo. There are some possible solutions I’ve come across, but people probably won’t like them.
4 Likes
@happybeing , a very good point.
But I think DBC will be connected to Dapp or smart contract. In this case, attackers could initiate the attacks using an infinite loop. And Sybil attacks can exacerbate this. Thanks for @happybeing
In https://opaque.link/post/digitalmoneydbc/, it says: “In a typical transaction, user A would send a DBC 1 to user B, user B would then communicate with the mint to exchange DBC 1 into a new DBC 2.”
Unlike this, in SN, does User A send DBC 1 to Mints and get Mint’s signatures? Thank for @Nigel
1 Like