нет, и вам не советую

нет, не пользуюсь.

не ейте, это вредит вашему здоровью.

науитесь доверять.

Штрудель, приятно)))

мне не нравятся

это сугубо ваше дело

не верю

да, очень

интернет великая штука

в первые о таком слышу

нужно не сидеть на диете, а просто правильно и в меру кушать

никак, только покраска

Following the recent events, I thought that the following issue should be addressed.
Recently forks become more common, and in contrast to usual alts, bitcoin forks usually keep the same hash problem, and as such, they are competing on the exact same miners. BCH miners are BTC miners and vice versa.

Think about the following scenario. Two coins compete for the same mining power. Suppose we give one of the coins an unstable difficulty scheme, such that once in a while it's easier to mine its coins. Just as an example, suppose the forked coin protocol defined that 50 coins are given for each block on every odd week, but 100 coins are given for each block on every even week, (and the difficulty is kept the same as it was the week before), so it's much more profitable to mine blocks in the even weeks, and the mining power shifts to the forked coin on every even week.

Suppose also that original bitcoin network is directed by a spam attack, and you get a situation where the bitcoin network will suffer from a very slow block generation and transaction confirmations, every even week.

Of course, this scenario is just one example, that demonstrates what might happen when two coins compete on the same resources, an irregular behavior of one could affect the other one and cause an even worse irregularity, sometimes on a regular basis.

Thanks for the comment - I think you're right. The pool manager can send the merkle root to the miners, and the miners shall prove they're doing work by finding a less difficult block (using their private key) whose header include the given Merkle Root. In the Merkle Tree corresponding to the given Merkle Root, there should be a transaction from another address of the miner to the pool manager (or all pool participants). This way, the pool manager can verfiy the miners are doing their work, and when one of them finds a block - he gets the full reward, and pays from another address to the pool.

Look, suppose a change in the protocol will be accepted by the bitcoin users. In such case, the miners opinion is not relevant - they're just getting bitcoin in return to their service. I, and many others, can think that this service doesn't fit our need (due to centralization) and change the protocol accordingly. The protocol, and the value of bitcoin is determined by the users, not by the miners.

I think there is a vast majority of bitcoin users who would much prefer a decentralized mining agents, over centralized mining agents.

He can, but he has no incentive to do so, and the pool has no way, at least not any simple way, to make sure he does so.

You're right that in the current system, pool mining is necessary. This is why I wrote that I think the variance problem can be solved by changing the block frequency to 1 sec, instead of 10 minutes.

You're missing the fact that the nonce and the merkle root are part of the header, so the pool manager cannot sign the header without counting over all nonces himself.