Bitcoin Forum
July 16, 2019, 11:26:25 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 [75] 76 77 »
1481  Other / Beginners & Help / Re: A website to check "Who find the bitcoin blocks" on: July 15, 2011, 10:34:23 PM
Here's one that Artefact2 (from Eligius pool) created: http://pident.artefact2.com/
1482  Bitcoin / Mining support / Re: Under clock memory in Linux for 6970 up to core clk minus 125Mhz. on: July 15, 2011, 10:06:11 PM
Yes this is a good question.  As far as I know there is no Linux tool to underclock lower than 125 below core clock.

Windows users report MSI Afterburnder will allow this.

(1) Can anyone confirm the real world value of this under Windows?  Are you seeing lower temps?
(2) Are there any other windows tools which can do this for Cayman core?

If its worthwhile, and if I can figure out how MSI interacts with the card, I'd like to try to modify the linux tool- since AMDOverDrvCtrl is open source and all.

Yeah, if there is a way, that would be awesome.
Take a look at atitweak: http://forum.bitcoin.org/index.php?topic=25750.0
That is based on AMDOverDrvCtrl. Unfortunately, like AMDOverDrvCtrl, it will let you set a lower clock speed, but it doesn't stick if it's more than 125 less than core.
1483  Bitcoin / Mining support / Re: Under clock memory in Linux for 6970 up to core clk minus 125Mhz. on: July 15, 2011, 06:17:52 PM
If anyone knows a workaround to underclock memory clock more than 125MHz below core clock, please post. Thanks!
1484  Bitcoin / Bitcoin Discussion / What if deepbit started a new block chain? on: July 15, 2011, 04:41:44 AM
Imagine if tycho decided he wants to start a new block chain and uses deepbit's huge hashrate to do that. Or if a hacker hacked into deepbit. All he has to do is temporarily disable withdrawal for a day and have all the miners work on mining deepcoin starting at difficulty 1. Before anyone realizes the deception, thousands of blocks would have been mined and probably close to a million deepcoins. Then when the miners see that they have generated thousands of DPC each versus not even 1 BTC, some might decide to stick around and see what happens. Some othe pools or miners might then join this so that they too can be early adopters of this new coin.

What do people think? Is this a plausible scenario? Tycho likely would not risk his deepbit earnings to do this? But a hacker could. That's why I think it's a bad idea to have one pool control so much of the total network hashrate.
1485  Bitcoin / Pools / Re: A proposal for Recent Shared Maximum PPS on: July 13, 2011, 06:06:09 PM
What I don't like at both SMPPS and RSMPPS is that the pool can be in dept a lot out of a sudden bad luck streak with potentially no way to recover ever (imagine having a really bad bad luck streak at the time right before the block reward is cut in half and a lot of miners leave!)

