Hacker News Reader

Comment by mthoms | Hacker News Reader

By participating you're agreeing with whatever mechanism has been coded into the contract (which you can read for yourself). Obviously, you'd be stupid to participate in a contract that relies solely on twitter for resolution.

But, for sports scores the contract could be coded to check all three of espn.com, nfl.com and abcsports.com (just for example).

Same with the election results: usa.gov, cnn.com, foxnews.com, bbcnews.com

You make a valid point I think, but the examples you gave are pretty trivial. More complex ones are another matter.

View on HN

Actually, it can't. In no existing blockchain-based smart contract system is contract code able to request random data from websites and act upon it. Websites as external sources are not deterministic, and determinism is necessary for the computations to result in the exact same result on any of the nodes that are part of the network in question. This also includes - and this is forgotten quite often - determinism across an eternal timespan! It can't matter when I want to recompute a certain contract transaction - it always has to return the same result.

The only known solution for these problems is to have an oracle inject the necessary "knowledge" into the blockchain itself and then have the smart contract code work with this data, that is then stored on the chain forever and thus makes everything deterministic again. But the oracles come with their own sets of problems, like them just being another "trust anchor" (and they're one that you can't validate the code of, since the oracles themselves by definition have to reside outside of the blockchain, it's just the data that ends up within it) or the giant pollution of the blockchain with data that they cause.

Even these very simple examples don't pass the reality check on close inspection.

this is actually incorrect you can verify a tls connection was made to a server and a particular output was given in that tls connection with oraclize it.

Which is just an implementation of precisely the oracle scheme I talked about. Introducing precisely the problems I mentioned: blockchain bloat, additional trust anchor which can never be 100% validated and thus destroys the idea of requiring zero trust in any particular individual person or system.

I don't see it as so black and white. Sure, zero trust is the ideal, but there are potentially benefits even there's some trust involved. For example, I saw a headline indicating that Unicef was going to experiment with block chain technology and asset management. Charity strikes me as particularly suitable domain since benefactors are understandably concerned about how their donations are being used and there's little need or even desire for secrecy. Block chain could provide an unparalleled degree of transparency and accountability even if the humans in control of the private keys ultimately need to be trusted. "Trust but verify" as Reagan said, and it would help a great deal with the latter if not the former.

Once you're willing to trust, you don't need the proof-of-work that makes blockchain blockchain though. A distributed append-only, log-structured, cryptographically verified is a great idea with plenty of practical applications; OTOH "mining" is an immense waste of energy to minimal benefit.

You may only need to trust some but not all actors in the system, so there may still be benefit in mining.

Extending the chain of trust down to the source of information isn't exactly going to happen at a snap of a finger. If you trust TLS and trust what the server gives you then today that is a fine option, the server is signing a piece of information and giving it to you, this is no different from you signing a transaction and publishing that transaction to bitcoin the trust ends in just the same way in each case with the caveat of 'value' being created from a web service. An attacker gains access to either the producer of the transaction (client code or web service) or the keys to sign the transaction (tls or bitcoin private key). That said I agree that modern web services could much more easily be made to give an incorrect response.

I don't think your argument applies any differently to other cryptography, it all looks like jumping through hoops for no guaranteed safety. If you believe that the only thing that matters is 100% safety then you are going to be very disappointed with computer security in general.

Reply on news.ycombinator.com