Search content
Sort by

Showing 20 of 343 results by monsterer2
Post
Topic
Board Development & Technical Discussion
Re: Improved Measurement of Proof-of-Work using entropy
by
monsterer2
on 16/05/2025, 13:09:31 UTC
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:

Code:
import numpy as np 
from collections import defaultdict 
import matplotlib.pyplot as plt

def simulate(alpha, num_blocks=20000):
    honest_chain = 0  # cumulative sum of weight of honest chain
    attacker_chain = 0  # cumulative sum of weight of attackers chain
    attackers_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_chain += weight
            attackers_blocks = attackers_blocks + 1
           
            if attacker_chain < honest_chain:
           
                # attacker reveals branch when it's got the least probability of being mined block by block
                attacker_reward += attackers_blocks
                honest_reward -= attackers_blocks
               
                # start again
                attackers_blocks = attacker_chain = honest_chain = 0
               
           
        else:  # Honest miner mines
            honest_chain += weight
            honest_reward += 1
               
    if honest_reward > 0:
        return attacker_reward / honest_reward
    else:
        return float("inf")

# 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=20000, gamma=0.5):
    honest_chain = 0  # Length of honest chain
    attacker_chain = 0  # Length of attacker's private fork
    attacker_reward = 0
    honest_reward = 0
    deltaPrev = 0

    for _ in range(num_blocks):
        deltaPrev = attacker_chain - honest_chain
       
        if np.random.rand() < alpha:  # Attacker mines
            attacker_chain += 1
           
            if deltaPrev == 0 and attacker_chain == 2:
                attacker_reward += attacker_chain
                attacker_chain=honest_chain=0
           
        else:  # Honest miner mines
            honest_chain += 1
           
            if deltaPrev<=0:
                honest_reward += honest_chain
                attacker_chain = honest_chain = 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_chain=honest_chain=0
            elif deltaPrev>=2:
                attacker_reward += deltaPrev+1
                attacker_chain = honest_chain = 0       

    return attacker_reward / honest_reward
   
alphas = np.linspace(0.15, 0.5, 20)  # 15% 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:

https://i.imgur.com/CpFH3fT.png

It doesn't show if I try to inline the image, I get a proxy error.

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 lower bound on break even attacker hashing power is around 40%, Proof of Entropy Minima appears to have only around 32% resistance.

I think the problem is pretty much as described by earlier thread contributors: if you get lucky mining a block with a low enough weight, it skews your ability to profit from selfish mining.

Cheers, Paul.

 

Post
Topic
Board Altcoin Discussion
Re: Why Proof of Burn cannot work cleanly in practice
by
monsterer2
on 07/04/2025, 14:54:16 UTC
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.
Post
Topic
Board Altcoin Discussion
Re: Why Proof of Burn cannot work cleanly in practice
by
monsterer2
on 07/04/2025, 07:42:45 UTC
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.
Post
Topic
Board Digital goods
Re: Buying automated trading strategies - 100k USD budget
by
monsterer2
on 27/10/2020, 10:04:15 UTC
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.
Post
Topic
Board Digital goods
Re: Buying automated trading strategies - 100k USD budget
by
monsterer2
on 27/10/2020, 08:41:08 UTC
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.
Post
Topic
Board Trading Discussion
Topic OP
Buying automated trading strategies - 100k USD budget
by
monsterer2
on 26/10/2020, 12:01:10 UTC
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.
Post
Topic
Board Project Development
Re: Join new exchange Buytex.io based on the latest IT and blockchain technologies!
by
monsterer2
on 17/10/2020, 17:26:12 UTC
All the markets show $0, nothing is working.

Moreover, the name of the exchange sounds like 'buttocks'.
Post
Topic
Board Development & Technical Discussion
Re: The Finality Design of Blockchain Consensus Mechanism
by
monsterer2
on 17/06/2019, 08:32:16 UTC
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.
Post
Topic
Board Development & Technical Discussion
Re: Proof of Capacity as a replacement for Proof of Work.
by
monsterer2
on 08/05/2019, 08:28:18 UTC
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.
Post
Topic
Board Development & Technical Discussion
Merits 4 from 3 users
Re: [question] Is it possible to use Lighting Network to transfer USDT
by
monsterer2
on 27/03/2019, 10:09:10 UTC
⭐ Merited by ETFbitcoin (2) ,HeRetiK (1) ,d5000 (1)
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.
Post
Topic
Board Development & Technical Discussion
Merits 3 from 2 users
Re: What is sharding, and will sharding scale Bitcoin?
by
monsterer2
on 22/02/2019, 10:16:27 UTC
⭐ Merited by bones261 (2) ,Wind_FURY (1)
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.
Post
Topic
Board Development & Technical Discussion
Re: (Brief introduction): A Stake-Based Blockchain Voting Consensus Protocol
by
monsterer2
on 31/01/2019, 09:26:26 UTC
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?
Post
Topic
Board Development & Technical Discussion
Re: (Brief introduction): A Stake-Based Blockchain Voting Consensus Protocol
by
monsterer2
on 30/01/2019, 14:34:54 UTC
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?
Post
Topic
Board Development & Technical Discussion
Re: Proof of Accumulated Stakes: A Stake-Based Blockchain Voting Consensus Protocol
by
monsterer2
on 29/01/2019, 19:36:31 UTC
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.

Quote
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.
Post
Topic
Board Development & Technical Discussion
Re: Proof of Accumulated Stakes: A Stake-Based Blockchain Voting Consensus Protocol
by
monsterer2
on 29/01/2019, 17:23:15 UTC
"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.
Post
Topic
Board Development & Technical Discussion
Re: Proof of Accumulated Stakes: A Stake-Based Blockchain Voting Consensus Protocol
by
monsterer2
on 29/01/2019, 17:11:07 UTC
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.
Post
Topic
Board Development & Technical Discussion
Re: Proof of Accumulated Stakes: A Stake-Based Blockchain Voting Consensus Protocol
by
monsterer2
on 29/01/2019, 16:39:18 UTC
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.
Post
Topic
Board Development & Technical Discussion
Re: Proof of Accumulated Stakes: A Stake-Based Blockchain Voting Consensus Protocol
by
monsterer2
on 29/01/2019, 15:54:51 UTC
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.
Post
Topic
Board Development & Technical Discussion
Re: Proof of Accumulated Stakes: A Stake-Based Blockchain Voting Consensus Protocol
by
monsterer2
on 29/01/2019, 08:30:57 UTC
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.

Quote
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.
Post
Topic
Board Development & Technical Discussion
Re: Proof of Accumulated Stakes: A Stake-Based Blockchain Voting Consensus Protocol
by
monsterer2
on 28/01/2019, 19:42:59 UTC
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.