No, the highest difficulty block are the blocks being mined right now, with a diff of ~390,928,787.  Lower hash blocks were not more difficult. They arise by chance and don't reflect the work done to produce them.

At least get the terminology right in your FUD: ECDSA is not encryption.

I believe thats missing the point. The honest miners are being orphaned much more often than the selfish one. The new difficulty isn't "open" to you when you're being disproportionally orphaned.

Changing the header is absolutely not required to pre-forward the block. You simply pre-forward it along with a pointer to where the extra nonce goes, and when you solve it you send the resulting timestamp,nonce,extra nonce for substitution— even less data than the header in the most efficient case.  P2Pool already implements block pre-forwarding (though not that aggressively: rather than deny the ability to add transactions, it preforwards transactions and then sends the Merkle tree+header+extranonce) .

However, "10 minutes on average before they finish" isn't right... the whole network produces a block in that time, not each miner. Sending data only once every block per miner, instead of incrementally, would also massively delay transactions— the delays is not something we should encourage. Preforwarding also uses a LOT of extra bandwidth, because each non-successful miner is constantly broadcasting block data too.

In any case, I think making block propagation faster is useful generally— but you don't need to change _anything_ about Bitcoin to do it. You just need to make a little fast-block-daemon which runs its own protocol to relay blocks and that could be run in parallel to the current p2p network.

It's almost a bit orthogonal though, since a better positioned miner still has a _latency_ advantage. Making the data smaller doesn't beat the speed of light.

Sorry for confusing you there. Obviously any node prefers the highest total work— the protocol isn't convergent otherwise. This is about blocks which have equal work. Nodes prefer the first heard among those with otherwise equal work. The obvious alternative policies create issues like... incentives for large miners to delay their announcements.

It rebuilds the file which compacts it by removing housekeeping space that BDB kept around. It should almost always be smaller.

I wouldn't advise it. You'll reduce your security from two factor to one factor... and the encryption doesn't protect your privacy it only prevents spending/signing. Also, the wallet will eventually go out of sync once you've used up the keypool.

It takes longer to transmit more data, it takes longer to run more checksig operations (the latter reduced somewhat by caching, if the transactions had already been public). Thats it.

They do in the GBT protocol supported by bitcoind, sadly the market chose to use the later stratum protocol over it primarily.   This, I think, is largely offtopic. There is no reason you wouldn't expect the hashers to be complicit in such a scheme: Even if delayed blocks can't be prevented with non-GBT mining protocols, they still can be trivially detected. (E.g. miners often issuing work with non-public prev, big orphan bursts)

Your analysis is pretty incomplete. Their success at winning that "fast as possible" race, along with their total hashrate, is essential. Otherwise a delay is a pure loss.

I'm short on time, and this was announced to the public without advanced notice to e.g. the bitcoin-security list. Making an informed response fast is hard.

Ideally I'd like to think about it carefully, read the paper a few times, and run some simulations before commenting, but I'll likely be tied up at the IETF all week and people are already panicking and pushing for hasty changes in response to this which may be ill-advised, so I'm going to offer some preliminary comments here.

We've (or, at least, I have, see also Bytecoin's analysis in 2010) evaluated this general attack before but the simplest version of it just doesn't work out (in theory, or in simulation): Without significant hash-rate delaying your blocks ends up increasing the risk that you get orphaned since nodes prefer the first block they heard. The contribution of the paper (to my thinking, at least) is to assume that an attacker can also sybil attack the network, and in doing so can run nodes which will release blocks produced by the attacking miners in response to hearing a new block from the honest miners. So where the sybil attack is successful the delay does not confer a disadvantage and then the attack works (with increasing effectiveness the more effective the sybiling is and the more hashrate the attacker has).

Their proposed solution, which is offered without extensive analysis, is to relay all blocks, even late ones, and then choose the preferred block in ties at random. Ignoring collateral vulnerabilities which a hasty implementations of forward-all might create, I believe this proposal has a problem in that it creates a selfishness advantage even without any sybil attack at all, so long as the selfish miner has enough hashrate.  I believe this is a bad tradeoff because the degree of sybil vulnerability between mining nodes is likely much lower than assumed (many miners pin up connections to well known nodes and each other), and because we already have pools large enough to take advantage of the tradeoff vulnerability this creates.

Perhaps more importantly:  There are much worse vulnerabilities for us if attackers can perform successful large scale sybil attacks against miners.  In particular, if they're able to do that they could partition the network into two 50/50 hashrate groups and then drop blocks between them and hand conflicting transactions to each group and produce many-confirmed double-spends without having any hashrate at all.

