4 ms·

Exactly, ethereum is "pushing the borders" on a "border" of bitcoin that noone seems to be running into yet, or caring about, anyway. Once multisig is used mor

by drcode 13y ago

Exactly, ethereum is "pushing the borders" on a "border" of bitcoin that noone seems to be running into yet, or caring about, anyway. Once multisig is used more heavily in the bitcoin world then maybe a better case can be made for ethereum becoming a success (though I nonetheless find ethereum tremendously exciting, from a pure technology standpoint)

nullc 13y ago
> ethereum tremendously exciting, from a pure technology standpoint I don't. I think it's the wrong model and it's only interesting when you don't have a very complete model of what computation is doing inside a consensus system. What script is actually doing in Bitcoin is not "running code"— running identical code with identical on hundreds of thousands of nodes just for it own sake would be stupid and wasteful. What happens is that users of the network run the code themselves and their scriptSig is a proof that they ran the code correctly (and that the code accepted their inputs). The simplest way to do this is to replay the execution, but now it makes sense: The network runs the code to verify you ran it right, and by doing so the contract embedded in the script is made trustless. Running the code in the network has a lot of downsides, however. It completely lacks privacy (except to the extent that we have an opcode that implements a zero knoweldge proof of knoweldge of the discrete log of an EC point), and there is tremendous pressure on the computational complexity, implementation complexity risk, and size of these scripts because of the cost of verify them. Script execution is a pure externality that we only safely know how to cope with by making sure that it is very very cheap (we do this in Bitcoin by making sure that trivial static analysis can determine the execution cost (measure the size), and then bounding that cost). But actually executing the script isn't the only way to verify computation was performed correctly. Using cryptography it's possible to have constant size and complexity proofs, independent of the program size. This lets you cook up stuff like: https://bitcointalk.org/index.php?topic=277389.0 https://bitcointalk.org/index.php?topic=277389.0 and I find that a lot more exciting. Especially since these kinds of enhancements don't demand the risky tradeoffs that making script more expensive demands. I'm also excited about distributed oracles— programs that sign transactions conditional on user specified code, including— potentially— external inputs. The ability to have external inputs (trusted by the oracle) greatly increases the expressive power beyond what any in-consensus system could have, and using multisignatures with multiple oracles you can achieve good security though not trustlessness. E.g. "This tx pays to bob if bob.com is on the first page of google, otherwise after april 1st it can be redeemed by greg". I would expect to see any attempt at more powerful script first implemented via multisignature oracles before even considering making it trustless by merging it into the network.

by drcode 13y ago

nullc 13y ago

> ethereum tremendously exciting, from a pure technology standpoint I don't. I think it's the wrong model and it's only interesting when you don't have a very complete model of what computation is doing inside a consensus system. What script is actually doing in Bitcoin is not "running code"— running identical code with identical on hundreds of thousands of nodes just for it own sake would be stupid and wasteful. What happens is that users of the network run the code themselves and their scriptSig is a proof that they ran the code correctly (and that the code accepted their inputs). The simplest way to do this is to replay the execution, but now it makes sense: The network runs the code to verify you ran it right, and by doing so the contract embedded in the script is made trustless. Running the code in the network has a lot of downsides, however. It completely lacks privacy (except to the extent that we have an opcode that implements a zero knoweldge proof of knoweldge of the discrete log of an EC point), and there is tremendous pressure on the computational complexity, implementation complexity risk, and size of these scripts because of the cost of verify them. Script execution is a pure externality that we only safely know how to cope with by making sure that it is very very cheap (we do this in Bitcoin by making sure that trivial static analysis can determine the execution cost (measure the size), and then bounding that cost). But actually executing the script isn't the only way to verify computation was performed correctly. Using cryptography it's possible to have constant size and complexity proofs, independent of the program size. This lets you cook up stuff like: https://bitcointalk.org/index.php?topic=277389.0 https://bitcointalk.org/index.php?topic=277389.0 and I find that a lot more exciting. Especially since these kinds of enhancements don't demand the risky tradeoffs that making script more expensive demands. I'm also excited about distributed oracles— programs that sign transactions conditional on user specified code, including— potentially— external inputs. The ability to have external inputs (trusted by the oracle) greatly increases the expressive power beyond what any in-consensus system could have, and using multisignatures with multiple oracles you can achieve good security though not trustlessness. E.g. "This tx pays to bob if bob.com is on the first page of google, otherwise after april 1st it can be redeemed by greg". I would expect to see any attempt at more powerful script first implemented via multisignature oracles before even considering making it trustless by merging it into the network.