The idea in the ZKCP page is that you take some information you want to pay-for-disclosure for but which the Bitcoin network can't currently evaluate a disclosure test for and you use a ZKP to replace your original wish ("I want data X") with one the Bitcoin network can pay-to-proof ("I want the hash preimage of Y, because I know that if I have that I can decrypt something to get data X").

One of the limitations of this approach which reduces its usefulness for pay-to-identity it that it's interactive. You need a hashed key provided by the proving party and you need to see the out-of-band proof before writing the actual payment transaction.

If, instead, script could validate a SNARK you could remove the interaction and have a real "pay to proof" rather than an interactive "pay for proof" which would then make it more useful for things like the identity based payment.

Hm. Interesting point. It doesn't actually have to be backtesting based.  E.g. You say "I have a program that can win at stocks" I respond "Past performance doesn't indicate future results: Give me a proof that you timestamped your program in the blockchain N months ago, and a ZKP that your program also predicted future prices for the following N months", though a little care must be taken to eliminate post-selection: e.g. where I timestamp a million programs and then only offer to sell you ones that won retrospectively.

P2Pool all time "luck" is now at 117.6%— It would be interesting if we had a way of telling how much of that is actual luck vs just p2pool having a block relaying advantage due to its highly distributed nature.

I've finally moved my old (Nov 2011, yikes) "Why hash locked" page on the Bitcoin Wiki to the main namespace:

https://en.bitcoin.it/wiki/Zero_Knowledge_Contingent_Payment  (Go read this if you haven't before)

I'd like to get around to actually performing one of these transactions as a public demo, but I've struggled a bit with finding a simply understood (e.g. answer to some complicated science question is not so good) example which is not politically controversial ("I'll pay you for the masterkey that breaks Widevine DRM") but also one that isn't so contrived that everyone doesn't just say "Why not used a trusted arbitrator".

Any ideas?

A useful point I should have made here is that you can basically apply this same protocol encoding to any script-releasable-escrow in order to keep the release details private.

E.g. something like the zero knoweldge contingent payment protocol could be used in place of the normally-not-announced first release transaction in order to keep private that you were using a ZK-payment.

Hm? I'm not that negative, as far as I can tell a lot of people are perfectly happy with them. When I communicated with them they couldn't keep a consistent story and it made we wary, but I'm glad other people are happy with them. I'm personally not all that happy with any of the major hardware companies right now, I'm concerned that their business practices have not been doing the ecosystem well, but thats neither here nor there and KNC is certainly not the worst of it.

Go update the mining hardware comparison as it's claiming 2.5w/Gh, if thats wrong then I retract my whining.

You read incorrectly.

I realize you're joking there, as you've indicated with your small text. But a lot of users are really confused by this stuff and will actually do this, and over and over again they get robbed.

Desktop computers are actually quite good sources of randomness. They monitor the precise timing between keypresses, mouse movements, disk seeks, network packets, and other sources of enviromental nodes and then they combine this data into randomness pools which are stored by cryptographic hashes so that even if most of the data that goes in is unpredictable, so long as there is only a few hundred bits of actual randomness that makes it in all the output is at least computationally sound.

Bitcoin-qt retains its own randomness pool— really the openssl code— and augments it with further entropy from timing and, on windows, a screenshot at startup.

No. Trying to find something to simply pin an "in charge" badge on in Bitcoin is an effort doomed to failure.

Bitcoin is, first and foremost, a zero-trust consensus system which assumes its peers are malicious and so it autonomously validates all the information it receives and imposes the hardcoded rules of the system all on its own. Miners are anonymous participants— they self-select and come and go as they wish— and are also generally assumed by the protocol to be malicious.

Unfortunately, it's not possible to validate _everything_ in a fully autonomous manner, because the possibility of double-spends— two transactions which spend the same Bitcoin, something prohibited by the rules— demands knowing an ordering for transactions in order to resolve which of multiple spends is the survivor. A consensus ordering cannot be determined in a fully trust-less and decentralized manner for fundamental reasons (e.g. even relativity teaches us that the order you perceive events depends on your position).

