Satoshi made a few serious mistakes, expecting sequence mediated replacement to be usable may have been one of them. Perhaps he realized that and thats why— unlike so many other things— he didn't actually implement it.

There are two major issues with sequence mediated replacement:

First is that it opens a major DOS vulnerability: I start issuing bunches of the largest transactions the network will tolerate, with high fees, locked so they are not going to be mined for the immediate future... but I'll never pay those fees because I'll replace them all before they become due. But until then I'm running every node out of memory pool storage. Any way that closes the DOS attack provides a way for an attacker to help them violate the sequence ratchet.

The second is that it demands all miners behave in a way that reduces their income, perhaps substantially. If I learn of an earlier sequence spend with an child transaction that pays a high fee, why should I continue to attempt to mine the higher sequenced spend?

Miners behaving in their own short term interests against the interests of (some of) the users is not hypothetical, its a reality today.

So far I've not seen or come up with any way of solving the DOS problem, nor any way of solving the incentives problem that works for non-trivial-valued transactions (for trivial valued transactions we could perhaps use the threat of increased orphan risk, but that stops being a solution for high values or if attackers start bribing many miners with chains of fees).

The virt counter is not useful— it's measuring address space used, and there is normally quite a bit more address space used than pages due to threads, mmap, and other things that use address space.  The useful memory metric is res (resident).  On x86_64 with about 100 connections I'm used to seeing about 488 resident.

s/majority/all remaining users/

The expected return— that is the average over all possible futures— is the same for either (ignoring any outages, pool fees, pool stales, any differential risk of theft/hacks at pools/locally).  The variance of returns is what differs. If you're not depending on every cent of mining income for anything in particular you might prefer a higher variance option over fees and pool related risks.  If you're the sort of person who likes to gamble then solo mining should be unusually attractive because the odds are in your favor (assuming you're mining at a profit even in the pooled case).

There are things in between just pooled and solo. E.g. with p2pool you can turn your share difficulty up fairly high.

FWIW, I've had really bad cpu load on my miner— pegged at 100% and suffering slow responses, it apparently can't keep up with large blocks and large coinbase transactions. This isn't surprising: old cgminer had slow work generation code. Current cgminer and bfgminer have much faster work generation. It should be an easy fix: just port the driver over to current miner code. I'd like to work on this, but I'd need the source— preferably for the stuff thats actually running on the system.

I emailed bitmain earlier today, but perhaps someone here knows where I can find the sources for the devices that shipped.

Is this a 32 bit or a 64 bit binary?

Like a lot of other things on BC.i that are just guesses, its right often enough to confuse people.

Most altcoins change almost nothing at all. What they do change is sometimes outright bad, ... but mostly just a twiddling of different tradeoffs and not actual improvements.

E.g. some change to continuous difficulty adjustment, but that greatly decreases the cost for an attacker to mine out a low difficulty fork to trick an isolated node.

Sometimes the changes are bad enough that they make the coins so insecure that they actually are successfully attacked.

Or a "3", because we've already used this forward compatibility once, for P2SH, to make payments to escrows and other complex scripts as easy as regular ones.

Y'all realize that constantly bumping the thread is free advertising for hashfast, right?

Then go read the code.

Yes it's literally the arithmetic sum of all of the work of each block, and it's equivalent to the sum of the block difficulties upto rounding (difficulty is a floating point number presented for human friendliness).

uh.  Bitcoin does no "flops" at all. Flop numbers are now bad projections from matching up what a GPU could do when it wasn't mining Bitcoin and they're now irrelevant.

The right metric is the cost of what it would cost you to actually perform the attack.  You can go order 2TH/s miners for $6000. The current network speed is ~5000 TH/s.  Building a farm to outpace the network at that price would cost $15 million. Of course, those are preorders and the network will be faster once they ship, but even if you compute vs hardware available to ship today you end up with numbers under $100m.   I don't think there is really any serious threat— there are cheaper ways to attack bitcoin— but saying "way past the point that it's at risk from a falsified blockchain attack" is a bit of an exaggeration our high hashrate now is the product of extreme improvements in the cost of mining— which benefit attackers too— more that massive increases in mining investment.

You're confused by the definition of "longer". The chain selection is based on the sum of work, not the number of blocks. (The whitepaper was mostly written from the perspective of constant difficulty, under which the two are the same).

I can confirm— it mines.   Three days from providing my phone number for shipping to it arriving to me in California.  Will post writeup and pictures soon.

We mlock the memory used for private keys, however there could be a mistake someplace or another, so encrypted swap is still advisable— and very easy to do under linux.

There are no "pre-mined" coins in Bitcoin. The design makes this abundantly clear— and anyone can audit the software and look at the public history to confirm this for themselves. Please don't spread misinformation.

This is _strongly_ discouraged. If you do this you will not be able to tell which of multiple parties concurrently paying you is paying you, you will degrade privacy for your own service and other users of Bitcoin as well. You may be subject to blocking by hostile parties, it's just generally a bad plan.

The account functionality is purely local bookkeeping— like categories in a checkbook. It doesn't influence the transactions the system creates. It was created for a particular niche usecase (shared webwallets) and it's not even particularly useful for that case.  It's generally discouraged to use accounts for anything important.

Ditto.

Spiffy pictures.

Re: The smoke machine video, perhaps the babyjets will be free of the avalon problem where at high fanspeed the controller overheats due to a deadspot in the airflow.

A bad-guy is not required to play by your rules, he can issue spends although he knows better simply because its physically possible to do so.