Yes, there needs to be some data structure (which you call a database) to keep track of all of the shares. The point I'm raising is that the structure for linking the shares together does not have to be a chain. In a chain, each link has one parent and one child. This forces the serialization of share mining and submission, which causes performance problems for parallel and distributed systems. I'm proposing that we instead use a different structure, such as a directed acyclic graph (which I previously incorrectly called a tree).

You don't need to ensure that the database is the same on every node. There are some types of differences (a couple of extra leaves on the DAG, for example, or orphans on the share chain) that do not cause problems. You just need to ensure that if someone sends you a share, you can find all its (recent) ancestors and ensure that the submitted share rewards them all appropriately.

Essentially, the problem falls to how you deal with branching. Let's imagine shares as if they were mathematicians. Pythagoras proved a^2 + b^2 = c^2. Euclid referenced Pythagoras when he wrote Elements on the subject of geometry. Skipping a few years, Newton created calculus while making use of Euclid's geometry. At about the same time, Leibniz created calculus while making use of Euclid's geometry. A century later, Euler used calculus to define the number e. Who does he credit for calculus? If we're using a share chain, then even if Euler knows both Newton's and Leibniz's works, he has to choose one of them to ignore simply because they didn't know each other's works. What I'm proposing is that we allow Euler to credit both Leibniz and Newton at the same time, as siblings in science. Then, when Riemann comes along and cites Euler, we know that Riemann inherited influence from both Leibniz and Newton, and we don't have to stiff Leibniz just because Newton was better connected. Heck, we could even have the Indian genius Ramanujan (early 20th century) reference both Riemann (19th century) and Madhava of the Kerala school (14th century), so long neglected by Europeans.

When verifying a share (i.e. a candidate block), you collect all of the ancestors of that share and ensure that the candidate share includes appropriate payouts to the mining address associated with those ancestors. As long as you have verified all of the immediate parents of that share (of which there might be 10), you will also have all of the more distant ancestors. If you are missing any of those parent shares, you can get them from the node that's forwarding the candidate share to you, and then you can recursively verify those, etc. until you get to the height limit for the PPLNS system.

One (optional?) constraint that makes sense for which shares can be incorporated: all parent shares must have been efforts at solving the same bitcoin block. No need to reward work that is actually obsolete. Something else might be needed here. Need to think about it later.

The main benefit is that verifying shares and switching the share you're working on to one that's based on the most recent published shares is no longer time-sensitive. If you aren't working off the tallest share branch in existence, the shares you published will still probably be incorporated into the share DAG. Thus, even if new shares are being published every second, you don't have to rerun GetBlockTemplate() and flush the work on your miner for many tens of seconds, and possibly hundreds of seconds. The only constraint is that you need to publish your share early enough that it's cited before a new block is found.

Fleshing it out a bit more, you could define the share height H as being the length of the shortest path from the root to a particular share. The PPLNS window could be sized to include all shares with a height greater than (H - X), where X is some arbitrary number roughly corresponding to the N in the LNS system. Shares would be allowed to name any valid share as a direct parent as long as that share was not already an ancestor through any of the other parents, possibly with some arbitrary maximum number of parents hardcoded to reduce the size of the p3pool share data that needs to be incorporated into the blockchain. Or something like that.

My brother passed me this paper as being relevant, but I haven't read it yet. https://eprint.iacr.org/2013/881.pdf

I was thinking of it as being PPLNS like the current p2pool, but with the option for a larger number of shares in the LNS window than the 8640 of p2pool. However, the algorithm used to determine the rewards per miner or per share is partially independent of the share tree data structure, so it should be possible to make many different types of p2pool clones with different reward algorithms.

I was thinking about this the other day, actually, and I think I got a good solution to the problem. You can read it here:

https://bitcointalk.org/index.php?topic=18313.msg10519027#msg10519027

Cross-post from the Spondoolies thread, more relevant here:


I was thinking about this the other day, actually, and I think I got a good solution to the problem.

