roberrrrrrt

I put direct dependencies in requirements.txt. Then I run `pip freeze > requirements.lock` within a docker container of the team's target deployment environment. I commit both files, and the deployed application is configured to use the requirements.lock.

> it's running completely on smart contracts

The human judges/arbitrators aren’t, and they’re what’s critical. The contract cannot be sensibly completed without their input.

So you have an escrow system where human judges need to supply critical information. I’m left having to trust the human judges, unsurprisingly. Running this basic escrow code on the blockchain means that I no longer have to trust the kind of basic escrow code that’s used in centralised escrows. My question now is whether the escrow code of centralised providers (if condition then funds.release()) is really so unreliable that I’ll get get tonnes of benefit using blockchain escrows. Whenever there’s controversy over escrows, it comes down to the arbitration, which as you admitted would still be performed by humans.

Ok, but this isn’t purely a smart contract anymore. You’re describing a typical escrow (running on a blockchain, because ______) with human judges, conceptually identical to what goes on behind the scenes at EBay. What necessitates a blockchain here?

Getting data in isn’t the big issue though, and we’ve had market data streams since forever. I’m talking about the example above, where a smart contract would need some way of knowing when to flip the “Bob has satisfactorily finished community refurbishment” flag. This would require an abundance of interoperable data sources for bizzare things. Where do I subscribe to the count(dogshit_pile_in_the_playground) stream, and who or what is publishing to it in a trust-less manner?

The “different approaches to solve this” part, if it ever arrives, would be much more revolutionary than the blockchain itself.