Huh. No, in the (refined) GGPR'12 construction that you're referring to with the other criticisms (e.g. the CRS assumptions) the verifying keys are 2.8KB. This probably compares pretty favorably to program size for any program complicated enough to actually need a turing complete expression. The proving keys are huge, which might be what you were thinking of— but they don't have a major impact on the network.

The verification keys may end up being larger for something without the CRS security assumptions— though as you note its possible to just reuse a single universal circuit for all computations with some efficiency loss.

I think that the more important point in all this is that in a publicly verifiable system like Bitcoin what you want is _not_ execution. What you want is a witness that proves that execution was performed faithfully and what its result was.  There is no need to have an identical computation performed over and over again, it's just waste. In many cases this witness must be at least partially zero knoweldge, in order to prevent miners/other nodes from replaying it and stealing coins.

The simplest way to get a witness for execution is to disclose the code and have everyone perform it again... but it's not the best: It can't be zero knoweldge, it exposes a lot of code that never gets executed, it requires all verifiers to completely reproduce the work— which creates a disincentive against verification which is opposed to the decentralization goals of the system (and if you don't care about trustless decentralization why not just run open transactions?).

SNARKs are a way (well a family of ways) to improve this and in theory they tick a lot of those boxes— e.g. they can achieve zero knoweldge, they can be very small, etc. But SNARKs (esp one particular kind of SNARK) are not the only thing that can be done.  E.g. without invoking moon math we can use the merkelized abstract syntax trees to at least get succinctness and privacy for untaken branches in execution.

In any case, part of the problem with trying to do powerful things in script directly is not that turing completeness itself is hard to make safe— it can be made safe with careful design— but when script evaluation time is non-trivial it will be necessary to build things like JITs to eliminate the 100 fold slowdown from dumbly interpreted evaluation and that will come with a whole host of consistency and safety risks. JITs which are internally indistinguishable from interpreted execution seem to be a pretty much unstudied area.

Keep in mind that execution inside a consensus system multiplies the security considerations of normal sandboxed execution tremendously since absolute consistency becomes a security requirement too, not just memory and control flow integrity.

Likewise, though still at "Shipment information received".

Is your lawyer as real as your VMC mining hardware*?

Chilling out may be advised for the moment in any case— the assembly line pictures and demos show that there is actual progress being made, it doesn't seem like backlash could possibly make it move along any faster. Sadly early customers are already screwed on these systems.

*For some context: CanadianGuy claimed to have received VMC mining hardware last month, this month it was disclosed that VMC was still working on RTL.

So, if you just need the sign of R.y and still get a reasonable speedup then maybe (e.g. with the sqrt cost). If you have to have the full value for R thats far less clear, as it would increase the signature size by 32 bytes, and thats not really acceptable. (Also even with R— I don't think you can avoid the sqrt because I think you need to check that R is actually on the curve, otherwise I think you'll create an attack)

There is risk in anything changed.

We get a 6x increase from changing from openssl (which is faster than bouncy castle) to libsecp256k1, but we've not switched to that it in the reference software in part because of concern for the correctness of the implementation as it is not very mature and has not had a lot of review. That also doesn't have the integration complexity of batch validation.

We (at least Sipa and I) were previously aware of batch validation and IIRC sipa experimented with it some for another curve.

Are you really getting a 2.5x while not having the y coordinate sign and doing combinatorial recovery?  If so thats really surprising to me.

Can you try implementing this on top of libsecp256k1? Getting a speedup on a very slow implementation— even though the speedup is purely algorithmic— is less interesting than getting it on a state of the art implementation.

FWIW, many FPGA bitcoin miners made out reasonably well relative to GPU miners even though the FPGAs were higher $/MH/s just due to lower power costs and secondary costs (e.g. motherboards/cpu/ram/power supplies) per hashrate.  Make sure you consider these costs in your comparisons.

Who cares about the X GH/s amount. It's irrelevant.

Hashes per Joule? Relevant.
Hashes per BTC? Very relevant.
Hashes per cubic meter? Relevant for some.

Hashes per second per device? Almost totally irrelevant.

I think Bitmain has done well in offering a device smaller than some of the preorder unicorns. There are certainly people who bought only one or two units who wouldn't have bought a 4x performing unit at 4x the price because they didn't want to dive that deep in... doubly so when the prices are not attractive enough that a healthy profit can be completely assured.

I don't know anything about Bitmain's per unit order processing and shipping overheads, but assuming that they aren't enormous I'd imagine that around $1k to $2k in value is probably a purchasing sweet spot in terms of making devices which are accessible to a large number of people without dealing with the trouble of a lot of small purchases.   Keeping the per device price around that much value but driving up the hashes per joule and hashes per sec per $ would probably be a good path forward.

Hm. I don't think it's that loud, and me and my SO sleep in a room with two of them. Though, — we've also been sleeping in a room with an Avalon, so maybe we've already gone deaf.

They're _much_ quieter than the original avalon at least.

This has also long been my opinion. I absolutely cannot understand what people are thinking, my best guess is that they're honestly confused about expected returns.

What doubly boggles me is that some of the same people who say they cannot tolerate variance turn around and gamble (with negative expectation).

Why do you even assume they are testing (much) on the production network?  Up-thread I was arguing that doing so is a poor choice both for technical (not a great test case, noisy and doesn't test things like big blocks) and professional (competing with your customers is bad mojo) reasons.

They didn't leave it running. Though it doesn't look like problems— it looks like they ran it there just for the demo.

http://eligius.st/~wizkid057/newstats/userstats.php/1CTtm4iiwqt35Rgew1DQW6YoSwN4bKNopf

My S1 purchased on Saturday arrived today and has been mining a few hours on P2Pool.

The inclusion of the PCI-E connectors was a nice improvement over the early hardware, I was surprised at how much time it saved.

What firmware do you have on those antminers? Your DOA rate is quite high.

It's especially hilarious on old transactions:

https://blockchain.info/tx/84f96975ea88d317676771a482c71f39ff53beda790c89c07ae82e427b4d090f

THREE HUNDRED AND SIXTY ONE MILLLLION DOLLARS.

https://blockchain.info/tx/14947302eab0608fb2650a05f13f6f30b27a0a314c41250000f77ed904475dbb

FORTY ONE MILLION DOLLARS

 

It would be only horribly annoying if it didn't randomly flip while following links within the site. As is, someone is going to make some mistake thinking they were paid more than they were due to the flipping changing the units out from under them...

Or they punched in the address wrong and it was invalid.

They attorneys taking it on contingency on the amounts above and beyond the offered settlements sure don't seem to agree with you. Everyone can also see the clear and explicit promises of 1:1 Bitcoin refunds both in public and in private communications. By all means, anyone who somehow didn't get the message that 1:1 refunds on failure were part of the deal and didn't make their purchasing decision because of it: take the settlement— leave the assets for the recovery of those of us who relied on the original terms.

The antminer graph I posted above has considerably better latency than the Avalon batch 1s (which still happily get me 100% eff).

Work absolutely fine.
also work fine.

(My selective quoting is only of the hardware that I'm personally running hundreds of GH/s on P2Pool with but given that you're outright wrong about those, I assume the rest of your list is equally BS)

Single blade antminer S1, Works fantastically on P2Pool:


And if there are non-trivial numbers of people with miners that don't respond to LPs then you sure as heck don't want to be sharing a pool with them. Higher latency or the lack of LP will ding (severely!) you on P2Pool but these things increase orphaned blocks generally. With other pools that aren't so critical amount miner timeliness that cost is shared by the miners. If your setup isn't screwy you're paying for other people's screwyness. Not on P2Pool.

Usually when the presentation of a matter of fact is contested you can usually make a version which everyone agrees is acceptable simply by adding a bit more information.

Instead of  "Their 28nm product is already 2-3 months late and no silicon in sight so far", you can say something like:

For their latest 28nm product BFL originally advertised a target of X, but when they also said "this timeline is not a hard and fast timeline and is not meant to be the bible of how we will be rolling out this product." and "This is our current projected timeline. It is subject to change." they weren't kidding around: It's now X past that "target" and the network difficulty is now Y times higher then when they started taking orders, and they haven't yet demonstrated a working chip much less shipped any to anyone.

As far as criticism goes, I think this is even more effective (e.g. tells the reader why they should care), avoids the rat hole of arguing over what "late" means which some readers may use as an excuse to justify ignoring your complaint ("I read elsewhere that it was just a target, this guy has an axe to grind!"), and avoids sounding too whiny.

When you've really got a strong position you can usually concede every ambiguous point to your opponent and walk away all the more convincing for it. Getting into knife fights over every last issue makes you look weak, desperate, or biased (something some of the vendors around here should learn!).

Testing on the public network is actually a really poor test, in fact.  It doesn't test a gamut of difficulties, it doesn't test large block sizes (most pools are only generating 250k blocks right now), it doesn't test large coinbase transaction sizes, it doesn't necessairly tell you that your devices have severe latency problems (isn't obvious on the public network with a short test, but kills you if you want to merge mine with a fast chain).

Several miners have shipped from hardware makers with firmware which had severe problems with larger blocks as a result of inadequate testing.

I'm also of the opinion that testing should generally not be done on the public network, and that any "testing" done on the public network for demonstration or burn-in purposes should be limited to small amounts and ought to be 100% paid to the customers. Anything less creates creates a conflict of interests.

But hey, in a free decentralized system no one can dictate the terms from the top down. So if we want good conduct from hardware makers we're going to have to demand it as a community, or just hope that they'll adopt it on their own to foster goodwill. ::shrugs::

In any case, great to see that CoinTerra has hardware up and hashing.