Some questions about consensus, mining and hash-algorithms

[furk]

I want develop a new blockchain platform. But I have some problems understanding consensus protocols and mining. I have made research in documentations and blogs for this but all blogs described mining as solve a math problem or the riddle. Can someone who understands this work explain it technically in a simplified way? What is meant by the mathematic problem? What do CPUs and GPUs try to solve? Do the tasks solve the password of the encrypted files?

For example, Ethereum has 18k nodes. Do each transaction need to be approved by at least 51% of these 18k nodes at Proof-of-work protocol? Is it enough to approve 51% of a certain part of these nodes?

What are the cons of developing a blockchain platform with an easier hash-algorithm in terms of encryption difficulty and solvability?

I can understand a bit about the Tangle protocol, but how does Nano keep the nodes in the network without block rewards and transaction fees incentives?

[jackg]

I want develop a new blockchain platform. But I have some problems understanding consensus protocols and mining. I have made research in documentations and blogs for this but all blogs described mining as solve a math problem or the riddle. Can someone who understands this work explain it technically in a simplified way? What is meant by the mathematic problem? What do CPUs and GPUs try to solve? Do the tasks solve the password of the encrypted files?

Essentially, if you've heard of things like the mod sign (%) then it's like doing that to a very large number to get a hash digest.
You first run a hash algorithm (this could be anything specific to the algorithm).
This hash essentially produces a very large number, you take a very large number and mod it with a smaller number and get a number that better fits the algorithm (as the "small" number is still a fairly large number it is fairly difficult to reverse engineer the hash).
If we came up with a large number of say 926843 and mod it with a prime number, say 7 (would be bigger in real life), you would end up with the value of 1 as your hashed number. You can't know that you started with 926483. Obviously if both numbers were bigger, the entropy of the large number is increased and so has a much wider range of values.
Essentially, when a block is mined, the smallest number that can be determined for the hash of the block is attempted to be discovered using randomely generated private keys (as I understand it).

For example, Ethereum has 18k nodes. Do each transaction need to be approved by at least 51% of these 18k nodes at Proof-of-work protocol? Is it enough to approve 51% of a certain part of these nodes?

I don't know how their system works, although Bitcoin was said to need 95% adoption in a hard fork protocol before it was considered it would be successful to convert to that protocol (though that might have just been polite). It merely takes one node to accept a transaction/block however it might get rejected by other transactions/blocks.

What are the cons of developing a blockchain platform with an easier hash-algorithm in terms of encryption difficulty and solvability?

How "easy" an algorithm is is a bit unspecific.

If it's an algorithm that is considered relatively collision free then producing a coin in that algorithm would be collision free and have a fairly secure blockchain.
If the algorithm is very easy to reverse engineer then the currency is at risk of attack.
An easier algorithm doesn't mean much though as the difficulty should adjust automatically for the currency to be successful (unless it's an LN currency).

Note: the first part of this post is an analogy, it may not be perfectly accurate but it's a useful representation of how the hashing algorithms work to find a block

[furk]

I want develop a new blockchain platform. But I have some problems understanding consensus protocols and mining. I have made research in documentations and blogs for this but all blogs described mining as solve a math problem or the riddle. Can someone who understands this work explain it technically in a simplified way? What is meant by the mathematic problem? What do CPUs and GPUs try to solve? Do the tasks solve the password of the encrypted files?

Essentially, if you've heard of things like the mod sign (%) then it's like doing that to a very large number to get a hash digest.
You first run a hash algorithm (this could be anything specific to the algorithm).
This hash essentially produces a very large number, you take a very large number and mod it with a smaller number and get a number that better fits the algorithm (as the "small" number is still a fairly large number it is fairly difficult to reverse engineer the hash).
If we came up with a large number of say 926843 and mod it with a prime number, say 7 (would be bigger in real life), you would end up with the value of 1 as your hashed number. You can't know that you started with 926483. Obviously if both numbers were bigger, the entropy of the large number is increased and so has a much wider range of values.
Essentially, when a block is mined, the smallest number that can be determined for the hash of the block is attempted to be discovered using randomely generated private keys (as I understand it).

