P2Pool generates a sharechain block every 10 seconds (on average) where the bitcoin blockchain only makes one block every 10 minutes (again, average).

The BFL single takes ~5 seconds to report back the work it computes.
On the full blockchain, or on work from pools this isn't a big deal since a share from five seconds ago is likely to be valid.
On P2Pool because of the lower block generation time a share from 5 seconds ago may or may not be valid, hence the high rejection rate (usually DOA iirc).

So to fix the problem BFL has to reprogram the singles to report back faster like GPUs or other FPGA units do, or P2Pool has to hardfork and use a longer time between blocks. Neither are particularly useful suggestions as changing P2pool for one manufacturer's mistakes is a lot of work for no reason, and a bad precedent; while getting BFL to update their firmware for an obsolete product is a waste of resources.

Any updates on the ASIC front? Or current expectations?

Might be a good way to use the machines you've built after the big rig gets purchased. However with the halving and ASICs coming out there's some thought that a number of people may end up doing just that, so it's a bit of a gamble. Also I'm not sure how stable the BTC/LTC price is long-term as I don't think Litecoin has achieved the same acceptance from merchants. Interesting  though.

Hate to spoil the fun, but that's block 210354 and was only worth 25BTC. Still a solved block though!

I would personally also love to see this continue going, though I understand the other reasons for wanting to close down. For what it's worth I believe both cryptostocks and btct.co are both offering to take in GLBSE assets in for free. I'm less familiar with cryptostocks, but btct.co has a tool setup to help with import, will refund the 5 BTC setup fee, and person to person transfers are free.

Just to promote my own idea a bit more, the strongest use cases I can see are:

• Place orders, then deposit coins - Why wait for deposits to confirm when you can place orders now; orders would become active as they're funded by deposit
• DRIP investing - as above, orders are placed as they can be filled as dividends are paid out, whole shares only (Placing a order at the maximum price you're willing to pay would let you buy anything at a lower price, ie market price)
• Range trading - Anyone fairly confident of the future price of an asset could place a lower and upper bid and profit from volatility; orders would be bought and sold back and forth as funds or shares became available

As far as I can tell though you'd basically have to show the portion of the order that is currently funded instead of cancelling everything, the API may also need a flag for "View Funded" vs "View All" (probably defaulting to the former). Though that's lower priority. Such a system would also allow more automatic trading without intervention (buy some of X, sell old shares of Y, now more shares of Z can be purchased based on previously unfunded order). Hopefully this would be closer to the silver bullet of providing liquidity, though only across the whole exchange, each individual asset could still fly around pretty quickly.

The only drawback that jumps out at me immediately and painfully is spam bids stay around longer now, maybe force bids to be within a certain multiple of current market values? Or just hide such orders from view. This might just be a separate feature request in it's own right.

The only way I can think to do it is to allow unfunded orders and to just hide them until there are enough funds to back them again, but that would require several changes and would probably not work well with cancel on order.

Do you have anything else to stress test the USB stack with?

Is anyone in general aware if a powered hub fixes the rest of the problems?

From what I've seen there's a bunch of people trying to get in, and several people enjoying the view from the inside.

The best way I've seen to get an invite if you have talent is to post art on G+ for the people running the show to see and they're handing out invites on that basis as said. I've signed up for ingressinvites.com but since it was only this morning I haven't heard back yet

Lists are being sent out 1-4 a week I believe starting with the largest (I believe by total volume traded) and going down the list; gigamining was the largest security on the exchange, some people believe that lawyers also helped their case. Because this security was only started a short while before closing it's further down the list than it should be otherwise. Nefario has said he's doing it now and seems to be slowly getting around to it.

This is definitely a real problem you're facing, but to a point it's the burden for what has happened in the past. The same reason I imagine that you deleted over a thousand posts. So long as you stay in the same user account your history, and worse your trolls, will follow you.

This isn't nearly as relevant now, other things have been presented, the thread title just hasn't been changed.

The stock was being represented as worth the NAV as presented in your spreadsheets. If an inflated number was used it would make the investment appear to be worth more. The accusation was that the values were intentionally overvalued to inflate the apparent worth of the security; which would be defrauding investors.

At this point usagi is attacking me instead of what I'm posting, and in fact skipping over entire chunks of my posts just to pull out parts where I come right out and say I'm trolling him. As well I apparently have become illiterate to his form of English.

As for clear and concise, I've tried to lay everything out in bullet points; while the post is long, there's a lot in it. You've gone at me for semantics so I tried to be very clear in what I said, then you say I'm being too wordy, the whole time ignoring what I've said. If you care to respond to it please do not cherry pick the least important parts, ignoring both the bulk and significant comments and actually respond to the 3 (yes, only three!) issues presented.

If anything it's just time to make a new thread as this one is long, more than slightly off track in a few places, and has already been evaluated once by the mods.

Well someone beat you to the punch with a polite, helpful answer. To add insult to injury your solution isn't really adequate; a notification on this thread would work the first time anyone else posted in this thread (nearly daily) and have relatively little correlation to the new versions coming out.

As a curiosity, does the p2pool client support forwarding a signed message similarly to how bitcoind does? Could this be added to the low-priority wishlist if not?

Since a few other posts are beginning to get into longer chains of quotes, and one quote authored by usagi being attributed to me I'm just going to respond to this directly, however I agree with most of the other replies to usagi's post quoted below.

This probably should have been under conflict of interest with the later items. However, voting:
1) On non-action motions (ie "Is Usagi doing a good job?")
2) Where you're voting to represent shareholders of another holding (ie CPA voting on a NYAN motion without calling a CPA motion)
3) With unissued shares (ie shares not available for purchase by the general public held in the account segregated for such a purpose)
Is neither ethical nor a legitimate vote, in some cases such behavior would also constitute fraud. At it's height I believe NYAN.* had well over $10k USD (I assume USD because you've not specified otherwise and it's much more than $10k Yen), notwithstanding that $10k spread between NYAN.*, NYAN balancer (comprised of mixed NYAN.* holdings), BMF, and CPA is a fairly small stake at the end of the day and would not allow you to retain control of a 51% majority across all of your companies.

