No it wouldn't, it would just require different hardware.

Annoyingly, the obvious 'replacement' for pooled mining is not non-pooled mining, it's cloud mining that puts the hardware in the physical control of the pooling party. Thats a step down.

Instead we /just/ need to improve the tools so that people can pool for variance reduction without turning over their consensus controls. It's straight forward: the pool gives you a coinbase txn specification (e.g. "must pay these addresses") and you mine whatever block content you want, returning shares to the pool. Then you get low variance payout, but without handing over control.

GBT was supposed to enable it, but it was supplanted by stratum before it could get adoption.  I'm not sure of how to break out of the status quo.

It's not two transactions, it's one transaction plus the number of inputs transactions and their merkel paths. However, if you're asserting that an input simply doesn't exist there is no compact proof for that currently (though one could be added with an additional commitment). Proving things like "coinbase takes too much subsidy" also requires additional data. I enumerated many (most?) of the things that need additional data to be proved a long time back: https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs

I never saw this post originally, ... should have emailed me. :-/

For example— in the hash case you make your hash an iterated hash, like H(H(data))=X. By revealing to you H(data)=Y  you can compute H(Y)==X and are convinced that X is a hash.  Y may or may not be a hash, but at least it's just ephemeral— you don't store it, you just remember the Y values for blocks near the tip and don't require them for historical block.

Elsewhere I described a number theoretical hash which is provably a hash using pairing cryptography. But since it's slow it may not be of interest.   For that you have some paring compatible elliptic curve group which supports an efficient operation to coerce a random value to a point on the curve.   You compute point=G*H(data), point2 = to_point(H(point||masked_tx_hash)), proof = point2*H(data).  You transmit {point, proof}.  The other side computes point2 from point and verify that pairing(G,proof) == pairing(point,point2). This proves that point is a EC curve point for which you know the discrete log. The troof can be omitted from historical blocks (like the P2SH^2 above) to avoid the storage overhead. This also has an advantage that it's replay proof— even if you log proofs you cannot make another transaction reusing the prove hash without knowing the data.  The downside of this is the pairing computation probably takes 1ms per transaction.

In either of these cases people could randomly select their data and keep trying until the prefix of the point matches some data they want to send, but this has exponential complexity in the number of bits stored per value.

It doesn't prevent a dictionary search, but it prevents bulk enumeration: at least they have to guess. If they fail to guess, they'll never know. I don't think better than that is possible in a fully decenteralized system.

Thats the idea: Make it so that a SPV client can do secure resolution. People have been working on some committed utxo stuff for bitcoin but the implementations are not mature yet.

Client privacy can be improved further for ligher-than-SPV resolvers  by using information theoretic PIR: http://percy.sourceforge.net/

It's a test with randomly generated keys and signatures.
I'm not clear on what _precisely_ you're talking about there: During normal operation bitcoind isn't doing much if any ECDSA validation when it verifies a block, because it does validation when transactions are circulated on the network. If you're talking about initial syncup then the performance there is entirely bound by things completely unrelated to ECDSA (mostly due to poor fetching logic that does redundant work).  OpenSSL is also about 6x slower than libsecp256k1.  There is a benchmark flag in bitcoin core to make it log how much time is spend on each part of the validation.

This is addresses where Adam writes about firewalling (and in the IRC description of sidechains that adam linked; both of which you should read if you're posting here).   Take your casino example and imagine that the casino is hygienic— i.e. not intermingling their books, so that every chip they issue is backed. People bring the casino's teller dollars, the teller gives them chips with a promise to exchange back for dollars later. Now, say the casino's chips are insecure and easily cloned by the players.  The casino's teller is drained. Who loses out?  The people left holding the chips.  Other people using the USD are not /directly/ affected.

If instead there wasn't actually a fatal bug, just phobia about one, then no one loses at all— except perhaps people who overpaid some in transaction fees trying to hastily exit. Unlike an altcoin a sidechain-coin doesn't lose its value due to changes in sentiment, since you can go trade it back for Bitcoins regardless of what other people think about the side chain, unless the side chain is _actually_ insecure and the backing bitcoin is taken.

libsecp256k1 does over 40,000 ecdsa verifies per second on a desktop class quad-core cpu. I suspect any need for accelerators may be over-blown.

You should clarify that you're talking about the non-hardened derivation, since obviously none of this applies to the hardened derivation.

But yes, that's insecure.

If you have two signatures with the same unknown nonce (k) you have two (r,s) signatures of message m_n, such that r_1==r_2 because r is just k*G.  Normally you would write out s_1 - s_2 = k^-1 * (m_1 - m_2), simplifying from the signing equation, and divide m_1 - m_2 by that yielding k.   If you replace the secret key in the signing equation by the secret key plus a known constant the first step simplifies out to s_1 - s_2 = k^-1 * (m_1 - m_2 - r*constant) since you have the chaining code you know the value of the constant so you can compute (m_1 - m_2 - r*constant) / (k^-1 * (m_1 - m_2 - r*constant)) = k.   I haven't actually tried it, but I believe it will work. This also follows naturally that if you have one private key and the chaining code, you have all the private keys on a non-hardened chain.

You should treat all bip32 private keys on the same non-hardened chain as the same private key for security purposes. They're all just a constant private key plus a set of increment values known to attackers who know the chaining code. Additionally, even ignoring bip32 I would never reuse a nonce on signatures of different messages even with different keys.

Thats not strictly true. In that a side-chain could have a subsidy created by stashing coins in compulsory fees on coins crossing the boundary, or by not having a 1:1 value relationship with Bitcoin, or by issuing credits for future fees or other mechanisms.

I don't list these things to suggest that any of them or good or that I've considered them in depth— I'm just pointing out that there are more possibilities than you may have considered.

Absolutely, the one example of a MM alt in bitcoin failing was CLC which can be perceived as being overtly hostile (they took the pre-release bitcoin op_eval/p2sh code, complete with nasty exploits, and rushed it to market: announcing a new altcoin + exchange on the same day, basically trying to monetize other people's code, saying it would replace bitcoin, etc).  Services provided by sidechains enhance the value of the Bitcoins miners receive.

There are a number of things miners could do if they were short term greedy rational— esp considering that we have parties with >25% hashrate that they aren't doing— they'd have a 5% success rate at a 6 block reorg.. could make for some pretty nice theft.

This isn't to say that security is a non-issue, but the nice thing with the sidechains is that you can always choose to not use them. For whatever level of security arises out of any particular sidechains mix of internal incentives and redemption rules there are applications which would find that level of security acceptable. Esp when you start talking about things like high volume micro transaction-ish stuff there is some interesting tradeoff: if you hardfork bitcoin to allow gigantic blocks to make those things even remotely viable, you end up potentially pushing more and more bitcoin users to an SPV model. Given the choice between all of Bitcoin being more SPV like security and just regional microtransaction networks being more SPV like, the latter is a lot more attractive.

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.