Bitcoin Forum
May 02, 2024, 12:03:28 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 [380] 381 382 »
7581  Bitcoin / Pools / Re: [460 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: June 08, 2014, 06:48:38 PM
Thanks Dave

Merged mining slows down anything on BTC side?

Which cons are must for merged mining when running BTC node?

Also eligius says and i can see from payouts that my daily payout is 0.12213 BTC per day.

Your approximate maximum potential earnings at the current network difficulty of 11,756,551,916.90 and maintaining your 3-hour average hash rate of 2,855.07 Gh/s is 0.12213214 BTC per day.

P2Pool says that my payout if a block is found is about 0.11 BTC.
So far 3 days I would have gotten payouts with Eligius of 0.36 BTC.
But with P2Pool I have 0. You saying that something within the week I should get about 4 blocks to compensate statistically for the loss?
Or as long as there is no payout from P2Pool the payout amount is increasing?

Merged mining slows down anything on BTC side?
Not if the server has enough RAM / CPU speed / Drive Speed. At the smaller node level it's not a lot of extra power, as you get to the larger levels it can jump quickly.
 Once again simple numbers 1TH = X amount of computing power, 10TH = 2 times X computing power, 50TH = 5 times X computing power, 100TH = 70 times X computing power. Somewhere along the line you have to go to separate stratum server, and DB server, wallet server, etc.  Once again, these are made up numbers to illustrate the point.

Which cons are must for merged mining when running BTC node?

If you mean which coins then:
It's an opinion question. Some people think that anything but NMC is a waste, others think mine everything if you have the computing power after all money is money.

If you mean what are the cons, then the more processes running on your server makes for more things to screw up, which could put you off line and not mining till you fix it...

But with P2Pool I have 0. You saying that something within the week I should get about 4 blocks to compensate statistically for the loss?

In *theory* yes. In reality luck can be good or bad for weeks / months at a time. And with the difficulty increasing every 2 weeks or so a long dry spell might take a while to catch up. P2Pool should be finding a block about once a day using my back of the napkin numbers at 550 TH. From 10:45 AM on June 3rd to 7:30 AM on the 5th the pool found 5 blocks, with 3 of them being on the 4th. And none since the 5th. Luck can be like that.

Or as long as there is no payout from P2Pool the payout amount is increasing?
Nope, what you get paid per block is what you get paid per block, there is no "bank"

-Dave
7582  Bitcoin / Pools / Re: [460 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: June 08, 2014, 04:44:31 PM

Using simple numbers
2 Pools
1 has 1 miner with 10 TH
1 has 10 miners with 10 TH each for a total of 100 TH

The faster pool will find 10x as many blocks as the slower one. BUT when the slower one finds a block that 1 miner gets the full amount with the faster pool each miner gets 1/10 of the amount. In the end you do wind up with the same amount.

And yes, the old work gets chucked in the trash.

-Dave

Thanks Dave,

so if I understand correctly it doesn't really matter where you mine. Based on chances you will anyway get the same amount of BTC any pool you mine (maybe with a 10% luck difference) if you mine for a year.
So what about solo mining then? I have 2.8TH/s so my chance is that I find a block in 208 days. Even if I do find it in 1 year it is much more than mining in a pool.

So that's question #1.

Which bring me to question #2:
So for 3 days no blocks have been found with p2pool. If I stop mining today in p2pool I will get payment for 1 block only? Or will I get payment from next blocks as well even though I'm not in to compensate for the "loss" ?

This is a vast oversimplification of it but you get paid on shares of work submitted. These are rolling shares that are good for a period of time. So using the simple numbers that I like. If you submit 10 shares an hour over 10 hours you will have 100 shares. If the rolling period of time is 10 hours and you keep up the 10 per hour you will always have 100 shares in the pool. So if a block if found at 1:00 and then again at 1:01 and another at 1:02 you will have 100 shares in each block. And get paid accordingly. Now, if you stop mining at 2:00 then by 3:00 you will only have 90 shares by 4:00 you will have 80. If a block is then found at 4:00 you will get paid on 70 shares. If a block is found at 11:59 you get nothing.

Now along that same note if we are in a dry spell like now and with my simple numbers your shares fall off after 10 hours then whatever you did 11 hours ago does not matter.

Let me state again, this is an oversimplification but should give you a good idea of how it works.


Now as to the which pool you use, for the most part in the long run yes they all will give you about the same payout. However, there are other factors.

Some pools charge a fee some don't, some are closer to you and will give you slightly fewer stales shares then others, some will merge mine coins and give them to you. Some will merge mine coins and pocket them, never tell you making them money. Some pool operators are friendly and help out others are egotistical a--holes who think they know better then everyone and you just want to slap them upside the head. Also, when mining at a pool that is not p2pool node you have to trust the operators not to run off with your BTC, with P2 they can't. Although they still can merge mine and not tell you about it.

-Dave
7583  Bitcoin / Pools / Re: [460 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: June 07, 2014, 10:48:05 PM
I installed p2pool 2 days ago and still no payment.
I see the past two days no block has been found.
I assume today or tomorrow 1 or 2 blocks will be found and get payouts.

Which brings me to the next question.
How many blocks is p2pool is trying to discover at the same time?
No blocks found for 2 days, 8 hours, 37 minutes and 54 seconds as of me writing this.  Expected time to block is 23 hours, 19 minutes, 42 seconds.

It's variance.  On 6/3, p2pool found 4 blocks in 24 hours.

Pretty sure the answer to how many blocks at the same time is exactly like the answer for every other pool: the latest one.

Thanks for your answer.

Just to clarify how mining works among competitive pools.
So if P2Pool has 500 TH/s and Eligius has 6500 TH/s how can any "smaller" pool (e.g. P2Pool) be competitive?

Eligius in this example has more chances to to find the block as it has more TH/s.

What happens to the work that the P2Pool has done on this block as well as the work done from other pools? Just goes to trash?

Just trying to figure out with simple words/example how pool mining works...


Using simple numbers
2 Pools
1 has 1 miner with 10 TH
1 has 10 miners with 10 TH each for a total of 100 TH

The faster pool will find 10x as many blocks as the slower one. BUT when the slower one finds a block that 1 miner gets the full amount with the faster pool each miner gets 1/10 of the amount. In the end you do wind up with the same amount.

And yes, the old work gets chucked in the trash.

-Dave
7584  Bitcoin / Pools / Re: *** GHash.IO mining pool official page *** on: June 07, 2014, 10:12:32 PM

As far as I can tell US1 is not a real stratum, it's just a proxy.

And I think that's why there are issues with it.
Plus on http://www.liveipmap.com/home it comes up as the Netherlands. I doubt they really have any US servers at all. Just misrepresentation.

Running a traceroute from my laptop on a Verizon circuit to 46.229.169.89 (us1.) the next to last hop is a cogent router in the US as far as I can tell (38.122.62.114).

You don't have to have IP space from RIPE in their region. I have some clients with LANIC IP space in my data center in NY.

-Dave
7585  Bitcoin / Pools / Re: [460 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: June 07, 2014, 08:13:35 PM
If some of you have some spare hash power could you point some to a small node I just setup for testing. (0% fee)

http://75.127.136.68:9332

PLEASE PLEASE PLEASE have a failover set as I am still working and learning and I don't want to cost you any BTC.

I want to do more with it over the next few weeks but for now I just want to make sure what I did so far works.

Thanks,
Dave
7586  Bitcoin / Pools / Re: [6600Th] Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB (New Thread) on: May 28, 2014, 10:55:35 PM
Working on some server shuffling right now actually... and ended up triggering a failsafe and subsequent database catch up. Sorry guys. Sad

On a side note, the new NMC code should be done tonight if all goes well.

As always, shares are always tallied so, no worries.

https://www.youtube.com/watch?feature=player_detailpage&v=s_Whz9yapTc#t=72

-Dave
7587  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]LOVEcoin – POW+POS | 5 Exchanges | Games | On Multipool on: May 18, 2014, 12:36:38 AM
am I the only 1 mining this?!?


There aren't too many people doing it, that's for sure.

But I appreciate the effort, keep on going.

In the new version (to be announced on Monday)
the proof-of-work era will end at block 22068,
about a week from now.



That's an strange number, what not 22000 or 22500?
-Dave
7588  Economy / Computer hardware / Re: [WTB} Old but working block erupter on: May 10, 2014, 08:00:34 PM
for some reason, the shipping to me costs +40$ when I buy it on ebay. I'll keep looking, otherwise cannachris I'll take up on your offer  Smiley

Where are you located?
-Dave
7589  Alternate cryptocurrencies / Mining (Altcoins) / Re: [AUTO SWITCH] ScryptGuild (BTC Guild) Beta on: May 10, 2014, 04:04:46 PM
Any news on when the change over is going to happen?

It's been pushed back a little bit due to illness.  It will be announced clearly on the website when it happens.

Feel better dude.
-Dave
7590  Bitcoin / Pools / Re: [8500 TH] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers on: May 07, 2014, 06:55:28 PM
Meanwhile, a smaller pool in that same time frame may be much lower, or much higher than neutral.


Which sometimes is part of the "fun" EMC had a block that took 1 day 13 hrs that solved yesterday. Since then 6 in about 18 hours.

-Dave
7591  Bitcoin / Pools / Re: [8500 TH] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers on: May 07, 2014, 03:01:34 PM
If you look at the ghash #'s over the last day they have had three 2+ hour times w/o a block and seven 1+ hour times w/o a block. Since they have about 3x the hashing power as BTC Guild that would that be the same as three 6+ hour blocks here and seven 3+ hour blocks?

-Dave
7592  Bitcoin / Pools / Re: [8500 TH] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers on: May 07, 2014, 12:15:37 AM
<snip>
Hardware is possible, but doesn't quite make sense given how barebones a mining ASIC *should* be.
<snip>

https://twitter.com/ID_AA_Carmack/status/128988479114854401

-Dave
7593  Bitcoin / Pools / Re: [8500 TH] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers on: May 06, 2014, 10:57:01 PM
Well, if we want to entertain the idea of faulty hardware having some bearing on the overall results, we need to identify recent release's. I follow a number of the Antminer threads and see a significant number of miners struggling to keep the S2's up and running. Also see a significant number of S2 miners posting screen shots with concerns over large numbers of Hardware Errors and Rejects. Some one will do a little math and say...Mheee...that's not too bad. My point though is that is 1TH/s equipment and those rejects and errors accumulated in 2-3hrs exceed my accepts for a given time period. AND knock-off miners with slightly less advertised total hash speed from Bit-Mine seem to have a slightly higher error rate/hour as well. Just seems too me like these units are a bit off, maybe they are putting out some bad vibe static.......

If the problem is related to the difficulty going above the limits of a 32-bit variable, it may not have anything to do with *recent* hardware releases.  It could be OLD hardware.  It would likely be firmware or software in the controller for the hardware.  (See edit for more info).

This would explain why these accounts were not noted the last time I did a pass.  I was looking for active withholding previously.  Accounts with significantly low block submissions vs shares submitted.  Last night's pass was specifically targetting shares vs blocks over the last 6 weeks, eliminating the chance of past luck making up for recent shortfalls.


EDIT/CLARIFICATION: The hardware itself has no reason to actually know the result of its hashing outside of diff>=1 (or >=1024 in some newer hardware I believe).  It's probably not in the software since *most* ASICs do not use custom software, they use cgminer or bfgminer.  So the point in the middle that handles communication between the hardware and the software is the most likely culprit.

There have been many issues with chips though the years. Both ASICs and regular processors.
The Intel FDIV bug to the huge errata lists on some RISC processors tend to be more impressive then ASICs, but that is because they are more in the public eye. Do you think that the get it out as fast as you can hardware that we are using is *really* that well tested....

-Dave

Still love this error list from the old days (the 5th one down is my favorite) you could blow your hardware with bad code:

The Amstrad Plus ASIC improved a lot of the old CPC's capability. Yet this was a bit flawed.

    Despite removing some tasks from the CPU (Z80), ASIC registers are mapped onto memory from #4000 to #7FFF range prior to other type of memory (RAM or ROM).That means this memory range is not accessible when ASIC registers are paged.

    PPI emulation is not correct as the original 8255 does not need validation.On ASIC emulation , this validation is needed so some programs written for "old CPCs" will not be able to get keyboard state.

    Z80 IM2 mode is bugged.In this mode , the Z80 I register gives the high word for vector table.ASIC gives the low word from IVR and the devices that generate interrupt (raster and DMAs channels).ASIC generates sometimes a bad values and the raster interrupt routine is called instead of DMA0 routine.The reasons of this bug are not known.

    There is a conflict between programmable interrupts and some CRTC settings (line screen split).That will cause the RAM refresh to stop and the memory content will be quickly corrupted causing machine crash.

    Reducing Horizontal BLanking could cause another internal conflict when using DMA lists.In the worst case , this conflict can cause irreversible damage to the ASIC.

    Original CPC colors emulation is not correct.
7594  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]LOVEcoin – POW+POS | 5 Exchanges | Games | On Multipool on: April 28, 2014, 09:47:34 PM
I found this in kernel.cpp, line 21

Quote
// Hard checkpoints of stake modifiers to ensure they are deterministic
static std::map<int, unsigned int> mapStakeModifierCheckpoints =
    boost::assign::map_list_of
    (     0, 0xfd11f4e7u )
    ( 10001, 0xd42268a1u )
    ( 30001, 0x7e0d6e1eu )
    ( 50001, 0xa5a4473eu )
    ( 70001, 0xbe5e3360u )
    (100001, 0x6cafeba8u )
    (133333, 0x011868fcu )
;

Those are PoS checkpoints that shouldn't be there.
The first number is block height, the second one modifier checksum.

My guess is that whenever someone tries to generate block 10001, it doesn't get accepted since
the checksum is different from the hardcoded checkpoint  ( 10001, 0xd42268a1u )

To verify if my guess is correct, someone who has been mining could look into his debug.log and
see if there's anything like

Quote
AddToBlockIndex() : Rejected by stake modifier checkpoint height=10001
 

ERROR: AddToBlockIndex() : Rejected by stake modifier checkpoint height=10001, modifier=0x756f6ca000813145
ERROR: AcceptBlock() : AddToBlockIndex failed
ERROR: ProcessBlock() : AcceptBlock FAILED
ERROR: BitcoinMiner : ProcessBlock, block not accepted


7595  Bitcoin / Pools / Re: [6600Th] Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB (New Thread) on: April 28, 2014, 03:36:47 PM
I might make an appearance the next time a conference is in Vegas, assuming some of the core devs are there.  I just don't want to go through the hassle of a modern day US airport.

Then fly through LGA in New York. It's more 3rd world airport then modern day airport.

http://www.travelandleisure.com/articles/americas-worst-airports-2013/3

I live here and have to use it a lot. Walking is starting to look like a better option.

-Dave
7596  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: April 26, 2014, 11:26:50 PM
I have had the same issue the last 2 days as well. Same ip as above, a restart of my ants or cgminer/bfgminer cures it. My miners are in 3 different locations, running differnet software and on different ips all using unique Worker names. Antminer S1, BFL LS, BFL Jala and Red Fury's.
Out of curiosity, do you have Teamviewer installed?

I'm a bit more active on this on the Eligius thread, but I don't have TeamViewer installed.

-Dave
7597  Bitcoin / Pools / Re: [6600Th] Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB (New Thread) on: April 26, 2014, 10:18:48 PM
I spent the better part of the day investigating this issue.

  • It's not a pool side hack - No pool servers are or were compromised
  • It's not a pool-side close network hack - No datacenter infrastructure is compromised
  • It only affects certain clients, is not pool wide, and affects affected clients repeatedly

Presumably there is some issue with some client side routing hardware that is being exploited.  Anyone effected, please post how your connected to the net.  PC->Router->Cable Modem, etc, with makes/models of such so we can possibly narrow this down.

#1
2 S1's behind an old linksys running DD-WRT (V24-sp2)
Our own IP space (Juniper running BGP)


#2
1 S1 running behind a TRENDnet TW100-BRV214
However a few Technobits running on a TL-MR3020 pointing to BTC were not hit
On cable


#3
S1 and a generic Avalon behind a ZuniConnect router pointing to GHash were hit.
On cable.

-Dave
7598  Bitcoin / Pools / Re: [6600Th] Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB (New Thread) on: April 26, 2014, 10:07:48 PM
As a miner side fix you can block that IP on your firewall (ideally at the router but even the windows firewall should work for some types of miners).  If your miner gets redirected it should be unable to connect to the pirate pool and then switch to whatever you have configured for a failover.

Holy crap, that's so obvious I can't believe I didn't think of that.

You would not believe the route I was going to stop this from happening.

-Dave
7599  Bitcoin / Pools / Re: [6600Th] Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB (New Thread) on: April 26, 2014, 06:45:54 PM
This jumping to 46.28.205.80 happens on ghash too... And every time at same time... So it might be something automatic...

17 rigs, 3 locations

What software were you using to connect?

-Dave
7600  Bitcoin / Pools / Re: [6600Th] Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB (New Thread) on: April 26, 2014, 05:28:52 PM
And I just noticed the share difficulty on the ant was set to 1K.

Has anyone else noticed this?

-Dave
Sounds like you're MITM'd...

I *knew* that, just trying to post more info. If it's a 1K share difficulty it's not like they are getting any work out of it. AND also that it was on ghash not just yours as Mr.Teal (slush) mentioned so it's a few more data points.

-Dave
Pages: « 1 ... 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 [380] 381 382 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!