Safecoin: Gold, Silver & Copper

[neo]

@safer

Could I put SD with the size of 1MB

FYI: SDs have a maximum size of 100KB each

[TylerAbeoJordan]

@Lazarus_Long

Create a group of vaults on their botnet to generate Safecoin
Use all this Safecoin to create more identities and vaults

Farming requires real resources that cost real value. if Safecoin grows in value, then the network will become large as there is a huge amount of real resource out in the wild that is untapped e.g. every cell/mobile phone in the world. Any botnet would hence be a minor player no?

[Lazarus_Long]

@bluebird

If they are interchangeable without friction, and if they’re divisible down to dust values, then they’re functionally the same currency, so the three currencies are functionally mere names for the same currency.

When we had the gold standard (I’m thinking of pre-WW1), the currencies of the day were approximately the same currency.

You’re right on the first point. In my thinking I combined the risk of free resources with the problem of balancing those same resources. On second thought this is not a problem for Safenet, as Safenet is a monopolist within it’s own sphere. It can set any price it wants.

Your second point is not right however. There were lots of problems between nations. As soon as they introduced fixed exchange rates between gold and silver, any change in markets condition for gold and silver production made the coin fixed above its relative market value to an object for hoarding and melting. That will not apply for the foreseeable future however.

I still stick to the point that, if one of two more or less interchangeable resources is free, the free resource is a potential attack vector. It is free rewriting instead of free creating that might be the problem with SD however.

@TylerAbeoJordan

Any botnet would hence be a minor player no?

This thread was started because someone asked after attacks on Safenet to cripple it from the very start

[tfa]

To check the effects of this kind of DoS attack, I plan launching such an attack today April, 15 at 19:00 UTC time. I will begin slowly by writing 100644 bytes on each SD of a set of 49, within a 5 minutes time frame. Then the writing speed will progressively accelerate. I target a one-hour experiment but I am not sure of my computations and it may last longer (or shorter if my program crashes!).

The number of written bytes was chosen so that it is below the limit triggering the storage of the payload in an immutable data (but I don’t know the exact limit).

Until safecoins are introduced it would be easy to attack the network by repeatedly creating accounts and putting the maximum authorized size of immutable data for each account (5GB). But this kind of attack is not an interesting stress test because in the real network it will cost a lot of money to execute it: as the attack advances, free space decreases, cost of put increases dramatically and finally the attacker will run out of safecoins.

By contrast, I think the results of the attack I plan to execute will be useful, because in the real network writing a set of SD will cost a fixed predictable one-time payment and will be possible with a low budget.

I need the help of the community members to use the network during this test and observe if any regression appears. This attack may cause disruptions (this is what I want to check) but only while it is running. After that, things should return to normal because the volume of data in the network will remain the same as now (the 49 SDs are already created).

I apologize in an advance for the lost time if my experiment fails miserably.

[janitor]

@tfa

I apologize in an advance for the lost time if my experiment fails miserably.

There’s no reason it should fail if the script works.
If you want to share the code, I’ll gladly join you in smashing the testnet.
I’m too busy to do it manually or write my own (and the latter may be beyond my level of competence).

[tfa]

I have just put the program on Github.

You’ll have to:

• modify credentials at lines 71/72/73 and SD names at line 121 to manage your own SDs
• copy safe_launcher.crust.config file in the directory containing generated repeated_sd_writes executable file (target/debug by default) and rename it to repeated_sd_writes.crust.config
• execute following command to create the SDs:
  RUST_LOG=repeated_sd_writes=debug ./target/debug/repeated_sd_writes writer -c -o
  (to be done in advance)
• execute following command to launch the stress test:
  RUST_LOG=repeated_sd_writes=debug ./target/debug/repeated_sd_writes writer
  (to be done tonight at 19:00 UTC)

[tfa]

My stress test is beginning right now.

There should be in no impact at the beginning because the flow is minimal for now (49 * 100KB / 300s = 16KB/s). But it will slowly accelerate and in about one hour it will be maximal and I don’t know how the network will behave then.

[mvanzyl]

Hopefully the network can handle it!! We may want to see if we can loop in @dirvine or @Viv to be able to check the results from the dev end…

[dirvine]

No worries, it’s a testnet if it can get broken then lets investigate. There is a bunch of security things not in place, but every attack is good for us to see. Small testnets like this need attacked when possible. This seems like a good time as this testnet will probably get taken down soon enough.

This one for instance has no handling for network full, (was put up before this was coded) so if it does fill it should be interesting to see the logs and look for anything new. The network always surprises us in test though so neat to try all this before it costs money to do these attacks as we can see what folks with lots of money can do later. At least form some angles.

You may see some tools very soon to allow folks to spin up small networks (or large) and try and bash them from all angles. We hope many folks will

[dallyshalla]

Nice one @tfa Glad to see experience gains of devs

[tfa]

My test finished about 20 mn ago.

Did anyone notice any regression during its execution ?

A problem in my test is that the peak SD writting rate was at about 115KB/s. That’s not a lot. Maybe it was not enough progressive and should have begin at a higher speed.

[tfa]

@dirvine

This one for instance has no handling for network full, (was put up before this was coded) so if it does fill it should be interesting to see the logs and look for anything new.

I didn’t want to fill the network because it wouldn’t be a realistic attack without safecoins. I have specifically chosen an attack that will not cost much money on the real network.

[tfa]

@tfa

Maybe it was not enough progressive and should have begin at a higher speed.

I have just launched a more stressful test with a higher initial speed (160KB/s) and that will last about half an hour.

[tfa]

My second attack didn’t complete and crashed after 15 mn with the following error:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: CoreError::RoutingInterfaceError -> NotConnected', ../src/libcore\result.rs:746

At that time the writing rate was about 280KB/s. The network itself seems to have handled this rate very well.

I will stop my tests on this subject for now. Testing a significantly higher rate would need a distributed attack involving several people.

[janitor]

Thanks for giving it a try.
I passed out before the test (very late in my time zone), maybe I will have better luck next time.