piotr_n  you were part of the thread where we reproduced our curve parameters, were you not?

No. Timestamps don't come into this at all. (And most suggestions to tighten timestamps result in (usually minor) vulnerabilities)

2013-10-27 14:55:42 SetBestChain: new best=000000000000000000028c32e6952731326747bae4be8db0f832d6eea0362050  height=266381  log2_work=73.237967  tx=26093998  date=2013-10-27 14:49:44 progress=0.999972

In [592]: math.log((2**256)/0x000000000000000000028c32e6952731326747bae4be8db0f832d6eea0362050,2)
Out[592]: 78.65083195521588

Right. It doesn't have an 18 billion diff, but the hash value is low enough to be accepted by such a one.

It also isn't the lowest block hash yet.

2013-10-27 14:55:42 SetBestChain: new best=000000000000000000028c32e6952731326747bae4be8db0f832d6eea0362050  height=266381  log2_work=73.237967  tx=26093998  date=2013-10-27 14:49:44 progress=0.999972
 
Is vastly lower, and would be accepted by a difficulty of ~110,484,089,548,580.

Bitcoin has now done ~2^74 hash operations. I'm reasonably confident that it will do 2^90 of them in my lifetime, I am not confident that it will be the only 2^90 search.

Also the workfactor to break one of your 90 bit keys is less than 2^90 the moment two of your keys have been used... If your scheme were widely used, it would be much easier to find one at random. It may also turn out that your RNG is less uniform than believed and after careful analysis doesn't require a 2^90 search to match even a single key.

Your scheme also only generates a single address, so users are stuck reusing it, compromising their privacy.

In general symmetric cryptography applications 128 bits has arisen as a general standard. Is 128 meaningfully better than 90?  Is it meaningfully better than 120? Meaningfully better than 65?  Part of the purpose of having a standard size is so that you don't have to constantly engage in a complicated tradeoff discussion: you just demand that everything is 128 bits.

Is 128 bits more to memorize than 90? Yes. But relying on memorizing keys which can never be recovered via any other means is already skating on thin ice. People are used to it being possible to recover access if you forget— though sometimes with great effort. Crypto is different. Memory is just reliable enough for its unreliability to be surprising, especially since you don't remember all that you've forgotten by definition.

Of course, once you're up to that size you could just use the scheme electrum uses (or the one that it will use). Of course, the implementation isn't 1024 bytes— but neither is yours: The dictionary is an utterly essential part of the implementation.

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.