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…")

No. Not quite. The bitcoin protocol has no concept of balances. A new transaction redeems old transactions. Transaction can only be redeemed once. Think of coins and the network is a forge that can combine them and split them.   You can write a transaction which can't be included in the blockchain until a particular time/height.. but it has to identify which coins it's spending. Not balances. Groups. Etc. The specific coins.   And until its in the chain you could spend those coins out from under it.

It doesn't just require a simple majority, the chain must also be forked more than two weeks in the past (and at just over two weeks in the past it would take a long time to push the difficulty down), then must catchup and overtake in sum difficulty.  This is _much_ harder than just a majority. With only a 1% advantage you'd be toiling for a very long time in secret to overtake after cutting month back.


I don't think that rule is sufficient.  You can tick the clock just 1 second per 5 blocks without advancing forward the oldest permitted time.


 I put a timewarp attack in the testnet3 chain to make it easier to test out rules to deal with it, so you might enjoy playing with that.

No.

Change goes to new addresses. Funds should only go to that first displayed one if you copy that address out of the client and send ones there.

We already have LOCKTIME which does what you're asking, but doesn't do what you want.

The locktime field on a transaction lets you specify the earliest time or height that the transaction can be included at.

It doesn't do what you want because you can't spend an input you don't have— so you'd have to have and freeze the funds you will use in advance. And since they're stuck in place— why not just pay up front?  ... There can be reasons, yes, but I don't think it really fits the subscription use case where you don't necessarily have the funds up front.

 

More than overnight means that something is broken (unless your hardware is very slow or you're running it on truecrypt).

Can you post the debug.log someplace (it will include your IP, so don't if you need to keep that private)