I just discovered this post, so forgive my thread reanimation. I happened to be working on a selfish mining simulation for a number of different ideas, and I wanted to post my results for Proof of Entropy Minima here in case they are useful. I hope I have understood the protocol well enough, it seems quite simple: branches are weighted by the least probability of being mined based on their hashes. Here is the full simulation code in python: import numpy as np from collections import defaultdict import matplotlib.pyplot as plt
def simulate(alpha, num_blocks=100000): honest_weight = 0 # cumulative sum of weight of honest chain attacker_weight = 0 # cumulative sum of weight of attackers chain attackers_blocks = 0 honest_blocks = 0 attacker_reward = 0 honest_reward = 0
for _ in range(num_blocks): r = np.random.rand() weight = np.log(r) if r < alpha: # Attacker mines attacker_weight += weight attackers_blocks += 1 if attacker_weight < honest_weight: # attacker reveals branch when it's going to be selected as the best branch attacker_reward += attackers_blocks # honest miners lose their rewards honest_reward -= honest_blocks # start again attackers_blocks = honest_blocks = attacker_weight = honest_weight = 0 else: # Honest miner mines honest_weight += weight honest_reward += 1 honest_blocks += 1 print(alpha, attacker_reward, honest_reward) if honest_reward > 0: return attacker_reward / honest_reward else: return num_blocks
# selfish mining as explained in "Majority is not Enough: Bitcoin Mining is Vulnerable" https://arxiv.org/pdf/1311.0243 # note that gamma is optimistic so this is a lower bound def simulateBitcoin(alpha, num_blocks=100000, gamma=0.5): honest_weight = 0 # Length of honest chain attacker_weight = 0 # Length of attacker's private fork attacker_reward = 0 honest_reward = 0 deltaPrev = 0
for _ in range(num_blocks): deltaPrev = attacker_weight - honest_weight if np.random.rand() < alpha: # Attacker mines attacker_weight += 1 if deltaPrev == 0 and attacker_weight == 2: attacker_reward += attacker_weight attacker_weight=honest_weight=0 else: # Honest miner mines honest_weight += 1 if deltaPrev<=0: honest_reward += honest_weight attacker_weight = honest_weight = 0 elif deltaPrev==1: # miners chose at random which fork to mine on based on gamma parameter g = np.random.rand() if g <= gamma: attacker_reward += 1 else: honest_reward += 1 attacker_weight=honest_weight=0 elif deltaPrev>=2: attacker_reward += deltaPrev+1 attacker_weight = honest_weight = 0 print(alpha, attacker_reward, honest_reward) return attacker_reward / honest_reward alphas = np.linspace(0.05, 0.5, 40) # 5% to 50% attacker hashing power results_poem = [simulate(alpha) for alpha in alphas] results_bitcoin = [simulateBitcoin(alpha) for alpha in alphas]
# Plot results plt.plot(alphas, results_poem, label="PoEM") plt.plot(alphas, results_bitcoin, label="Bitcoin") plt.axhline(y=1, color="red", linestyle="--", label="Attack break-even cost") plt.xlabel("Attacker Hashrate (α)") plt.ylabel("Attacker Reward / Honest Reward") plt.ylim([0, 1.2]) plt.legend() plt.show() ...and the resulting plot is here:  Anyway, as you should be able to see in the graph, compared to selfish mining as described in "Majority is not Enough: Bitcoin Mining is Vulnerable" which the upper bound on break even attacker hashing power is around 40%, Proof of Entropy Minima appears to have only around 18% resistance. In short it looks like this fork selection rule is catastrophic for any consensus design. The problem is this (blocks are letters, attackers are A, honest are H, bracketed number are block hash represented as real number between 0 and 1, so expectation = 0.5): A 0[0.001]<-A 1[0.5]<-A 2[0.5]<-A 3[0.5] => fork weight = 0.001*0.5*0.5*0.5 = 0.000125 H 0[ 0.5]<-H 1[0.5]<-H 2[0.5]<-H 3[0.5] => honest chain weight = 0.5*0.5*0.5*0.5 = 0.0625 Both sequences of blocks are equally likely, but if the attacker gets lucky with any block hash, because the fork weight is multiplicative (and will choose the lower weight) he can withhold his fork until it's going to be selected as canon, which appears to be possible at only 18% hash rate. I hope this hasn't been implemented into any live blockchain, because its vunerable. Cheers, Paul.
|
|
|
Interesting to see that you came back to expand on a nearly 10-year-old thought. I'm just curious was to what is being burned in your hypothetical: is it BTC or an entirely new coin? If its the latter, it means that you will have issued the entire supply at the genesis block, which leads to distribution issues. Perhaps I'm not totally following your idea but if implemented correctly, PoB has the capability to be the fairest consensus mechanism there is.
Those are great questions. Entirely new coin was the original design, and yes you're correct the entire supply has to be issued in genesis because as I wrote, you cannot increase supply via block reward without instant inflation. Essentially, it's a liquidity problem... Had the design looked promising, I was thinking to add USDC to the chain which would be the thing that you burn to mine native coins and have the supply start at 0, to mirror bitcoin's "anyone can mine" philosophy.
|
|
|
I thought I'd update this idea with a solution to the problem as stated and also a great reason why no one will ever implement proof of burn as described in the OP:
The goal is to produce a design equivalent to Bitcoin, with the same objective consensus mechanism and security guarantees.
The major problem as stated is that miners can just dump a bunch of blocks mined in secret onto the chain to orphan the best branch instantly (Finney attack) to recoup the supposedly "sunk cost" of burning coins.
There is a way to mitigate this problem, which is to make the chain a DAG and have it be totally ordered by maximum cumulative burn. That way attackers burns always end up being a sunk cost because the DAG has a total order and no branches are orphaned.
The problem that this creates is no the is no competition to mine blocks, because every burn in the DAG counts, so every miner wins. This is a critical flaw.
The logical conclusion is to use the total order to define a rolling window of N burns, the largest of which will win the block reward. Once the reward has been won by a burn, that burn is no longer eligible to receive new rewards, the miner must burn again to be eligible. Of course, then it is optimal for every miner to submit N-1 tiny burns and one slightly larger one such that they always win the reward, leading to spam and chaos. To mitigate the problem you have to limit the block reward to the sum of the burns within the window.
Once you've done that, there is no incentive to mine because a miner can never win. If you increase the reward to be slightly larger than the sum of burns, then the coin will hyper inflate instantly because there is nothing limiting the time between blocks.
So, after all that we've learned two things, the under the heading Satoishi didn't make mistakes:
1) Without some objective measure limiting the time between blocks, you cannot have a block reward. 2) Without a mining incentive there will be no security in the chain
Hope you enjoyed this rambling and please feel free to shoot me down.
Cheers, Paul.
|
|
|
But as far as I know, every black box bot gets rekt at some point without the involvement of human, I would be glad to see if you find such a bot and seeing it working.
That's why I look at the equity chart for months of forward testing, because I can tell if it will rekt itself. Rest assured, there are indeed strategies which are viable for months/years and they never rekt. Worst case they stop producing profit and then search for a new strategy.
|
|
|
I wish this thread wasn't moved to somewhere traders do not read.
Automated trading strategy is any trading strategy which is automated. Not sure why this was confusing.
I am completely able to tell the viability and value of any given strategy simply by looking at the P/L or equity chart. I have been doing this for a long time.
|
|
|
I'm looking to add to my library of automated trading strategies and I have a 100k USD budget for the right ones.
The right ones will have:
* Complete automation, no human influence * Profit + equity graph for at least four months * Low drawdown * Enough trades to confirm strategy confidence
PM me, or post here with questions.
|
|
|
For example, PoW does not have absolute finality, only probabilistic finality; BFT has absolute finality, so does Casper FFG. YeeCo’s Tetris consensus also has absolute finality.
Use of 'absolute' is horribly misleading. There is no 'absolute' in any system which is not fully objective. Casper and all BFT-type consensus designs are subjective by nature. You are correct that PoW only has probabilistic finality, but nothing else has 'absolute' finality, at best they have finality within the set of tolerances set out by the design, which usually include such things as an honest majority of bootstrapping nodes etc.
|
|
|
There is less at risk than in traditional PoW, but not nothing; the point is that if PoC was carried out in an "industrial" fashion like Bitcoin mining then the loss of failed hard drives would become a major factor.
That is not value-at-risk in the same way as electricity cost of mining; what you are referring to is the marginal cost of maintenance, which of course all hardware has especially regular bitcoin mining hardware.
|
|
|
Since USDT also use Bitcoin network , i am wondering if this is possible. If it is possible , is it a same lighting network or a totally different with bitcoin lighting network.
You'd need omnicore (the backbone supporting USDT) to support LN internally for this to work, because the way omni tokens are identified as BTC UTXO's is not trivial. This would also need LN operators to run omnicore as well as bitcoin core.
|
|
|
The problem with sharding is that if you want miners to work separately in each shard (as you must), then the hashrate of the network is divided up by N shards, meaning a double spend attack just got N times easier within each shard.
|
|
|
The bootstraping nodes have to: Check the forked place between two different branches and analysis if there are more than a certain proportion (in this case >5%) unusual "suddenly inactive" stakes and miners and mark the suspicous chain.
And what is the chain selection rule for non-bootstrapping nodes? Same? Different? Different. With finalization, without the check above. What about the cumulative stake rule, how does that combine?
|
|
|
The bootstraping nodes have to: Check the forked place between two different branches and analysis if there are more than a certain proportion (in this case >5%) unusual "suddenly inactive" stakes and miners and mark the suspicous chain.
And what is the chain selection rule for non-bootstrapping nodes? Same? Different?
|
|
|
Or, your attacker can pay large portions of previously active stake to go quiet, then wait some amount of time and launch his attack when he knows your selection rule will favour his fork.
How does that work? Bribling? Yes. How long does the quiet periods usually last? If I find out that the chain I accepted have some proportion of stakes suddenly disapear for two days, I'll check it again. Late, but still objective.
More importantly, in PoAS, miners are working fulltime with accumulated stakes. If you don't want the real miners suddenly stop working , which is too obvious, you have to buy the accounts of those working miners. I can't figure out how to purchase that yet. It cannot work. Whatever rule you come up with related to inactive stake, you can easily replicate either through bribing, or just might happen by accident. In addition, the attackers could easily be miners as well. You cannot cobble together a chain selection rule + some other bizarre ad-hoc rule for detecting history attacks; they have to be one and the same rule, otherwise this will just be to easy to exploit due to complexity.
|
|
|
"A certain proportion of active stakes suddenly become never active for a certain period of time." as I said. Isn't that objective?
Yes, but it doesn't work. That could easily happen on the canon chain during quiet periods. Or, your attacker can pay large portions of previously active stake to go quiet, then wait some amount of time and launch his attack when he knows your selection rule will favour his fork.
|
|
|
That was an example, what I want to say is : you can't easily fake a perfect chain that can't be recognized when we compare it with the real one.
I'm saying the opposite - you can easily fake a chain by doing this. Give me one objective way of distinguishing between a history attacked chain and the real one.
|
|
|
I mean the 20% active accounts he didn't buy. He can't fake them as active.
You can't build a selection rule based on inactive stake. The canon chain may have a whole load of inactive stake during genuine quiet periods, you don't want to select against it during these times, because that's another attack angle.
|
|
|
True, I was wrong about that. But there exist many objective methods that can tell the differences between the original chain and the fake one. Such as "the inactive account with 20% stakes never active anymore since..." or something like that.
I don't think so. 'Active since' doesn't make sense because when the attacker buys the private keys, he forks from the point where they were active and produces a fake chain with this now active stake participating. The only thing preventing this attack from succeeding is online nodes being relied upon to keep their existing fork and reject the attackers fork. But this is subjective, not objective.
|
|
|
Don't forget about bootstrapping nodes - this attack is also a bootstrap poisoning attack, as well as an attack against already up to date nodes and bootstrapping nodes cannot use your re-org depth limit.
Bootsrap attack may be a common problem of all chains with finalization. Let's talk about the difficulty and the impact of launching a successful history bootsrap-poinsoning attack in our system. First, you have to find a history point where there are enough empty accounts that had more stakes than the average total online stakes after that history point. That isn't true for bootstrap poisoning - as far as any bootstrapping node knows, there is no history available *after* their currently syncing block. A bootstrapping node will accept any valid data as canon, whereas an online node would be able to discard old forks because it has a memory of the real chain. Moreover, I would say bootstrap poisoning is a problem for all coins which have the NaS problem. 'Finalization' is not a well defined term. As the example I gave, the users who sold their empty accounts to the attacker are actually risking their assets (if the attacker succeeds ,their current assets A' and B' will become useless.) for a short-term profit which is the cost of the attack. And that risk cost should not be low enough for one to bear. At least he can't attack constantly, that makes the influence of the bootstrap poisoning attack limited (maybe a fork with a few victims, which won't last long).
The users who sold their now empty private keys to the attacker risk nothing. They have long since profited by cashing out.
|
|
|
Under the circumstance you described, the history attack could be succeed. But if you can't control the time of your attack, what's the point of the attack? Besides, if there is a chain with the ability of finalization, I will not confirm my transactions untill the final state is established when I am going to make an important deal.
Don't forget about bootstrapping nodes - this attack is also a bootstrap poisoning attack, as well as an attack against already up to date nodes and bootstrapping nodes cannot use your re-org depth limit.
|
|
|
The other one is the branch priority decision strategy:The branches with higher online stakes will definitely be heavier. Therefore, unless the historical stakes that an attacker possesses exceed all the online stakes of the current main branch, it will not succeed. For example: the total stakes are made up of three equal part A,B and C. If you collect the private keys of part A and B at a history point, that's 2/3 of the total and you plan to build a new fork from the history point and replace the original one. But the owner of stake A and B must have moved their stakes to other accounts, like A', B', before they give the old private keys to you. So the original branch will have the active stakes of A'+B'+C and your branch will have the stakes of A+B. Your branch will never heavier than the original one under my strategy. Besides, your account A and B will become invalid when a new save point is established.
But what if that is easy? What if I own old (now empty) private keys containing more stake than the current online stake in the main branch and that is within your re-org limit? Surely I can just construct a new branch from there which will become selected as the best branch? If the amount of current online stake dwindles due to a network outage, or other force majeure, this doesn't seem to far fetched.
|
|
|
|