If you're still doing SPV mining, you are doing it the wrong way.  It is bad for the network and there is absolutely no way to try to spin it to state otherwise.

That's because most ASIC suppliers are run by people who have no fucking clue how to run a business or how to follow the law.  Bitmain is actually doing the correct and legal thing.

With Stratum, each connection is assigned unique identifier that is inserted into the coinbase transaction.  This prevents two connections from hashing the exact same headers for the block since the coinbase will never be the same on two different connections.  

Since each connection has its own unique identifier, you couldn't route your hashes to different connections running at different difficulties, since the hash would only be valid on the connection assigned to that identifier.  It's similar to how you can't take a block solving share and submit it to your own wallet, since changing the destination wallet of the coinbase would change the hash, meaning it no longer would meet difficulty.


Obviously, this all assumes the stratum implementation was done properly.  AFAIK, no pool has ever been known to have screwed up this specific part of the stratum spec.

No pool should ever submit empty blocks these days.  BTC Guild had 3 out of 32,000, but I would wager all 3 were probably in 2011 (*maybe* 2012).  Back in the days where the mempool could actually be empty for a brief period if the network solved multiple blocks in quick succession.  These days, that is virtually impossible.  It would require a miner to receive work that contains *every* tx in the mempool of that pool, find a solving share, submit that share, and have the pool coin daemon validate the block before a single new transaction is seen.

With the network almost always at 1tx/sec+, it's extremely unlikely all that happens before a new tx is seen.  Additionally, somebody else would have to solve another block with the empty work that pool provided.  This means 30-60 seconds after the pool solved the previous block (depending on how frequently they push work updates).  So on top of the unlikely scenario of a mempool actually being empty from a block solve, the pool then needs to be extremely lucky immediately after.

A few larger NMC withdrawals got hung up because the hot wallet ran out.  It will be refilled tonight and the withdrawals that failed will be re-processed.

Obviously, the 9/30/15 original shutoff date is being extended because of how many people decided to wait until September 20th+ to log into their accounts.  The exact length of extension hasn't been determined yet.

Your opinion/belief is objectively wrong.  Any pool that not only causes significant problems in the network due to using SPV mining instead of a fully validating node, but then states openly that they have no plan to stop doing so after it has been shown to be a problem, is not even close to one of the best pools around.  This isn't debatable, it is objectively damaging to the network for a major pool to be doing this.

Just make sure you collect a ton of information on who he is *exactly*, including tax identification, because otherwise you've just been an accomplice in money laundering.  And good luck defending yourself on that, when somebody paid you money just so you could give them a lesser amount of different money back.

Closing in on the September 30th close date.  Since there is still a continuous trickle of withdrawals (10-20 per day), it is likely this date will be extended.  There will be a temporary placeholder when the servers are pulled in early October out of colocation.  A new withdrawal-only version of the site will be setup to continue allowing withdrawals.  Accounts that had not been emptied by September 30th will have a fee deducted to cover the cost of continuing to run servers for a service that has not been active for over 100 days.

It was pointed out in the post above yours if you read it.  Slush converts the NMC to BTC and credits it to miners as BTC.

Slush wasn't merged mining for over a year, it only just started up again (I assume it's an option on the site somewhere to opt-in to receiving them).  And while 1 NMC = $0.40, a pool only generates ~2.5 NMC blocks per BTC block.  It's hardly a "lot of coin" compared to the BTC being taken in via fees.  EDIT:  Okay, it's actually about a 20% increase in pool revenue for a 2% fee pool if they keep 100% of the merged mined NMC.  Of course, selling that many coins will drop the price quite a bit.

Just a case of a clueless user...your internet is not routed through your Cable/DVR box on AT&T (or any other ISP that also provides video service).  They're hooked to your service, but they're not in front of your computers.  They probably have the DSL Modem+Router and then a second router behind it that they plug their computers into, and have only opened ports on the internal router, not the DSL Modem+Router combo box.