As an aside to troll you (from her to the next quote), how's it feel knowing that you can't even blame an incompetent, asshat fund manager for losing your $10k investment? You've only got yourself for that.

Ian asked to end all obligation to CPA and end the insurance contract. He had enough in store to I believe fulfill the full term of the CPA contract however wanted out because of the clusterfuck around CPA's liquidity after pirate fell out and a large number of contracts were collected against as a result. In Ian's own words the situation was clouding but Maged's comment simply acted to erase the last shred of confidence Ian had. Even if Bakewell did not have on funds to complete the full length of the contract the askwall maintained on GLBSE during the IPO that became unfortunately drawn out was well in excess of the required premiums, so some fabricated story about Bakewell's lack of funds is complete bullshit and exactly the kind of misleading statements (if not outright lies) that Maged was referring to. Additionally Ian attempted to work inside the terms of the contract to accelerate the normal return of funds per the contract, the same method that helped keep BMF from ever seeing a bitcent claimed against the insurance they were forced to buy.

To reply specifically to your points:
1a) Even if he was in default of his contract I fail to see how that constitutes fraud.
1b) He attempted to act on behalf of his investors (excluding yourself) who voted to terminate the contract with CPA, you changed the terms repeatedly on him attempting to avoid following through on your commitments made to Ian
2) Maged's comments surely let a few more people see what kind of crap you were pulling, hats off to him. My condolences to the people who lost money investing with you between your initial unscrupulous actions and his comment observing them.
3) There were several different interpretations of your poorly written contract, I believe the consensus was that the coins should have been returned to Ian and allowed be retained in the company for investment instead of being sent to investors against their will.
 
