Signing? Verification? Key generation?

This subject is relevant to my interests, but I haven't seen anyone doing anything in it.

Sounds good. Yes, it would be ~1/65536*2.  I was about to suggest something where you need N of M of even smaller checksums and then realized that the bloom filter is basically the limit case of that.   If you don't want to support more than two values, you could specify having more than 11 extra 1s is also regarded as a false match.   E.g. if this key only sets 8 ones and there are 20 set in the filter (including these) then then also regard it as a false positive (because there is no possible single second value which would result in more than 11 bits being set).

The structure I gave has the same property.     If you have StrongH and the encrypted wallet you still need the whole output of the initial KDF, which means you need to know or guess the password and grind the initial KDF.

Practically all of the web keygen / signing apps I've audited use a really sketchy structure where access to the system's cryptographically strong prng is inside a try/catch block and failure results in silently replacing the entropy with snake oil...

Interesting to see that this instance was a different failure mode where the inadequate type-safety of JS combined with a lack of testing for deterministic DSA yielded sadness. (It appears to use a derandomized DSA, but had no tests for it, and the ability to test is one of the big advantages of derandomizing DSA... an underlying library change the behavior of the hash function and the signatures started using a constant nonce).

The data posted here appears to be purely http server data.  I don't see the relationship with bitcoin except they used running-a-bitcoin-client as a way to find interesting targets.

Is there an advantage I'm not seeing to this approach instead of

preH=PBKDF2-HMAC-SHA512(salt,passphrase)
strongH=KDF(preH[first 256 bits])
H = HMAC-SHA512(preH,strongH)

?

This construction seems simpler and faster—or, more importantly, would allow moving the computation budget from postH into preH where it could add more strength against dictionary attack by the delegatee.

Snazzy approach to denyablity. I certantly like it better than what some other people have done.

Do you have any number on the false positive rate for the no-specified second key?  How does it compare to "two 16 bit check values, ordered randomly"? Presumably its better when there is no second key or where you've done some brute force search to find two that share their bloom bits?

We'd proposed something like this in P2Pool a while back— at least the basics of it: announcing key in share and doing threshold cryptography so that larger p2pool miners could automatically peer with similarly sized miners—  there are some obvious shortcomings that come up like even if you assume a large miner will keep the data secret out of self-interest they may not be a large miner forever: once a large miner is no longer a large miner they don't have as much reason to keep the data a secret.

You could constantly re-share new introduction keys to end leaking, but knowing the miners address alone is enough to DOS attack it.  This kind of approach also doesn't address the issue large miners often suspect other large miners of being a perpetrating attacker, e.g. delegating your peering to a hopefully neutral third party can make business sense. I guess you do accommodate that by virtue of the miners being able to choose the addresses they share, allowing them to instead delegate a third party at that point.

I guess these reasons along with a lack of visible attacks on P2Pool, the ease of the manual peering method, and the complexity of implementing something like this is why it hasn't been done so far... but its good to see someone thinking out more of the details.

Very little happens at all if it doesn't work. It's only used for hosts which are behind nat, which don't use UPNP to learn their address, and which don't have a manually configured address. These addresses are only used for announcing to other peers what addresses they can connect to.

Because it should have been lower based on the hashrate, but the system imposes a minimum (which is the definition of difficulty 1).

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.