I think you're missing the point. Consensus in bitcoin does not depend on fee policy - miners can include whatever transactions they want. In Etherium, the fee policy is tightly integrated with contract balances and the ledger, so changing the fee policy is not an option. It doesn't have to be this way however - Etherium could have used a bitcoin-like input/output transaction system with optional fees. Fees would then determine transaction priority, but not be part of the consensus mechanism.

But what if the voting mechanism is flawed/insufficient/exploitable? Changing it requires a hard-fork.

Consensus is tied to fee calculation in etherium, so there is no mechanism for adjusting fees later without a hard fork...

Ultraprune (0.8+) already packs the validation state as small as it can reasonably get. It's correct that pruning makes the network less secure. This is ultimately about tradeoffs, and lightweight clients. Right now if you can't run a full node you are basically force to put your trust in those who do. UBC makes this a gradual loss of security (for you and for the network) instead of a sharp dropoff, so you have the ability to choose how much is appropriate for you.

It can bring the required state for a fully validating node down to few measly kilobytes of working state, forever. Provided you have access to one or more archival nodes willing to serve untrusted data, that is.

"Ultimate blockchain compression" is a bit of a misnomer these days. Pieter Wuille aka "sipa" implemented the compression the name was referring to in his "ultraprune" branch of bitcoind, which was merged with the 0.8 release of the reference client, prior to my getting involved with UBC. That release and all releases since maintain a separate structure containing all data necessary for validating future blocks, stored in a database which at the time I am writing this is about 305MB (vs. about 18GB, so about 94% compression). The reference client still keeps the historical block chain data around, because there are not adequate features in place yet to protect the health of the network once a significant number of nodes start pruning old chain state. But that is something both I and others intend to fix in the near future, thereby allowing people to benefit from these space saving features already deployed. Nodes will still need to retain all of this data however, as they would have no way of retrieving it from untrusted peers in a safe manner.

That is the problem that UBC solves: safely querying a peer for data extracted out of the validation structure. If you assume that there will be at least one reachable peer with the information you need and appropriate bandwidth, then it becomes possible to "compress" (sic) the block chain further by offloading this data onto the network, down to a minimal size of 28 bytes - the hash of the current best block, minus the 4 bytes that are always zero. In reality you'd have to have a few (10's of?) kilobytes to store and process the network messages, and much more than that in cached data to be reasonably performant. But you could probably, for example, make a hardware wallet device with only about 512kb of storage, that nevertheless operates as a full node by querying bitcoind over an untrusted USB connection.

Why would we use a new commercial library over the stable and audited OpenSSL?

Use the search tool, this has been discussed to death already...

Tachyons. I can't say more because there's a patent pending...

I believe in magic. And unicorns.

The location of the data directory has not changed. It should be "/Users/<your-user-name>/Library/Application Support/Bitcoin". If you didn't find it, then you were probably looking in the wrong spot...

Just put the bootstrap.dat file there, and reopen Bitcoin-Qt.

In a data structure in memory (the mempool), where they are kept for the next block.

The limitation is on block size, not the number of transactions. A block cannot exceed 1MB in size, in the serialization format used by the p2p message protocol. The size of a transaction can vary.

@d'aniel Turing completeness has a very specific academic definition that the language I am co-designing probably won't meet[1], but that distinction is not interesting or important. In a Turing-complete language you can write an infinite loop, but why would you ever need to do that in practice? There are more limited forms of recursion and required type safety which allow expression of solutions to nearly all real world problems, or the emulation of space- or time-constrained variants of Turing-complete solutions.

I don't consider this overkill or window dressing at all. There are some very serious applications (e.g. restricted buy back) which require these features if they are to be emulated in Script; I wouldn't be working on this otherwise. We should probably move this to the thread linked to by Adam, however.

[1] I haven't seen this proven yet, but it looks like we'll probably have to choose between decidability and Turing-completeness in the type system, and for this application decidability is far more important as I foresee wallets using theorem proving to determine script safety and to categorize / quarantine coins by their attached covenants. For similar reasons, it may make sense to restrict ourselves to a total functional programming language (which restricts the range of expressible programs to those which are provably terminating, and therefore not Turing-complete in the strict sense, but nevertheless sufficiently expressive just about any actual use).

Wrong forum. Try over in Mining or Mining Software.

Well, talk to the people who run that site. Transactions do not have times associated with them, so they are simply guessing in some way. Obviously there is an error in the algorithm, the implementation of it, or the data made available to it, but what that error is we have no way of knowing.

This is so very much the wrong way to ask the question. Figure out what your orderbook design will be, and how you will make it consistent at scale. Your strategy for that will determine what databases or locking frameworks you intend to use, and then look at which languages integrate best with that infrastructure.

Transactions don't have times. Ignore blockchain.info.

I can't speak to the "watch only addresses", but I'm one of the developers working on an address index. It's a nontrivial undertaking, but finally in the implementation phase. The draft BIP and Python prototype implementation are about a week away from finishing (just need to implement and document some last minute changes).. although it's been "a week away" for the past three weeks as I work on other, higher priority tasks. It might take a little bit of time to be finished. The C++ implementation is only about 50% complete, and that needs to get finished before we can even think about finalizing the spec and deployment.

To really make efficient and secure use of an index requires a soft-fork, and it is less clear when that might occur. Look at how long it took for P2SH to happen, and that was a considerably simpler change originating from the core developers (I'd still count myself as an outsider). In the mean time though it might be usable as a merged-mined side chain.

Gavin, as far as I can tell there is no such thing as a bogus contract in Etherium. You pay a one-time fee to register a contract - setup an execution context for a script in the validation state of every node - but script representing that contract is not validated in any way. There's no way for a contract to be rejected, so there's no way to "DoS with bogus contracts".

Pretty sure the OP is trolling. But in case the actual owner of 1933phfhK3ZgFQNLGSDXvqCn32k2buXY8a is reading, these blockchain.info "notes" are not part of the block chain - they are records submitted by users of blockchain.info. I would talk to the people running the site, who would be able to give you logs of the person who made the threat. Then go to the police.