Correct.  To put some numbers on that, the namecoin chain is currently about 4GB of data, and its mined by >80% of Bitcoin's hashrate.

Though I'd like to see something deployed that didn't force merged mining. I think having the flexibility to do other things is good.

Whats interesting now that this has had some press coverage is that people have piped up and pointed out places where they'd invented substantially similar things in the past. So we're now up to ~5 independent inventions of the core idea... perhaps a good sign.

What you propose is creating competing systems with their own redundant supply of coins. I am boggling that you call it non-threatening (what do you think people holding those coins will do as the ownership of them diverges from Bitcoin? Sit idly while their coins remain worthless because people are using Bitcoin instead of it? ... No, they're going to go out and tell people to accept their Foocoins instead and suggest that old bitcoins will soon be worthless) and non-inflationary.

It may be a useful thing to do, especially as a promotional method— for someone who already was convinced they wanted to create a new currency...  but it doesn't address the issues that the sidechain idea hopes to address, including giving people the freedom to choose to use new transaction processing systems as they see fit without the loss of network effect and adoption dillution that comes from having to choose to accept a whole different currency.

I don't think we need any of these things, in fact I think they're outright undesirable. I'm open to be convinced otherwise, but a list of demands doesn't do much for me— implementations of interesting tools do.

Generally "colored coins" have huge hype inertia, but in virtually every proposal to make them do something useful that I've seen you can generally apply some modest transformation to eliminate the colored coin and end up with the same, or better, security model and usually better scalability.

A lot of what pundits promise are pointless, nonsensical, dangerous, or outright impossible. Thats what pundits do.

Decenteralized things are great and essential and are most of my motivation in the Bitcoin space— but colored coins are usually superfluous to creating trustless exchanges and usually hurt scalability at the same time.

Regardless of all this, you aren't going to make any progress with this approach. If you go author useful tools and people use them, great. If that happens it doesn't matter what I think and I suspect that along the way you'll learn the truth of what I'm saying in a more convincing and efficient way than anything I could write here.

You already get a factor of 4 billion speedup from just the nonce alone, you can update the extra nonce with no more than 12 compression function calls. It's good to update the block in any case.

I draw your attention to "if the usage persists". The problem is if some application comes to depend on coding crazy data there then it may be difficult to get the usage to cleanly stop in order to set the flag day point for the signaling.  So thats why a threat to start orphaning the things is effective: it doesn't matter if someone does it some, and if they are persistent some orphaning will make them stop before the usage becomes enshrined and breaks forward compatibility.
Not may fork, will fork. And thats fine. The chain forks ~every day. Unless the crazy version numbering miner had a (near-)majority of the hashpower the forking will rapidly resolve itself— and if such a miner did have a majority hashpower we'd have worse issues to worry about. It's also possible to 'discourage' a block— reject it until its burried at least two deep, disadvantaging it, but not producing a persistent fork in the case that it were a majority hashpower.

I've tested the RPC SSL pretty extensively with this attack and was unable to get it to leak anything more private than the prior rpc request.  This isn't surprising, OpenSSL basically has its own allocator and doesn't free memory.  While I can't promise that there isn't some crazy sequence of operations that makes it leak something else in the RPC case, it appears unlikely and I was unable to get it to do so in practice.

I wasn't able to get a fake SSL server working to try triggering it in the payment protocol case. I would hope expect the behavior to be similar there, but since I haven't even tested it I'm less confident.

None of the fields are "arbitrary" except for the nonce.

Time has a range of accepted values, though the range has a fuzzy definition and setting it too high increases your probability of being orphaned without a completely sharp cutoff.  You can easily find a list of the block validity criteria.

Version is defined for forward capability. While it only has some constraints today, it is not a free form field: to be useful for forward compatibility future values it must not be constrained, but it also must not be set randomly. You could, if you wanted, begin to attack the network by signaling other values in the version field— disrupting its use for forward compatibility if the usage persists. If you do this I will circulate a patch to miners to orphan your blocks, however.

Please do try to keep this on-topic.

https://people.xiph.org/~greg/m.sst  is a 16 byte sequence that appears to trigger anywhere in the file for clamav, so long as the file is under 32 MBytes in size.

You can't. If replacement was functional in the network you could pay a higher fee and hope that this incentivizes the next miner to do the right thing, but it's not a guarantee. (And I can't see how any amount of 'passive mode' could really help there, except perhaps by making sure the sequence number cranks only in one direction, but someone could still fail to include a newer one).

If only it turned out that way. Instead, it doesn't do any of that at all, and displaced the less efficient GBT stuff that did, in theory, have that capability.

None of this however involved any public discussion of what was actually developed for mining, alas.

There is some terminology confusion between the Bitcoin community on Bitcointalk and the Bitcoin Core implementation.

In the satoshi codebase there is something called an "orphan block" which is quite literally a block which doesn't have a parent— the previous block is not known the the node yet.

The reason that a block which isn't in the longest chain— I'd call it a stale, abandoned, or extinct block— is called "orphan" by the community is because the generated transaction of a stale block displays "orphaned" in the transaction list. But here it's pedantically correct: The generated transaction has no parent in the blockchain, because the block that created it is not in the blockchain.  The transaction list is the only way many miners bothered looking at blocks (instead of things like the debug.log or the source code, which call parent-less blocks orphans), and so they naturally started calling the stale blocks orphans.

Changing an enshrined practice is usually a lost cause, but the word orphan still causes confusion: it's still applied to blocks without a parent, and its the most intuitive term in that case. So I recommend using one of stale, abandoned, or extinct when referring to blocks that didn't make it into the longest chain though I don't begrudge people using the word orphan here too other than by noting the potential for confusion.

Can you please change your topic, it's a bit inflammatory.

What you're seeing is virus false alarms because the virus detection software on your computer checks for short (e.g. 16 bytes) 'signatures' and not the viruses themselves, and people have put some of these signatures in transactions.  The AV software correctly ignores the blockchain itself but is falsely triggered in some of the leveldb database files. You should configure your AV to ignore the bitcoin directory.

There is no risk to your system here.

OB-Pedantic: the timestamps are bounded by needing to be greater than the median of the last 11 blocks in their chain and less than two hours in the future from the perspective of each validating node.

The initial development was secret to the public before it was up on slush's pool along with the python proxy. I'd always understood this to be a (anti- )competitive move.

There remains no BIP describing it, there was no design discussion prior to its release on bitcoin-development. Justifying the closed development, Slush wrote (in the second email my mailbox ever received mentioning stratum mining) "There's no requirement to have BIP for everything what people do. Stratum is NOT related to bitcoin protocol or bitcoin implementation, it is just custom, pooled-mining extension and bitcoin network doesn't need to know about Stratum existence at all."  Perhaps you were somehow an insider on it— if so, why didn't you discourage some of the poor choices in it?  But from my own perspective it really was developed in secret and, in my opinion, carries some of the predictable flaws of a protocol developed without broad input. It's not the end of the world, in any case. Far worse has been done elsewhere.

Yep. There are two computer power connectors on the devices, which can be fed from one or two 120 or 240v citcuits.

I have another CT unit running in my apartment already (as well as a number of other miners). Keep in mind these devices are a bit loud in terms of a residential setting (they're about as loud as you'd expect a typical high performance rack-mount server to be), especially in a warm room when the fans fully spin up.

The CT miners draw close to 2KW (across both power cables)  at full speed. Typical US residential power wires circuits with 15 amp breakers, so you need to spread them across two circuits to avoid tripping the breaker. You can run them at lower speeds to lower their power usage, but obviously thats not how you want to run them long term.

Since it didn't make sense to have it just sitting here while I arrange a sale I went ahead an powered up the unit, but have to keep it at the lowest power level (and had to slightly downclock some of my other miners) to avoid tripping a breaker here. Runs fine.

From a protocol development perspective, stratum being defined in terms of difficulty is an embarrassing flaw of the sort that would have been avoided if it hadn't been developed behind closed doors. ... The fact that it's a floating point value which cannot precisely specify the actual values used in bitcoin is a pretty big facepalm.  All of this really should have been using bits like the bitcoin protocol does both for precision and consistency sake (or an expanded target— to accommodate legacy stupidity, but then again people will just get the byte order confused and complain it wastes bandwidth. ).

In any case, should have beens aside— what am I missing here?  There is no formal specification for stratum at all, slush was apparently sucked into Trezor land before publishing it.  AFAICT nothing is implementing the difficulty based message that was suggested way in the past, but at least luke's stuff has implemented the target based approach.  Whats to debate?

That isn't true. It's being triggered by little 16 byte sequences (for example), no virus itself is 16 bytes long. You may also note that it doesn't actually report _anything_ against the actual blockchain, only the leveldb SST files.

It's not a really hard dilemma at all: Obfuscating the block files was a suggestion made back in 2010 or 2011, it's a relatively trivial change but I'm not eager to do it if its not absolutely necessary as doing so will break armory and any other tool that processes the blocks, and still won't provide complete confidence against broken AV software because they're being triggered by obscenely short strings...

In your extended diatribe above it would have been nice if you'd explain why the report here is against the sst files only and not the actual blockchain.

Has anyone charted out the cointerra power stepping vs wattage (vs hashrate too, perhaps)?

I am precariously close to over-provisioning some breakers and short on power meters. It would be handy if someone had charted this stuff out so I can set it in a way thats more reliable than trial and error.

Still available.