For example, Ethereum has 18k nodes. Do each transaction need to be approved by at least 51% of these 18k nodes at Proof-of-work protocol? Is it enough to approve 51% of a certain part of these nodes?

I don't know how their system works, although Bitcoin was said to need 95% adoption in a hard fork protocol before it was considered it would be successful to convert to that protocol (though that might have just been polite). It merely takes one node to accept a transaction/block however it might get rejected by other transactions/blocks.

What are the cons of developing a blockchain platform with an easier hash-algorithm in terms of encryption difficulty and solvability?

How "easy" an algorithm is is a bit unspecific.

If it's an algorithm that is considered relatively collision free then producing a coin in that algorithm would be collision free and have a fairly secure blockchain.
If the algorithm is very easy to reverse engineer then the currency is at risk of attack.
An easier algorithm doesn't mean much though as the difficulty should adjust automatically for the currency to be successful (unless it's an LN currency).

Note: the first part of this post is an analogy, it may not be perfectly accurate but it's a useful representation of how the hashing algorithms work to find a block

Thank you for your interest and your response.
I knew that the hash process encrypted and compressed the operation. what I was wondering was that this hash was related to miners. Did the CPUs attempt to decode the hash by inverting it? I was wondering about that.
Only one node need to be approved for each operation to take place? I thought the 51% rule was not just for the fork and that it was necessary for the transaction approval.
I meant an algorithm that does not require high power consumption and expensive hardware for mining by calling it an easy algorithm.

[jackg]

Thank you for your interest and your response.
I knew that the hash process encrypted and compressed the operation. what I was wondering was that this hash was related to miners. Did the CPUs attempt to decode the hash by inverting it? I was wondering about that.
Only one node need to be approved for each operation to take place? I thought the 51% rule was not just for the fork and that it was necessary for the transaction approval.
I meant an algorithm that does not require high power consumption and expensive hardware for mining by calling it an easy algorithm.

Only one node needs to add it to a block for it to get confirmed, a block can then go on to be "orphaned" by the network/specific nodes.

An easy algorithm would need to be complex enough to make it as close to asic proof as possible without making the efficiency of mining make a loss.
Large amounts of power are currently needed due to live difficulty changes in the algorithm (every 2016 blocks) so it started with the ability of being mined on a desktop computer and now needs powerful servers instead just because that's what people are using.

I assume (don't actually know per se) but mining a block uses a type of private key-public key encryption. Hence, the miner merely can release the private key they used to mine the block (randomly selected) and then use that to verify they were the block's miners. They also append a transaction to the start of the block with their btc reward+fees and other info to make the block valid.

[furk]

Only one node needs to add it to a block for it to get confirmed, a block can then go on to be "orphaned" by the network/specific nodes.

An easy algorithm would need to be complex enough to make it as close to asic proof as possible without making the efficiency of mining make a loss.
Large amounts of power are currently needed due to live difficulty changes in the algorithm (every 2016 blocks) so it started with the ability of being mined on a desktop computer and now needs powerful servers instead just because that's what people are using.

I assume (don't actually know per se) but mining a block uses a type of private key-public key encryption. Hence, the miner merely can release the private key they used to mine the block (randomly selected) and then use that to verify they were the block's miners. They also append a transaction to the start of the block with their btc reward+fees and other info to make the block valid.

Instead of increasing the degree of difficulty in order to prevent inflation would not it be more correct to limit the number of nodes to be miner according to the transaction volume?

[jackg]

Instead of increasing the degree of difficulty in order to prevent inflation would not it be more correct to limit the number of nodes to be miner according to the transaction volume?

No. Yiu can still get powerful machines that could mine it by doing this. And then those nodes that are permitted to mine makes the network too centralised.

You could probably change the code to add time intervals between block submissions to the network but I'm not sure that's a good idea as it might be easy to manipulate.

[furk]

Instead of increasing the degree of difficulty in order to prevent inflation would not it be more correct to limit the number of nodes to be miner according to the transaction volume?

No. Yiu can still get powerful machines that could mine it by doing this. And then those nodes that are permitted to mine makes the network too centralised.

You could probably change the code to add time intervals between block submissions to the network but I'm not sure that's a good idea as it might be easy to manipulate.

Thank you for your responses again .