Unfortunately I am not able to see your deleted posts or the contracts inside them. My understanding is as follows:
-The contract was signed by the head of BMF and the head of CPA, as usagi was both this made negotiates extremely simple.
-Total premiums were 550 BTC, total coverage was 500 BTC in 100 BTC increments
-The contract was presented to investors as security that should BMF lose value (in the form of NAV) CPA would pay, thus insuring the value of BMF
-Due to poor market conditions and poor management BMF lost value after paying some premiums (I am not able to find the address currently, usagi says this was less than 100 BTC)
*** Here's where the conflict of interest and your failure to handle it correctly comes in, watch closely
-BMF chooses to "accelerate" their payment of premiums with the money that should have been used to insure NAV of BMF
*** A good chance to check how you should handle such a conflict of interest is "Would this be the choice of an operator who wasn't also in charge of the company providing insurance?" I certainly wouldn't, and I can't think of any reasons to.
-CPA pays out nothing since total premiums were in excess of coverage
-BMF still owes 50 BTC in premiums above what would be covered by insurance
-BMF investors were forced into a lose-lose situation without a motion and told they were protected
-If this were simply an experiment I see no reason for the net value of the contract to favor CPA, and I imagine that if it didn't matter CPA should refund the premiums paid since it was just for fun, or it should act the way it was advertised to shareholders as a way to protect the value of their investment and act in there favor instead of against it.

If you believe I'm still lying please let me know where the lie is, if you believe my semantics are incorrect I can restate as needed.
-BMF's total obligation to CPA was 550 BTC, the majority of which was paid through the address that I don't know and can't find usagi's post to or "accelerated" to CPA in order to avoid burdening CPA with their liabilities.
-usagi failed to properly resolve the conflict of interest.

Why would a good manager not claim coverage that was due? Why would a good manager lose 50 BTC across the lifetime obligation of a contract for no reason? How could such a risky venture like BMF get insurance if they were guaranteed to lose money?

The only thing I can see being misrepresented is that BMF was insured. Further the fact that BMF lost NAV is fine, shit happens, that's why they bought insurance (or maybe not I guess, it was just an experiment for fun), except when advertising to investors. (Man, how do you keep all this shit straight usagi?)

Also are these comparisons made on BTC value or USD value and across what timeframe? I don't want to let silly things like facts get in your way but I remember a lot of your valuations (that I can't see anymore) changing both of these in your rose-tinted view.

My apologies for messing up the semantics again. As I've already mentioned BMF was obligated to pay 550 BTC over the life of the contract for 500 BTC in coverage, leaving a difference of 50 BTC. When BMF was able to claim coverage it was avoided by "accelerating" payment of premiums but even once all the premiums owed were paid BMF was still liable for 50 BTC in premiums beyond the coverage they could claim.

-Did you or did you not act as BMF's representative in forming a contract with yourself acting as CPA's representative?
-Did you or did you not fail to act in such a way to best benefit investors of BMF in favor of CPA in a way that a third party would not have in resolving your conflict of interest as the head of both BMF and CPA?

-Will you or will you not provide substance to your rebuttals instead of just yelling that I'm a blasphemer insulting your indulgent godhood?

Or we can play it your way. usagi's an incompetent sack of shit that can't run a single company anywhere except straight into the ground. The end. Get it? (That also means you're not allowed to argue, just in case it's not obvious. I said "The end" what more proof do I need (I EVEN called you names and slept with your mother))

---

When I thought it was done:
Great, another self-centered piece of self-glorification. These new business ventures are what's calling you into question. Your first businesses were a trainwreck in the best light. Frankly I can't see any of your old posts about how you sacrificed everything for your fellow comrades who fell at bad luck due to some incompetent oaf because you've deleted them. If you've had to sacrifice to cover your losses I feel for you but that's the way you chose to play the game. (And for the record I believe Goat also had to let go of a few of his personal effects to make ends meet during some of the rougher times after the pirate fiasco).

I was just going to unwatch the thread, but crap like this annoys me. The only reason this post is written in third person is to make it sound like a third party is vouching for usagi. Saying "I did things" sounds a lot different.

