As of today, I have decided I will stop working with Shucck. He was always paid ( 3446.5 ZNN in total ), even in advance for the work he has done and for over a month no task was given to him that would require more payment. I did not have time lately to test the code, integrate it and check what else we need but I am sure it is not complete. I am afk now but when I come back I will work by myself.
2 Likes
Sounds good. Thanks for responding. @Shuccck did contact me via telegram and I mentioned we needed to hear back from you before taking any action. thx!
The main challenge with the current approach is the amount of data that will end up on the embedded account-chain.
If the merge-mined chain operates at 20x the pace of Bitcoin blocks (with adjusted difficulty), the on-chain storage required for 1 year would be approximately ~2.69 GB. With 100x the pace of Bitcoin blocks (block time around 6 seconds) we will have ~15Gb on-chain storage annualy. We canât go that fast because our current implementation is capped at 10s block time.
This is without using zk-proofs to minimize the on-chain footprint. Depending on what proof system we use, the on-chain storage requirements can decrease with a factor of 2 up to 10x.
Here is a Circom implementation that verifies the Merkle path:
Proof Data: The zk-SNARK proof, which is typically around 128 bytes in size.
Public Inputs: In the context of verifying a Merkle path, this would include:
⢠Merkle Root: The root hash of the Merkle tree (32 bytes).
⢠Leaf Hash: The hash of the leaf node (32 bytes).
⢠Leaf Index: The position of the leaf in the tree, which can be represented in a few bytes depending on the treeâs size.
The total on-chain data required for each proof verification would be approximately:
⢠Proof: 128 bytes
⢠Merkle Root: 32 bytes
⢠Leaf Hash: 32 bytes
⢠Leaf Index: ~4 bytes (assuming a tree with up to 2³² leaves)
Total: ~196 bytes per proof verification.
We can optimize even more by creating and posting a proof once every 100 share-chain blocks. Itâs not feasible to create a zk proof for each share-block, thatâs why batching share-chain blocks is the logical step forward. The share-chain be coordinated off-chain by the mining entities and the on-chain embedded will be required to attest the share-chain integrity and release rewards accordingly. Basically we end up creating a zk-rollup for merge-mining Bitcoin with NoM as DA and settlement layer.
Iâm still trying to wrap my head around how merge mining will benefit NoM.
In order for merge mining to be useful to NoM doesnât the consensus protocol need to take into consideration the PoW (by the BTC miner)? Is this contemplated in the whitepaper and how do we propose to incorporate these changes with Sentinels and N&T? This sounds like a gigabrain project that requires a massive lift.
Today, the only way a BTC miner will use their equipment to merge mine is if the miner receives their share of the BTC rewards (less a fee). I donât think we can assume a BTC miner will use their expensive equipment to only earn ZNN while Zenon Network accumulates the BTC. Is the current design to be a decentralized mining pool where NoM acts as a decentralized âorchestratorâ for mining. We become an Ocean.xyz of sorts?
In previous posts we discussed miners becoming a new ecosystem player (a new citizen) that was not contemplated in the WP (I think). This seems like a very large change that requires considerable analysis. Is someone looking into this?
thx
This is a great question. My idea is to anchor NoM into Bitcoin. But we need to take it step by step.
Afaik the whitepaper mentions ASIC PoW that Bitcoin miners can provide and contribute to ledger weight.
Yes, this is the idea: creating the first decentralized p2p mining pool on BTC. We wonât gather much hashpower in the beginning, but we can attract a lot of attention.
Non-competitive BTC miners can redirect their hashpower towards NoM. I agree that we need to incentivize them with both BTC and ZNN/QSR to gather hashpower. Thatâs why we can redirect 90% of the mined BTC back to them (directly on NoM as zBTC) in the beginning + ZNN and QSR. After that we can adjust the amount of BTC. This is an open discussion.
Actually this is specified in the whitepeper (PoW pools and ASIC hashpower) as well as itâs aligned with the core design of NoM as a dual PoS and PoW chain.
4 Likes
Thank you for those responses. This makes more sense to me now. Iâll take a look at the WP again.
From the WP:
âIn order for the pillars to be competitive in the process of producing the proof of work, they will have the possibility to outsource it using the mining pool concept. This will create a market-efficient ecosystem that will further strengthen the network and clients committing resources for Pillar pools will be rewarded proportionally to their contribution of processing power.â
So I guess the idea is to build a decentralized mining pool that (initially) does not interact with the consensus in any way. Itâs âjustâ a decentralized mining pool where older miners can merge mine zBTC (convertible to BTC eventually) and ZNN/QSR. I wonder how we can award zBTC with the understanding it will be convertible to BTC without knowing how that will work. Maybe the miners earn BTC rather than zBTC??
Over time as the project evolves we believe (per the WP) Pillars will need to perform a serious amount of PoW in order to be competitive. So much so, they will need to outsource that PoW to mining pools through the merge mining concept.
So by building a decentralized mining pool today on NoM we can more âeasilyâ transition to Pillar PoW outsourcing in the future.
Does that look directionally accurate?
-
Are noncompetitive BTC miners cost effective in terms of the cost of electricity?
-
Why not target competitive miners?
1 Like
I think you answered your own question. They are non-competitive for the exact reason that their hashrate per kw produced is lower. Most of these miners are either offline or mining random altcoins with a centralized service that mines alt coins and dumps them for btc while charging middleman fees as they please.
1 Like
I think the main takeaway is the emphasis on the integration of a PoS & PoW mechanism.
They arenât if they only mine BTC. But this is the idea, to onboard them and create incentives for them to start mining again. This is a win-win for them (theyâll earn ZNN and QSR in the process) and they will also help decentralizing the hashrate.
Because we will have a harder time to convert them. We need to first prove the concept and if we get enough traction and have the right incentives, they will come.
1 Like
@MoonBaze some of the guys in TG were discussing the status of Merge Mining and I was wondering if you have any updates on your work. Hope you are doing well!
I have 1 TH ready to point at Zenon 