I would expect about 9% variance due simply to random chance if this metric were calculated with a sliding window of one day. I would expect even larger variance if that sliding window were smaller (as appears to be the case here).

Note that there is also a strong periodic daily cycle causing swings up and down, and almost certainly due to those miners turning their machines off at night.

Again, that isn't any different than with double-spends. ByteCoin posted a double-spend attack exploiting segmentation just a few posts below Satoshi's in the thread you pulled that quote from. From a technical perspective the two cases are identical. In either case it could happen accidentally or maliciously that transactions are invalidated due to a double-spend or timeout. But I reiterate my original point #3: it's not exploitable, short of a 51% attack (a network segmentation attack being a funny sort of 51% attack).

Keep in mind we are talking about the stars aligning under already extraordinary, unpredictable, and exceedingly unlikely circumstances. I would like to see the chances of this calculated and compared to, say, being hit by a deorbiting satellite, or being struck by lightning twice.

Unless it's exploitable, in which case show me the protocol.

I did some simulation of blocktime variance (assuming honest nodes, and after calibration for network growth) for various difficulty adjustment intervals, posed on the freicoin forums. The nifty chart is copied below. The difference between one-week and two-week intervals was negligible, and is what I would recommend if a shorter interval was desired.



A 24-hour interval (144 blocks) would have a variance/clock skew of 8.4%--meaning that one would *expect* the parameters governing difficulty adjustment to be in error by as much as 8.4% (vs bitcoin's current 2.2%). That's a significant difference. A 1-week retarget would have 3.8% variance. Twice-weekly would have 4.4% variance. I certainly wouldn't let it go any smaller than that..

I am 100% for DIGEST160 stuff. (Along a similar vein, CHECKSIG should have been four opcodes from the start: LOADTX (to stack), DIGEST, SIGN, and VERIFY, and we could use better escaping than CODESEPARATOR provides.) It would solve problems now while a better, more general solution is being hashed (hah!) out.


But be very wary of an OP_EVAL. Allowing execution of data is extraordinarily powerful, and extraordinarily difficult to secure. Attackers could do things like cause infinite loops, or rewrite a TX script to always pass. The semantics of eval() are notoriously difficult to pin down.

That said, my company is implementing a bitcoin-like crypto-token system featuring Lisp as the scripting language (with eval, lambdas, macros, and all), and I was primarily responsible for the decision to do so. So I both speak from experience in warning of its danger and difficulty, and simultaneously as a strong advocate for it, if done right.

Cool points for quoting Satoshi, but I'm afraid that line of reasoning doesn't hold up. During the reorg the client needs to revalidate transactions to prevent a double-spend, and in the case of a double-spend those transactions will go VALID -> INVALID in the reorg (if not, this is an exploitable hole; PM me if you run a large mining pool ).

Yes, just as with the double-spend case it is possible that there might be transactions dependent on the now-failing BLOCKNUMBER/UNIXTIME transaction that don't get included either. However there are three points to be made: 1) this is no different than the analogous double-spend situation; 2) it would only happen if the 2nd and following spenders do not each wait the usual number of confirmations (making “tough luck” appropriate IMHO); and 3) it's not exploitable.

theymos, can you provide a reference for that? It's not an intuitive result.

EDIT: to be clear, once accepted into the blockchain BLOCKTIME or UNIXTIME would return the block number/timestamp of the accepting block. I thought that would be obvious, but just noticed it hasn't been explicitly said by anyone. Does that fix the issue you are referring to?

Why make the address a hash of the script? Unless the scripting system allowed Lisp-like code-as-data interpretation of scriptSig (it doesn't, but I'm working on a blockchain that does), you'd have to have some sort of system for resolving hashes to actual scripts. There I see two approaches: the client looks at all existing transactions to find a script which matches (so you'd have to publish a 'model' transaction first--this would serve a different role than current bitcoin addresses), or some sort of centralized or federated resolving service (a DHT?). I'd rather just distribute the scriptPubKey itself, base-58 encoded with a checksum and a different prefix than the current address format. But I can see the merits of both.

I approve of adding BLOCKTIME and UNIXTIME opcodes (which is actually a separate issue from nLockTime).

For your dummy transaction, I think that's the wrong approach. This is a “problem” that should be solved outside of the blockchain. I put “problem” in quotes because the only time this would be useful is when you have two devices connected to the Internet (because they are both reading the blockchain and sending transactions). In which case.. why not have them talk to each other directly? This shouldn't be solved at the blockchain level.

