Those private pool software are good, but most don't have their own front end. If you want to run your own private pool, it could be interesting to hack p2pool to not actually run as a p2p pool but simple a single node of a private pool. You can then use their web interface, use their username = address method of payouts, use their fee structure (you set your own fees if you want others to pay you for using the pool). the hack is from here: https://bitcointalk.org/index.php?topic=193669.msg2010200#msg2010200In p2pool / p2pool / networks.py: in the bitcoin section change the BOOTSTRAP_ADDRS='list of addresses'.split(' '), to BOOTSTRAP_ADDRS=''.split(' '), Change PERSIST=True, to PERSIST=False, Change P2P_PORT=9777, to something else (so no one accidentally connects to you) I'm trying it out now, could be an easy hack to get a private pool running using PPLNS. EDIT: to be clear, you don't share anything with the rest of the p2pool network. It really is just you and whomever logs into your server. |
|
|
|
|
I don't think it's too much of a leap to think that. Although I wouldn't call it a smoking gun, just something that appears to convenient to be pure coincidence.
|
|
|
|
Hi everyone, i have been trying to disconnect my p2pool node from the global p2pool network, to turn it into a private pool. I tried setting --outgoing-conns 0 --max-conns 0 but it when i try to connect a miner i get SON-RPC call failed: {
"message": "p2pool is not connected to any peers",
"data": null,
"code": -12345
}has anyone done this before? Thanks in advance!! some litecoin pools do what you want to do, but you have to edit the source code to do it. |
|
|
|
Hi, Like the look of p2pool..  I understand that p2pool is DOS resistant and HOP proof but can some one explain how it manages to mitigate the 51% attack ? Is it because the sharechain it uses is so much faster that you would need 90% (or more..) of the hashrate to overrun that chain ? So basically IF everyone was using p2pool we would only be vulnerable to a 90% attack ? ? p2pool is kind of immune to the 51% attack problem because p2pool doesn't decide what goes in a block (what work to serve), individual users do. Since centralized pools choose what work gets sent to miners, a nefarious pool operator can pull off a 51% attack. p2pool is "dumb" and blindly assigns work based on whatever bitcoind serves it, so there is no centralized way of p2pool coordinating a 51% attack. |
|
|
|
Check out: https://bitcointalk.org/index.php?topic=153232.0for ways to improve efficiency. quick comments: 41% DOA seems really high, something might not be configured correctly. Check out the link above for how to improve it. The efficiency number doesn't have enough data yet to be accurate. If you looked at your console output, it'll say something like Efficiency: 85.85% (20%-110%), or something like that in the parenthesis. As long as 100% is inside of the range of the parenthesis you're probably ok (but that 40% DOA doesn't look right) Payouts to p2pool have higher variance than PPS. If you normally get .016 / day on 50 btc, then you may get .032 BTC on day on p2pool and zero BTC the next. You have to keep track of your earnings over a longer period of time. If your efficiency is >= 100%, you will, on average, earn more than any other pool. The downside risks that will decrease your earnings include: how stable is your p2pool and bitcoin nodes? could extra latency creep into your connections? Do you have the bandwidth for a bitcoind and p2pool node? |
|
|
|
that's not true, either. people with better systems win out in the 'everyone includes every transaction' theoretical.
i'll throw this out there: people saying to include all these transactions are being greedy. you want to increase your own "efficiency" rate at the expense of people with slower systems. for someone to have >100%, someone else has to have <100%
In the presence of a health p2pool network strength, the theoretical optimal strategy of a p2pool node operator is to have the have the best system, lowest latency, you can get. That includes: 1) have a top notch fast system 2) limit transactions Following (2) to its logical conclusion (i.e. zero transaction blocks) is bad for the network. Following (1) isn't necessarily bad for the network (unless you say it discourages smaller p2pool nodes, but they can just mine the bigger/faster public ones if it gets bad). However, I think there is some happy medium where (2) could be beneficial for the bitcoin network. In exchange for adding the hashrate of many small p2pool miners you get some smaller blocks. That is could be an acceptable trade-off. Going to zero-transactions, however, is not acceptable. My point is that the optimal p2pool strategy is bad for the bitcoin network. Is there something that can be done? Force p2pool shares to contain a certain number of transactions? A number small enough that doesn't kill small pool latency but big enough to help the network? |
|
|
|
...
Now you are just playing dumb. Normal pools have much more tolerance for bitcoind latencies: their target is a 10mn window: a latency of ~0.2-0.5s instead of 0.01s during which orphan blocks can be produced is nothing for them. P2Pool is 60 times faster with a target of 10s: orphan shares produced for 0.2-0.5s instead of 0.01s matters for the miners.
Bitcoind getblocktemplate interface slows down with the number of transactions to include in a block, period. This is only an implementation choice, period. Arguing against these facts is just ignoring reality and making you look like a fool.
What has that to do with orphans? If you want to put the blame on p2pool users instead of the slow bitcoin RPC interface you might want to learn what an orphaned share in P2Pool is and what its consequences are. You can read the guide in my signature to understand this and related information about P2Pool. The actual risk of having an orphan is only your bitcoind.
Not relevant to the problem some p2pool miners try to solve by lowering their block size. So what you are trying to tell me is that it's not orphan blocks that you are trying to reduce but orphan shares in the p2pool share-chain? Seriously? It's even worse? You are trying to increase your share count at the detriment of the bitcoin network? exactly - this is the problem. Like I just posted above, there is no financial incentive for a single p2pool user to include transactions in their p2pool share. It's game theory: if everyone includes transactions, everyone wins. But if one person chooses to make zero transaction p2pool shares, and everyone else chooses to make normal shares - the zero transaction share person wins. EDIT: this is selfish, but it is the way it is. Pools do have a financial incentive to include transactions since transaction fees offset the increase in orphan rate. p2pool nodes, however, do not see the transaction fees they include (but only a tiny fraction of the fees), so there is more of an incentive to have lower latency than higher transaction fees. |
|
|
|
furball: the latency is (from my experience) mostly determined by your maxblocksize. set it to 5000 (so you can catch a few transactions that might have bloated fees) and your latency should drop a lot. less transactions = lower latency. also less orphans
Thanks so much for the tip zvs, will definitely give that a go. ... and another p2pooler makes p2pool 100 times worse than using any of the top pools ... He might well lose a bit of money with a maxblocksize so low but it's better than almost any other pool. If income is better on p2pool, the market decides to switch to p2pool. So Kano, why don't you patch bitcoin for speeding up getblocktemplate to avoid this instead of harassing miners who don't have the knowledge to do it themselves? No the problem is people using crap hardware and crap internet connections and then blaming bitcoin and setting their bitcoin setting 100x worse than the top pools. Why don't the pools have this problem? Coz they don't use crap setups. Now you are just playing dumb. Normal pools have much more tolerance for bitcoind latencies: their target is a 10mn window: a latency of ~0.2-0.5s instead of 0.01s during which orphan blocks can be produced is nothing for them. P2Pool is 60 times faster with a target of 10s: orphan shares produced for 0.2-0.5s instead of 0.01s matters for the miners. Bitcoind getblocktemplate interface slows down with the number of transactions to include in a block, period. This is only an implementation choice, period. Arguing against these facts is just ignoring reality and making you look like a fool. I agree, it has nothing to do with crap set us but simply the behavioural economics of mining. Even someone with the best set-up in the world would do better with a zero transaction block than not. Galvin has shown that for big pools it is more profitable to take more transactions (and transaction fees) at a risk of higher orphans than it would be to take zero transactions and lower orphans. However, with p2pool, it is more profitable to make 0 transaction blocks and have lower sharechain orphans than it is to have more transactions in a block. This is because if I choose to include transactions in a block, I don't see the profit since it is shared amongst the pool. If I choose to make 0 transaction blocks, I see an increase in profit but the rest of the pool sees a drop. This assumes extreme selfishness (ignoring effects on the larger bitcoin network), which implies optimal efficiency. |
|
|
|
Returning with an answer to yesterday's issue: my p2pool is again showing payout if a block were found now at 0 btc and I have 6 peers out 3 in. Why does it say i'd get 0?
I believe you earn shares in quantum increments. Until you earn a share, it will be at zero. Could you explain more about earning shares? I've been mining for a month and until yesterday I never saw 0. What exactly is my node doing less of? your node is unlucky at the moment. When you hash, you're basically guessing a number. Sometimes you'll guess the right number (and solve a share - kind of like solving a block), and sometimes you'll guess a wrong number. As difficulty goes up, it's harder and harder to guess the right number. When you guess the right number, you get credit for a share which then means you get paid every time p2pool finds a block over the next day (currently for p2pool, but this can change). Your node has been unlucky at guessing numbers lately, so you haven't gotten a share and won't get paid until you do. Sometimes you'll get luck and guess two in a row, in which case you'll get paid 2x more than if you found just one share. regarding static address: p2pool generates one the first time you run it, and as long as there is a "p2pool" address in your wallet it will mine to that one. It wo't create a new one with new address unless you wipe your wallet. |
|
|
|
Now that you are hoping for a few different boards, can you give so updates for cost with and without parts? I am strongly considering going in on the funded ASIC group buy, and I am just trying to figure out how many I can afford. I am not looking you to lock into a price, maybe just a ballpark. Especially for the 64 chip board you mentioned.
If I had to ball park a kit price right now I'd throw out numbers like: ALL QTY 1 --- SUBJECT TO CHANGE (board + parts) (without ASIC, heat sink, ATX PSU, cables) Klondike 1 - $16 (I did a design and parts list this evening, and board partly done) Klondike 16 - $35 Klondike 64 - $100 (board only) Klondike 1 - $6 Klondike 16 - $12 Klondike 64 - $25 PDF Assembly Manual included (hopefully). Shipping not included. I'm not planning to get into full assembly myself except maybe for the Klondike 1 (dongle). I will supply boards/kits at wholesale pricing to other assemblers. if someone is interested in a distribution business, you can find people like http://www.screamingcircuits.com and http://www.sunstone.com to do your pick and place and pcb fab, respectively. With doing 100+ boards, assembly and PCB should come out to be around $50-60/board +parts for the klondike 64 (just guessing some of the specs from bkk's posts). Add in $600 worth of asics and you can make a 16 GH/s miner for ~$700. put some markup on that, might be an interesting venture. |
|
|
|
This is probably really what happened.
Unlike futures market in the "real world", where the operator knows your identity and can come after you, your losses are limited to the amount you deposit on your margin account. On an ordinary futures exchange, there is in principle no upper limit to your losses, as the exchange operator can drag you to court to get what you owe him. The downside of this limitation of your loss it the introduction of counter-party risk: If your counter-party's loss is limited by his available funds, so is your profit. And yes, this introduces a risk to arbitrageurs. On the other hand, the profit is also above the normal in arbitrage.
We cannot have it both ways, and in a quasi-anonymous bitcoin setting this counterparty risk is probably unavailable, unless the fees are so high that the exchange can afford to assume that risk - but that would probably scare us all away.
rather than have higher fees, just require larger margin and perform margin calls earlier (before the account would be forced to go negative.) This would help ensure that no one goes negative. It reduces people's ability to leverage and decreases the risk of an account going broke. In fact, you can force margin calls before the account would go negative AND force sell below market which would "hurt" the account that ran too low and "help" the accounts that are in good standing. This is similar to what a brokerage would do in the real world as an incentive to keep your accounts in good standing. It is (and always was) this way. Only very small (1-5 contracts) positions are excluded, and also position is not touched if trader lost money trading that contract.
Otherwise, it would be too unfair.
I think arbitrary rules are unfair. The fair thing is for everyone is treated equally, but that is just my opinion. The best scenario is for such situations to not happen at all (stricter margin enforcement so contracts are force sold at market rates). |
|
|
|
For what it's worth... My node ( http://ask.gxsnmp.org:9332/) has: P2Pool - Peers 8 out, 29 in Bitcoind: "connections" : 51, "currentblocksize" : 66063, Getwork Latency -Mean: 0.695s And it seems to be doing fine. Uptime: 11.257 days. That's @ all the 'default' settings Could it be better? Probably.. I'm just not really sure what to tweak to make it better, it seems to be working and I get payouts whenever a block is found. you're doing fine, but your efficiency is not has high as someone with 0.003 s getwork latency. Your expected DOA due to getblocktemplate latency: .7/10 = 7% Someone with a 0 tx fee blocks (3ms) .003/10= 0.03% assuming everything else equal: if your efficiency is 100%, theirs can be 107%. They get 7% more profit than you by choosing to not process any transactions at all. Thus Kano's argument that if the optimal p2pool setup is to process 0 tx, then p2pool (as it stands with standard bitcoind) hurts the network |
|
|
|
regarding custom compiled bitcoind for "optimal" p2pool operation he can run his pool the way he wants to. right now, that's the best way to run a p2pool pool.
you can either a) fix p2pool so that having a bunch of transactions doesn't cause you to get double, triple, or quadruple as many orphans, b) implement a stop-gap like i proposed, or c) stfu
This is an interesting point: should p2pool be changed so that we take away a miner's freedom to choose what transactions to accept in order to help the bitcoind network? Summary: by custom tweaking bitcoin code, you can create 0 transaction blocks with tiny p2pool latency. That is great for the individual miner that does it (higher efficiency) but horrible for the bitcoind network (and for other p2pool miners who are "honest"). Galvin Anderson did some calculations to show that the 0 tx strategy is not profitable compared to accepting transactions for solo (or regular pooled) bitcoind mining. I wonder if it's true for p2pool... Whether it was written in C or python (or intercal), this would be a problem and is a fundamental question. |
|
|
|
I don't think Fireball was being malicious, but the lack of downside (worst thing that happens is he liquidates everybody and walks away) can make for negligence. As a short, there is NO way I would have accepted a full session of time to make margin call - it's a free option to the long (if the market goes up he wins, if it goes down, he gets closed out at a guaranteed price). This is immediately OBVIOUS to me because I have downside risk.
I believe the free options given to accounts not in good standing are going to be eliminated. However, the existence of that free option introduces a trading exploit strategy: Make two accounts Sell/Buy from/to yourself from the two accounts. Remove everything except the minimum margin requirement from the account Get margin called One account gets a free option, but hope that you get liquidated. One account gains linearly with price, one account losses is capped at a price You make free money (at other trader's expense) I am of the opinion that if an account goes below 100% margin, they get a warning to bring it back into good standing. If it goes below 75%, it is liquidated at market to prevent this exploit |
|
|
|
Could you post the line from the p2pool program feed that looks like:
New work for worker! Difficulty: 0.000200 Share difficulty: 0.994552 Total block value: 50.210500 LTC including 10 transactions
It's still the same as mentioned above: "New work for worker! Difficulty: 0.232827 Share difficulty: 5.000000 Total block value: 53.123000 LTC including 45 transactions" This is using: Usrnme/5+5 P2pool version is: 11.3 (I tried 11.4, that seemed to decrease my share rate further) Cgminer version: 3.1.0. I'm receiving payouts. The odd behavior is receiving consistent share/payout per block of .45 LTC for 12+ hours, then it drops to .10 for another 12 + hours. This happens when the p2pool node has been operating fine, along with all the miners connected. Smooth & even hashrates. The overall pool hashrate has a mean score of 580MH/s. I would anticipate a much lower payout if the pool hashrate jumped to 1,200MH/s, but it stays within 100-150+- MH/s variance of the mean score. My efficiency is normally between 110%-120%. Thank you for the reply. Thanks - I think this shows what's wrong: 1) your +5 difficulty is way to high so p2pool has already reduced it down to .232 (otherwise it would get no statistics) 2) the /5 difficulty is causing 200% higher variance than is typical. The payouts change so much because you are only submitting a rare high difficulty share instead of frequent low difficulty shares. p2pool is not a PPS payout system, but a PPLNS. When you find a share, you will get paid out every time p2pool finds a block for some period of time. If you find shares infrequently, there will be much variance. With a /5 difficulty, you'll find shares infrequently. Both of those settings won't affect your expected or average payout, just change the variance and frequency of payouts. i'd try one of these two: 1) don't use /difficulty+difficulty at all and let p2pool tune it for you (especially good if you're a small miner) 2) If you're a bigger miner and want to tune your difficulty, perhaps trying /2+.0002 as a starting point and tune as you see fit. If you're payout variance is too high, get rid of the /2. If you're statistics reporting to p2pool is too much (crashing the server) then increase +.0002 to something higher (or lower if you want more accurate statistics) |
|
|
|
When Avalon posted their TMSC contract, they didn't fully black out the prices and someone saw they pay around $4k per wafer. They get ~4k chips out of the wafer, and packaging would add less than $1 per chip, so their cost is likely in the $1-2 range. That might have gone down with their recent increase in volume though, who knows.
But how much was the mask cost? OP says MARGINAL cost. The mask cost is a major cost which you have to divide by the total volume. For low volumes it will outnumber the wafer cost. The Avalons are using very old technology where the mask cost is pretty low compared to a more recent technology. The software cost is also typically in the multi 100k$ range. In economics and finance, marginal cost is the change in the total cost that arises when the quantity produced changes by one unit. They've already paid for the mask. While the number of wafers produced will affect the average cost, it won't affect the marginal cost unless for some reason another set of masks needs to be made. "total cost" includes the mask. Includes input costs, labor, etc. i agree with kingkoin. source: wife is a cpa. I know this is semantics, but "total cost" does include the mask. "Marginal cost," however, does not include the mask. The marginal cost is $1-2 per chip. Break-even cost (marginal cost plus sunk costs, loan interest) is about $8-15 (from how much they are selling the chips for in batches of 10,000 chips) Edit: this is very basic accounting/economics. Marginal cost ignores all sunk cost and only considers the cost to produce one additional unit. It's the "slope" of the supply curve, excluding any offset due to NRE/tooling costs - but it does include additional costs of labor for each unit. They do need to make the money back, but that is not included in the calculation or definition of marginal cost. |
|
|
|
I need some clarification on how the P2pool Difficulty operates with Litecoin. I have a P2pool node setup, with my miners connected to it. I've been mining the node for 1 month now, yet the difficulty/shares/payout still is a bit fuzzy. I've appended my username with the /+ flags, and tried several difficulty levels. I've seen examples of usrname/2000+16 or usrname/2+2. I've made the assumption that the /2000 would be for bitcoin mining and the /2 would be for litecoin. Can someone explain the difference between the /2000 & /2 and how it relates to Litecoin mining.
I understand the the /2000 is for the pool/share difficulty, and the +2 is for the miner difficulty.
Example Stats:
P2pool version: 11.3
Cgminer version: 3.1.0
P2pool share difficulty: 1.15 (according to the web/static detail)
P2pool share difficulty: 0.232827 (according to P2pool program feed)
P2pool requested difficulty: Difficulty 3.000 (my username/3+3)
P2pool Shares: 8 total (1 orphaned, 0 dead) Efficiency: 113.7%
Cgminer difficulty: 15.3K (according to cgminer)
Cgminer difficulty: 31.6M (according to cgminer)
I've received "accepted" shares in cgminer of 250k/15,300 with a difficulty of username/2+2; however, p2pool does not recognize or "accept" a high share like that. I've also let the miners run for upwards of 48-72 hours and have odd payouts. What's the voodoo magic behind p2pool & the difficulty settings?
The difference between /2000 and /2 = bitcoin's algorithm is ~1000x "faster" at finding hashes than LTC's algorithm. Thus the difficulty must be ~1000 lower for the same amount of work. Also, the /2+2 you are using means your p2pool server and stats are going to have a sparse sampling rate. I'd suggest something like /2+.002 (or .0002) otherwise your p2pool node will show extremely high variance statistics (unless you don't mind it and know your setup is ok). Something else is suspicious with your setup, since you have so many different difficulties: Could you post the line from the p2pool program feed that looks like: New work for worker! Difficulty: 0.000200 Share difficulty: 0.994552 Total block value: 50.210500 LTC including 10 transactions It should pretty much match the web interface: Pool rate: 504MH/s (18% DOA+orphan) Share difficulty: 0.993 Notice both share difficulties are the same (+/- the delay it took me to hit refresh) what version of p2pool are you using? recently they changed the way LTC share difficulty is reported to match what other pools are doing. What are the odd payouts you are getting? Your efficiency is > 100%, so it looks like something is working. |
|
|
|
someone would need to make a platform where people can make donations and disclose who they are (confirming they are US citizens) under the penalty of perjury - i'm sure that this would probably meet the requirements?
Political donations are accepted only in those forms of fiat - credit card, personal or business check, bank wire, ACH, & etc. - that have an reasonably uncontestable identity linked to them. Except that isn't true: http://bitcoinmagazine.com/bitcoin-usage-for-political-donations-expands-to-vermont/ |
|
|
|
|
I didn't even know they were pregnant!
Oh, you said wafer...
|
|
|
|
|
Show Posts
