ArticMine PMed me after I wrote
that flaming post, and said he would reply after studying my posts. He has not yet replied. Does that mean I am correct and there is no solution for Monero. I think so.
It is fundamental. Afaics, you'd have to completely rewrite Moaneuro.
Rewrite Monero, is not necessary at all but some documentation on how the Cryptonote adaptive blocksize limits actually work is needed, especially given the formula in section 6.2.3 of the Cryptonote Whitepaper is wrong.
https://cryptonote.org/whitepaper.pdf. My response will come in time.
I will start by examining the Cryptonote Penalty Function for oversize blocks. This is critical to understand any form of spam attack against a Cryptonote coin. From the Cryptonote whitepaper I cited above the penalty function is:
Penalty =
BaseReward (
BlkSize / M
N - 1)
2The new reward is:
NewReward =
BaseReward -
PenaltyWhere M
N is the median of the blocksize over the last N blocks
BlkSize is the size of the current block
BaseReward is the reward as per the emission curve or where applicable the tail emission
NewReward is the actual reward paid to the miner
The Maximum allowed blocksize,
BlkSize, is 2M
NThe penalty is only applied when
BlkSize > (1 + B
min) M
N Where 0 < B
min < 1 In the Cryptonote whitepaper B
min = 0.1.
The error in the Cryptonote Whitepaper was to set
NewReward =
PenaltyFor simplicity I will define:
BlkSize = (1+B) M
NBaseReward = R
basePenalty (for a given B) = P
BNewReward (for a given B) = R
BThe penalty for a given B becomes:
P
B = R
baseB
2While the new reward for a given B becomes:
R
B = R
base(1 - B
2)
The first derivative of P
B with respect to B is
dP
B /
dB = 2R
baseB
In order to attack the coin by bloating the blocksize the attacker needs to cause at least over 50% of the miners to mine oversize blocks and for an expedient attack close to 100% or the miners to mine oversize blocks. This attack must be a maintained over a sustained period of time and more importantly must be maintained in order to keep the oversized blocks, since once the attack stops the blocks will fall back to their normal size. There are essentially two options here:
1) A 51% attack. I am not going to pursue this for obvious reasons.
2) Induce the existing miners to mine oversize blocks. This is actually the more interesting case; however after cost analysis it becomes effectively a rental version of 1 above. Since the rate of change (first derivative) of P
B is proportional to B the most effective option for the attacker is to run the attack with B = 1. The cost of the attack has as a lower bound R
base but would be higher, and proportional to, R
base because miners will demand a substantial premium over the base reward to mine the spam blocks due to the increased risk of orphan blocks as the blocksize increases and competition from legitimate users whose cost per KB for transaction fees needed to compete with the attacker will fall as the blocksize increases. The impact on the coin is to stop new coins from being created while the attack is going on. These coins are replaced by the attacker having to
buy coins on the open market in order to continue the attack. The impact of this is to further increase the costs to the attacker.
It at this point where we see the critical importance of a tail emission since if R
base = 0 this attack has zero cost and the tragedy of the commons actually occurs.
This is the critical difference between those Cryptonote coins that have a tail emission, and have solved the problem, such as Monero and those that do not, and will in a matter of time become vulnerable, such as Bytecoin.Afaics, the above does nothing to remove/ameliorate the
Tragedy of the Commons in Satoshi's mining algorithm[1], except if viewed as short-term solution while no miners have a significant percentage of the network hash rate.
The problem is that as
I explained for Ethereum, as transaction rate scales up and thus the block reward is dominated by fees, then unless there is a uniform distribution of hashrate amongst all full node miners (which is of course impossible since not everyone can locate their mining equipment next to a hydropower plant with 2 - 4 cents electricity or for that matter perhaps
free subsidized electricity in corrupt environs such as China), then those miners with more hashrate will have lower costs of verification. Thus they will be more profitable and can buy more hashrate faster than the other miners. Thus mining will entirely centralize over time, because the economics are designed to centralize mining. So since mining will centralize, then attaining 51% of the mining power will be guaranteed and thus the above algorithm can do nothing to stop miners from spamming the block chain size by paying transaction fees to themselves. But of course with 51% of the hashrate, they can do anything they want, except up to the limits of what public perception will tolerate. I am assuming of course that transaction fees in a free market will reflect actual (marginal) costs and that verification cost will be significant relative to other costs such as bandwidth.
There is also afaics a math flaw in ArticMine's analysis. Unless
N is very small, then a miner with a significant but less than 51% hashrate is going to win a block in most every
N set, and thus they can hit the
2 * MN hard limit every time (or what ever rate of increase they deem most cost effective according to the Penalty cost being a function of a square), gradually ramping the median block size up over time. Thus the spam attack is not avoided, rather it just takes longer. And again I had pointed out that by shorting the coin, they can potentially recover their lost block rewards and profit. And if
N is very small, then the likelihood that a miner can win all N blocks with less than 51% hashrate increases. Also it is not clear to me from ArticMine's specification if
N is overlapping meaning a FIFO queue? But I doubt that makes any difference to my conceptual math point (note I have not written down the equations to precisely quantify this alleged flaw).
Also the
2 * MN hard limit means that block chain can't handle transient spikes in transaction load, e.g. such as would be required by Lightning Networks (which has sort of a garbage collection overhead which manifests has large spikes in transaction load).
Conceptually at the highest-level semantic model of the generalized essence, an anti-aliasing filter on transaction rate can't ameliorate the fact that a spam transaction is indistinguishable from a non-spam transaction.
To solve this problem we need to make the cost of what is burned when submitting a transaction greater than the cost of cumulative network verification costs. That both solves the economics of the first paragraph above and it also removes the need to limit the block size in any artificial way other than the burn cost. But in my design, I don't waste the burn cost and instead apply it to security in the form of unprofitable mining. Note that the only way to limit culmulative network verification costs is to centralize mining. And this is why I wanted to give up, because I didn't see any solution that didn't centralize mining. But then I realized the design I had for intra-block partitions can centralize while remaining controlled by decentralized PoW, thus effectively still decentralized. And this is why I say you will have to completely rewrite Monero (at least the consensus design portion of the block chain code).