So, instead, we use a weak computational vote to choose an order, which has the benefit of being easily validated by computer so its useful as an automatic consensus tool. But Bitcoin is not a democracy, democracies are inherently oppressive if less so than the other systems that order people around against their will— the majority wolves voting to eat the minority sheep for supper— and the computational vote seldom aligns with actual people, it can be bought. The 'vote' is only used for determining transaction order, and the imposition of all the rules by all the other participants is believed and hoped to remove most of the incentives to abuse ordering influence— a kind of economic hack, because participating in the ordering requires expending scarce resource, and that effort is only rewarded if your work ends up in the chain that the network accepts.

So when you ask the question about changing the rules you have to ask about what kind of change you're talking about:  If it is a change which involves tightening them— e.g. restricting transactions that previously would have been permitted— then you can achieve the change through ordering control, a super-majority (a simple majority is unsafe) of miners can use their ordering control to "infinitely delay" any transaction which doesn't meet the new rule. Sadly ordering control implies the power to censor, but on the plus side it does make adding new restrictions easier.  The Bitcoin protocol was designed with many placeholder "meaningless but permitted" messages, which can later be restricted to add new features.  If instead you ask about a change that would permit something which is currently forbidden, then _every_ remaining participating node must be updated. If the rule weakening shows up in a block it— and all subsequent blocks in that chain— will be completely ignored by nodes not updated to accept it.  This is why miners printing themselves 100btc/block is simply equivalent to them no longer mining, at least in a world where many people run full nodes.

Cheers,

KnC's inability to tell a consistent story was one of the reasons I happily chose to not to business with them. They've clearly stated both before and after product production that it was a structured asic run, and their power results support it. Ultimately it doesn't matter if they used crackerjack boxes to make their masks, at the end what matters is the specs and they're a mixed story. I mean, sure, feel free to not care.  But a 2x increase in operating cost, and thermal load is not "a few watts", especially for those of us not interested in a high risk gamble involving mining for a few months and then throwing the hardware out.

By all means, be happy with their product— they shipped a working device to many people mostly on time, better than a lot of other vendors, and many of those customers will be happy enough with a product that goes to the landfill before the bitfury and bitmain devices. Though in terms of feature size I don't see a reason to brag about 28nm when it doesn't achieve substantially better hashrate per U or hashrate per watt even close to multiple competing 55nm designs.

even in a datacenter— Three antminer S1 are is faster than a KNC jupiter, and I believe they take up less space (if not less, it's close— I don't have the dimensions of the KNC handy). yea, sure they involve more chips... but they are low power so they can reach reasonably high chip density in a single unit.

I dunno that fixating on the process node matters.  KNC's product is a structured asic, just one step up from a FPGA hardcopy... and it shows it— the power efficiency is half that being achieved in shipping products by others (bitfury, bitmain) on 55nm, and much lower than the 28nm products in preorder are claiming.

Maybe in the future bids should have to come with signmessages for keys with access to enough coin. Geesh. Too easy for a trouble maker to goof up an auction.

Ah ha, it's an anagram for "Gets mine, hide!"

6 @ 3.50

Absolutely not.

Can you tell me more about what configuration you're running?

Not to be too blunt, I hope, but are you making up figures? You shouldn't be able to obtain that many connections (and at that level you're close to causing memory corruption from >1024 file desc in select).

The spec described it as random, and if you looked at and didn't think too hard the claim of random sounded pretty good... "They used a cryptographic hash to set the values, not really any algebraic structure going to be found there!".

Like a lot of things, its seems completely obvious in hindsight, but personally I only thought to reconsider it while I was in the middle of blabbering off to someone "there is no real reason to be concerned, they set them randomly using ... wait a minute!",  ... and even then I'd been spending time dorking around with zero knoweldge proofs based on the fiat-shamir heuristic, in which an attacker grinds at a hash hoping to get a lucky value the has him make successful validation probes.

I wasn't the first person to express some reservations about the methodology used for the NIST curves (e.g. the Brainpool curve RFC shows the NIST curves no love), though I'm not aware of anyone pointing out that someone could have tested seeds until they got a weaker (or stronger) one until I did, though I sure others _must_ have realized it. It's also more obvious in contrast to secp256k1 and ed25519 which have fewer— almost no— degrees of freedom.

Is this on a VPS?   Can you run ulimit -a and show me the output?

There were a bunch of incidents where it looked like SD customers got screwed by doublespends... I never understood why people didn't complain.  This had upped my estimation that most of the SD activity was shareholders trying to pump their shares (an estimate that increased exponentially after it went non-public and the traffic basically dried up instantly)