For your chargeback suggestion, you could implement that by putting an optional lock time and revocation script on each output. However I would never implement this because undoing a transaction mould have all sorts of bad effects. If the transaction included fees, for example, those would already have been paid to the miner who might have spent them or transfered them. Then what do you do?

Public key operations in bitcoin are done by signing and verifying signatures of a hash of the transaction. That hash will be different for the two transactions (so claiming one transaction wouldn't reveal anything useful about the other). It might be possible to make them the same with an OP_CODESEPARATOR and appropriate SIGHASH value, but that's more work than it's worth because you can do the same thing by making the secret a nonce in the scriptSig, and comparing with its hash in scriptPubKey (you'd just have to exchange one-time hashes in a separate secure channel).

However both approaches still suffer from a more fundamental problem. As far as I can tell--and I spent some time working on it--there is no way to design a protocol without introducing new opcodes or enabling transaction replacement that doesn't enable one side to claim both coins if they're dishonest.

If you're going to add something though, you might as well provide basic AES primitives for various modes. And while you're at it, raw ECDSA sign/verify primitives (operating on items on the stack rather than just the transaction). Most everything else can then be composed.

jtimon, you're conflating signature operations with secret keys.

I'm not sure why there has to be voodoo involved. Most of the bitcoin network is GPU-based (at the moment). Modern GPUs can perform true floating-point operations. So get the most popular GPUs in use, get their IOPS and FLOPS ratings, and use the median ratio for calculating the Guinnes world record value.

Multi-sig is being discussed here. Multi-sig is a primitive operation that would enable quite a few of the contracts described here and on the wiki.

How could you not suspect a laundering operation? Look how white that labcoat is! ------->

They're not disabled because there are known attacks against scripts using them (although there may be for some), they are disabled because they are not needed (yet).

EDIT: I stand corrected.

Miners will have to set their fees somehow, and spenders will have to have some expectation of what a reasonable fee is for quick processing. In both cases an automatic method would be preferable because people don't have time to stay up to date with the details of the network and set reasonable policies.

This would provide a reasonable default (from which you can opt-out of course). I'm not sure how that's any different than the current policy, except it's less arbitrary.

You are either ignorant, or tin-foil paranoid.


EDIT: That came off as mean, which was completely not my intention. Attacking SHA-256 in the mannor you describe would require either a) a computer larger than the known universe, or b) entirely new mathematics. During it's development, millions of dollars and many person-years of researcher time were spent demonstrating that, among other things, SHA-256 output exhibits no statistical correlations of any kind, exploitable or benign. Since then, it has been the target of continued cryptanalysis by some of the best and brightest minds around the world, and every crypto grad student that wants to make a name for themselves.

So again, if you think believing that no such statistical correlations exist is "naïve"... you are eiher ignorant of what I just described, or tin-foil paranoid.

It might be a good idea for the downloadable reference client (opt-out of course), although obviously not for mining platforms that enforce the security of the network.

I am in greater fear of an attacker finding a flaw in the client software and continuing to exploit unpatched nodes than, say, Gavin's keys being compromised and a fake update (with a back door) being issued.

But for that reason I don't expect automatic updates would never be implemented. If you fail to patch your software, it's your fault. OTOH, if Gavin's keys are compromised one could make the case of (criminal?) negligence against him.

Why wouldn't there be a need?

Once generation of new coins tapers out, there will have to be sizable transaction fees assessed each block, to ensure there isn't a reduction in security of the network. Once bitcoin goes mainstream, there will be orders of magnitude more transactions being processed per-block, and a commensurate increase in the size of the blockchain.

I've played around with some economic models of what per-block transaction fees would be needed to maintain the security of a mature, stable monetary base currency and avoid a tragedy of the commons. Working backwards from those goals and the network parameters, one can arrive at an estimate of the minimum necessary per-tx/per-kB transaction fees. The network parameters are continuously changing, however, so occasional re-adjustments would be necessary, just as is the case with the difficulty parameter.

The bitcoin developers are continuing to tweak the transaction fee parameters and rules with each release. Automating this process would not only make the network safer, it'd take a lot of the heat off the backs of the core developers making these unpopular choices.

@hashcoin: that's the case for a second-preimage attack, but I believe my statement holds for a first-preimage attack, no? The importance of that distinction depends on the application of course, but to use your own example it wouldn't much matter if you could find a different key that maps to the public hash of my secret/private key. Regardless of its hash, if it's not the same key you can't use it to decrypt my messages or impersonate me.

I'm *not* trying to increase the bit strength of the encryption (the sort of security that increasing the keysize would give), but given that I've reapeated that three times now, it's probably not worth our time to get that point across.