|
All updates/restarts complete, block on.
|
|
|
|
Well stated. However, I have observed the dropping of entire hashing boards or the temporary failure of a string of chips from my S7LN miners while mining on p2pool WITHOUT a manually specified difficulty. The issue would occur when p2pool changed difficulty both rapidly and frequently. The issues were temporarily resolved by cycling the power and completely resolved by using the "+2048" option.
With regard to notabeliever's specific problem, I would say that there must be some other issue at play. The A721 should have easily found a share during the time frame specified. I personally was finding many shares with only 2x S7LN. I would bet that either the payout address was incorrect or the node was collecting a 100% fee.
It's well known that the extra block changes happening effectively every 30 seconds on the p2pool chain unlike bitcoin at 10 minutes leads to more fluctuations in effective hashrate on most hardware and unfortunately the avalon2+ designs do stratum on the inbuilt fpga on the devices because they were designed to be bundled with extremely low power Rpis that aren't up to generating the amount of work these devices hash at the software level. Moving stratum to the fpga means the change takes longer and is a little more prone to misbehaviour as a result. I'm not saying the antminers are much better as they have their own crazy design issues but either way p2pool work is more tricky for hardware to manage than the regular block chain. Newer hardware at least doesn't cut the power on changing blocks till there was new work the way old hardware does; the more the power levels were fluctuating to the chips, the more prone they were to failure. |
|
|
|
Do you care to argue the facts above?
No I think I'm quite done here, thanks. |
|
|
|
Yes. Anyone who wants to be a central element of a multibillion dollar system is going to have to buck up for the requisite (and rather trivially-valued, in the scope of things) hardware to do so.
Bitcoin's dirty little secret is that non-mining nodes provide zero benefit to the network at large. Sure, operating a node allows that particular node operator to transact directly on the chain, so provides value to that person or persons. But it provides zero utility to the network itself. Miners can always route around the nodes that do not accept their transactions. Miners don't care whether non-mining nodes accept their blocks - only whether other miners will build atop their blocks.
And the number will not be ten - it will be many more. As again, anyone who wants to be able to transact directly upon the chain in a trustless manner will need to buck up to the hardware demands.
Thanks. If anyone wants to know what BU'ers think of what the system is and should be, I think I can now refer them to your post. I rest my case. |
|
|
|
Maybe its the nature of p2pool's but what bothers me is the strain on my avalon A721 getting push to excessively high difficulties where it starts to under perform.
The flip side of that is when I set my own difficulty to 4096 I can't find any shares and on several occasions have missed 4 rewards from blocks because my miner was unable to find just 1 share.
Are their any nodes that have controlled the pool difficulty as when I mine on other types of pools my miner chuggs along nicely.
So what would be the recommended difficulty to use.
The mining difficulty doesn't affect the avalon at all; it does not cause extra strain and it doesn't change your chance of finding a share. The mining difficulty is purely cosmetic in the case of p2pool and won't affect your chance at getting a reward. The only reason you're not finding a share at all for some blocks is the intrinsic design of p2pool - when the hashrate gets higher, smaller miners get lesser and lesser chance of finding a share per block. It's an unfortunate side effect of the design that it increases variance as the number of miners increases. |
|
|
|
Miners employing parallel validation do not fall victim to extended time validating blocks containing aberrant large quadratic hashing time transactions. Instead, they orphan such blocks. By continuing to mine and validate on other threads while the validation of the aberrant quadratic hashing time block runs on one other thread. Miners who continue to make blocks with such transactions will eventually bankrupt themselves. All without doing any damage to the network. Problem solved.
What implementation includes parallel validation? Oh yeah... BU does.
Given the massive amounts of ram required by ultra large transactions that are heavy in sigops that would be prone the quadratic scaling laws, validating yet another block in parallel is an excellent way of using even more ram. High ram servers with 256GB may be able to cope temporarily with it but normal machines and even normal servers will likely run out of memory and kill bitcoind. Which implementation has had out of memory issues already? Oh yeah... BU did. You don't think the significant mining pools can afford one large server each? And that's your solution? Have only 10 nodes that can stay online worldwide during that parallel validation period and crash the remaining 6000+ nodes worldwide at the same time? |
|
|
|
She can take plenty more Cap'n... some time around now would be a nice time to hit this! look at those fees  Yeah, wow. Good thing I don't need to send BTC anyplace right now. Unconfirmed Txs 137,503 Size 111,703,831 - 111.70 MB Yeah well I'd love to do my part by solving some blocks and mining some transactions for the short term and helping activate segwit for a longer term solution... |
|
|
|
Share difficulty is adjusted too low. Theres no advantage if shares get old before block is found.. Like if now expected time to block is 10 days and shares ttl is 2 days :/ It should be much more difficult to find a share and maybe the share could be calculated to live at least 2 blocks time. So share would be valid for 20 days... Keeping easy to find shares is stupid and prevents big miners as well as small miners to get decent payout.. Min share difficulty is now 1234113 an it should be at least 30x that.. Every share counts but not pays..
I suggest making share life a function of current network difficulty rather than time. |
|
|
|
Miners employing parallel validation do not fall victim to extended time validating blocks containing aberrant large quadratic hashing time transactions. Instead, they orphan such blocks. By continuing to mine and validate on other threads while the validation of the aberrant quadratic hashing time block runs on one other thread. Miners who continue to make blocks with such transactions will eventually bankrupt themselves. All without doing any damage to the network. Problem solved.
What implementation includes parallel validation? Oh yeah... BU does.
Given the massive amounts of ram required by ultra large transactions that are heavy in sigops that would be prone the quadratic scaling laws, validating yet another block in parallel is an excellent way of using even more ram. High ram servers with 256GB may be able to cope temporarily with it but normal machines and even normal servers will likely run out of memory and kill bitcoind. Which implementation has had out of memory issues already? Oh yeah... BU did. |
|
|
|
Yes it's temporary. The same number of pools are still mining BU blocks and this is normal day to day variance. The BU and segwit support levels in mining have remained unchanged for weeks now. You're kinda wrong, another pool has added SegWit support, they show as Unknown. No I'm kinda right. There has been support from an unknown for a very long time. |
|
|
|
Yes it's temporary. The same number of pools are still mining BU blocks and this is normal day to day variance. The BU and segwit support levels in mining have remained unchanged for weeks now. |
|
|
|
So if the mining network was ever decimated by an catastrophic attack no one would ever be able to mine a block again; because no one would be able to mine a block (unless they had a huge amount of hardware) in 2 hours. I mean like if 90% of hardware was bricked and all the mining pools were knocked offline. It would be really hard to restart the network with the difficultly set so freaking high. The time limit would not help matters is what I'm saying.
No I believe it's the time stamp on the block relative to what nodes think the current real time is. |
|
|
|
I have some rental hash on the pool for the new 8 hours or so, there are some hash hogs on NH so I'm only doing 250TH. Better than nothing  Every bit of HERP makes us more likely to DERP. |
|
|
|
|
Restart all complete. Mine on and let's bust this one.
For those curious about the mention of a DE server, it is not a full server, only a passthrough so unless your ping time is at least 70ms less than the main pool I do not recommend using it. I'm still trying to gauge whether it's worth keeping or not.
Use one of:
depool.ckpool.org:3333
depool.ckpool.org:433
|
|
|
|
depool is shown DEAD for me. Ping works by 56 ms. Anybody else with this?
I took it down along with the post because I didn't think anyone was using it, but I can easily bring it back up. Your ping time has to be dramatically better to de to warrant using it. |
|
|
|
Another block for the pool. Is anyone getting paid? I don't mine here, just curious.
This pool no longer appears to be doing generation payouts so all the block rewards are going to the one address meaning no one is paid until the payments are processed from there. Three blocks solved without a payout is enough to raise eyebrows. |
|
|
|
This is an element of centralisation when pools can dictate their own rules... Thus dictate was relevant to pools.
Explain why it would be "extremely unpopular move and suicide for a cryptocurrency"?, when a miner producing an empty block when there is outstanding txs is stupid enough itself.
I don't disagree that pools producing empty blocks is stupid; heck I'm one of the BIGGEST campaigners against doing so in the mining world. As for why developers cant mandate what goes into a block through network rules via a hard fork, bitcoin is an open transaction system and any attempt to strictly specify which transactions must go into a block in the reference core implementation would be futile. Not only does every node have a different mempool consisting of different transactions (it's impossible to sync all nodes to the same set of transactions in time and space), but enforcing certain transactions is actually creating a system with an unintentional censoring, prioritising and filtering of transactions in the world. The current system works off transaction fees as the incentive to choose transactions based on the reward making them more worth mining and indirectly creates a type of consensus without mandating order. Either way, the fact that no 2 mempools will be alike means it would be impossible to mandate anything anyway. Even empty blocks, as much as it pains me to say, must be allowed since theoretically there is a time and place where there are no transactions (though unlikely in bitcoin I agree) but additionally when a bitcoin node is restarted it has no transactions until they're gathered from the network or some are loaded from disk (in 0.14+). Even the ones loaded from disk may be all old and no longer mineable if enough blocks have passed since the node was restarted. I didn't say 'which' but any validated txs. As long there are txs in the mempool, then the block should fill up until there is no txs in the mempool or block is over 95% full, for example. Empty blocks when there are no txs is fine but when there are thousands of txs waiting to be confirmed is madness. Isn't that what the miners are already doing ?I agree they SHOULD but as I said there is no way to reliably make it so they MUST. Of course miners are choosing what goes into a block - that's precisely what mining is; mining transactions into the blockchain. You can't mine only "verified" transactions because the process of mining IS the verification. |
|
|
|
This is an element of centralisation when pools can dictate their own rules... Thus dictate was relevant to pools.
Explain why it would be "extremely unpopular move and suicide for a cryptocurrency"?, when a miner producing an empty block when there is outstanding txs is stupid enough itself.
I don't disagree that pools producing empty blocks is stupid; heck I'm one of the BIGGEST campaigners against doing so in the mining world. As for why developers cant mandate what goes into a block through network rules via a hard fork, bitcoin is an open transaction system and any attempt to strictly specify which transactions must go into a block in the reference core implementation would be futile. Not only does every node have a different mempool consisting of different transactions (it's impossible to sync all nodes to the same set of transactions in time and space), but enforcing certain transactions is actually creating a system with an unintentional censoring, prioritising and filtering of transactions in the world. The current system works off transaction fees as the incentive to choose transactions based on the reward making them more worth mining and indirectly creates a type of consensus without mandating order. Either way, the fact that no 2 mempools will be alike means it would be impossible to mandate anything anyway. Even empty blocks, as much as it pains me to say, must be allowed since theoretically there is a time and place where there are no transactions (though unlikely in bitcoin I agree) but additionally when a bitcoin node is restarted it has no transactions until they're gathered from the network or some are loaded from disk (in 0.14+). Even the ones loaded from disk may be all old and no longer mineable if enough blocks have passed since the node was restarted. |
|
|
|
|
Show Posts
