If I have misinterpreted his writings, he will I assume point that out.
You have, but I've given up responding.Btw, a couple of months ago I solved the selfish-mining problem and proved to myself that gmaxell was wrong. Here I quote a snippet from my private design document:
Code:
3. Sharing revenue proportationally with the fork(s) of lower cumulative
difficulty entirely defeats selfish mining (positive relative revenue) for
any α. All blocks in the merged forks receive their full block reward
adjusted by relative difficulty.
r_others = p_0(1-α) + p_1(1-α) + p_2(1-α) + p[k>2](1-α), cases (e), (f), (g), and (h)
r_pool = p_1(1-α)/2 + p_2(1-α)2 + p[k>2](1-α)/2, cases (f), (g), and (h)
r_others = p_1(1-α)(1/α + 1 + α/(1-α) + (α-1)/(2α-1) - 1 - α/(1-α))
r_pool = p_1(1-α)(1/2 + 2α/(1-α) + (α-1)/(4α-2) - 1/2 - α/(2-2α))
R_pool = (3α/(2-2α) + (α-1)/(4α-2))/(1/α + 3α/(2-2α) + 3(α-1)/(4α-2))
Plot the following at wolframalpha.com.
(3α/(2-2α) + (α-1)/(4α-2))/(1/α + 3α/(2-2α) + 3(α-1)/(4α-2)), α, 0 < α < 0.5
However, merging forks of lower cumulative difficulty would remove the
economic incentive to propagate forks as fast as possible; and issuing a
double-spend would be trivial. The solution is to only merge forks of
lower cumulative difficulty when they are known by the majority before
receiving a fork of higher culmulative difficulty. Thus an attacker or
network hiccup that creates a hidden higher culmulative difficulty fork
has an incentive to propagate it before that fork falls behind the
majority. A node assumes it is part of the majority if it is participating
non-selfishly; it will attempt to merge any lower culmulative difficulty
forks it was aware of upon receiving a higher culmulative difficulty fork.
If it is not part of the majority, then its attempt will not be accepted.
If there are double-spends at stake, each node will continue to try for
the longest fork miners wish to be able to merge, i.e. longer forks with
double-spends won't be merged so the market will decide the value of the
two forks. If there are no double-spends at stake then to defeat selfish
mining, each node will continue to try during the duration of the longest
fork probable for an attacker α < 0.5[6]. If a node selfishly forsakes its
obligation and joins the attacker, that node attacks the value of the
block rewards it earned.
Also, forfeiting double-spends defeats any incentive to temporarily rent
greater than 50% of the network hashrate because the persistent honest
miners will forfeit the double-spends from the attacker’s fork upon it
relinquishing control. Compared to Bitcoin, there is no increased
incentive to double-spend, because miners will not place into any block a
double-spend they’ve already seen; double-spends can only appear in forks.
In Bitcoin one fork wins so one transaction from each of the double-spend
is forfeited so the honest recipient loses when the attacker’s fork wins.
In this new algorithm both of the transactions from each double-spend are
forfeited, so both the honest recipient and the attacker lose.
Defeating short-term rented hashrate attacks in conjunction with only
accepting inputs to a transaction which are as old as the longest duration
fork that will be merged, proves the probability of a double-spend[6] to
be determined solely by the number of block confirmations no matter how
fast the block period is.
Instead of monolithically choosing a winning fork, forfeiting double-
spends deletes selective downstream transactions. Thus fully opaque block
chains such as Zerocash, are thought to be incompatible because they not
only obscure which transaction consumed its inputs but also hide any coin
identifier that could correlate spends on separate forks. Cryptonote’s
one-time ring signatures are more flexible because mixes could choose to
mix only with sufficiently aged transaction outputs.
Each block of the Proof Chain contains a tree of block hashes, which are
the forks that were merged and a branch in a subsequent block may continue
a branch in a prior block. The restricted merging rule, double-spend
forfeiture and proof trees avoid the risks of Ethereum’s proposed
approximation[5]. Miners have to maintain transaction history for the
longest fork they wish to merge. And downstream consumers of inputs must
wait for the longest fork they anticipate[6].
[5] https://blog.ethereum.org/2014/07/11/toward-a-12-second-block-time/
Now, we can’t reward all stales always and forever; that would be a
bookkeeping nightmare (the algorithm would need to check very diligently
that a newly included uncle had never been included before, so we would
need an “uncle tree” in each block alongside the transaction tree and
state tree) and more importantly it would make double-spends cost-free...
Specifically, when only the main chain gets rewarded there is an
unambiguous argument...Additionally, there is a selfish-mining-esque
attack against single-level...The presence of one non-standard strategy
strongly suggests the existence of other, and more exploitative,
non-standard strategies...True. We solved the selfish mining bugs of
traditional mining and 1-level GHOST, but this may end up introducing
some new subtlety; I hinted at a couple potential trouble sources in the
post.
[6] Meni Rosenfeld. Analysis of hashrate-based double-spending.
Section 5 Graphs and analysis.
http://arxiv.org/pdf/1402.2009v1.pdf#page=10
difficulty entirely defeats selfish mining (positive relative revenue) for
any α. All blocks in the merged forks receive their full block reward
adjusted by relative difficulty.
r_others = p_0(1-α) + p_1(1-α) + p_2(1-α) + p[k>2](1-α), cases (e), (f), (g), and (h)
r_pool = p_1(1-α)/2 + p_2(1-α)2 + p[k>2](1-α)/2, cases (f), (g), and (h)
r_others = p_1(1-α)(1/α + 1 + α/(1-α) + (α-1)/(2α-1) - 1 - α/(1-α))
r_pool = p_1(1-α)(1/2 + 2α/(1-α) + (α-1)/(4α-2) - 1/2 - α/(2-2α))
R_pool = (3α/(2-2α) + (α-1)/(4α-2))/(1/α + 3α/(2-2α) + 3(α-1)/(4α-2))
Plot the following at wolframalpha.com.
(3α/(2-2α) + (α-1)/(4α-2))/(1/α + 3α/(2-2α) + 3(α-1)/(4α-2)), α, 0 < α < 0.5
However, merging forks of lower cumulative difficulty would remove the
economic incentive to propagate forks as fast as possible; and issuing a
double-spend would be trivial. The solution is to only merge forks of
lower cumulative difficulty when they are known by the majority before
receiving a fork of higher culmulative difficulty. Thus an attacker or
network hiccup that creates a hidden higher culmulative difficulty fork
has an incentive to propagate it before that fork falls behind the
majority. A node assumes it is part of the majority if it is participating
non-selfishly; it will attempt to merge any lower culmulative difficulty
forks it was aware of upon receiving a higher culmulative difficulty fork.
If it is not part of the majority, then its attempt will not be accepted.
If there are double-spends at stake, each node will continue to try for
the longest fork miners wish to be able to merge, i.e. longer forks with
double-spends won't be merged so the market will decide the value of the
two forks. If there are no double-spends at stake then to defeat selfish
mining, each node will continue to try during the duration of the longest
fork probable for an attacker α < 0.5[6]. If a node selfishly forsakes its
obligation and joins the attacker, that node attacks the value of the
block rewards it earned.
Also, forfeiting double-spends defeats any incentive to temporarily rent
greater than 50% of the network hashrate because the persistent honest
miners will forfeit the double-spends from the attacker’s fork upon it
relinquishing control. Compared to Bitcoin, there is no increased
incentive to double-spend, because miners will not place into any block a
double-spend they’ve already seen; double-spends can only appear in forks.
In Bitcoin one fork wins so one transaction from each of the double-spend
is forfeited so the honest recipient loses when the attacker’s fork wins.
In this new algorithm both of the transactions from each double-spend are
forfeited, so both the honest recipient and the attacker lose.
Defeating short-term rented hashrate attacks in conjunction with only
accepting inputs to a transaction which are as old as the longest duration
fork that will be merged, proves the probability of a double-spend[6] to
be determined solely by the number of block confirmations no matter how
fast the block period is.
Instead of monolithically choosing a winning fork, forfeiting double-
spends deletes selective downstream transactions. Thus fully opaque block
chains such as Zerocash, are thought to be incompatible because they not
only obscure which transaction consumed its inputs but also hide any coin
identifier that could correlate spends on separate forks. Cryptonote’s
one-time ring signatures are more flexible because mixes could choose to
mix only with sufficiently aged transaction outputs.
Each block of the Proof Chain contains a tree of block hashes, which are
the forks that were merged and a branch in a subsequent block may continue
a branch in a prior block. The restricted merging rule, double-spend
forfeiture and proof trees avoid the risks of Ethereum’s proposed
approximation[5]. Miners have to maintain transaction history for the
longest fork they wish to merge. And downstream consumers of inputs must
wait for the longest fork they anticipate[6].
[5] https://blog.ethereum.org/2014/07/11/toward-a-12-second-block-time/
Now, we can’t reward all stales always and forever; that would be a
bookkeeping nightmare (the algorithm would need to check very diligently
that a newly included uncle had never been included before, so we would
need an “uncle tree” in each block alongside the transaction tree and
state tree) and more importantly it would make double-spends cost-free...
Specifically, when only the main chain gets rewarded there is an
unambiguous argument...Additionally, there is a selfish-mining-esque
attack against single-level...The presence of one non-standard strategy
strongly suggests the existence of other, and more exploitative,
non-standard strategies...True. We solved the selfish mining bugs of
traditional mining and 1-level GHOST, but this may end up introducing
some new subtlety; I hinted at a couple potential trouble sources in the
post.
[6] Meni Rosenfeld. Analysis of hashrate-based double-spending.
Section 5 Graphs and analysis.
http://arxiv.org/pdf/1402.2009v1.pdf#page=10
