Unlike the NIST curves the Bitcoin curve is not "random": There is no parameter question there. The comments on the safer curves page addresses a whole host of analysis points, so with the randomness off the table I was speaking to some of the other things where there are meaningful engineering differences between Bitcoin and curve25519.

It most certantly does not.

In any case, many (most?) miners do "regard" fees below some threshold as zero in order to prevent people from jumping the queue just by paying an infinitesimal fee... but they still collect it all the same, they just treat it as zero when prioritizing.

Sure it will. If mining centralization undermines the usefulness and values of Bitcoin people will take action— it's not even a question about bitcoin-core developers (though we're bitcoin users too!), since anyone can offer a modified version... The users of bitcoin are not going to just sit back when something moots the system.

No. Not at all.

Can you review my post again with this in mind. Communication is hard and I take full responsibility for being unclear... but I think I'm going to just repeat myself at this point.  I'll gladly retry if you reread with the assumption that the users do not reuse the session key.

No.

You can send a single message, the concern has nothing to do with _you_ potentially reusing your nonce.

I can intercept your single message, modify it, send it to the receiver. I can take advantage of the receivers misbehavior on receipt of the corrupted message— either doing new things from bitflips (e.g. I guessed what part of your message likely was and twiddled bits), or if garbage messages will make the receiver echo back in plaintext I can use that to recover your one-time pad.

Another way to look at it is that without authentication an attacker can cause multiple messages with the same nonce to exist. It doesn't matter that you didn't create them, the additional messages with the same nonce are potentially problematic none the less.

Not at all. It's actually so easy to implement turing-completeness that we implemented it accidentally in the first OP_EVAL patch and took it out (the recursion limits didn't actually work). The implementation in their demo code on github is (or was, I haven't looked in a while) just basically a replication of bitcoin script with a single JUMP opcode added. It's not uncommon for things to be accidentally turing-complete (using the non-pedantic definition which permits bounded memory or computation time as turing complete (otherwise what ethereum has proposed is not either)).

Now, making a system that won't magically implode into insecurity because almost no one validates it anymore takes more work than this, but it's unclear that anyone knows at all how to solve this if validation is made expensive. None of the things ethereum people have discussed there would be particularly difficult to implement in Bitcoin— and many of the ideas like prefixing scripts with an operation count and weighing fees against them were proposed for Bitcoin long before ethereum existed.

All that said, Turing completeness doesn't actually increase the expressive power of cryptocurrency much— the examples usually given for ethereum can also be accomplished with finite state machines. The primary advantage an actually turing complete machine has appears to be that some problems can have much smaller encodings for them, the primary disadvantage is that someone can give you a script and determining exactly what it can do (e.g. if you'd like to agree to it as a contract) can potentially be much harder than a reduced computation model.

Danger! Will Robinson, Danger!

Say someone were to deploy the simple scheme you described just as you described it—  they they used it to secure queries sent to a simple web server.

I capture a message sent to them that I want to intercept, and I take the nonce out of it— but replace it with a message of my own (perhaps all zeros).

The server responds to me "INVALID REQUEST:  20iE⊥∩θ⊂∏↔θ⊂dlkvc25πδjdk⊕κ×σκk8κσ×3th7hξκδι2λσ∃ΚΣ‡"  ... now I xor with my 'message' and have the session keystream and can decode the message I intercepted.

Even if there isn't some handy error response I can invoke, I can still freely flip bits. "Wait, but if its in a transaction, thats signed right?"— no, I can rebind your message without knowing its content either with or without bitflips into another transaction but reuse the ephemeral key and exploit whatever interesting behavior I can squeeze out of that.

This kind of cryptosystem is often trivially insecure without strong authentication tied strongly to the ephemeral key.

Behold the kind of fun that happens when you don't get every detail just right (start reading at the second message): http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/5325B5BC.3030501@gmx.de/  (A cryptographic disaster (near miss) which started with a thread on this forum very much like this one, but one where more experienced folks happened to not notice it…)

Some people have said this— but the history doesn't really support it. With how fast (and, often, recklessly) various players have moved in the larger economy technical development may seem slow by comparison… but while a stream does not carve a canyon over night, it does so all the same. Someone looking to create a speculative asset boom by copying a bit of other people's code and hopping out weeks later before it busts might honestly say that within the time frames they care about Bitcoin won't adapt... But some are in this for the much longer term possibilities.