As far as scam accusations I'd like to add the following
6) Voting as a shareholder with interconnected stocks and personal shares.
-"Shareholder Majority" was replaced by the number of shares Usagi wanted to vote with. I believe one poll was even voted on by more shares than were outstanding before or after the vote (made active by transferring to Usagi and then back, or voting with non-voting shares).
-This voting also happened on non-action polls like "Is Usagi doing a good job?" for all the obvious reasons.
-Actual shareholders are the victims in this case held hostage to usagi's whims

7) Usagi first promised then rescinded on Bakewell insurance saying that it would be refunded at first if Ian wanted, then if the shareholders voted for it. After the shareholders voted in favor of reversing the insurance, then only if a dividend of the same amount was paid, then finally relented to if Ian promised to pay out a dividend of equal amount after
-Ian's link to here for the relevant start
-Ian's later post in the same thread here with his added emphasis on PMs between usagi and himself where usagi agreed to refund pending a motion.
-Bakewell shareholders and Ian are the victims in this case, Bakewell was held hostage to usagi denying repayment, Ian while usagi tried to drag his name through the mud for trying to end his affiliation with the "upstanding" usagi and illiquid CPA

BMF's CPA insurance plan, usagi failed to properly resolve a conflict of interest
-BMF paid 550 BTC for an insurance policy with CPA to insure against loss of NAV
-BMF lost NAV (as with most of his funds and attributed to poor abilities as an investor)
-usagi chose to "accelerate payment" on BMF's end to the amount that would have been collected from CPA
-BMF was still on the hook for the additional 50 BTC above coverage paid to CPA
-So either
*usagi acted against BMF's interest and bought overpriced insurance from CPA without a shareholder vote
*usagi acted against BMF's interest by accelerating payment unnecessarily
-BMF shareholders were the victim to usagi doing whatever he wanted and then voting with his own shares as in example 6

In this case each miner would receive work with the target adjusted such that on average each would report back once per second. The slower hasher would get a lower difficulty share (though solving a sharechain block would be just as hard for either one) and the faster hasher would get a higher target so they still report back once per second.

I was wondering if this could be changed by the server/node (to reduce how often they're contacted) or by the client/miner (so they didn't have to report back as often/more often). Less often leads to lower badwidth and less time used waiting for the server's response to the submitted work, lower times give a more accurate picture of miner performance at the cost of more overhead.

I don't have any particular need, I can make up use cases (miners over local network who don't care about server and network usage, wanting to reduce overhead, and wanting lower variability in stats) and I figured it would be similar to setting share difficulty manually at the miner using :diff syntax on the username. Wouldn't have known without asking basically. In truth I could see this being abused much more than it's worth by people trying to tweak their statistics and making overall performance worse.

Is there any way to configure the period server or client side?

If you're mining on your own P2Pool instance it's not an issue anyway. If you're mining on someone else's P2Pool instance then you're already becoming more centralized.

It does defeat some of the ideological niceties of GBT, but it's still an optional flag (Stratum has similar from what I've heard, though it's off by default, instead of on by default with this proposed compact flag).

You're missing a semi-truck barreling down the road at you. The coinbase rolling that P2Pool uses is different because of the way p2pool payouts happen. While it may not be impossible having miners roll the coin base (and by extension, the whole merkle tree) may be harder. I don't know enough to elaborate but you seem to be completely ignoring what forestv is saying.

Given what else was said and assuming the other issues can be worked out stratum may be a better choice then, mostly because of bandwidth. GBT and Stratum both offer some modification to the coinbase (GBT through "coinbase/append" flag and Stratum through how the coinbase is always built to identify each miner).

Maybe it would be worth adding a "transaction/compact" flag to the GBT request and allow it to respond with just the merkle branches instead of the full transactions. If my logic isn't too far off that would close the gab between GBT and Stratum based on bandwidth usage.

Then this may be less of an issue than I expected. I'd imagine it depends some on the hardware it's being run on, though I have no idea what you're running your node off of.

It may be easy enough to just give out work that has a 1 minute old timestamp and just allow 2 minutes of rolltime.