deepbit op thinks we are evil and is working hard to get rid of usI really dont get this mindset of theft, everyone gets paid exactly for the shares they submit. For one, most people hopped onto bitcoin because it was profitable and most would leave when it isnt. WE just do that same at the pool level. Most of them hopper haters would have no problem hopping onto a rival currency when it becomes more profitable. But somehow they seem to want to think that pool hopping is different and like to call us names.. the pols even said us hoppers were akin to murderers You have seen the jars of jellybeans where they want you to guess how many are in there. Most people just make a random guess.. some wiser people buy a jar and some jellybeans and try to find out how many it holds. It isnt cheating, he didnt break into the real jar and count the jellybeans, he is just trying to maximise his chances of winning. Oh i get why they dont like it.. they are lazy and they dont like seeing others make more money than them.. yeah yeah yeah their shares are worth less on the short blocks and a tad bit more on the long blocks and they want it the other way arround. But the thing is.,. IF WE STAYED and did not hop.. their shares on the short blocks would be the same.. but their shares on the long blocks would be even less.. eh sorry for the rant, i know their is a thread for this.. I dont see why deepbit cares, we are such a small percent of their total hash, that we really dont effect their users much at all. ANything perceieved is most likely due to luck and not hoppers. You seem to be the best at these self-denial diatribes, perhaps arguing with yourself to justify your unethical behaviour in pool hopping. Think of it this way: Imagine there is a bakery that leaves day-old loaves of bread out for the homeless at closing time, and then you start coming by and take all the bread every day. Others in need get none. Then after complaints, the bakery decides to put out the bread at random times so one person doesn't take them all, so then you have someone watch the bakery all the time and still come get the bread when they put it out. Then the bakery stops putting out the bread and makes the homeless come in and ask for their fair share, it seems then you would rant about how the bakery is unethical, you would never shop there, etc. The bakery doesn't want you anyway, you contribute nothing, your complaints are unheard. Or: The convenience store has a take-a-penny, leave-a-penny tray. You come in three times a day and take all the pennies from the tray. You go around to all the convenience stores and do this. Eventually they put the pennies behind the counter so only the clerk can grab some pennies for you to make nice change. To counter this, you plan your purchases to always need pennies, so you can get the clerk to add pennies to your purchase. Eventually they quit, and nobody has the convenience anymore. This is what you are doing to bitcoin and pools. The goal of pools is not directly to "solve blocks", and saying that pool hoppers "help solve blocks" is a straw-man argument. A pool is there for bitcoin miners to pool their resources to reduce variability and get more regular payments. Miners do not pool mine to make more or less money, they pool mine to make the same expected amount, but not have to wait months for a payout. Having a bunch of opportunists jump on and saying we "help solve blocks" is merely a convenient and fallacious excuse for stealing the early shares in pool rounds that are compensated more because of the chance of a short round happening, in an otherwise fair payment system for full-time miners. You think your work should be paid more than everybody else's? You think everyone else's earnings should be decreased because the short rounds (that should compensate full-time miners for the long ones they suffer) are exploited? It is fair to hit the bandwidth of a dozen pool's web pages every minute and open a bunch of TCP sockets, causing pool ops to need hardware upgrades and spend time with mitigation measures? You think pools want more variability - shorter short rounds and longer long rounds? That is an antisocial narcissistic notion. Pool hoppers do decrease the earnings of everyone else in pools, and on bitcoin as a whole. Hoppers aren't adding more hashrate to bitcoin, they are just strategically moving around their share submissions to be compensated more for the same amount of work, more than others. This leaves less earnings for others on a pool, and less earnings for all bitcoin users. Legitimate pool miners have less time to submit shares in short rounds, and then they have to split those earnings with more people. It is game on, pools that still prefer the proportional payment method should do whatever in their power makes their pool mining experience a positive one, including not having egocentrists degrade a fair rewards system and network stability. |
|
|
|
What is to stop a PPLNS pool operator from cashing in a winning block silently once in a while and keeping the reward for themselves. I don't mean to cast doubt on the trustworthyness of Wuked at all; I'm sure no such scam is taking place. Is there some kind of mechanism in place which makes it impossible for the pool operator to keep the odd block for themselves and if so how does it work?
Any pool system besides PPS requires trust in the pool operator, regardless of the payment system used. A pool admin could withhold a winning block payment, or be contributing fake shares into the system so they get paid for work they didn't do. There doesn't seem to be a good way to hold a pool op accountable if you can't know from the outside when a pool has solved a block or verify that all contributed shares are from real miners. With PPS there are typically high fees, since the pool operator is paying for mining in advance of block solves, takes a risk that there may be a long period of bad luck where he still has to pay miners, and also a PPS pool can be attacked by withholding - bad miners not submitting a winning share if found. |
|
|
|
<luke-jr> Graet: Catholics do not believe in freedom of religion.
wow Every religion demands absolute belief that their dogma is the correct one, and punishes doubt. Allowing doubt opens the gateway to thoughtful analysis and logic. Analysis such as "if I was born in a different country with different parents and a different color skin, would I believe just as deeply in the religion I was taught there since my birth?" |
|
|
|
# Your Shares:
Total this block: 17100
Eligible for Reward: 17109
# Your Reward: 0.23924596 BTC How comes my shares are now so high? I was used to 4-5K shares eligible for reward... is something changed? spiccioli. The pool uses Pay-Per-Last-N-Shares, where your reward if a block is found is computed by how many recent shares you contributed in the period it took the whole pool to contribute (difficulty/2) shares. If the total pool hashrate decreases, you are able to submit a higher percentage of shares in the N shares window, and your reward is higher when a block is found. We of course prefer the more regular payouts that come with a higher hashrate, but your expected reward over time is the same whether the pool has a high or low total hashrate. BTW, there is no penalty for jumping on in the middle of a long round on a PPLNS pool (and also no logical reason to leave on a long round either). The work you submit now determines your earnings on future block finds (the past luck does not matter), so mine away! Is there a plan to include a way to donate a percentage of my gains to the pool automatically?
I like that there is no option on the site shaming users into donating a fixed percentage. The donations address from the pool's web site is 1D3ro6Xb9XDvPFCytiNLdSLDHpWXZoA2kn if you want to send something. BTW, this is the highest earnings pool around - a fair unhoppable payment system, no fees, and pays miners the transaction fees earned per block solve in addition to the 50BTC. BTW, is Wuked on a legendary European vacation? He hasn't signed on to the forum since July 31 (although his sig shows he is still mining away...) |
|
|
|
Confirmed Rewards 29669.89232442
*walks away whistling*
So the post-mortem: -Miners were instantly klined from IRC, and can't bootstrap to get other clients to connect to, -Difficulty 20000 worth of miners try to use a difficulty 1 network with about 1000 block finds every second -miner -> pool latency is major fail and still can't keep up with new blocks every few seconds. Conclusion The p2p network becomes completely useless. The miner with the most hashrate on their local i0coind makes the longest blockchain independently. When there are finally enough connections and a high enough difficulty that everybody can start to get blocks from each other's blockchain forks, the longest blockchain wins - the person who could independently get 600 blocks ahead of everybody else by block 3500, and wipe out everybody else's balance when it was announced. The few miners with the fastest local hashrate can keep on adding generate wins to their own blockchain. Because of continued network fail they can get two transactions or more ahead of everybody without hitting the network, and the slow network with dozens of blocks a second just keeps toasting everybody else's block finds that are a block too late in their block find announce. 1ghash with 0 i0coins after 6 hours, kinda like i0=I got 0. Early adopter hate now replaced with mega miner hate. Kinda like this: However, an attack vector if you are a huge pool that is ready to go - jump on after modding the release client to also ignore any chains except ones with a block 1 you just made, you could cause everyone else's work and coins to be discarded by overwhelming the solo miners with consecutive block solves and growing a longer chain than theirs.
|
|
|
|
nmc@nmcpc:~/i0coin/daemon$ ./i0coind getdifficulty
4.00000000
past block 4032 on somebody's chain - difficulty 16 now |
|
|
|
I predict there are several blockchains all more than 120 blocks apart, bitcoin doesn't know how to 'orphan' block chains with so much difference, this will create a clusterfuck of seperate blockchains that cannot be reconciled. This was an abortion, it should have had difficulty 10000 to start.
no, this is great, i got a bunch of blocks You will lose them, I had 480 confirmed coinz go poof, and then 400 different blocks start downloading. |
|
|
|
|
I predict there are several blockchains all more than 120 blocks apart, bitcoin doesn't know how to 'orphan' block chains with so much difference, this will create a clusterfuck of seperate blockchains that cannot be reconciled. This was an abortion, it should have had difficulty 10000 to start.
|
|
|
|
I'm just watching because I was curious to see how the network/protocol would behave in this situation. It looks like from look at btcguild's block page, they believe they're finding ALL the blocks from their perspective. In periods where they're finding >50% of the blocks, they're effectively coming up with their own block chain where they're the winner to everything. When they don't manage to muscle out everyone else, they end up losing their whole forked chain. Is this right? Anyone with more experience with how the block collision scheme works could probably answer this better, but it's kinda interesting to watch the debug log showing the battles. The longest blockchain will eventually win, so if i0.btcguild has more hashrate than all the soloers and doesn't connect to everyone until later, they will grow a longer blockchain that will orphan all the solo miners generated coins, as previously detailed by me. |
|
|
|
|
Crap, I need some IP address to bootstrap, since it looks like I got the IRC k-line too and I'm dead in the water with 2 connections...
Post some IPs from the IRC channel or your firewall connection log please!
Or if you have more than 8 connections, upload your addr.dat file to mediafire.com (it has the ip addresses of other network clients) and share or pm please!
|
|
|
|
There's a mistake with the dates, right? May 7 is not two days after June 5 Hey, don't point out my mistakes, that takes all the wind out of my theory! I'd point out other wacky things, like how -> block 2016-> block 4032 was 5-29 to 8-5, but block 4032-> block 6048 was 08-05-> 08-08, before it was announced... |
|
|
|
Anyone with problems with Ozco? It doesnīt show me any "est.earnings" and i send about 800 shares!
Edit: wich one of these commands works better or are necessary with the "mine_deepbit" mode? or the three of those at the same time?
--startLP = Seeds the LP module with known pools.
This is now the default, it doesn't need to be specified at the command-line any more. --noLP = Turns off client side longpolling*
*i donīt understand what this one does..
I believe client-side means that Bithopper doesn't push LPs to your miner with this option, your miners would just request new work when their queue is empty, which would increase stale shares. --p2pLP = Starts up an IRC bot to validate LP based hopping
I would encourage people to set up pool worker accounts for at least a dozen pools and add them as 'info' before using this option, otherwise the information you will be sharing with others using the IRC LP info-sharing technique would be sub-optimal. |
|
|
|
Seeing as people are already mining and running clients for i0coin I assume you'll change the genesis block and redistribute the client. But what about all those that *don't* update the client because they mined a huge fuckload of i0coins_v0 already? Did you manage to create 2 forks in a single throw?  If miners stay with the released blockchain and client, there will be two blockchains bouncing around on the same network, one that doesn't accept the other's blocks as valid. You can't really make orphan chains out of the new client's blocks, since the new client will know to ignore chains with a different 0 block. However, an attack vector if you are a huge pool that is ready to go - jump on after modding the release client to also ignore any chains except ones with a block 1 you just made, you could cause everyone else's work and coins to be discarded by overwhelming the solo miners with consecutive block solves and growing a longer chain than theirs. |
|
|
|
I don't have sim figures for slice vs standard yet but if you work it out scheduling, number of pools and pool size choice affect efficiency and variance as follows: - Standard scheduling has better efficiency but higher variance than slice
- Larger pools have lower variance than smaller pools
- Larger number of hoppable pools available lead to higher efficiency.
So a couple of choices are: - Have lots of pools including the smaller ones and use slicing to reduce variance
- Only mine larger pools for better variance and use OldDefaultScheduler for best efficiency
Anyone else spot other tactics? "Standard scheduling has better efficiency but higher variance than slice" - I think that's a misguided assumption there. You are already greatly reducing your variance by spreading your love over many different pools. Even a 100Ghash pool is going to be solving a block in less than 24 hours on average; five that size, and you are averaging 5 smaller-payout blocks a day vs. one pool's variance. Add in hopping a "top five" pool and your daily payments are clockwork. The old scheduler wants to submit the same percentage of shares to every pool, and the same number of shares to every pool round. Decreasing variance at the cost of mining efficiency shouldn't enter into any consideration you make. Instantaneous share value quickly drops from 13x to 1x within difficulty N/.43 shares, and a +28% per pool return estimate only happens when you start mining right at new round start. A pool has a five minute round, and now you've only put in half as many shares as you could have by sub-optimal slicing. If there was a time-slicing option to be made at the expense of profitability (which, only as a side effect, would reduce variance), it would be to spread random shares around to all the pools you are checking for stats and LP pushes when no pool is <N/.43, to justify your bandwidth and avoid being profiled as an exploitative hopper. |
|
|
|
|
Announcement - Ponzi-scheme crypto-currency - Pyramid-Coin: ΔCoin!
-Minimum/genesis difficulty is .001,
-Difficulty resets every 25,000 blocks (next difficulty predicted to be 100),
-After 100,000 blocks the number generated drops to 0,
-Mining Reward 50 ΔCoin per block,
-Worth 1BTC each (that is what I've been trading them for with myself),
-Completely useless!
Oh, BTW, I already mined 1/4 of them yesterday...get in early!
|
|
|
|
|
The mining details are - he wants to get people to mine IOCoins for him when it is released. I would get the BTC in full first.
|
|
|
|
I did some in-depth analysis of Bithopper Long-Poll timing method for identifying block-solving pools, initially to see how pool-delay corrections can be used to make round-finding results more accurate, I used the console log output of BH, which after some grepping, looks like this: (round 141030 - found by deepbit) [1295][23:39:34] LP Call mining.mainframe.nl:8343/LP
[1326][23:39:35] LP Call pit.deepbit.net:8332/listenChannel
[1333][23:39:35] LP Call mineco.in:3000/LP
[1334][23:39:35] LP Call eu1.triplemining.com:8344/LP
[1341][23:39:36] LP Call arsbitcoin.com:8344/LP
[1344][23:39:37] LP Call uscentral.btcguild.com:8332/LP
[1355][23:39:38] LP Call pool.bitclockers.com:8332/LP
[1356][23:39:38] LP Call pool.bitp.it:8334/longpoll
[1358][23:39:39] LP Call bitcoins.lc:8080/LP
[1392][23:39:42] LP Call su.mining.eligius.st:8337/LP We see above, the first pool to respond is NOT the finding pool! I have workers logging into 16 different pools; however only 11 of those reply with new block LP pushes. Current Bithopper logic simply guesses that the first LP is the finding pool; as we can see in above, the first LP was not from deepbit in this case. As I had seen this behavior before, I requested the addition of an lp_penalty option - a per-pool option in Bithopper, where you can "delay" the LP reponse time on fast-reporting pools. Now, we must classify what that delay should be. I used the LP timestamps from the console log as shown above. I was originally expecting the finding pool to clearly stand out, with a definitive earlier LP push after correction, but even this turned out not to be the case, so I should have modded the output to be tenths of seconds for better analysis before I started.. Here is 11 rounds of data, with the actual finding pool verified with digbtc.com and pident.artefact2.com. The block delays for each pool and each round are normalized against the time of the finding pool, if present:  The time-delay table is the top, different analyses are in blue, and the actual correction I am using is on is on the far right. Note the lp_penalty setting would be the opposite of this correction - eligius might get lp_penalty:0 and mineco: 4. The bottom table is the time delays after applying the best correction I could hand-tweak. We see that still the finding pool almost never is the fastest (highlighted in red). (This might improve with 1/10th second stats resolution). However, we see that if we average all pool LPs after learning a delay correction, the finding pool does begin to stand out. The conclusions I have to make:-Per-pool LP delays are more random than one might expect; and some pools have more variation than others (likely related to number of miners, and their p2p distance from block-solving pool) -Deepbit's block-find LPs do not clearly stand out from other non-finding LPs received from deepbit, -The first reporting pool, even when testing many delay correction formulas, will not necessarily be the finding pool. -Only with a time delay correction for each pool, and then comparison of each pool to the average of all pools can we hope to reliably identify the stand-out block-finding pool. We also need a confidence factor, so if no pools stand out, we can conclude none of LP-returning pools we check found the block. We have also seen --p2pLP come to prominence, where LP block-finding information is shared on IRC, and then a vote helps further refine results. However this still is very rudimentary; and as nearly all bH users get LPs from deepbit vs only some getting other pools, deepbit tends to win votes undeservedly (and these biased voting results would be more wrong if it wasn't for DB being the largest pool). So to improve BH LP block finding to the point of reliability, we need:- Self-learning of per-pool LP delays (LP delay learning must remove the finding pool however, or else we bias deepbit's delays because they find so many blocks) - Publishing of all local corrected new block LP results to IRC, not just winning pool (perhaps JSON format, like " ** block 3fe33a: {"triple": 0.0, "bitp": 0.3, "deepbit": 0.5, "mineco": 1.3, "bclc", 1.7}" - Averaging (not voting or first response) all IRC results (including pools we don't actually check ourselves), to determine if there is a clear LP block winner; a confidence level can be assigned. For the super-advanced, it may even be able to profile a 'signature' of block delays to determine who found the block, since pools also seem to have a different LP delay depending on their p2p distance from the finding pool. |
|
|
|
|
Show Posts
