I saw the same.. potential investors out there, send me an PM. I'm leading an innovative startup that's getting ready for our first round of funding. (Details in private.)

This is a problem (the big problem I mentioned), but it's only tangentially related to backups. How do you identify transactions that belong to you in the first place? With P2SH multi-sig, the sender knows he is transferring money to you, but there is not sufficient information in the blockchain for you to figure it out. The solution to this problem (say, DHT of P2SH scripts) is also a solution to the backup issue.

A far more likely use would be a fishnet over GSM-encrypted phone calls in realtime.

@ShadowOfHarbringer, it depends on how you use P2SH. etotheipi is going a little overboard in that regard. With (currently) standard transactions, you shouldn't need to back up P2SH scripts as those scripts are fully recoverable from your wallet. However there are new types of transactions/crypto protocols on the drawing board would involve both your key and one or more keys not currently in your wallet. The fact that you are involved in that transaction would become opaque with P2SH, and some system would have to be put in place to recover the scripts involved. That is a big problem, but a solvable one.

That's not what's at issue. FLOPS is not, in fact, FLoating Point Operations Per Second but the numeric result of running a very specific, standardized benchmark from the LINPACK codes solving a large, dense system of linear equations. It is a benchmark that is meaningful for most scientific and technical disciplines, but says *nothing* about the ability to crank out SHA-256 hashes.

LINPACK, which is what measures FLOPS, is a test of general-purpose scientific/technical capability. Bitcoin is highly, HIGHLY specialized. Using a measurement of one to derive the other could be off by orders of magnitude, not even in the same ballpark. It's a totally meaningless, apples-to-oranges comparison.

Lol, that sounds so ominous.

Sure, but you'll lose any donated money that hasn't received enough confirmations to claim yet.

Not sufficient. What if I send money to you with a return address in case you don't claim it (your-key OR my-key)? The backup won't have my public key, so there's no way to recreate the P2SH hash.

There are some possible scripts whose properties depend on being public. David Schwartz describes one here that achieves anonymous donations/transfers, although it requires new opcodes for the scripting system.

Such a system would not be possible under P2SH.

I just had a few minutes to skip BIP 18, but I like it so far. Is there any reasons we would not want to depreciate the scriptPubKey/scriptSig system? In other words, is there any use case for knowing the actual script ahead of time?

I recommend timing the conference to be around the same time as the 25BTC reward reduction. Either shortly before so people can talk preparation, or shortly after (better, IMHO) so people can talk lessons learned.

Mini, instead of having an address represent a pair of keys, what about using the key associated with existing bitcoin addresses to sign a delegation certificate, which basically says "the owner of bitcoin address A approves of any blocks signed with key B". Delegation certificates could even be revoked, obviating the need to transfer money around if the block-verifying key is exposed.

It's a more general solution, doesn't require changing the bitcoin address format, and could be implemented without touching the block chain on an overlay network used by miners.

My knowledge about such things is more theoretical than practical. First of all You'd want to make sure your host/datacenter has a low-latency net connection (co-located close to a backbone would be ideal). Then you'd want to tweak p2pool settings to increase the maximum number of connections, and probably add code if it isn't there already to prioritize both low-latency as well as distant (many-hop) nodes.

As to how you'd actually do that, others might be more knowledgeable. I haven't actually worked with the p2pool codebase yet.

Except that it does. If I'm getting 7.0% stales on my setup, switching to p2pmining at 6.3% would net me 0.2% profit even after his 0.5% fee. Likewise if I can get much lower on my own, the effective fee of using p2pmining would be that much higher. You can think about it this way: your stale rate is money you are losing out on, but everyone is sees a "bonus" equal to the average stale rate. Only if your stale rate is were exactly the same as the average rate would the net effect be zero.

The op seems to be on par with the average p2pool stale rate, which is good. I would expect that he could do even better though, if he tweaks his connection settings.

What's your stale rate?

EDIT: Sorry, I see that you have that on your website. I should have looked first.

Thanks gmaxwell, that's the kind of explanation I was looking for. I think I understand Meni's original post now--the harmonic mean is clearly a flawed choice in this case.

That's no different than the incentive in the current system, however. The existing constraint on block header timestamps vs. network time caps the amount of michief that can be done in either case. But with the harmonic mean every miner would have to lie to achieve the same effect as just the miner of the first/last block being dishonest in the arithmetic mean scenario.

Are you talking about continuous difficulty adjustment? Otherwise I'm really not sure where you're coming from. The question in the OP is about a drop-in replacement of the method for determining the average hashrate in bitcoin's once-every-2016th-block difficulty adjustment. I assure you it does work as I have live code doing it right now, and it retargets just fine; it even results in a more accurate adjustment. The harmonic mean, not the arithmetic mean, yields the actual average hashrate for the last N blocks, although the difference between the two is typically very small.

The question is more theoretical than anything. Such mischief would result in at most an increase or decrease in the difficulty by a few percent, and would likely be corrected in the next round anyway. Really I'm asking the question out of a desire to understand: I'm wondering if there is a reason Satoshi decided to use the arithmetic mean (such as preventing an attack or removing incentive for bad behavior), or if it was just a mistake (a very common mistake, to be fair).

That's actually how I came to thinking about this. I was looking at the retargeting code and got to thinking about how even if the time-warp bug were fixed one might still go about causing mischief by coming up with acausal values for the block header timestamp. Because an arithmetic average is used, all that matters for the difficulty calculation are the endpoints of the retargeting interval--the miners that happen to find the first and last block of an interval are privileged in their ability to affect the difficulty retargeting algorithm by about +/- 2 hours (0.6%) each. If the harmonic mean were used instead, such potential/risk would have been evenly distributed across all blocks. (Additionally, a pool operator with a significant percentage of the global hash rate could further move the difficulty by a few percent by mucking around with all its blocks so as to skew the network time in one direction or the other, but this remains true in either case.)

By not fixing the time warp attack the problem is exacerbated, as otherwise (with the fix in place) an inflation of the perceived difficulty of one retarget interval would have a corresponding deflationary effect on the following round, and vice versa.

Bitcoin uses a simple arithmetic mean for its retargeting algorithm. But since it's adapting to a change in rate, shouldn't it be using a harmonic mean instead? Of course it is probably way too late to change the algorithm, but wouldn't an arithmetic mean give mine pool operators who fudge timestamps a disproportionate effect?

EDIT: As gmaxwell and Meni Rosenfeld point out, bitcoin is actually measuring the rate parameter of an exponential distribution, for which the arithmetic mean is the proper choice. Also, the harmonic mean could be manipulated by miners via acausal blocks or very short timestamp differences.

And I see now that is the other half of the equation that I was missing. PPLNS pays the last N shares of the share chain, so a high stale rate means that shares which do make it into the share chain stay within the PPLNS dividend window for a longer period of time, so that on average it balances out. It's interesting to note though that the two effects are not exactly the same from the perspective of an individual miner: the hit due to stale rate depends on their individual setup, particularly their network and graph connectivity, while the “bonus” due to PPLNS is based on the whole network's average stale rate. In practice well connected miners would be taxing a small but measurable amount from miners that haven't bothered to "fix" their stale ratio.

But that's leaps and bounds different from my claim in the OP, and I apologize for the unintentional (though well-meaning) FUD. I'll update the OP accordingly.