 Show Posts
|
|
Pages: [1] 2 »
|
|
I'm not against compiling XMRig with zero dev fee per se, but I find it unfair for OP to ask for donations to his own address. He should at the very least link to the donations page of XMRig on github or list their XMR address.
Disclaimer: I'm not affiliated with XMRig and I don't benefit from the donations they receive.
|
|
|
|
I didnt see a point you made that not solvable with similar characteristics to bitcoin mining pool.
Bitcoin mining pools are centralized. What you posted are not real solutions for a decentralized blockchain. Wanting To obtain funding is not incompatible with having a working solution, what kind of logic is that lol it make you skeptical, doesnt mean everyone "should be"  It's common sense to be sceptical when someone is asking for money on the internet. its ironical for someone advocating decentralisation to make so many argument of authority, maybe there is room for skepticism about your opinion as well Yes, I'm advocating for decentralization, that's why I don't see your centralized pool-protocol as a solution to anything. And please look up what argument from authority means. I didn't make any. I simply pointed out the holes in this concept and expressed my opinion that they cannot be fixed. If someone posts an actual working solution, I'll be more than happy to admit that I was wrong. |
|
|
|
He Said after it solve the pow problem in itself with the properties he listed, which i already checked and they work.
There is no "pow problem". Proof of work is a solution to the problem of decentralized consensus. The PoW posted here doesn't solve it. he says he has other solution to solve work distribution.
I don't see any solution posted anywhere. It looks like he is using this argument to obtain funding, which everyone should be very sceptical about. |
|
|
|
nobody claimed this is a full solution to solve all problems of current blockchain protocols.
The claims made by OP are certainly strong:
What to do with it?
You can implement this algorithm in any cryptocurrency and it will be the best POW algorithm you have ever known.
I was just pointing out that this is not something usable at the moment and probably never will be. The things I mentioned above are not just minor issues but fundamental flaws. |
|
|
|
bitcoin solo mining that is used by 0.1% of bitcoin miners today.
It's not just for solo mining. Different pools also need to reach consensus among themselves. Your argument would be valid only if 99.9% of bitcoin hashrate came from a single pool. Your protocol fails even in the very likely case that two pools mine two blocks with different merkle roots. |
|
|
|
It could still be less centralized than pooled mining on certain aspect, like currently nothing prevent mining pool to cheat on the reward / share, and they already take a % of the benefits, here at least this aspect is more transparent.
So basically you want to fight ASIC mining centralization with even more centralization. The problem with different version of the blockchain is transposed to establishing the consensus on a "mining route" , that start with a merkle root, and break the work into different miners selected evenly in the pool.
And if two nodes have a different merkle root? It seems that you have missed the main point of proof of work and the Nakamoto consensus. |
|
|
|
Everyone can still check the transactions in the merkle root, the pow consensus show that all nodes agree on this merkle root. If not they will not mine the block. Enough node need to be honest like in any byzantine fault tolerant system.
So you are basically saying "all nodes must agree otherwise they will not agree". Then you will have at least several chain splits per day and the whole network will malfunction. You simply cannot hope that all nodes will always have the same set of transactions. In monero they take more care about privacy, but in itself bitcoin protocol doesn't specially protect again ip/address association. All nodes that receive a new mining block know the ip of the mining node and the address used for the reward.
Mining pool already know your ip and your mining address and it wouldn't be really hard for an attack to connect the two.
If there was a way to link bitcoin addresses to IP addresses on the protocol level, it would be a huge issue for bitcoin. Although bitcoin is already pretty much a surveillance coin due to its linkable transactions, this would be a whole new level of orwellian proportions. And modelling a decentralized network based on pooled mining is flawed since pooled mining is centralized. |
|
|
|
1. All nodes need to work on signature starting from a hash that contain the same merkle root, like pool mining.
Then what you are describing is not actually a consensus mechanism. You are saying that there is only one version of the truth and all nodes have to follow it. That's a centralized network. You may as well have a central bank to simplify everything. Pooled mining is also centralized. If you want a consensus protocol, you need a way to choose which version of the blockchain to follow (and all nodes must agree on that). Yes, the IP addresses of nodes are known but not linkable to their coin address. There was a recent attack on ZCash an Monero which allowed IP addresses to be linked with funds. It's already been fixed. Do you want to reintroduce this attack as a "feature"? |
|
|
|
Ok let say on 10 minutes block you would create chunks of 10 sec of work, like first generating the total ring chain to be computed, then breaking it down to séries of sub ring chain, in sort that each sub chain need to hash its address or id with the previous work. Now let say this miner id is not just the address, but an ip/address pair. Each time a new node appear on the network it register itself on the network, and put on the global list of miners id, each time a new block arrive this address/Ip pair is hashed with the new block signature and miners id sorted on this hash, and the first 60 are selected for the next block. The Ip will be used to send the work to the miner and to send it to the next so Ip can checked in and out even if that wouldnt prevent 3 ips to collude to steal work. It could be made stronger if all nodes do traceroute on miners and a consensus can be reached on topography of ips, i tend to think its a problem that has a degree of byzantine fault tolerance as any node can check the traceroute of other nodes and deduce if the traceroute sent by another node is incohérent, i think its a classic problem of graph theory with a byzantine fault tolerance, similar to this Techniques for Detection of Malicious Packet Drops in Networks , taking in account that the topography doesn't have to be 100% accurate, but at least give sufficient probability that two nodes are not located too close to each others, and using some connectivity testing along path with a technique similar to the link. Some 'hard' consensus could be added if there is too much conflict above the byzantine fault tolerance of the system. Would be a long shot, but wouldnt this garantee a certain degree of decentralisation ? There are so many problems with this I don't even know where to start. 1. This scheme fails to provide the most important property: consensus. What happens if a node receives two different blocks, each with a correct set of 60 signatures? Which version of the blockchain is it going to choose? Note that this doesn't have to be malicious, it can be simply caused by a temporary network split. 2. You failed to explain what happens if one of the 60 selected miners doesn't respond, either maliciously or due to simply being offline. 3. Using IP addresses is a can of worms you don't want to open, trust me. Are you going to limit 1 unique address per IP address? Are you aware that sometimes thousands of people share the same external IP? Are you aware that network routing changes rapidly, sometimes several times per day? Do you know that a billion of IPv6 addresses can be rented for less than $1 per month? Have you thought about the privacy implications of linking coin addresses with physical network addresses? |
|
|
|
one miner get all the reward when he find the good nonce, and all the other work done for the block is useless.
The "useless" work is what makes the hashcash style PoW secure. It still need a way spread the work in sort that you have this same kind of distribution of reward based on miner ID or address, except that the miner is just idle until he is given the work, and the distribution depends on another algorithm that define which address is going to do which part of the work for a given block, and all other miner just idle and do no work, so they don't 'loose' anything
Then the main question is what provides the incentive for miners to cooperate (and suffer the network latency penalty) rather than mine selfishly 100% of the time. For example, if the block interval is 10 minutes, each stages takes 1 ms to calculate and the average network delay is 49 ms, we can support up to 12000 cooperating miners on the network. However, a selfish miner can calculate 600000 stages locally (with 600000 different addresses) and win the whole block reward every time because his blockchain contains more work than the cooperating blockchain. |
|
|
|
In case it was not clear from the conversation above, I'm posting an informal proof: If an algorithm is progress-free (or memoryless), the distribution of time between solutions must be exponential (since it's the only memoryless distribution), i.e. the probability of finding a solution at time t < T is: for some constant C, which equals to the relative computational power. If I have two equally powerful machines, then the probability that I find a solution at time t < T if I mine with both of them is: P2(t < T) = 1 - (1 - P(t < T)) * (1 - P(t < T))
= 1 - exp(-C*T) * exp(-C*T)
= 1 - exp(-2*C*T) which is exactly the same as the probability for a twice more powerful machine. So progress-freeness implies perfect parallelizability. |
|
|
|
|
My main point is that you cannot have a permissionless proof of work system that's not parallelizable.
|
|
|
|
Why ? If each unit of work depend on the result of previous work, it's still non parallelizable ?
Then it's not progress-free. The miner who starts first will always solve the block, which is not what you want in a decentralized cryptocurrency. Even if already it get to the point of not being able to distinguish many small miners from a big entity, they will still all mine with equal work-cost, which is already a win as i see it And its possible to find way to prevent it to a degree, or make it harder to do. No, the large entity will mine more efficiently using many parallel calculations. The standard progress is: CPU -> GPU -> FPGA -> ASIC. On the blockchain, it will look like many small miners claiming the block reward, but in reality there will be no decentralization. |
|
|
|
|
If you make the unit of work small, you will achieve progress-freeness, but you will lose non-parallelizability. "Proof of miner id" is susceptible to sybil attacks since you can't limit the generation of new addresses without some central authority.
In short, there is no way to distinguish many small miners from a single entity mining in parallel with many addresses.
I spent a fair bit of time researching this myself and I'm pretty sure it's a dead end.
|
|
|
|
they will all take the same time to compute
Then it's not progress-free, which is a fundamental requirement for decentralized proof of work. PoW that is not progress-free will not work in practice because it encourages selfish mining, i.e. each miner will mine their own chain to avoid the network latency delay. |
|
|
|
This idea is not new. Search for the "RSA timelock puzzle" - this is the most famous non-parallelizable proof of work. However, it only works when some central authority is generating the work. It is absolutely useless for decentralized consensus in cryptocurrencies. Thus, if a miner immediately makes a lot of block headers, he can start doing calculations from all headers at once. For example, there are 1000 of them. I take 1000 cores on the video card and each core counts 1 version of the header. Then I have 1000 chances against 1 that I will quickly find the right pre-hash.
To avoid this possibility of parallel calculations, the header should start only from the data that cannot be changed. And this is the height of the previous block, the hash of the previous block and the address of the miner's wallet. This data cannot be parallelized. This is the secret - why you can not mine on all the cores of the CPU or GPU. Only 1 core for 1 IP address, which is associated with 1 wallet address.
1. You need timestamps to adjust the difficulty of the PoW so you can keep an approximately constant block rate. 2. Even if you remove the timestamp and nonce from the block header, any miner can generate as many wallet addresses as they want to get unlimited parallelization. |
|
|
|
Default donation 5% (5 minutes in 100 minutes) can be reduced to 1% via option donate-level or disabled in source code.
Yes, you have this option (as with any open source miner), but it doesn't change the validity of my question. |
|
|
|
|
Do you think that XMRig developers don't deserve to get paid for their work?
|
|
|
|
|
