Pre-proposal: Protecting the Network Against Flood Attack

[Ricardo Temporal]

I have designed an economic model that calculates the block size dynamically in order to mitigate the attacks against the network.
I intend to submit the proposal to the vote of the masternodes. If the proposal is approved, it does not mean that it will be implemented. It means that the DAO considers the proposal as a possible way to go. The vote allows we to know the opinion of the investors without the noise caused by the debate.
The cost of the proposal is just the reimbursement of the fee if the proposal is approved.
The link to the paper follows in another post.

 

[Ricardo Temporal]

Abstract. The block size is analyzed under the perspective of a deliberate attack against the
network. We talk about the naive proposals that do not consider a deliberate attack. We argue for an
economic model that calculates the block size dynamically in order to mitigate the attacks.

 

[Ricardo Temporal]

The focus of this proposal is the defense of the network against the enemies. We take the
assumption that there are enemies out there, and the enemies may have massive amount of
resources. Some enemies haven’t attacked yet; but, we should be prepared in advance.

 

[Ricardo Temporal]

Follow the link to the paper.

https://www.dropbox.com/s/ngmk66p0v55pizo/Dynamic Block Size.pdf?dl=0

 

[Dashmaximalist]

you should post this is technical discussion part , over here just tell us why you think your solution is better than current one in English not in maths , Thanks

 

[Ricardo Temporal]

The economic incentives of the current solution is vulnerable. The enemy can overload the cost of the system to make the ownership of a masternode becomes not profitable. Technically, the system can continue to run, but it will not be economically viable in the long term.

My solution holds the costs low.

 

[Dashmaximalist]

how exactly ? we plan to increase the blocksize based on the demand , which is not exactly bad

 

[GrandMasterDash]

As pointed out, this should be submitted as a DIP in the technical forums.

Personally, I would prefer a solution for dealing with micro-transactions. Recently, for example, Coinfirm told us they were using the dash blockchain as a non-financial ledger, issuing thousands of micro-transactions. I support their idea but it's clear a technical solution is needed to prevent bloat / reduce system load.

 

[Ricardo Temporal]

The demand is unlimited. but, the resources are limited. Scarcity is considered as 'the basic economic problem', check the link for reference. For example: With current block reward of 1.8 Dashs per week, the increase of the block size cannot increase the cost of ownership to more than that value. People presume that the price will go up in the same speed of the demand in order to offset the cost. But, that assumption is false because it does not consider a deliberate attack. The enemy can buy just small amounts of the the coin in other to broadcast a massive demand.

Perhaps, this should be a DIP instead of a proposal. Ok.

https://www.investopedia.com/terms/s/scarcity.asp

 

[demo]

Perhaps, this should be a DIP instead of a proposal. Ok.

No, it should be a proposal.
We have to expose the stupidity of the masternode owners.
Those stupid, fat, greedy masternode owners are supposed to govern, but they know nothing!

 

[Coqui33]

I agree that the decision whether to implement or not should by via a DIP. But I read the OP as suggesting MNO's voting on this proposal merely to get the opinion/preferences of the MNOs. I see no harm in finding out. I would vote "yes" just out of curiosity.

 

[Vedran Yoweri]

wouldn't it be the case that this solution is more dangerous for the network than the problem it tries to solve? large mempool is a problem, but no danger to the blockchain. unlimited growth of blocksize could stop or damage the network. imagine how many nodes would drop of the network (crash or fork) now if someone would push a 1gb block through every 2.5 mins.

 

[Ricardo Temporal]

wouldn't it be the case that this solution is more dangerous for the network than the problem it tries to solve? large mempool is a problem, but no danger to the blockchain. unlimited growth of blocksize could stop or damage the network. imagine how many nodes would drop of the network (crash or fork) now if someone would push a 1gb block through every 2.5 mins.

You might have read only the title. I don't blame you, it's my communication mistake. I must fix the title, sorry. The dynamic part of the block size is about decreasing, not increasing the block size. Exactly to avoid the damage of the network when somebody is pushing 1Gb block every 2.5 minutes.

In the version 12.2, the maximum block size is 2 Mb. In this case, the dynamic model would make a decision to use that full capacity or not. The model would just decrease some blocks to 1 Mb. It would never increase to 3Mb, as it's prohibited by the protocol.

 

[Vedran Yoweri]