This seems to imply that BIP100 is somehow still Bitcoin Core.  BIP100 is not core either. BIP100 doesn't actually exist right now, there is no implementation in any client.  Until it actually gets merged into Bitcoin core, it's no different than BIP101 requiring a separate client implementation like BIP101 and XT.

As of right now, BIP 100 is also defecting from Bitcoin Core.

There's 3 options:
1) No change (bitcoin core as it stands today)
2) Bitcoin With BIP100 Hardfork (doesn't have an implementation in ANY client)
3) Bitcoin With BIP101 Hardfork (has an implementation in Bitcoin XT client)


Unless BIP100 actually get implemented into Bitcoin core, it's the same situation as BIP101 with XT.  XT as of today is literally just Core+BIP101.  The client has other features, but the only protocol level change is BIP101 enforcement once certain criteria are met.

Not a miner here (or anywhere anymore), but just going to promote BIP100 nonetheless.  Given a choice between BIP100 and 101, I would strongly favor 100, since the exponential increases in BIP101 last far too long to be considered reasonable.

Just because people have asked me a few times due to my involvement in mining over the last 4 years:

I think we MUST have larger blocks implemented in under a year.
I do NOT think BIP 101 is the right choice due to rate of increase being absurd.
If forced to pick today, BIP 100 is the best choice at this time.


However, if BIP 100 is implemented, conversations should begin IMMEDIATELY in terms of planning how to increase the max block size again down the road, to come up with a solution to allow organic growth that doesn't put all the power in the hands of a few massive mining farms.  If BIP 100 happens, it should not mean we stop talking about block size.

1 in 2500 chance that any block a pool solves is 99.96% CDF or worse.  That is a fact.  Slush has solved just under 25,000 blocks.  Over an infinite number of samples of pools with 25,000 blocks solved, you would expect the mean number times the pool encountered a 99.96% CDF or worse block to be 10.

Now if you go through slush's history and find 20 times that there were 99.96% CDF (or worse) blocks, then you might have something.  Or maybe if you find that in the last 5000 rounds it has happened 5 times, you might have something.

Otherwise you're trying to claim something shouldn't happen when it clearly SHOULD and WILL happen multiple times in the lifetime of that particular pool.

Not only is it not unlikely, it's extremely likely and has SHOULD have happened multiple times.

It's not 0.04% of it happening ever in the lifetime of the universe.  It's 0.04% chance *on any block* that the pool solves.  Slush has probably around 25,000 blocks under its belt in the history of the pool.  Meaning it could have happened 10 times on Slush and it would be *exactly* within expectations.  And with such an unlikely event and a sample size of only ~10x the expected rate of occurence, even if the pool has had 12 rounds at that 99.96%+ CDF, it would not be a statistically significant deviation from expectation to cause alarm.


(Note:  25k is probably a conservative estimate used for illustration purposes, estimated by using how many blocks BTC Guild solved in its lifetime, which is shorter than Slush's pool lifetime, but BTC Guild was larger than slush for the majority of its existence, so they're probably similar in terms of total blocks solved).



EDIT:  Actual number:  24,580 based on the Slush website block ID.  I know there's been a few IDs that were skipped due to a block being put into the database multiple times, so lets say 24500.  Pretty much changes nothing stated above.

It would actually be trivial to implement it via an account flag.  The only thing changing if you want to vote for XT is a version number on the block header.



#1 and #2 are the same.  Bitcoin-XT is a CLIENT for a BIP101 Hardfork.  All the bullshit people keep raising over blacklisting and IP tracking is CLIENT SIDE denial of service measures.  They are not protocol level changes.  They could be implemented in a Bitcoin Core client and probably have been by people already that have been trying to do blockchain analysis and de-anonymization analysis.

It really is...for some reason I treat the Bitcointalk forums like IRC/real time chat and end up posting the initial thought and editing it to complete it.

Stop using Windows XP.  If you insist on continuing to use an obsolete operating system, you'll have to use Firefox which has it's own SSL implementation that can handle ECDSA certificates.