Dynamically change the size of the buckets?

Is it viable to dynamically change the size of the buckets (cutting up those buckets to create more buckets in the range where most of the trx are being done in the last N hours? This information could be shared asyncronously between nodes every M hours?

PROBLEM: If the spammer knows the fixed size of the buckets and knows which buckets are typical with high saturation he will attack in consequence...

POSSIBLE SOLUTION: It would be better if this change dynamically so the spammer won't affect other valid trx...

Adding a field of “bucket saturation” the nodes could adapt the size of the buckets.

For example, if there is high saturation in one bucket (because is under attack) that bucket could split into two buckets. If the attack continues in one of the two buckets, then it will split again into two buckets and so on...

The “bucket saturation” field of one bucket should be relative to the “bucket saturation” fields of the rest of the bucket so the node could check which is the bucket with the highest saturation and split that one.

To keep the number of buckets fixed (129), and keep it simple, the last buckets will be deleted.

For example, considering this sample of buckets:
Bucket 010: 0.000000000000000000000000000512 Nano
Bucket 011: 0.000000000000000000000000001024 Nano
Bucket 012: 0.000000000000000000000000002048 Nano
Bucket 013: 0.000000000000000000000000004096 Nano
....
Bucket 127: 85070591.730234615865843651857942052864 Nano
Bucket 128: 170141183.460469231731687303715884105728 Nano

If the spammer is attacking with 0.000000000000000000000000002000 Nano from multiple accounts, and the Bucket 011 has the highest saturation, it will split this into two buckets:

		Bucket 010: 0.000000000000000000000000000512 Nano
		Bucket 011: 0.000000000000000000000000001024 Nano
		Bucket 011bis: 0.000000000000000000000000001536 Nano
		Bucket 012: 0.000000000000000000000000002048 Nano
		Bucket 013: 0.000000000000000000000000004096 Nano
		...
		Bucket 127: 85070591.730234615865843651857942052864 Nano
		Bucket 128: 170141183.460469231731687303715884105728 Nano

To prevent the creation of more than 129 buckets, the rest of the buckets could reassign their amount of Nanos from bucket 13 to 129 (taking this range instead of 1 to 13 because the split bucket was < to bucket 64 and starting from 13 to keep the amounts of the nearby buckets 11 and 12 of the split one).
To keep it simple, we will delete the last bucket (no one will use this bucket in real life...)

		Bucket 010: 0.000000000000000000000000000512 Nano
		Bucket 011: 0.000000000000000000000000001024 Nano
		Bucket 011bis: 0.000000000000000000000000001536 Nano
		Bucket 012: 0.000000000000000000000000002048 Nano
		Bucket 013: 0.000000000000000000000000004096 Nano
		...
		Bucket 127: 85070591.730234615865843651857942052864 Nano

Renaming the buckets:

		Bucket 010: 0.000000000000000000000000000512 Nano
		Bucket 011: 0.000000000000000000000000001024 Nano
		Bucket 012: 0.000000000000000000000000001536 Nano
		Bucket 013: 0.000000000000000000000000002048 Nano
		Bucket 014: 0.000000000000000000000000004096 Nano
		...
		Bucket 128: 85070591.730234615865843651857942052864 Nano

We could do the same process at least 6 times (because no one will attack the network holding more than 2658455 Nanos... and if it does, the spam attack will probably affect only himself...)

		Bucket 122: 2658455.991569831745807614120560689152 Nano
		Bucket 123: 5316911.983139663491615228241121378304 Nano
		Bucket 124: 10633823.966279326983230456482242756608 Nano
		Bucket 125: 21267647.932558653966460912964485513216 Nano
		Bucket 126: 42535295.865117307932921825928971026432 Nano
		Bucket 127: 85070591.730234615865843651857942052864 Nano
		Bucket 128: 170141183.460469231731687303715884105728 Nano

Considering that the attacker continues attacking with 0.000000000000000000000000002000 Nano we finally have the following:

		Bucket 010: 0.000000000000000000000000000512 Nano
		Bucket 011: 0.000000000000000000000000001024 Nano
		Bucket 012: 0.000000000000000000000000001536 Nano
		Bucket 013: 0.000000000000000000000000001792 Nano
		Bucket 014: 0.000000000000000000000000001920 Nano
		Bucket 015: 0.000000000000000000000000001984 Nano
		Bucket 016: 0.000000000000000000000000002000 Nano
		Bucket 017: 0.000000000000000000000000002016 Nano
		Bucket 018: 0.000000000000000000000000002048 Nano
		Bucket 019: 0.000000000000000000000000004096 Nano
		...
		Bucket 128: 2658455.991569831745807614120560689152 Nano

As you see in this case, the attacker will stay "alone" attacking a bucket of just the amount which is sending... doing the attack extremely inefficient...

After 6 splits, the network will destroy the bucket created on the first split done (FIFO) and continue to split the next bucket (so bucket 128 will always have 2658455.991569831745807614120560689152 Nano)

With this approach, the spammer could only attack with a random amount of money in lots of buckets (doing the attack extremely less efficient).

QUESTIONS:

  • Is this necessary considering that the spammer will be slowed down by the Balance*time_last_use?
  • Should the splits be a decentralised process where the nodes share between them the most saturated bucket or could be done in every node locally?
1 Like