With SMPPS, a real bad luck streak right before a huge difficulty increase or block reward being halved could cause the pool to never recover. This is because new incoming rewards will not be enough to payoff the old debt. (Assuming due to the bad luck, there won't be enough new miners to make up for the harder difficulty)

But with RSMPPS, this is not the case. A bad luck streak will only affect the miners mining at that time. This extreme case will look just like a normal proportional pool to the miners. Since for each long round, they are paid their proportional reward and not the ideal PPS reward. If the pool ever recovers from the bad luck, the difference will get paid back. If not, then they won't get more for those shares, but then the miners are not worse off than if they were in a proportional pool. So the RSMPPS pool will not be burden by this old debt.

To me PPS systems still seem to be tha fairest ones, but with SMPPS or RSMPPS there is a risk involved that some shares will never be paid, if the pool hash rate has a peak at a bad luck streak.

Like Luke said, each share will be paid at least something. And that something will be equivalent to what you get in a proportional pool. If the pool gets a short round in the future, you may be reimbursed for the difference.
1486  Bitcoin / Mining support / Re: Any way to under clock memory in Linux for 6970 on: July 13, 2011, 10:30:18 AM
Yeah, the mem clock in level 2 cannot be lower than that of level 1 and 2. So what I do is just set the mem clock for all levels to the same and then just set the core clock for level 2. That works for me.
1487  Other / CPU/GPU Bitcoin mining hardware / Re: New command-line tool for overclocking ATI cards (Linux) on: July 12, 2011, 10:22:36 PM

Good stuff mjmvisser ... !

Yeah, seriously good stuff. Do you have a donation address?
1488  Bitcoin / Mining support / Re: Any way to under clock memory in Linux for 6970 on: July 12, 2011, 07:34:46 PM
I've been using atitweak: http://forum.bitcoin.org/index.php?topic=25750.0

I could set the memory to something low but it won't stick. It seems like mem clock cannot be more than 125 lower than core clock. Not sure why that is.
So if you set your core clock to 900, you can set your mem clock to 775 but not lower. Otherwise, it will revert back to 1375.
Thanks.
I tried with core clk 975 & mem clk 900 now with both aticonfig & atitweak. But still i am getting peak as 1375 for 6970 cards & no less in temperature also.
I used 11.6 catalyst.
Which catalyst you used?

11.6 also.

Paste the output of these commands:

aticonfig --adapter=all --odgc
atitweak -l
1489  Bitcoin / Mining support / Re: Any way to under clock memory in Linux for 6970 on: July 12, 2011, 05:15:00 PM
I've been using atitweak: http://forum.bitcoin.org/index.php?topic=25750.0

I could set the memory to something low but it won't stick. It seems like mem clock cannot be more than 125 lower than core clock. Not sure why that is.
So if you set your core clock to 900, you can set your mem clock to 775 but not lower. Otherwise, it will revert back to 1375.
1490  Other / CPU/GPU Bitcoin mining hardware / Re: ATI underclocking memory under linux? on: July 12, 2011, 05:13:14 PM
Try atitweak: http://forum.bitcoin.org/index.php?topic=25750.0
This new tools works much better for me.
1491  Bitcoin / Pools / Re: A proposal for Recent Shared Maximum PPS on: July 12, 2011, 04:32:16 PM
Anyone with the most basic knowledge of stochastic processes can see that SMPPS is a bad method.

There are two valid hopping-proof methods:

1. Geometric method. Cons: Requires implementation in logarithmic scale, has high (but tunable) variance.
PPS is a limit case of this.

2. PPLNS. Cons: Crosses round boundaries.

It looks like your RSMPPS is trying to take SMPPS and make it more like PPLNS. Better just use PPLNS instead.

(In case people mean the geometric method when saying "the cheat-proof method", please stop. "cheat-proof" is an adjective, not a name. Better edit the thread I guess.)

I agree that both geometric and PPLNS are pool hopping deterring methods and are fair. But correct me if I'm wrong (since I don't know the geometric method that well), they really only work well for people mining 24/7. If I'm not mining 24/7, I will be unfairly punished for looking like a pool hopper. RSMPPS works better in that case. Each submitted share to RSMPPS will always have the same expected return.
1492  Bitcoin / Pools / Re: [140 GH/s 0% fee SMPPS] Ars Technica community mining pool! on: July 11, 2011, 10:46:18 PM
You can now hide all those extra workers you created.