All of the curves most preferred on there are ones that DJB made. Some of them have no implementation in software, only the curve25519/ed25519 stuff has any non-trivial deployment at all.

While the analysis there is generally good and thoughtful, I believe that the page crosses the line into being a bit ... uh .. marketing motivated. This has been discussed before several times— e.g. it cites several points which are irrelevant to us (e.g. the elegator encoding), are 'one time costs' completeness making a correct implementation take some more work, and other points which are compensated by increased security of secp256k1 in other respects.  (E.g. the efficient endomorphism for secp256k1 that yields very fast verification for our curve reduces security by a couple bits, which is pretty comparable to the cofactor of 8 in ed25519 that reduces their security by a couple bits (actually slightly more).

Whats implemented in openssl has more or less nothing to do with what bitcoin uses, and getting rid of openssl wouldn't change it.

Hm. Adopting script changes is _trivial_— in fact we've done it before. From a technical perspective P2SH replaced the script system with a copy of itself nested inside a hash.

Really the stuff that is not integrable is things that make economic changes (e.g. freicoin), have very negative scaling impact, or involve very different security assumptions (e.g. trusting a centeralized party).  The biggest barrier so far as been the lack of actual innovation or at least it not being clear if the changes that they make are useful and not totally broken.

There aren't any current alerts for fraud.  The original idea in the paper was a bit immature— the problem is that a DOS attacker could cheaply force SPV nodes into the very expensive operation of fetching the whole blocks.

Subsequently we've come up with some more refined versions of the idea where, with a few additions to the data blocks contain we'd be able to extract compact proofs that a block is invalid, preventing that DOS attack, but they've not been implemented yet.

There are hosted wallets, but the true mobile wallets like "android wallet" use SPV mode see section 8 of the bitcoin whitepaper.  SPV wallets do not trust the nodes they query except for some denial of service/privacy issues, and have basically no storage requirements and very low bandwidth (far below your keyframes), and they do not use a centralized server (they use the bitcoin p2p network). SPV nodes security involves additional assumptions about miner honesty.

What you're describing is a pretty radical change in the security model. In Bitcoin we do not trust the data we are given at all, we verify it. The 'keyframes' you'd send there would need to be trusted, if one bogusly claimed to reassign ownership of a bunch of coin— no one relying on that data could tell (at least not mechanically). Assuming they are mined it would basically be the SPV security assumption set, but less efficient for a mobile wallet (since they'd have to transfer a full 'keyframe').

It's perfectly reasonable to relax the security assumptions for some applications, mobile wallets— for example— but thats why we have SPV mode already.

What it does is removes a differential advantage you'd get from using more complex miner designs that queue and pipeline work better and have more communications bandwidth to minimize latency.

There is a reason— just that it can hide the faults when your other things failed.  Sort of if you assume everything is right, then no— it's no harm. But of course, if you could really get away with assuming that everything is right you would have not worried with additional entropy sources to begin with.  Another reason is that it makes audit and review harder, e.g. if you can test it and confirm that it always gives the same keys for the same deck then thats a useful property to facilitate testing.

Not a reason to not do it, but it's just something to keep in mind.

It's insufficiently specific, but existing examples which require developer controlled block signing or closed source software don't really pass a sanity check as decentralized tools— though they're often marketed as such.

You may find this enlightening: https://download.wpsoftware.net/bitcoin/pos.pdf

I've generally found it to be pretty easy to shuffle poorly... I'd rather throw hex dice 128 times and compress 2:1 with sha256. Even a little excess entropy plus a cryptographically hard compression function should overcome all small biases, and the order dependence in a shuffle much harder to notice or test for. The excess input also gives you enough data to perform some tests that thwart user misuse (you rolled 0 100 times in a row? really?) without compromising security.

Yes, but they still cost more in marginal fees, instead those transactions used priority to get them through which could have instead been used to make valid transactions... and the loss of priority will me that person must pay more fees in the future.

They are technically spendable but they cost more in marginal fees than they are worth... It's altruistic to redeem them but not rational to do so otherwise.

Several indeed: On average the network tries 16,818,461,371 modifications (each allowing 2^32 hash attempts) per block solved these days.

Normal nodes do not relay old transactions... but, indeed, could have just been them not updated after all this time.

The one I searched for got not hits, good sleuthing.