Questions about DBC's transaction fees on SN?

Autonomi Network Token
1

In the third of fundamental principles in Primer (https://primer.safenetwork.org/), it say: Allow the transfer of the Network currency Safe Network Token to any user free of transaction costs.

However, in general, if an attacker can continue the spam attacks that send repeatedly his DBCs to his another account, the network may be at risk. Therefore, the transaction fee is recognized as necessary for the security of the network. In other words, it is a useful means of protecting the limited resources of network or nodes.

For this reason, I think DBC’s transaction fee in SN is necessary.

This is the question I have. Very Thanks…

3 Likes
2

This has been discussed many times before here … although not much perhaps since DBC’s have come forward as SNT’s. I think the primary method in the past for dealing with this was a rate limiter, but also that the bottleneck for doing a transaction was with the client, not the network.

This potential issue will be worked out though in the testnets and you can be certain that it’s not being overlooked by the developers.

3 Likes
3

Thanks for your kind reply.
I got interested in SN this year and didn’t know about the previous discussions.

However, SN is based on anonymity and open source. Open source will defeat the rate limiter of client, and anonymity will make it impossible to distinguish attackers. Therefore, the network may have no control over the attackers. I think this will be the problem. Thanks for all…

1 Like
4

The rate limiting has to be not on the client side, otherwise there is no point in having a rate limiter. Aren’t clients connecting directly to the destination sections, so its not anonymous anymore?

2 Likes
5

Yes, the rate limiter is not on the client side … the rate limiter and the bottleneck issue are separate … I’m not sure if the bottleneck issue even exists anymore with DBC’s, but before it was due to processing issues in the client, and not an in-built rate limit. The rate limiter itself is with the nodes processing the requests, not the client.

Also keep in mind that XOR connections to the network means it will be super hard for gangs of computers to overwhelm the network.

2 Likes
6

I am also guessing that a blind signatures of DBCs could make it difficult to implement paying transaction fees. But I don’t know the details about this.

1 Like
7

Yeah, I was a little surprised to read this. The prior methods appeared more secure imo since the clients couldn’t speak directly to sections. I would be interested in hearing a rationale for the change, or more description about the differences/implications.

Transaction fees are not going to happen imo. Goes against the Network philosophy.

5 Likes
8

One thing that has been done to mitigate this has been adapting a trick that I believe came from the AT2 implementation but now extended to DBC, which is that clients collect all the required signatures for transactions before passing them on to the section elders to sign.

This reduces network load and especially lowers load to elders who already have the most important job in the network.

I imagine spamming is still quite possible though and I think it is something that is planned on getting more attention in due course. Always good to hear the team’s preliminary thoughts or approaches ahead of time though.

9 Likes
9

Yes, I’m not entirely comfortable with this myself.
It means that every client will pretty soon have all IPs of every Elder, just by using the network and storing data.

The previous solution was supposed to put some sort of threshold effort in being able to achieve that.

I think it comes from the idea that “a msg should be accepted regardless of where it comes from”.

I think it translates into “forwarding and relaying was a bit of a PITA to work with, so we skipped that - at the cost of revealing all Elder IPs to every client”.

If we flipped the coin, we would say “hiding the Elder IPs as far as we can, is so important that we accept the PITA of getting forwarding and relaying to work properly”.

That’s my view atm I think :thinking:

8 Likes
10

Each DBC can occupy several KB. and anyone can divide a DBC into billions of new DBCs occupying a huge space in the network and, presumably, in the same section.
Furthermore, if I am not mistaken, the size of the DBCs increases with the number of parents amplifying this attack as the divisions get deeper.
The rate limiter could slow down this attack but not prevent it.

1 Like
11

I think it’s a “digital bearer certificate”, so DBC? Or have I mixed up my acronyms?

1 Like
12

:+1:
Edited…

1 Like
13

I’m not certain this is right, or at least part of it … if you send a small amount of a DBC to another account, then it’s not likely going to be in the same section and you’d have to iterate that billion times right? How are you imagining that you are going to break up a large DBC into smaller ones? It seems to me that the section elder handling this operation isn’t going to just break a large note into many smaller notes and send it back to you. Possibly I’m not understanding something here.

I agree that over time there will be more and more smaller DBC’s, but these can be merged as well as split I think. Plus this will happen as the network grows, so more nodes to take up the larger load?

14

I don’t think this is how it works. DBCs don’t have to exist on the network unless you decide to store them in your space, in which case you pay to store like any other data.

This might be the case, but it isn’t clear so it requires someone to dig in further to understand exactly what is involved in a transaction.

For example, I don’t believe the network is involved in creating a DBC any more, only in checking if it is valid which doesn’t have to be done in order to create a transfer.

I think of DBCs as more like coins and notes which we can independently split and merged without involving the network. We can also ‘transfer’ their value by specifying the owner, all without the network being involved. If you give me a DBC in my name in exchange for goods (using a USB drive or in an encrypted message for example), I might take it on trust or I might check with the network that it is valid before giving you the goods.

I think the above is how the current design works, but I’m not 100% so if anyone knows or checks this out it would clarify this discussion.

So it would I think be a matter of spamming the network by repeatedly asking it to check the validity of a DBC and the measures to combat this would be more likely similar to nodes spamming by GETs rather than needing to charge a fee. Charging a fee itself adds complexity and work for the network, so I don’t think it is obvious its the best way to deal with this, and I hope it won’t be necessary.

3 Likes
15

Thanks for the clarification.

Yes, I’ve heard it both ways and am confused as to where we are with this.

Is that right? I must still not fully understand how DBC’s work … it sounds like magic! :slight_smile: I can understand them being transferred offline, but seems like verification + splitting/merging would still require the trustlessness of the network.

1 Like
16

My understanding (again may be wrong) is that validation with the network involves checking all the inputs and outputs add up and that the inputs have not been spent already. So you can take a load of DBCs and create a new one (split, merge, transfer etc) without involving the network.

2 Likes
17

The client does the work of creating the DBC which creates an issue for a PC generating massive numbers of transactions. Now botnets counter this, I guess the point is that its not as simple as the client sending a request to the network to send “X” SNT to an address.

Thus there is some work for the client to do.

Also the DBC must be received by the receiving client and unpacked before it can create a new one and send it back, or elsewhere.

All this creates some limits too on how fast any one pair of clients can bounce DBCs between themselves. What that is is uncertain. Now David mentioned that preliminary tests show that any one section will achieve very high rates of transactions, on the order of thousands to 10’s of thousands per second. Thats for a section to transfer the DBC. If there are 100’s or 1000’s of sections then it will be a very high rate of transfer achievable. Remember the majority of the work is to create the DBC.

This surprised me too since it was not all that long ago that David corrected the thought there was no hoping between sections, now its no hopping. That was an important part of anonymity where IP addresses are stripped off. I hope there is another measure now to keep the anonymity otherwise tracing by 3rd parties has become easier.

7 Likes
18

Yes, this is one of the things that limits a client.

The client needs 5-of-7 mint signatures to be able to send a dbc.

The client sends 7 requests, one to each mint node (7x more work for the client than any mint node)

Each mint node signs the request (this signing operation takes about 1.347 milliseconds on my laptop, but each node needs to do it so it’s 9.429 milliseconds total network time spent generating the signatures).

The client receives 7 responses, one from each mint node (7x more work for the client than any mint node)

The client combines 5 of the 7 signatures (on my laptop takes an average of 2.233 milliseconds)

Overall the network does 9.5 ms of work for each tx, with each node individually doing 1.3 ms of work. The client has to do 2.2 ms of work, almost double the work of any individual mint node. This seems pretty reasonable to me. Clients will have much more work to do than any individual mint node.

I missed out some verifications etc but this is the broad picture; the client always does more work than any mint node.

The network only stores the spentbook, ie the identifier of each spent dbc, not the whole dbc itself.

The client is the one that writes to the spentbook, not the mint nodes. The client can never make the mint nodes do a lot of work before having done work itself.

I’m not trying to say the amplification isn’t there, I think free payments does come with risks, but it’s maybe not as big as first thought.

The main thing will be to ensure the client always does more work than the network, which will limit the effects of spam greatly.

This may mean clients might need to add some proof of work to their dbcs to act as a spam prevention (like hashcash was originally designed for), or maybe the 7-to-1 difference of mint nodes as outlined above will create enough work for clients. We’ll have to see how it goes in testnets.

Yeah this may be, but the exact transaction mechanism is still being fleshed out so going into details now is probably a recipe for future confusion. It’s tempting to write a whole lot about the cool tech (there’s some very cool stuff both in use and thrown away) but I feel just now it’s probably counterproductive.

7 Likes
19

So the receiver verifies the DBC … but do they need the network to do so?

20

Thanks @mav and I agree not too much point going into great depth although it would be useful to have any misconceptions - such as in my descriptions - dispelled and corrected.

Your description seems to say that to create a DBC you need the network to confirm, while I contradict that and have said it is only needed for validation. Are you clear about this part?

5 Likes