What happens when you hide a worker that you are currently mining with? I assume that would screw things up, right? You should probably only show the hide button if the worker is idle (when it's red).

Also, can you please sort the worker list by name? Thanks!
1493  Bitcoin / Pools / Re: [130 GH/s 0% fee SMPPS] Ars Technica community mining pool! on: July 11, 2011, 09:54:28 PM
I just upped my donation percent. Thanks for all your hard work!
You should definitely add some optional perks like miner idle emails.
1494  Bitcoin / Bitcoin Discussion / Re: Hypothetical Bitcoin clone except backed by gold on: July 11, 2011, 07:13:44 PM
Quote
I think anyone can mine the goldcoins, and then redeem them at the exchanges for gold.

I don't think that's the OP's idea.

Why would any exchange back goldcoins with physical gold when anyone can mine for goldcoins? Exchanges like mtgox have traders on both the buy side and the sell side and that's how they come to the USD/BTC exchange rate. You don't just start an exchange and permanently set the exchange price yourself. If you do that, you will find that people will trade the worthless goldcoins to you for real gold and no one will trade away real gold for these goldcoins.

Only governments can really pull this off. That's because governments have a lot of gold, they have an incentive to make fiat currency successful, and they can force their citizens to pay tax in fiat currency. Tax forces people to have to trade in their gold for fiat currency. None of this is true for goldcoins.
1495  Bitcoin / Bitcoin Discussion / Re: Hypothetical Bitcoin clone except backed by gold on: July 11, 2011, 06:59:44 PM
There are just so many potential problems with this idea:
  • You want to have a central authority distribute goldcoins and have them store gold as backing?
  • Is the central authority going to pay to store the actual gold needed for backing.
  • Where does that money come from?
  • Who is this central authority and why would they do this for free?
  • Why would they not steal your gold?
  • Where do the goldcoins come from if not mined?
  • Does the central authority just mine the goldcoins themselves and then sell it for gold?
  • If mining does not create goldcoins, then there would be no miners. If there are no miners, who keeps the blockchain secure?
  • Where does the initial trust for goldcoins come from? Why would I use real money/gold to buy goldcoins?

1496  Bitcoin / Pools / Re: [130 GH/s 0% fee SMPPS] Ars Technica community mining pool! on: July 11, 2011, 05:48:41 PM
Yeah, thanks for being so honest BurningToad. You could have easily just kept the extra 50 BTC and no one would have known. It's nice to find such a good pool and pool operator. And the fact that it's also lucky right now is just icing on the cake. Smiley
1497  Bitcoin / Pools / Re: A proposal for Recent Shared Maximum PPS on: July 11, 2011, 07:37:12 AM
So you mean something similar to RSMPPS but also favor unpaid shares from miners who are still active. So if miner A worked on block 1 (a long block) and didn't get fully paid. And miner B worked on block 2 (another long block) and didn't get fully paid. Miner B stopped mining with the pool, but miner A continued mining. When the pool finally starts to get lucky and has enough BTC to pay the unpaid shares from block 2, we might favor paying miner A for his work on block 1 because he's still active instead of paying miner B for his work on block 2.

I think seems ok. It will give people incentive to keep mining and stick with the pool. But I can't think of a good formula that makes this simple to understand and implement. It might turn away miners due to it being too complicated even though the idea behind it is valid.
1498  Bitcoin / Pools / Re: A proposal for Recent Shared Maximum PPS on: July 11, 2011, 06:23:54 AM
Just throwing out an idea here as well... it's quite unpolished, as I came up with it a couple of minutes ago...  Wink

Would a "tax" on old Max rewards be some sort of compromise? I'm thinking of some sort of system that moves accumulated unpaid PPS during longer streaks of bad luck and pays it forward to the the current round... let's say that with two rounds it proceeds as normal, but when the pool goes into the third bad block it starts taking a percentage of the unpaid shares from the first round and adds those to the current round, and if there's a fourth bad round it takes a cut from both round one and two and so on.

That way, the unpaid PPS from those who jump to another pool would gradually be shifted over to those who continue mining.

Not exactly sure what you mean by this. What does moving unpaid PPS from previous unlucky rounds to current round mean?
1499  Bitcoin / Pools / Re: A proposal for Recent Shared Maximum PPS on: July 11, 2011, 05:49:47 AM
RSMPPS was something I considered when I was coming up with SMPPS. The key problem with it is, that cheaters (that is, people who only submit useless valid shares) can avoid taking any of the damage from their cheating. Solve that, and we have a winner Wink
Can you elaborate on the submitting useless valid shares? Does SMPPS solve this?
Only the one share that gets the pool a block is actually useful. Cheaters can reduce pool luck by refusing to submit those. With PPS, the liability is held entirely by the pool operator. With proportional, MPPS, and SMPPS, the liability is distributed among everyone in the pool. With RSMPPS, that liability is distributed among everyone except the cheater.

I don't get it. If the cheater refuses to submit the winning share, would he be able to submit it elsewhere and get the 50 BTC? If not, is he just doing this to screw over the pool? Why would the liability not be distributed to the cheater in case of RSMPPS?
Yep, pretty much just to screw the pool. So long as the cheater is careful going about it, he gets paid full PPS with no penalty under RSMPPS. I won't elaborate, as I don't care to encourage it.

With RSMPPS, the liability will be distributed among everyone including the cheater also. Let say if the cheater/saboteur finds a winning share after an average length and decides to not submit that share. The pool goes on and keeps looking. And let say it takes another average length to find another winning share. So because of the sabotage, the cheater turns 2 average rounds into a double length round. And he will only get half his work paid. Whereas if he didn't sabotage, he will get paid his full work for the 2 blocks. So the cheater is being penalized for cheating in the case of RSMPPS also, right?

In the end, I think this is an edge case that we don't need to worry about. In order for a cheater to really have a real effect on a block by sabotaging it this way, he needs to have quite big of a hashrate. I can't imagine someone with such a hashrate spend his time throwing away winning blocks just to sabotage a pool. Just imagine... all those winning shares are worth 50 BTC to himself if he solo mined! Who in there right mind would be so stupid.
1500  Bitcoin / Pools / Re: A proposal for Recent Shared Maximum PPS on: July 11, 2011, 05:30:04 AM
RSMPPS was something I considered when I was coming up with SMPPS. The key problem with it is, that cheaters (that is, people who only submit useless valid shares) can avoid taking any of the damage from their cheating. Solve that, and we have a winner Wink
Can you elaborate on the submitting useless valid shares? Does SMPPS solve this?
Only the one share that gets the pool a block is actually useful. Cheaters can reduce pool luck by refusing to submit those. With PPS, the liability is held entirely by the pool operator. With proportional, MPPS, and SMPPS, the liability is distributed among everyone in the pool. With RSMPPS, that liability is distributed among everyone except the cheater.

I don't get it. If the cheater refuses to submit the winning share, would he be able to submit it elsewhere and get the 50 BTC? If not, is he just doing this to screw over the pool? Why would the liability not be distributed to the cheater in case of RSMPPS?
Pages: « 1 ... 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 [75] 76 77 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!