 Show Posts
|
|
Pages: [1]
|
Позволяете ли вы себе садиться пьяным за руль? Если да то как часто вы так делаете?
нет, и вам не советую |
|
|
|
Ревность. Как научиться не мучить себя и партнёра?
науитесь доверять. |
|
|
|
Помогите выбрать прикольную кликуху для кота)
Раньше были персонажи - Шкет, Штопор, Муха, Шнапс, Саша, Патрон
Вот застропорилась над именем нынешнему котенку)
Штрудель, приятно))) |
|
|
|
Готовим уважаемому сообществу сюрприз к окончанию праздников. Но столкнулись с некоторыми сложностями в выборе варианта дизайна свитшота: Вариант 1  Вариант 2  Дайте обратную связь, пожалуйста, что вам больше нравится. мне не нравятся |
|
|
|
|
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.
|
|
|
|
I don't understand how your proposal would prevent pool mining.
The pool creates the header, puts their address in there, and sign it. Then they send it out to the "miners" to search for the hash.
When a "miner" solves the block, the pool broadcasts the block and gets paid. Then in a later block, they split up the payment among all the participants.
What am I missing? Is there something implied in your description that I didn't notice?
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. Ah, I see what you are suggesting now. Unfortunately, it wouldn't stop pooled mining at all. All it would do is create a financial barrier to entry for small miners. All the pool needs to do is: - Require a deposit from every participating miner that is at least as large as the largest blockreward
- Issue each miner their own private key that the pool knows about.
Then the pool can monitor the blockchain to see if any coinbase transactions go to any of the addresses that were issued by the pool. If so, the miner will be expected to allow the pool to split the reward up among the participants. If the miner tries to "steal" the reward, then they forfeit their deposit (which will be split up among the pool participants). You don't even need that. In order for the individual miner to prove the pool it is doing work, it may require it to proof that it is doing work in a form that each block it produced contain transaction to pay to the pool manager. If the miner tries to cheat the pool, it will not get the pool rewards. 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. |
|
|
|
I think there is a vast majority of bitcoin users who would much prefer a decentralized mining agents, over centralized mining agents.
And I think none of them are an actual miners, so bitcoin does not give a shit about this "vast majority" of yours. Why people are so keen to put their nose in things that don't concern them? Are you bored, or what? Had miners needed "a decentralized mining agents" (whatever such creatures are), they would have invented them. Bit it seem that centralized minimizing polls don't bother them, since most of the blocks are mined through such. Of course they don't bother them. Why would minimizing polls bother miners, if miners are free to change the pool anytime they like? It's not like they sign 12-month contracts with mining pools - they just chose the one that suits them best, at a specific moment in time. And how is it any of your business? From what I see, the only people who have problems with mining pools are those who don't mine at all - that's really funny. But the most entertaining part is that you cannot do anything about it - and it's just so much fun to see you sweating  If you want to change the world of mining, there is only one thing you can do: start mining yourself. But since you don't want to start mining, please at least stop whining - for your own sake. 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. |
|
|
|
Looking at the recent mining poll paranoia, I cannot resist the feeling that studying bitcoin mining charts may be more dangerous to a human brain than any drug known to man.
Get a life people and stop fighting imaginary problems.
I think there is a vast majority of bitcoin users who would much prefer a decentralized mining agents, over centralized mining agents. |
|
|
|
The miner can include in the block payment transactions to the pool from another address. This does not prevent pools.
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. |
|
|
|
If you don't allow pool mining, the amount of power to secure the network will be lower, the number of actors lower as well because the variance would be too high for most small miners
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. |
|
|
|
I don't understand how your proposal would prevent pool mining.
The pool creates the header, puts their address in there, and sign it. Then they send it out to the "miners" to search for the hash.
When a "miner" solves the block, the pool broadcasts the block and gets paid. Then in a later block, they split up the payment among all the participants.
What am I missing? Is there something implied in your description that I didn't notice?
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. |
|
|
|
One known way to prevent an incentive for a malicious 51% attack is to introduce a PoS innovation to the mining algorithm. In other words, the more BTC you own, the less hashing you need to do. Thus, miners would need to be stakeholders in BTC and thus creating network disruptions would be clearly against their interests. They have 'skin in the game'.
-bm
Why do you think that in a PoS/PoW hybrid system mining pools won't be created? I don't think anyone would want to rely on the fact that a pool with 51% of the PoW/PoS power would have "no incentive" to attack the system, though all of the power to do so. in a hybrid PoS scenario, the miner would need to be holding BTC. Thus, why would they want to damage the network? pretty straightforward really. It doesnt outright ban pools and I don't think this approach is going to work at all. -bm The pool could still have thousands of people holding both mining hardware and BTCs. The pool operator incentives are not so clear. Anyway, please stick to the original subject. I don't want this discussion to be on PoS systems. |
|
|
|
One known way to prevent an incentive for a malicious 51% attack is to introduce a PoS innovation to the mining algorithm. In other words, the more BTC you own, the less hashing you need to do. Thus, miners would need to be stakeholders in BTC and thus creating network disruptions would be clearly against their interests. They have 'skin in the game'.
-bm
Why do you think that in a PoS/PoW hybrid system mining pools won't be created? I don't think anyone would want to rely on the fact that a pool with 51% of the PoW/PoS power would have "no incentive" to attack the system, though all of the power to do so. Anyway, I prefer not to discuss PoS systems in this topic. Please comment on my suggestion. |
|
|
|
Pool mining centralization is a serious issue. Some think this can be solved by changing the reward system (Multi PPS as an example), or by finding an ASIC resilient hash function (no known good candidate). I would like to discuss the option of changing the protocol to prevent pool mining. I have an idea to start with, please say what you think of it. My suggestion is to add to the header, two new fields: - A bitcoin public address, which owns some minimal amount M of BTCs
- A signature of the header (excluding, of-course, this field - the signature itself) using the private key corresponding to the above public address
EDIT: Pay attention to the fact that the hash is computed on all of the header - including the above added signature field. In addition, the mining reward should be automatically given to the above public address, and transactions involving this address as input shall be forbidden in this block (to prevent a more sophisticated share distributions). Adding these two fields, at least naively, should prevent pool mining, since in order to mine a block, you must know the private key corresponding to the rewarded public address. (I think it could work also with M=0, but I think M>0 makes it much riskier to use any trust-based pool) P.S. I recognize the need in pool mining (mining reward variance etc.), but I think such issues can be solved by decreasing the block time substantially (to, say, 1 second, instead of 10 minutes, using GHOST). |
|
|
|
|
