|
The steady state of Bitcoin is when new coin generation is negligible and mining is rewarded with transaction fees. Currently the amount of mining is indeed too high for the network security requirement, since it actually serves 3 purposes:
- Having an objective way to make the initial distribution of coins
- Securing the network
- Practicing mining for when it will really be needed to secure the network
Going forward, there will be a tradeoff between the inconvenience of paying fees and the need to incentivize mining to secure the network. There's been discussions of how to reach a good tradeoff but nobody knows what exactly the future holds.
|
|
|
|
Some people are doing it and it is confusing  Scammers will like it because they keep the post count but can use a new identity. The only way to check is to see their old posts and try remembering who it was. It's not that hard, look at an old post and see the name used when it is quoted. I do wish it would be easier, and that people would give a heads up - it's confusing to see a name I've never heard with >2000 posts (creighto/Moonshadow, I'm looking at you). I had a good reason to switch and carried a nametag for a month. |
|
|
|
It's unnecessary to forge the timestamp, having an old timestamp doesn't make a block invalid unless it's earlier than the blocks it builds on. It's the reference to the last block that matters. If a pool tries to concoct an alternative branch the miner can easily find out that the previous block he works on is not the latest block known to the network. Makes sense but old timestamps would rise suspicion. Also it's not true that the block chain only contains strictly growing time stamps. I've seen examples where this was not the case. I don't remember the exact rule and it didn't seem relevant, something about not being earlier than the median of the last X blocks. The point is it can't be too early. And a branch with all the blocks having similar timestamps will raise more suspicion. can't this be used to detect attacking clients that want to withhold the winning blocks?
withhold the winning blocks??? what does that mean? i'm not a native english speaker but according to my dictionary "withhold" can mean "keep for them self" which is not possible as pool mining means the pool dictates the block (txs that get in, timestamp and addresses for the 50BTC reward) and the miner only finds a salt so the hash fits. Changing the data will make him fail on test data and get him kicked out of that pool. "withhold" also means "hold back" which would not make sense neither as it would simply delay the next block from being found. I provided a link with some discussion about potential attacks. Unconditional withholding can be used for sabotage and is especially deadly against PPS pools. Postponed submission can be used for additional profit. |
|
|
|
|
5 is wrong, transactions are propagated in seconds. You don't need to wait for a confirmation in a block to buy coffee.
6 is wrong. Bitcoin has many advantages over alternative currencies and payment methods. Anonymity is just one of them, and if it's less relevant to large transactions it doesn't mean Bitcoin is "bad" for them. And it's of course excellent for small and medium e-commerce.
|
|
|
|
I read that (some) pools trial the miners with payload they know contains a hit just to verify they actually do work.
I'm fairly sure no pool has done that in ages, verification of work is done using shares. If that is the case as I assume and if changing the timestamp would change the result of such test, the pool *must* dictate the timestamp and thus can do unpublished blocks in advance.
It's unnecessary to forge the timestamp, having an old timestamp doesn't make a block invalid unless it's earlier than the blocks it builds on. It's the reference to the last block that matters. If a pool tries to concoct an alternative branch the miner can easily find out that the previous block he works on is not the latest block known to the network. can't this be used to check attacking clients that want to withhold the wining blocks?
Possibly. |
|
|
|
Just would like to have the option to change to another pool with out the losses.
There are no losses. You can freely change to another pool any time you wish. This will have no affect on your payout for already submitted shares (if no block is found they will quickly depreciate whether you're in or out). |
|
|
|
the getwork command should be re-written to give to the miners full block data instead of just the header.
that way miners can verify that the block they are working on will give money to the pool and not some other wallet.
currently pool owners can easily cheat by giving the miners work that generates for some different address.
i dont claim some do that but it is very easy AND absolutely undetectable. sure you can in theory check nonces on each new block to see if your found successful nonce is in any of them (and check who they generate btc for) but this check is only possible if you do find a solution which is very very rare and I doubt some mining software is written with that function...
face it, when you can cheat and you're absolutely sure no one will ever catch you .. the temptation is too strong.
the thing is, client was not written with pool mining in mind .. it needs to be amended according to the current times.
You're confused about several things. There's no "pool's address" which is the indication that the pool found a block. It uses whatever address it wants, possibly a different one per getwork request. It's up to the operator to distribute rewards when the pool finds a block. The way to avoid cheating is for the miners to notice that when they find a block it is acknowledged by the pool (with my oblivious shares suggestion, this can only be done with some delay). It's possible that having a fixed address for the pool can improve transparency but that's a separate change. Also, in the future each block can be gigabytes or terabytes and it will be unfeasible for miners to download it. |
|
|
|
What attack could there possibly be? My hash only works for the exact block and modifying details doesn't work. I would only have two options: report the block to be found or not. How would the latter possibly be an attack? What am I missing? If you're mining against a PPS pool, for example, you're getting paid immediately for every share you submit. Now, while doing that, withhold any shares you've found that would result in the pool getting a block. You're still getting paid the same amount of money (-1 share in a million), but the pool is getting less found blocks. This, as well as others. See for example here. Well ... If the promotion of found blocks is to the discretion of the pool, only, it can pile up some blocks ahead of time to release them if the pool risks to lose the race for the longest chain but hold it back to leave the rest compute for the wrong chain.
...
Nah I meant rather if pools watch for dropped blocks as this would be a sign of cartel activity.
It shouldn't be difficult for miners to verify that they're working on the latest block. And clients can detect when they suddenly get a whole new long branch. I don't think these tests have been implemented yet because we're just not there. The sudden media attention notwithstanding, everything is still in beta. How does the proof of work work if the miner chooses the timestamp. It must be part of the hashed data.
The miner decides the nonce by itself, in theory there shouldn't be a problem to choose the timestamp too. With 50% to get a block per month I claim people should be patient and rely on maths. With your projection I more or less get the picture. BTC becomes gambling more and more.
The math says that the utility of money is concave and hence variance is bad. Also when you don't get any payout for a long time it's difficult to know everything is working. The .5% per month can happen right now if you're using a low-end GPU. And we're not Vulcans, when I tried mining solo I couldn't handle the pressure, and I was at an average 10 blocks per month. |
|
|
|
this is perfect for multipool, since you can tell all the miners in multipool to switch to slush while holding the winning share for 9 minutes thus making every miner score high
This thread is about oblivious shares, and discussion of lie-in-wait is only on topic insofar as it refines the understanding of oblivious shares. Discussion of best ways to perform it belong elsewhere. |
|
|
|
About 8%. Bitcoins used to be cheaper and easier to mine, someone having 500K is not at all unusual […].
Please define ‘unusual’. With BTC 6.603M in circulation right now, approximately 13 persons could have BTC 500k in their wallet if they held the total amount of BTC. With that in mind, having BTC 500k cannot be called ‘not unusual’… Cheers, What I meant is that it is expected that at least one person in the world has this amount. |
|
|
|
Does the pool also implement the Lie-in-Wait attack, discussed for example here? |
|
|
|
as to my understanding, bitCoins success is based on the peer to peer structure and any entity owning 50% of computational power could cheat on the rest or stop the show for all. While pools are no threat in the latter sense as miners are no zombies tied to them against their will, I come to understand that pools really pose a threat in the former sense.
(Yes I know this must have been discussed somewhere in depth but i could not find it. It's mostly annoying me that all people suggest to join a pool based on the kh or Gh they do.)
Indeed it has, and solutions have been proposed. In fact "don't join deepbit because it's harmful for the network" is commonly heard. As in slush pool's sticky post it is made very clear that in a pool situation it is not the miner who decides what gets into the block but the pool delegates the work to the miners. I read it such that not only does the pool dictate the reward (would make sense) but also transactions, time, prior block and the salt to try out.
That's how it works currently, yes. There are suggestions to allow the miner to choose what to put in the block. Am I about right in my analysis?
More or less. Does the miner know when it found a block?
Yes. Which is actually a problem since it opens up several types of attack. I suggested once to allow miners to know if they found a block only after the fact. Does the miner promote its finding only to the pool?
Yes, the generation transaction in the block rewards the pool so there's no sense doing anything else with it. But the pool then broadcasts the block to the network. Does the miner do plausibility checks for the timestamp at least?
What if it is not plausible?
I think the miner chooses the timestamp. And the timestamp is validated by nodes on the network before propagating the block. Do pools keep an eye on each other by comparing block chain data ...?
A block is propagated in the network only if it is valid. If not, why is all the world still promoting to use pools? What's the big benefit of having a cash out every day over having one every month or two if the sum is the same taken you support fuzzy constructs that promise a profit where there should actually not be a profit if the system itself was not flawed.
It's the same on average. But it's completely random. Suppose your payout should be $1000 per month. If you mine in a pool you get $1000. If you try to mine solo you could easily get $0, or $2K or $3K. And it's not like if you didn't find a block then it's waiting around the corner, for the next month you have exactly the same odds. Not only is this nerve-wrecking, but economically it is inferior since the utility of money is concave. Not to mention availability if you actually need to use the money. And this only gets worse as more people start to mine, instead of 50% of getting $1K you could be looking at 0.5% of getting $100K. Variance is bad, and reducing it is not a luxury. Economics is not a zero-sum game, pools and miners can have a mutually beneficial arrangement - the pool takes some fees and the miner greatly reduces his variance. |
|
|
|
|
About 8%. Bitcoins used to be cheaper and easier to mine, someone having 500K is not at all unusual (keeping them on mtgox up to now is, however).
|
|
|
|
my bitcoin address changed, should I just keep using the old one?
I didn't really use any other pools of this kind that don't have "accounts" or whatever
The client will automatically generate new addresses for you. You can keep using your older address. |
|
|
|
By the way, why is Eligius on the list? Didn't they switch to maximum PPS to be safe from pool hopping?
According to http://eligius.st/wiki/index.php/Maximum_PPS this is only a planned feature. And "maximum PPS" is stupid, it will leave miners without payment for days or weeks during periods of bad luck - the variance is much higher than in other methods. Why can't people use a working method like those mentioned in the original post of this thread? |
|
|
|
instead of trying to block it, why don't pool operators get rid of the exploit in the first place?
You'll have to ask them, but in my experience: Because acknowledging the exploit means admitting they were wrong to start a proportional pool, which is too difficult emotionally. |
|
|
|
Thanks for responding. So just to confirm, MAX is being set to the score of the last share, which is arbitrary in so far as it could be anything depending on when the round ends?
Yes. And it's also arbitrary in the sense that it's just used for numerical stability, you can use another value for it as long as it's used consistently in all parts of the calculation. I think I understand what's going on now as far as lscore - max. Is the share table then intended to contain one row per share each with a score as opposed to one row per user with an aggregate score that is increased for each share submitted? I think that may be where I went off track and why it wasn't making sense.
Correct, one row per share. Is each share worth a certain amount, regardless of who submitted it or does the value of a share differ depending on who submitted it? By this, I mean if person A has submitted 500 shares in the past hour and person B has submitted 200 shares in the past hour, person A's 500th share is worth more than person B's 200th share or A's 500th and B's 200th are worth the same if they are submitted at the same time (well, one is worth slightly less than the other depending on which order it was submitted)?
Yes, the value of a share depends only on when it was submitted and not on who submitted it. The total payout of a worker is just the sum of the payouts for all of his shares. |
|
|
|
|
This is very interesting. I'll probably join.
You should target Continuum pool if all other pools are dry. It always has 100% efficiency like solo, without all the variance. It will also help reduce the variance of those who mine on it normally, further promoting fair scoring methods.
|
|
|
|
|
The formula you quote is used only when the round ends to calculate the payouts.
lscore is the logarithm of the score for a given share.
"share" is a table that contains information about all shares. "max" is the lscore of the last share (note the "order by id desc limit 1;" part). So only for the last share lscore - max will be 0, for earlier shares it will be negative. You sum over all shares.
The later the share was submitted, the higher its lscore, as specified in the algorithm.
|
|
|
|
who wants to wait several days per block with the difficulty constantly raising, when you could just mine at a larger pool and get full advantage from current difficulty which is lower than it will become in just a few days?
How about being the only pool around using a hopping-proof scoring method? with PPS those miners would still get their reward but the pool would also grow.
martok's PPS and score-based are two separate pools. Drawing people to the PPS does not help the score-based grow. And opening up a new PPS pool makes no sense for someone small. also why are you only talking about pools being cheated? why not talk about the miners?
Because that is a different problem which has not come up in this discussion. The short answer is that the mining software knows when it finds a valid block. The user can monitor for this event and if he discovers that a block was found and the pool wasn't rewarded he can blow the whistle. And yes, not having to worry about this issue is one of the selling points of PPS. |
|
|
|
|
Show Posts
