(quoted post by asdf)
This is brilliant!
In the future, when bock sizes are huge, this will save a lot of bandwidth and storage. Only one “server” node needs the blockchain and the fat bandwidth required to receive the flood of transactions. Many clients can then contribute to bitcoin without the need to pay for all that infrastructure multiple times. This means that small players can stay in the market and kind of solves the whole scaling problem. Awesome!
Am I the only one who thinks it would be way more simple to just rent distant shell access ??
Quote from: asdf on November 28, 2010, 02:44:58 PM
This is brilliant!
In the future, when bock sizes are huge, this will save a lot of bandwidth and storage. Only one “server” node needs the blockchain and the fat bandwidth required to receive the flood of transactions. Many clients can then contribute to bitcoin without the need to pay for all that infrastructure multiple times. This means that small players can stay in the market and kind of solves the whole scaling problem. Awesome!
Oh, I didn’t even realize this. But it is correct I think. Only the header needs to be hashed. So this scheme has benefits beyond reducing the variance in generating. Very nice.
I think I initially misunderstood the blocks in that the hashes that we compute are independent of the address. Now, I believe that we are looking for something like sha256 (bitcoint address + amount (I am not sure whether the value is implicit, so this value might not be there) +
If the computation is like that, then it might work, but I don’t see why someone cannot just only send you the worthless hashes (for you) and don’t send those that are useful to you. By this mechanism they can bankrupt you. Anyway, I think it is a bad way to communicate with natural language only about these topics. Just write out the computations that you intend to do on the server and the client and then we can see whether it is a brilliant idea or a flawed one. Annotations on the computations as to which goal they intend to achieve is also useful for communication.
Forcing cooperation out of nodes is not easy.
ribuck’s description is spot on.
Pool operators can modify their getwork to take one additional parameter, the address to send your share to.
The easy way for the pool operator would be to wait until the next block is found and divy it up proportionally as: user’s near-hits/total near-hits from everyone
That would be easier and safer to start up. It also has the advantage that multiple hits from the same user can be combined into one transaction. A lot of your hits will usually be from the same people.
The instant gratification way would be to pay a fixed amount for each near-hit immediately, and the operator takes the risk from randomness of having more or less near-hits before a block is found.
Either way, the user who submits the hit that solves the block should get an extra amount off the top, like 10 BTC.
New users wouldn’t really even need the Bitcoin software. They could download a miner, create an account on mtgox or mybitcoin, enter their deposit address into the miner and point it at anyone’s pool server. When the miner says it found something, a while later a few coins show up in their account.
Miner writers better make sure they never false-positive near-hits. Users will depend on that to check if the pool operator is cheating them. If the miner wrongly says it found something, users will look in their account, not find anything, and get mad at the pool operator.