You can still get the 20 minute blocks from time to time.

As Maaku hints to, the a big reason Bitcoin has 10 minute blocks is because the variance is desirable. We need the variation in order to increase the allowed network radius/block processing time, the latency permitted for miners, and to control the incidence of long forks.  The only advantage to having lower variance without increasing the number of blocks would be reducing header traversal costs to link a block, but we know how to do secure header traversal now in logarithmic time in any case.

Progress freeness is also very important. You do not want to reward people super-linearly with their hashrate.

Eligius' approach doesn't remove as much variance as it could, however.  The problem is that no miner has an actual expected return of the PPS rate because of blocks that fall out of the chain, withholding, etc. As a result miners who are mining when the pool is lucky get overpaid (full PPS), and ones mining when the pool is unlucky get underpaid (pool will never make it back to them).

The approach used by Eligius could be improved by measuring the difference between actual recent income in a window and PPS and coming up with an expected true reward coefficient C.  Then credit the share stack PPS*C, and credit in a second share stack PPS*(1-C), the second share stack is only ever paid in the unlikely event that the first share stack is paid completely.

But I'm not really sure if that payment mechanism really makes that much sense to continue developing simply because it requires a fair amount of storage and computation, and results in payments happening months or years later, which complicates key management.

Precisely. Checkpoints are there to prevent a number of dos attacks where we'd waste storage or resources on bogus forks which are never going to be better. They also allow for some optimizations, and also ensure that you can't successfully fool a node by isolating it from the start. There are other, better but more complicated, ways to address those issues, so I expect that they will eventually be removed from the reference client.

I'm afraid you must not be very experienced with this ecosystem. There have been hundreds of pools created. Operating a pool, especially a small one, is not a business that has many barriers; and large pools have had revenue at times in excess of $100k/mo, so it's not like any more income is needed to justify running one.  Just having a choice of centralization does not result in Bitcoin being decenteralized, and the major reason you see consolidation in pools isn't because there aren't people running them but because pools do their job (reducing variance) when they are large.

Centralized pools are not, however. (P2Pool is an existence proof that there are other options)

Can't be yet, a majority of transactions on the network still fail the check.

Sort of, the first stage is "get all widely used signers to only produce canonical signatures", which making the reference client do it is just the first step. I believe the latest bitcoinj does this now too.

Thanks for the reminder though, it's time to start the nagging engines.

Sort of a tough problem considering how poor wallets handle the change.


We can't verify a transaction without the input since they're included in the signatures.
I thought we templaitized the signatures, but apparently we don't (sometimes it's hard to remember whats been implemented vs discussed).

Safety for what? I agree that it's reasonably fine against trouble making when the attacker gains little and the harm of a loss is small. But there are already substantial pools like ghash.io who have mined maliciously in order to rip people off.

Block-creation is basically free however. More costly is block validation— after all we want mining to be evidence that the chain is valid for SPV nodes... but that also means not having miners skipping out on the validation. Forrest has been working on some improvements to make it possible to mine with very low resources, but I think I disrupted his progress somewhat by pointing out that validation is really important.

No, they weren't. The real malleabiltiy fixes in 0.9 were in the wallet code.

(but indeed we did merge the changes from last September to expand the non-canonical forms to include the non-canonical pushes.)

Of course. It implements its own IsStandard() rules.

You were looking in the wrong place.

0.9 authors transactions which always have low-S, this is the a prerequisite to making non-low-S non-canonical.

Additional superfluous operations get blocked by IsStandard, IIRC.

Though only relevant for multisig.

You might as well say that it could be fixed using OP_S_EVEN ... "Disabled" OP code are no more existent than purely hypothetical ones and require no less effort to deploy.  What Sipa proposes is that we make one of the version bits on transactions effectively a flag that controls enforcing a tighter set of canonical rules, including this one.

You've misunderstood the code. Go look at the code that actually implements the cast.

Correct.

"Protected" unless the attacker has the help of a miner. This is an adequate defense against griefing but doesn't make things like refund using protocols safe.

No. There does not.

This is undesirable as it disallows users control of their own transaction selection.

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.