As I've posted several times of Bitcointalk: beyond the cryptographic assumptions Bitcoin makes _two_ additional security assumptions: That an attacker doesn't control a majority of the hashrate and, quoting Satoshi, "the nature of information being easy to spread but hard to stifle", effectively— that an attacker can't substantially isolate or partition the honest participants.

With this in mind, rather than rushing in any changes in the consensus algorithm I recommend we take the following actions:

(0) Make a new concerted manual anti-sybil effort to ensure that all large miners are well connected to strong relaying nodes, including a mixture of public and non-public nodes (non-public for DOS resistance), in order to make partitioning miners infeasible.
(1) Evaluate our sybil resistance more generally and consider what measures and automation we could add to make sybil attacks harder (including supporting authenticated peering, or measures like including addr messages in coinbase txns to jam addr message manipulation).
(2) Build better stats collection for monitoring network wide orphaning.
(3) Improve node scalability (e.g. make it possible to support nodes with larger numbers of connections)

(Maybe it would also be useful to instrument miner software to detect block delaying, in the same way bfgminer will detect a pool issuing work that conflicts its own prior work)

It may ultimately make sense to change the consensus preference for _very_ near ties (e.g. ones which arrive with time differences comparable in scale to the difference in latency between your peers), but I think we need to be very careful that we don't trade a potentially irrelevant problem (because its either infeasible or if its not infeasible we have much worse problems) for a practically exploitable one.  Making our infrastructure stronger against sybils has many benefits and has been on and off the radar for a long time, and AFAICT if we prevent miner from being partitioned/intermediated by sybils we close the concerns here.

Thoughts?

The implementations were buggy.  In the case of the LSHIFT operator there was a remotely triggerable crash. All the operators that changed the sizes of types basically got disabled as a precautionary measure.

alas, actually they're useful. With them you could validate a SPV proof for a cross chain txn, for example.

Nlocktime is supported fine, replacement is not. But the OP's request doesn't need replacement.

He needs to create a transaction moving his coins to a key he keeps safe,  preferably signed with single|anyone_can_pay  so fees could be added later, with an nlocktime for the future... and then he needs to destroy the private key the coins are currently assigned to.

I do not recommend this— at least not for long spans of time, no one knows what the future holds. Future discovered security issues may make a transaction authored today no longer good in the future— unlikely, perhaps, but no one will promise otherwise.

Because it's a collision not a second-preimage.  You don't need to find some H(Y_2) = X for some specified X.  You need to find Y_1, Y_2 such that H(Y_1) == H(Y_2) and thats fundamentally easier. E.g. 2^80 work instead of 2^160 work, if you have unlimited memory with zero access cost (otherwise you end up with some small constant more work than 2^80 in order to make your memory use more efficient).

I think Adam overstates this a bit, as you note the collision is constrained. In most protocols you can avoid this being an issue by not letting the other party (e.g. the one you'd count on revealing the preimage to your hashlock) pick the P2SH address. E.g. have them specify their inputs, and then you specify some inputs into that script. For the coinswap stuff you probably wouldn't use P2SH for the actual hashlocked parts (which normally should never get transmitted).

It was also discussed on IRC that you could make your p2sh addresses expensive to generate, e.g. using a vanity P2SH, to make collision searches more costly.

What electrum does is not "12 random words" in the way that you'd produce them.  It generates a cryptographically strong 128 bit random number, and using that number selects a unique string from the set of all possible 12 word sequences (using a particular dictionary), there is a 1:1 mapping so each value is equally possible an the value has 128 bits of entropy.  It then applies a moderately computationally expensive transformation to convert that 128 bit value into the 256 bit bitcoin keys, so even an attacker who knows part of your electrum seed must do a lot of computation to check it.

If you try to pick 12 "random" words on your own you will fail. Humans are terrible at randomness.

Even most people who think they know how to choose good passwords are incorrect. The common password advice people receive is applicable to security for centralized systems like login passwords, but not Bitcoin key security, as they have entirely different threat models. (e.g. Bitcoin key security for a brain wallet is inherently unsalted: you have to worry about attackers all over the world, over all time, potentially using high speed hardware crackers, and precomputing rainbow tables).

Yea, we would have been able to help JimJones in IRC if that existed.

Also, — roundup!

Verifying SPV proof is trivial in embedded hardware. It's just a linked list of 80 byte headers, hashing each and checking the prev and hash under target, it can be streamed so they don't need to be in memory the whole time.

In any case, this is getting a bit far afield of what the othercoin design is... there are a lot of potentials in this space.

No problem there: When you load a coin give it a SPV proof that it's loaded, the bitcoin network provides the date.