Slush is both intelligent and thoughtful and cares about what happens with Bitcoin. I've never seen him do anything for a quick buck.  Your unkind words here are unjustified and just make you look foolish.

Yes, barring implementation bugs it behaves just like a normal node externally.

Wow. I'm really disappointed to see this misinformation still being promoted. It is completely untrue.  It's perfectly possible to solo mine and solve a block with your very first hash operation— just unlikely.   Assuming an idealized zero latency zero fee pool your expected return is the same either way.  With real pools its somewhat lower compared to a well maintained local node solo mining (although that may be something of a stretch, the reference client has some scalability / stability issues that make maintaining it harder than should be, but we're working on that).

Sequential trials of N months each isnt the right way to think about this. There are sequential trials— but they're happening billions of times a second, one for each hash operation.   A better mental model is to imagining forking off 2 million copies of the universe, a million solo mining, and a million pool mining. After any span of time the average of each of the groups would be the same (minnus pool fees and stales from latency to the pool, and differential maintenance quality in each), but the distribution would be different: in each of the pool universes you'd have a similar amount of coins, while in the solo universes some of you would have nothing, some would have the expected, some would have an enormous amount more than expected, but the over expected would match up with the under expected and the result is the expected average.

Or you you can think about it as choosing between two lotteries to play, one has a 1/1000 odds and pays out $0.98 (2% fee) for each win, and the other has a 1/1000000 odds and pays out $1000 for each win. Playing the lotteries cost the same, and you can play them thousands of times a day. Sometime in the future the relative odds will change but the payouts will stay matched. Which lottery do you prefer to play?     If not getting $.98 right away would make you die of dehydration then the pool is a clear win... otherwise it just depends on your relative risk tolerance and how you value your time. If the risk reduction and time savings doesn't justify the pools fees and hazard to bitcoin security (even if just theoretical: FUD hurts bitcoin too) for you then you should prefer to solo-mine.  (Or P2Pool!)

Difficulty changes don't make a bit of difference in this.  If you instead think about hash rate in terms of percentage of the total you can pretty much ignore the difficulty changes entirely.  

As a long time user of Bitcoin and a developer: Thank you for taking a firm position against making dust payouts. Blockchain bloat is no one's friend, and tiny outputs will likely never get spent— meaning they'll bloat the txout set perpetually.

I've seen fairly little evidence that the botnets are especially big factors (especially since many of the pools will block them when discovered), though they're something of a factor.

There are a great deal of other factors though.  Mining is— once established— passive income. As long as their GPU keeps spitting out coin many people are not in a rush to mess with what works.

There also has been (and continues) to be a widespread misunderstanding of mining: a lot of people fervently believe that mining is like a race: the fastest wins almost always, and they expect a non-linear increase in returns from being in the biggest pool.

Some of the larger pools have used tools like google adwords to promote themselves in the past too— with high fees that smaller pools an decenteralized services can't collect they can afford more marketing and polishing work.

This subject is a concern— but we're much better off now than where we were a year ago.  And the concerns are somewhat overstating the risk. Miners can and do switch pools pretty quickly (e.g. automatically), and more recently developed miners like BFGminer have checks which can automatically detect some kinds of pool treachery. "no one here or anywhere else can prove me that dozens of computers contributing more than 51% of network processing power is better", doesn't of pols is not the same as "dozens of computers contributing more than 51% of network processing power"

It doesn't not look like a bottleneck. It provides a factor of four billion in reduction in whatever serial task exists outside of that. I have yet to see any evidence that it's a bottleneck.

As an aside, many people searched and none could find an orphaned block in their storage (bitcoin stores all blocks lost in reorgs) which contained a double spend against the main chain, making their claimed attack vector very unlikely. Moreover they refused to provide a copy of their blockchain file, which would have conclusively proved the attack. In light of this I believe it's far more likely that they gambled away or just outright stole the funds.

In any case, Bitcoin "takes advantage of the nature of information being easy to spread but hard to stifle"— you only need one honest connection to resist this kind of attack, and the attack can't be performed against reasonable client software that enforces a reasonable number of confirmations without a considerable cost in producing doomed blocks.

Then don't mis-design your hardware in the first place. Seriously, if you can't do the small bit of multiplication to figure out what your bandwidth requirements will be then you _have no business making mining hardware_, operating pools, etc... Nothing suggested avoids changing design and adding costs. At best the suggestions externalize cost on future bitcoin users.

I embedded the quote steganographically in the wooshing sound you heard as you read my response.

… The paper was written something like a year before the publication of the system. It covers the core concepts but omits things such as the script system, which is easily the most complicated part of a full node implementation. Since the paper covers _very_ little of the actual implementation, including a number of critical design decisions (I provided some examples of uncovered things), it would have been surprising if it _had_ mentioned extranonce.

Because:
(1) None of them were about ASIC mining. So I had to assume you were confused, and given that you are confused all bets are off.
(2) BIP 22 is primarily documenting (and cleaning up) an API we've had since long before 0.7; we merged it from forrestv in Septemberish 2011. So your talk about new in 0.7 more or less precluded it.

HUH? GBT is a rename of the poorly named getmemorypool which we've had for a long time— much longer than anyone was talking about 1TH/s mining devices— it's used by pool daemons and p2pool. Mostly for dynamic coinbase creation (e.g. to do fancy payouts) and because bitcoind coinbase creation is somewhat slow (it's synchronous, single threaded, and basically completely unoptimized).  The changes made in 0.7 beyond the rename were some extra fields to remove a potential DOS attack where some of the limits couldn't be properly enforced when the caller does dynamic transaction selection, support for the height in the coinbase, and some general cleanups to make it more 'designed' than accreted. BIP 22 makes no mention of 'asic', nor do the pull requests for the changes, and I don't believe asics _ever_ came up in discussion related to it around the reference client's development.

To the extent that GBT is useful for higher speed miners getmemorypool was absolutely as useful.

The same place scripts are referenced as well as locktime and nbits.

It's awfully hard to work out what you're talking about when you haven't the foggiest clue about what you're talking about yourself.

We are not and have not.


Wtf are you talking about.


Extranonce has been part of the design since day one. It was the only way to make your coinbase transactions have unique IDs other than constantly changing to a new public key whenever you update the candidate block. It's fundamental and is required for things independent of the nonce size.


A _4 billion to 1_ work factor is pretty reasonable. There are a couple tradeoffs here. Header size is utterly critical for SPV nodes of various kinds, and even adding a single byte to the header increases the size by 1.25%. Having too much workfactor ratio between header only work and block update work encourages miners to build devices which never process transactions: Cheaper to just build a constant root with no transactions and increment the header until you solve a block. On a fresh design I may have given a bit more space to nonce, sure. But there is no need to change it now.


Yes, in fact it will.


Huh? The P2SH deployment went pretty smoothly.  About the only bad thing that came out of it was that we discovered Bitcoin had a bug in handling large reorgs with lots of transactions.  Timed less well— with large miners unable to reorg because of it— this could have been pretty fatal for the network. But since it only really impacted non-mining nodes (plus the tiny minority of non-updated miners) due to fork being invalid P2SH it was harmless. It's very fortunate, because I'm not sure we would have discovered that BDB issue even by now wthout it.


That we're not permitted to throw you into a volcano.

Thats no magic bullet.  It may be protective against "omg regulators exist; PANIC!" ... but it greatly increases exposure to  "Hm. Think I'll just take everyone's funds."

"securely anonymous" identity is cheap... and it must be cheap if anonymity is to be functionally available for people... so an operator of such a venue could just open up a second supposedly independently run clone and when people start to trust the second a bit they just pop the first and vanish with the funds. People then switch to the second, and they quitely spin up a third. etc.

The better advice is don't skirt laws when you're not pre-prepaired to deal with the consequences; and don't put your funds with obvious centralization targets which aren't at least making comforting sounds about their legal status.  (I've cautioned people about various webwallets which offer secondary services like "mixing" and gambling frontends as risk factors— asset seizure for these other things will give you a bad day none the less).

It's ridiculous, completely unnecessary, and craps on one of our very few backwards compatible upgrade mechanisms. Backwards compatibility means we may need to put some data there in the future— since even incrementing the version can't change the layout without creating a hard fork. Perhaps worst of all, it's simply tasteless. The version field? really. yuck.

Even a fairly slow computer can do extra-nonce advancing for many TH/s, esp once considering a few bits of ntime rolling— well, at least if someone doesn't insist on writing their SHA256 in javascript or other ultra slow interpenetrated language... And all these TH/s are not free. If someone can't manage a modest CPU or two per hundred thousand dollars in mining asics then they have a financial management problem that no amount of protocol fiddling can fix. Certainly it's not healthy for the network to encourage miners which are so CPU starved they can't even afford to update their coinbases enough to keep up with their hardware even given the ~2^48 work reduction that they get from nonce plus ntime rolling.

As far as communications goes, presumably people engineering products that cost as much as a nice car are smart enough to not use lawnmower wheels on it when it needs tank treads. If they aren't then I feel bad for their customers for all the other bits of the design they'll get wrong. But since its totally unprecedented that some mining hardware maker would produce a horribly mismatched design which did something daft like provide their hardware with a fraction of the required power supply we should have nothing to worry about…

Validating that use of height is actually stateless in script would be horrific and more or less intractable. If script were designed so that there was a table of redemption options which had their own lock time then it could have been done... but alas.

It's no big deal in any case:

You are selling me your car. We decide to use a 2-of-2 escrow.  But I'm afraid you'll hold up the funds if the deal falls through.

I compute the payment into the escrow and sign it. But I do not announce it yet.  I also compute a transaction spending the escrow transaction and paying it all back to me with the locktime set some months from now.  I sign that transaction.  I give it to you (along with the txout its spending but not the whole payment). You can look at it and confirm that it is indeed unlocked until whenever, so sign it and give it back.  Then I announce the payment into the escrow. You don't need height in scripts to get refund timeouts. QED.

Or into a multisig escrow.  If people are interested in that I can help set it up, and would be willing to act as an arbitrator for its disbursement.

Transaction malleability has been known and discussed many times— including padding and other encoding differences. Is there some reason that you believe the s-flip to have distinct implications from all of the other signature encoding differences?

The understood risk of this in prior discussions has primarily been that troublemakers could create confusion by changing the transaction ID of confirmed transactions to be something different than the transaction participants were expecting (so, e.g. they'd see two transactions doing the same thing, one which never confirms). There is a secondary risk that parasites could 'hijack' other people's transaction to pay the way to embed data in the blockchain for them.


In the reference client the spent-ness of candidate inputs when drafting a transaction are checked with IsSpent(), the txid of the spending transaction should be irrelevant. Can you elaborate on what you're thinking here?

It's just more clearly confused now.  The confirmation count is the number of blocks following when the transaction was initially confirmed. Every block implicitly confirms all prior in its chain because you couldn't have creates that block without processing all prior ones. Leaving transactions out has nothing to do with it... the effect of leaving transactions out is only that new transactions won't start getting confirmations.

This is confused.

Yep. Moreover, the price has already gone up. GPU mining is loopy profitable again... rate is still catching back up, no doubt tempered by expectations of incoming asics.

I haven't considered if your newly proposed rule is sufficient yet or if it's otherwise dangerous.  But it's deployment would be a fork risk unless it had super-majority miner support. Otherwise an attacker could intentionally split the network.

Two ways:
(1) If there is an unlikely moderately long gap between the median and now (5 blocks in 24 hours) he can just directly mine one block with a violating timestamp.
(2) Since you're already postulating majority hashpower attackers, one could replace the end of the chain with a violating chunk.

I wasn't saying that it isn't a concern, I was just cautioning against overstating it.  I'm not sure about the "order of magnitude worse" part— at the very start it's going to undo four weeks of transactions. That there is also a bunch of new coin created just increases the incentive to for the collective users of bitcoin to voluntarily kill the fork by checkpointing against it at its start point four weeks ago.

Getting a conservative rule in that kills these but which has hopefully never been violated by the mainnet would still be a good idea.  If nothing else the timewarp complicates explaining the security model of Bitcoin.  ("…such an attack can only do X/Y, except for this bug, also allowing Z but doing that is much harder than a simple overpowering…")