dynamic time lock in the value lock mechanism

The following is a draft proposal for using a dynamic time lock in the value lock mechanism

tldr; The idea behind value locking is to make sure that spamming the network is costly. The cost involved is an opportunity cost. Needing to wait a some time for being able to use your bitcoin is surely worse than being able to use them immediately. The current approach is not optimal because :

Having a constant time lock means that the mechanism is not optimised for the edge cases. Sometimes it is too costly and other times too cheap.
It is very difficult to predict what the cost will be in the future, therefore what are the edge cases.

1. constant time

Locking some btc for a certain time is costly. Here is how to compute the opportunity cost, given a base interest rate is known

opportunity_cost = btc_locked * base_btc_interest_rate * time_locked

Currently the time_locked is equal to 4500 blocks. This number sometimes it is too small and sometimes it is too big. When defending from an attack, higher is better, but it can be prove uneccessary costly for an honest user.
There is nothing wrong with 4500 per se, but the choice of using any constant time_lock is always sub-optimal for the edge cases.

2. what the cost will look like?

Saifedean Ammous has made the following compelling argument :

in a bitcoin standard, people will develop lower time preferences
people with lower time preferences, discount less the future compare to the present; this is equivalent to say that base_btc_interest_rate is 'low''

So my point is that even if the current value locking implementation seems costly now (1), in 100 years this might not be true.

Proposed solution / draft

Dynamic value locking draft (recursive approach)

max_operations = 600,000 (The maximum allowed ION operations per block is currently 600,000)
initially time_lock = x1 blocks (x1 is set as a constant)

in the past x2 bitcoin blocks there have been x3 ION operations
if x3 > 95% * max_operations * x2
          then  time_lock = time_lock * p1
if else x3 < 10% * max_operations * x2
          then  if p2 >= x1/time_lock
                    then  time_lock = time_lock * p2

p1 > 1 , p2 < 1

This way the cost is dynamicaly adjusted based on the utilisation of the network.

in case of a spamming attack the attacker would have to lock bitcoin for longer and longer periods of time
during normal times the cost could be lower than the current cost

(1) given the numbers provided by the example below

The amount of btc needed for spamming the network forever is 4500 60 6.66 btc ~= 1.8M btc

because after 4500 blocks the attacker would be able to re-use the newly unlocked btc for spamming the next block

@pippellia-btc thanks for this thoughtful proposal, and taking time to understand the mechanics of value locking in ION in the first place!

I want to clarify on the "amount of btc needed for spamming the network forever" part. There are two types of cost involved here:

Opportunity cost - capital required to be locked to write all 600,000 ops in every block. I believe 1.8M btc is this value in your calculation above. In reality (currently), this value is far far far less, because as long as you have a value-lock in place, you are entitled to write a large batch in every block within the duration of that lock. So you just need 60 value locks each capable of writing 10,000 ops to earn the right to "attempt" to saturate the network with spam. I say "attempt" because continue to read the 2nd type of cost:
On going per operation fee There is a per op minimum fee imposed relative to actual ongoing bitcoin transaction fee as parameterized by normalizedFeeToPerOperationFeeMultiplier, currently set at an hefty discounted ratio of 1000 : 1 to encourage adoption, meaning each op fee is 1/1000th of the bitcoin transaction fee. This value can be adjusted to be less generous in subsequent protocol version increments. Assuming ~$2 btc transaction fee, it'll cost the spammer 60 * $20 = $1200 every 10 minutes, which is ~$170,000 a day. And let's not forget the spammer also needs to compete with other writers, since ION prioritizes writers paying the most fee, in combination with adjusting the mentioned ratio above to say 100 : 1, the cost would be in the millions a day.

The main intent for value locking was to discourage once-off spam ION transactions, the primary anti-spam mechanism is still the fee imposed.

Above said, the proposal of using dynamic algorithms over hardcoded magic value is still valuable, and I am supportive if it significantly improves ION's anti-spam capability further! Also in addition to or instead of dynamically adjusting the value lock period, we can also look at dynamically adjusting valueTimeLockAmountMultiplier (which is currently set to 60000) to drastically change the btc amount to be locked based on usage.

Fortunately given the relatively low write traffic right now, we have time to discuss and brainstorm further. Adding @csuwildcat to ascertain his view on this.

@thehenrytsai thank you for your response. I understand now that currently the primary anti-spam mechanism is the fee imposed. I think there might be a problem with that honestly.

Let's list some facts (please correct me if I am wrong in any of these points)

anti-spam based on fees is not always a sufficient mechanism If there are other incentives for spamming the network, then it might happen that the value gained from spanning is higher than the fees paid. A prime example of this is spamming for arbitrage, something that we already seen on Polygon https://cointelegraph.com/news/arbitrage-bot-s-spam-attack-on-the-polygon-network-generated-6-800-per-day Increasing the fee level can ofc mitigate the problem, but it will discourage honest users from using it.
why I mention arbitrage if we are talking about ION? Well, as @csuwildcat pointed out on both Discord and Twitter, most of the times to use NFTs one is trusting the issuer of those NFTs (especially utility NFTs). Under the assumption of trust (otherwise one should not buy) on the issuer, it is possible (and cheaper!) to have VCs to replace NFTs. If those NFTs are not transferable, then a simple VC is enough; If those are transferable, then if I understood correctly Daniel pointed out that 2 entry VCs are the way to go.

This of NFTs is just an example of how we might see a marketplace for VCs build on top of ION. Every time one buys one such VC he/she is writing an operation on ION. That being said, the financialisation of ION (which is possible), might bring incentives to spam the network. In this case increasing the fee level is only a partial solution, because it comes to the detriment of onest users.

Those are the reasons that imho we/you should consider when choosing how to implement the value locking mechanism. Curious to hear what you guys think about that.

unrelated Question : Let's say that attacker wants to spam one single ION transaction. He can :

"buy the space" of 10k operation and then pay the necessary fees
spin up multiple adresses and perform enough small writing operation, again paying the necessary fees

Is the second approach feasible? Are there any drawbacks ?

decentralized-identity / ion