Luke made it online and got it back up— unfortunately he's suffered a laptop failure while on his trip.

I'll instrument the code I'm running to check.   One thing that might help is just increasing the number of front ends you're running, even on the same systems.

I haven't hacked on pushpool for a while, but when I last did it had a lot of blocking IO.... so a few slow sockets could really bog down its response time.  I actually have no clue what you're running but if has a similar design you might get better throughput just by running more processes.  (You could load balance with some OS level rounding-robbining  of the sockets or just by giving users more ports to connect to)

I'm seeing the same issue with cgminer on fast systems— watching the traffic I'm seeing the pool take several seconds to respond to getwork requests and the miner runs dry.   I _assume_ this is hurting my hashrate as you're reporting 1.80GH/s against a system which does 1940.6 MH/s day in and out, though maybe I've just had bad timing.   I do see the 0.2% stale rate, which is nice enough.

Cgminer systems can have a lot of hash rate behind a single connection, and they avoid queuing much work to avoid stales... so it's important to keep them saturated.

I didn't bother reconnecting to check the headers, do you have nrolltime enabled?

(For the purpose of this reply I'll use 'money' to mean a commodity which is super fungible and liquid and is used as a proxy exchange of value)

The notion that something used as money ought to have independent value is fundamentally broken.

If you have some useful good, there will be some price which depending on the supply and demand, costs and benefits of using the good should result in the most efficient use of that good possible. (given a bunch of assumptions that are never true, but are probably close enough)

If you have some scarce thing used as a highly liquid exchange placeholder, a money good, there will be some valuation at which it does its job best (depending on the overall economy and the properties of the thing).  

It is unlikely that these prices will be the same, or even similar.  So when you combine the uses you get something which is less efficient than having them separate.  We see this with gold where gold is priced much higher that materials which are more rare (and harder to mine), more industrially useful, or compared to things which are equally useful or superior for jewelery, etc.  Many productive uses of gold are denied because much gold is being held up in vaults in order to store value.

The argument that bitcoin is somehow backed by computational power is a misunderstanding of what people conventionally mean by backing.  When people talk about a money being backed by something, they're referring to something providing a floor under which the value of the money can not fall even if confidence in the good as a liquid unit of exchange is lost. E.g. If everyone suddenly hates gold you can still use it to manufacturer useful electronics.  This is the _only_ benefit that comes from using an otherwise useful good as money.  Just like broken escalators become stairs unwanted gold coins can become excellent paperweights, tooth fillings, and electronic connectors.

The computational power behind the block chain does not provide this property. The computation is not reusable, it's not useful to you except insofar as it makes bitcoin technically secure, something you only care about if people consider bitcoin valuable. If everyone hates bitcoin you can't melt yours down and reuse the cpu power. It may be necessary to give bitcoin value but its not sufficient.

Bitcoin is unbacked as are all major official monies— sure they're theoretically backed  by the ability to pay taxes using them but should confidence in the money collapse to the point when that backing becomes relevant you're probably not going to care about paying taxes (especially since the taxes will increase in amount as the money loses value). People trust official monies because they know other people trust them and because they trust the issuers to not destroy their value by ruining scarcity.  The same applies for Bitcoin though the trust is justified for different underlying reasons.

If you really must believe that bicoin is backed by something even if its a backing which would be worthless if you ever had to call on it like what backs the USD, then you can consider it backed by the interest of geek collectors. Even if the system is a complete failure there will always be some geek willing to buy it from you for novelty value.

Looking at the pure odds is misleading because for any given address the detectable errors might be all the impossible to type errors while the undetectable errors might be all the easy ones.  So sure, 1/2^32 overall, but in reality it takes the form of some addresses that are harder than that to mistype and a great many which are much easier than that to mistype.  This is why people almost always use CRC's rather than randomized hashes when the check data is as small as 32 or 64 bits.  Randomly distributed, 32 bits is not much protection and you can usually say something about the likely errors.

I don't see how to make an attack out of it— you could search for an address that was easily mistyped quite quickly e.g. with vanitygen  but finding a pair seems kind of implausible to me.

On reflection, the code for this would be simpler than I thought because you only need code for an encoder if you're not interested in recovering corrupted addresses only validating against errors. If we were using base 32 or 64 I'd already have code for it and it would only be a couple of lines and a small table. I'll give it a try this week and post a proposal if I get something I think sounds attractive... on a different thread. Sorry for feeding the tangent here.

Yuck.  And _still_ not get complete resistance to common typos.

32bits is already enough to detect all cases of up to to _5_ errored characters (and even correct fewer errors, if you want... as well as detecting many but not all cases of other errors).  This gets you immunity to many typos as well as all simple transpositions.  This is better than you're going to get even with increasing the hash size further. (figuring out the handling of dropped/doubled characters is harder, but the encoding should just be made constant length, which would make that easier to detect and easier to validate)

Someone could probably design such an error correcting code with better performance (e.g. strong resistance to near misses)— but the implementation would be non-trivial... Not that sha256 is trivial, but people already have it available.  This may make people who want e.g. JS validation of addresses a bit irritated.

This isn't a realistic threat.  No sane hardware miner would have any transaction visibility or any communication with the outside of taking block headers in and out.

Whats been proposed here is a generic mechanism that would be useful even if we only had machine to machine transactions.  I'm not seeing how other mechanisms can provide what op_eval provides, especially not without having more parties to trust.  Can you elaborate further on this point?

There have been a number of proposals that would make this more safe to deploy, e.g. using a flag in the coinbase to perform a majority vote of hashpower to decide the height to enable the feature.  Someone obviously needs to talk to some of the bigger miners and see if they have other concerns that need to be addressed but I don't see why a hashpower vote isn't sufficient, since the feature is non-forking.

But it's not a protocol rule (well, maximum txn size is I guess but thats already there)... this is more an issue of common norms on the network today, enforced by peers sure— but its not part of the distributed algorithm, nodes can and do disagree on it and it doesn't fork bitcoin.

Perhaps best practices should be described there, but just like the protocol rules don't tell you not to perform undefined operations in C I don't know that these other recommendations belong there.

Well, ideally (but not in the official bitcoin today) it's complicated by an additional integer-linear constraint:  You want the priority to be greater than the fee minimum unless there isn't a feasible solution with that constraint.

You also want to avoid creating change less than 0.01 btc, all things equal, unless you have a real output smaller than 0.01 btc or if meeting this constraint causes you to fail the prior one. (in which case, abandoning this one is better)

Well, now that you mention it... that number is only somewhat higher (2x-ish IIRC) than some estimates we did a while assuming a direct ASIC implementation, which was really a lowball figure and ignored support electronics and practical considerations. (Basically a straight account of gate energy usage with a basic unrolled miner on the 45nm process we had specs handy for).  So not completely impossible, but impossible for a FPGA on that process.

If someone was offering 22nm SASIC it might be a bit more plausible.

http://butterflylabs.com/products/

Their claims are not outside the realm of physical possibility like some past hardware miner scams have been— but they also don't appear to be possible, at least with current commercially available parts.

The webpage is very thin on evidence that they aren't a scam. The most compelling thing I've seen is that they're looking to hire someone who speaks mandarin, though while that bodes well for their honesty it doesn't bode well for their product actually existing.

I understand that a fair number of bitcoiners have sent them money (or, well, that they claim so— but I only know of one).

Anyone have any information?   It would be a pretty good deal if it were true.

naive indeed!   This will tend to generate _much_ larger transactions that required and will pretty much not work on many wallets.

Consider what happens when someone rains a bunch of 1e-8 inputs on you and then you try to send 1BTC ... your resulting TXN will be too big and will be either need enormous fees and may be ignored by your peers and the miners even with fees.

The subset sum solver isn't just an optimization. It's an important optimization.

(The actual coin selection in bitcoin could be a lot better too... right now its fee blind and will tend to produce solutions that pay fees which could be avoided… the only real defense against this is that pre-filtering that makes it first try inputs with many confirms, unfortunately good solvers for big integer programming problems aren't small pieces of code)

I'm looking for suggestions on this point.

Greetings.  So— you're convinced that bitcoin is going down for good.  Great for you— personally I haven't a clue.

What I do have is some bitcoin, so I'm entertaining requests for bitcoin loans.

Here is how it will work:

You'll figure out how much you want to borrow (up to what I'm willing to lend you),  and you'll put up a significant multiple of that bitcoin's current market value in gold, USD, or some other agreeable non-cryptocurrency asset into a third party escrow (I suppose you could up up an equal value of BTC, but if you've got the coin why borrow from me? I won't accept alternative block chains as collateral).

You'll pay me a modest amount for interest who's value depends on the amount you've put in escrow and the maximum length of the loan— and I'm willing to negotiate over the exact terms this.

Presumably you'll sell the coin after borrowing it from me then buy it back later when the market price is lower... but thats your business I don't care.

When the loan expires (or any time before then) you either return the same amount of bitcoin,  or you break the contract and I get the escrowed funds.

I benefit because I'll make some income on coins I was just going to sit on, the risk to me that you're compensating me for is the risk that bitcoin increases a bunch in value and you break the contract and all I get is the escrowed funds back.

The benefit to you is that you get to make use of your superior predictive powers. Without my help all you can do is tell everyone how smart you are, with my help you can prove it and profit from it.

0_o

The bitcoin days destroyed metric doesn't support the idea that there are enormous amounts of horded coins— a good a mount of coins are moving around.

I also don't see why people assume Satoshi has some enormous number of coins— bitcoin was made public as soon as the chain started (and had been discussed in public months before, so people knew what it was when it was announced).

He was far from the only user when bitcoin was announced— if he was only mining with a single modest cpu of mid to late 2000s vintage he might only have a few tens of thousands.   This guess is actually well supported by the initial data— bitcoin had enough hashing right at its launch to maintain 1/block per ten minutes but actually fell to what should have been difficulty .05 in late august 2009.  Because the system can't adjust to difficulty below 1 this loss of hash power just mean less coin was created overall.  If you make the somewhat conservative assumption that the remaining  miners included at least Satoshi and that he had similar hash power all year, then Satoshi could not have more than 5% of the first years bitcoin and very likely he wasn't the only remaining miner so that 5% would have been shared between everyone else who was still mining during the lull (and there was less coin produced in 2009 than programmed due to the time spent with hash power below diff 1... about 60% of what the system is programmed to produce in a year).  The large gap between block 0 and block 1 (when he made the system public) also supports the notion that he didn't have a ton of hash power applied.

We often view the early difficulty through the distorted lens of todays faster hardware and software. This is a mistake. modern mining software is an order of magnitude faster than openssl's SHA256 used simplistically, and modern CPUs are also much faster (not to mention GPUs...).

The funnier part is that the _block chain_ is not stored using BDB.... the blocks are stored in a simple flat file with the blocks appended one after another.

Support for signing arbitrary data using bitcoin 'addresses' is in the current development code and 0.5 release candidate.