You might have read only the title.

true.

I intend to submit the proposal to the vote of the masternodes.

don't think that's needed. propose as dip in tech forums would start the relevant vetting. and a chance to change phrasing so lazy mno can still follow.

 

[demo]

don't think that's needed. propose as dip in tech forums would start the relevant vetting. and a chance to change phrasing so lazy mno can still follow.

@Ricardo Temporal
Dont propose a dip in tech forums, in order for others to steal your ideas, pay developers to implement it, then gain 1.5 billion dollars from it!
Keep the details for yourself, until the stupid/greedy masternodes pay you to reveal them.

 

[Ricardo Temporal]

I've made some changes to the document according to the feedback.

1) Changed the title: "Protecting the Network Against Large Blocks".
2) Explanation: "The block size will vary between the minimum and the maximum capacity of the network...".
3) Explanation: "The enemy can buy just a small amount of coins to broadcast a massive amount of transactions..."

The link is updated.

The DIP001 had been first a proposal approved by the vote before being transformed into a DIP. I think the core team should not even consider to implement such a change that is not approved by the masternodes. I will not do anything for a while. Let me improve the communication according to the feedback.

 

[Plateglassarmour]

I am struggling to see the problem with increasing the block size when the current size fills up.
If the spammer pays for a full block of spam, the fees generated should be enough to pay for the increase in network capacity; that is the whole premise for scaling in the future.
If the fees generated by a full block isn't enough to pay for the network capacity to host it than the whole blockchain model will break down in a few years anyway and we will have considerable larger problems than spam transactions.
If paying that cost becomes prohibitive to the spammer and they stop the attack, we will just have large, relatively empty blocks, which isn't actually a problem since large empty blocks don't take more resources to host than smaller blocks.

 

[Vedran Yoweri]

I think the core team should not even consider to implement such a change that is not approved by the masternodes.

couldn't disagree more. i'm not gonna vote positive on some core software change from a stranger, whatever it says.

 

[Ricardo Temporal]

... the fees generated should be enough to pay for the increase in network capacity; that is the whole premise for scaling in the future.

The network capacity is being paid by the inflation, the fees are not being enough to replace the inflation. The fees can be increased in the future to keep that premise true, ok. But, this is brute force. A model can avoid the problem while keeping the fees low.

 

[Plateglassarmour]

My point of contention with filtering the blockchain for large blocks of cheap transactions is that it can filter out valid transactions as well. If it is not necessary to do so, I don't think we should ever filter for cheap transactions, simply let the current system of competing fees handle any excess.

If we implemented your system, what would prevent a hypothetical attacker from spending more on an attack in order to get large chunks of cheaper valid transactions thrown out by the algorithm?

I am not actually against the idea if I can see the logic behind filtering our transactions, but as the incentives stand, I don't see how it would be an improvement on our current setup.

 

[Ricardo Temporal]

When the nodes accept a cheap transaction that is mostly paid by the inflation, not the fees. Then, every holder of the coin is paying the cost generated by the user of that cheap transaction. It's not fair, even if that transaction is valid. Therefore, I think it is necessary to filter cheap transactions.

The acceptance of the transactions of the attacker would clear his transactions from the memory pool. The following block would take the cheaper transactions. It's the opposite behavior of the Bitcoin where the transactions of the attacker are the cheaper ones and never get executed.

 

[demo]

i'm not gonna vote positive on some core software change from a stranger, whatever it says.

The definition of stupidity!!!

 

[GrandMasterDash]

I've made some changes to the document according to the feedback.

1) Changed the title: "Protecting the Network Against Large Blocks".
2) Explanation: "The block size will vary between the minimum and the maximum capacity of the network...".
3) Explanation: "The enemy can buy just a small amount of coins to broadcast a massive amount of transactions..."

The link is updated.

The DIP001 had been first a proposal approved by the vote before being transformed into a DIP. I think the core team should not even consider to implement such a change that is not approved by the masternodes. I will not do anything for a while. Let me improve the communication according to the feedback.

Many MNOs are not technical enough to understand the implications of this. I think, first, this should be peer reviewed by core. I'm sure they will help.

 

[Ricardo Temporal]

Many MNOs are not technical enough to understand the implications of this. I think, first, this should be peer reviewed by core. I'm sure they will help.

Yes. I have posted in the tech forum as well. Let's wait for a response.