p2pool uses a share chain much like the block chain for its reward allocation. This means that if you're mining on a share that isn't the most recent, your work is wasted. The blockchain was designed to solve the timestamping problem for creating a distributed ledger system for transactions, which is why the blockchain has to be serialized. With p2pool, there is no such requirement for timestamping and serializing the shares, so the shares do not necessarily need to be arranged in a chain. The fact that they are was probably mostly just a programming convenience in being able to reuse the bitcoin blockchain data structures. I think a better structure for p3pool shares would be a share tree, where each share references at least one parent share instead of exactly one parent share. That way, work done on shares that would end up marked as stale on the current p2pool (i.e. branching shares) could still be incorporated into the p3pool share tree. Add in a small reward to the miner who found the share for each parent share that's referenced for the first time, and everybody's shares should get incorporated as long as the share is based on the most recent block.

Since miners no longer would need to abandon work immediately when someone on p3pool finds a share, p3pool could target much higher share frequencies, such as 1 per second or faster. This would decrease share variance and allow for small miners to use p2pool effectively, and it would also allow p3pool to grow larger while keeping individual share targets reasonable.

It looks like about 41% of all p2pool miners are now running on the Toomim Brothers datacenter's nodes, since most of the rest fled.

Node 1: 298 TH/s
Node 2: 60 TH/s
p2pool total: 864 TH/s

I'm amused, but also a bit disappointed. Can't you guys bring your hashrate back?

If you are running your own node and want to add us to your hardcoded IP list, please only add one of our nodes, since adding both would result in shares and transactions being sent twice over our internet connection instead of once over the 'net and then forwarded once over our LAN. Also, both of our nodes are a bit stressed in terms of CPU cycles (especially the big :9334 node), and each connection adds CPU load. Also keep in mind that those nodes are not currently on a static IP address, and their IP may change once every few months. (The IP has changed once so far since August.)

By the way, my guess is that the previous block took as long as it did in large part because a bunch of hashrate left p2pool several days ago, and the p2pool total hashrate estimates are slow to update. The estimates are based on the last 8640 shares submitted (right?). The default share difficulty is based on the estimated pool hashrate, so when the hashrate decreases rapidly, 8640 shares can encompass a time period significantly longer than 3 days, since those 8640 shares are at a higher (older) difficulty.

It was originally 8 amps per pin, limited by the Molex connector, for 288 W. More recent PSUs (since 2005) are required to use 11 amp connectors, for 396 W. This assumes 3 pins for each of ground and 12V. The PCIE spec only requires 2 of each to be connected; although many PSUs include a 3rd of each, it is not universal.
http://www.tomshardware.com/forum/274631-28-power-spec-power-plug#2674391

The original PCIE power spec as a whole only specified 2 amps per pin, or 75 W total. The 8-pin revision of the spec specified 4 amps, or 150 W total. This is much less than the specifications of the individual components of the connector, which is why we disregard those limits entirely.
http://www.playtool.com/pages/psuconnectors/connectors.html#pciexpress

I've done this before on some of our early prototype PSUs. It works okay. It's not worth the time it takes to put it together, though, in my opinion, especially if you find a decent source for 16awg PCIE cables that are long enough etc.

If you're editing cgminer.conf, you may find some of these other cgminer arguments interesting:


A few of those (--bitmain-homemode, --bitmain-fan, --bitmain-temp) could make nice options for cgminer.conf for people who don't want their fans to burn out. I'm also curious if --bitmain-auto works.

