5 ms·

I mean, that’s just kind of argument against…computers? Code is itself a compromise. Do this thing for me, and in exchange for not having to do the thing you l

by tyre 8y ago

I mean, that’s just kind of argument against…computers? Code is itself a compromise. Do this thing for me, and in exchange for not having to do the thing you lose flexibility.

foepys 8y ago
If any (No)SQL database contains a mistake, you can either fix the mistake or change the program working with the data to either ignore or override the mistake. Smart contracts are running on an immutable database, the blockchain. If anything is landing there because of an error in the contract, you will never get the mistake out. It's engraved forever. Updating a smart contract should never happen because once you can update it, you can change its contents and its rules in a way that might benefit only one side. Even if you create rules to update the contract, finding 100% consensus (everything below 100% is unacceptable if you are explicitly using smart contracts to disallow cheating) to update the contract takes time in which more mistakes might happen and make the whole contract unusable.
TeMPOraL 8y ago
> I mean, that’s just kind of argument against…computers? No, it's an argument from programmers' common sense. Smart contracts are code, and we all know that any program more complex than hello world will contain bugs, due to both coding mistakes and errors in modeling the relevant aspects of reality. Given that, binding people with (immutable!) code seems like an extraordinarily bad idea.
- derefr 8y ago
  I've never understood smart contracts as binding people to anything in particular. People can cash out of the cryptosystem and go do whatever. Smart contracts are binding against machine agents, who have no alternative economy to participate in.
  - wrs 8y ago
    Contracts (smart or not) that aren’t ultimately binding some people to some behavior are pointless. Computers do not (yet) have their own independent desires and economy.
  - michaelscott 8y ago
    If it's exclusive to machine agents there are plenty of consensus-oriented protocols already in existence that could accomplish the same goal without relying on a blockchain. Machine agents are already bound by the code that executes and models them, all you'd be doing is adding a layer of consensus-driven redundancy for security reasons (both technical and social).
    - derefr 8y ago
      > there are plenty of consensus-oriented protocols already in existence that could accomplish the same goal without relying on a blockchain Assume: 1. a distributed system where the consensus algorithm is state-dependent (in the sense that an SQL RDBMS that exposes the ability to insert rules/triggers has state-dependent consensus—different MVCC states will see different transactions as valid/invalid); 2. malicious machine-agents (bot oracles) supplying arbitrary input into the distributed system; 3. the distributed system being open-membership, such that malicious people are running auditing nodes (and so you can't really do Raft consensus); 4. the distributed system being large enough that you can't really do Paxos consensus in any efficient way. Is there any other solution to this problem, than to use the consensus algorithm of: 1. have many nodes redundantly, eagerly audit a block of new inputs; 2. on each step, choose of those blocks essentially by lottery (specifically, a lottery no individual node on the distributed system can predict or cheaply craft an input to win); 3. allow anyone who wants to, to configure their node to fully verify past blocks, such that enough nodes doing this will create "herd immunity", diverging the system away from maliciously-crafted blocks. Step 2 of the algorithm requires Proof-of-Work (so far as we know); step 3 of the algorithm requires an accessible chain of signed proofs to audit. Together, those spell "blockchain."
      - TeMPOraL 8y ago
        Real-world applications rarely require all the assumptions that are necessary for blockchain to be the best solution. For instance, some real-world systems will not be distributed; others will be running under common ownership or under ownership of people who trust each other mutually, etc. There's this adage[0], that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations". It's usually meant negatively, but in this case one can draw a positive conclusion - just like organizations don't need the blockchain to efficiently do their businesses, automated systems designed by those organizations may not need the blockchain either. -- [0] - https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law

by tyre 8y ago

I mean, that’s just kind of argument against…computers? Code is itself a compromise. Do this thing for me, and in exchange for not having to do the thing you lose flexibility.

foepys 8y ago

If any (No)SQL database contains a mistake, you can either fix the mistake or change the program working with the data to either ignore or override the mistake. Smart contracts are running on an immutable database, the blockchain. If anything is landing there because of an error in the contract, you will never get the mistake out. It's engraved forever. Updating a smart contract should never happen because once you can update it, you can change its contents and its rules in a way that might benefit only one side. Even if you create rules to update the contract, finding 100% consensus (everything below 100% is unacceptable if you are explicitly using smart contracts to disallow cheating) to update the contract takes time in which more mistakes might happen and make the whole contract unusable.

TeMPOraL 8y ago

> I mean, that’s just kind of argument against…computers? No, it's an argument from programmers' common sense. Smart contracts are code, and we all know that any program more complex than hello world will contain bugs, due to both coding mistakes and errors in modeling the relevant aspects of reality. Given that, binding people with (immutable!) code seems like an extraordinarily bad idea.

derefr 8y ago
I've never understood smart contracts as binding people to anything in particular. People can cash out of the cryptosystem and go do whatever. Smart contracts are binding against machine agents, who have no alternative economy to participate in.
- wrs 8y ago
  Contracts (smart or not) that aren’t ultimately binding some people to some behavior are pointless. Computers do not (yet) have their own independent desires and economy.
- michaelscott 8y ago
  If it's exclusive to machine agents there are plenty of consensus-oriented protocols already in existence that could accomplish the same goal without relying on a blockchain. Machine agents are already bound by the code that executes and models them, all you'd be doing is adding a layer of consensus-driven redundancy for security reasons (both technical and social).
  - derefr 8y ago
    > there are plenty of consensus-oriented protocols already in existence that could accomplish the same goal without relying on a blockchain Assume: 1. a distributed system where the consensus algorithm is state-dependent (in the sense that an SQL RDBMS that exposes the ability to insert rules/triggers has state-dependent consensus—different MVCC states will see different transactions as valid/invalid); 2. malicious machine-agents (bot oracles) supplying arbitrary input into the distributed system; 3. the distributed system being open-membership, such that malicious people are running auditing nodes (and so you can't really do Raft consensus); 4. the distributed system being large enough that you can't really do Paxos consensus in any efficient way. Is there any other solution to this problem, than to use the consensus algorithm of: 1. have many nodes redundantly, eagerly audit a block of new inputs; 2. on each step, choose of those blocks essentially by lottery (specifically, a lottery no individual node on the distributed system can predict or cheaply craft an input to win); 3. allow anyone who wants to, to configure their node to fully verify past blocks, such that enough nodes doing this will create "herd immunity", diverging the system away from maliciously-crafted blocks. Step 2 of the algorithm requires Proof-of-Work (so far as we know); step 3 of the algorithm requires an accessible chain of signed proofs to audit. Together, those spell "blockchain."
    - TeMPOraL 8y ago
      Real-world applications rarely require all the assumptions that are necessary for blockchain to be the best solution. For instance, some real-world systems will not be distributed; others will be running under common ownership or under ownership of people who trust each other mutually, etc. There's this adage[0], that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations". It's usually meant negatively, but in this case one can draw a positive conclusion - just like organizations don't need the blockchain to efficiently do their businesses, automated systems designed by those organizations may not need the blockchain either. -- [0] - https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law