I've partially figured out the voltage setting issue. This is using smit's FW (from here: https://bitcointalk.org/index.php?topic=940250.0;all), but I'm guessing the same issue exists with the new Bitmain FW. The problem appears to be in how cgminer.conf is written. If you get something like this (for a voltage of 700 mV), it won't work:


It needs to have a leading zero, or else cgminer won't take it and will use the default value instead:


On smit's firmware, this is in /config/cgminer.conf. Probably the same location on 20150129. After you edit this, you may need to restart cgminer and then power cycle, or possibly just power cycle, I'm not sure which.

edit: You can probably also fix the issue by just pitting a zero first on the Advanced Settings page when choosing your voltage. I haven't tested that yet, though.

Several of our customers at http://toom.im have SP30s that they're interested in selling. I can think of 11 SP30s right now whose owners have expressed an interest in selling, and I may be able to find a few more by asking around. If you name a price, I can pass that along to the respective owners and see how many they'd be willing to sell to you for that price.

I have always seen this problem when ASICs get too cold. Some of our SP30s and SP31s generally start to show this problem when the intake air temperatures get below around 8°C or lower.

Since the affected ASICs for you are the ones in the back, they'll be warmed by the ASICs in the front. I suggest you turn down the fan speed to 30, then let it run for about 30 minutes, then restart minergate. The slow fan speed will make the air temperature flowing across the back ASICs much warmer, which may get your back ASICs to run again. Once they are running, you can increase your fan speed again, though I would suggest leaving it a little lower (maybe 80) as long as your intake temperatures are low.

What are your intake and exhaust temps?

Edit: I read the rest of the thread. This is not a temperature issue. My bad.

It appears there is a bug that affects SP35 PSUs. The PSUs appear to not notify the mining software properly when they encounter trouble (such as overloading), which results in the mining software not reinitializing that PSU. When this happens, one PSU and one hashboard will sit idle until the user manually restarts minergate. Zvisha is aware of this issue now, and will probably have a firmware fix for us soon. If you have received an SP35, I suggest checking on it frequently for the next few days. It might also be a good idea to drop the PSU limits by 50 watts until a fix is released.

Currently, 4 of our 14 SP31s are hashing above 4.90 TH/s. The average for the SP31s we're hosting is currently 4856 GH/s with intake temps around 15°C.

The SP31 contains two 1200W power supplies, which are run (with the PSU manufacturer's approval) at around 1330W of 12V DC output. The SP35 uses 1600W power supplies instead. The SP30 was identical to the SP31 except that it used ASICs from a different batch that were significantly slower and less efficient due to differences in silicon doping during wafer fabrication.

How much do you pay for electricity? You can probably increase the PSU limits by maybe 25W each and get some additional hashrate at the expense of efficiency, but depending on your electricity cost, you may prefer efficiency instead.

You can probably increase the power on those PSUs quite a bit. 1275 is pretty conservative. 1330W is about 90% likely to work without problems. If those are Emersons, I'd set it to 1350W and let it learn its limits. There's a good chance that 1350W will be below the limits, actually. Doing this will give you as much as 150W more power and possibly 200GH/s more hashrate.

Also, at those temperatures, I find that the optimal fan speed is 70. The temperature at which 70 and 80 are equivalent is about 16°C for SP30s and SP31s. Higher fan speeds use power that could be supplied to the ASICs, so too high a fan setting actually reduces performance slightly. The SP35, SP10, and SP20 are more temperature sensitive than the SP30 and SP31, so they should usually be run with higher fan speeds when performance maximization is the goal. If you don't increase the power to 1330W or 1350W, then the optimal fan speed is even lower. At 1275W and 11C, you might be best off at 60.

No overheating issues. There were some issues with the actual miners not meeting the pre-launch performance goals and forecasts. Spondoolies compensated their customers for the performance shortfall with refunds equal to the hashrate deficits. The current published specifications are based on observed performance rather than forecasts, and are more accurate.

Their hardware isn't perfect; it is only the best anyone has made.

Performance suffers on 120V for the SP30 and SP31. You'll get about 10-15% lower hashrate on 120V than on 220V+. Computer power supplies are less efficient on lower input voltages, which means they generate more heat, and therefore reach their thermal limits at lower output levels.

I think the power supply used in the SP35 is probably this: https://www.artesyn.com/power/assets/ds1600spe-05-30-131391227406.pdf

If so, that PSU is rated for 1600W output when supplied with 180V to 264V, but only 800W when supplied with 90V to 140V. In contrast, the SP31's PSUs are rated for about 1000W with 120V input and 1200W with >= 200V input.

If you're using 120V, you're probably better off using SP20s than SP3x models.

SP30/31/35s are not as loud as the SP10, but they're not quiet by any means. If you're using 120V, the power supply fans will have to run at higher RPMs which makes them louder. On 220V, they may be more bearable. Due to the small size and high speed of the SP10 fans, the noise the SP10 makes is relatively high-pitched and annoying; the SP30s' noise is lower in frequency and more bearable in tone.

I've gotten this problem a lot in the past too. I think if you send the same message from different email addresses, then Google will just think you've got several email addresses that are working in collusion to send spam. Try sending an email to a specific person at Spondoolies (e.g. katyap@spondoolies-tech.com or barbara@) instead of one of their shared email addresses, as the individuals' addresses aren't mediated by Google Groups. You should also forward the error along to stas@, as AFAIK it's his job to make sure this works.