3 ms·

The scripting language vision has been there from the beginning, but parts of it have been 'off' (in the reference client) because of incomplete implementation,

by gojomo 13y ago

The scripting language vision has been there from the beginning, but parts of it have been 'off' (in the reference client) because of incomplete implementation, or concern that the implications and potential bugs aren't sufficiently understood. I wonder if a future Bitcoin offshoot might even use a more general standard language for in-ledger transactions. Javascript? LLVM?

ssadler 13y ago
They couldn't, because Javascript etc are turing complete, so you can't predict if they're going to end (halting problem). With bitcoin you know that the script will end and that the running time will correlate loosely with the size of the script, so you can't really use it to mess up network nodes. Butcoin scripts have no loops or goto.
- gst 13y ago
  Actually you could. Just limit the max. number of instructions that are allowed to be executed in order for a script to be valid.
  - nullc 13y ago
    Indeed, you can, but then you have a very exact requirement on exactly how the interpreter is implemented which can never be optimized, and any disagreement between implementations can cause a world ending consensus failure. By not having looping or recursion script naturally gets an operation limit by virtue of having a size limit, and this is _relatively_ easy to get right between implementations. (Though, so far several of the alt implementations have gotten it wrong).
- topynate 13y ago
  You could require all scripting to be done in a language supporting total functional programming, like Epigram. That would be fairly hilarious (also counterproductive, because the increased script size would cause blockchain bloat).
- gojomo 13y ago
  A guarantee of completion isn't strictly necessary: you can cap the number of ticks/cycles a script is allocated on a deterministic reference machine. Surely there'd be a number of technical and economic challenges to be overcome, but Bitcoin itself is an example of how a good-enough solution may be hiding in plain sight.
pcwalton 13y ago
LLVM would be exceedingly bad due to its undefined behavior. A malicious actor could easily fork the block chain.
- ars_technician 13y ago
  >LLVM would be exceedingly bad due to its undefined behavior. A malicious actor could easily fork the block chain. There is nothing that indicates undefined behavior of LLVM would lead to a fork in the blockchain.
  - tlrobinson 13y ago
    Why not? The rules for validating Bitcoin transactions and blocks must be completely specified and followed exactly by all implementations of the client software, otherwise you risk forks.
  - nullc 13y ago
    Bitcoin is a consensus system. It is paramount that all participating nodes reach the exact same state. If undefined behavior could make some nodes accept a transaction while others reject it the state would become inconsistent and potentially mutually exclusive. From one currency, you'd have two and every coin could be spent twice.

by gojomo 13y ago

ssadler 13y ago

They couldn't, because Javascript etc are turing complete, so you can't predict if they're going to end (halting problem). With bitcoin you know that the script will end and that the running time will correlate loosely with the size of the script, so you can't really use it to mess up network nodes. Butcoin scripts have no loops or goto.

gst 13y ago
Actually you could. Just limit the max. number of instructions that are allowed to be executed in order for a script to be valid.
- nullc 13y ago
  Indeed, you can, but then you have a very exact requirement on exactly how the interpreter is implemented which can never be optimized, and any disagreement between implementations can cause a world ending consensus failure. By not having looping or recursion script naturally gets an operation limit by virtue of having a size limit, and this is _relatively_ easy to get right between implementations. (Though, so far several of the alt implementations have gotten it wrong).
topynate 13y ago
You could require all scripting to be done in a language supporting total functional programming, like Epigram. That would be fairly hilarious (also counterproductive, because the increased script size would cause blockchain bloat).
gojomo 13y ago
A guarantee of completion isn't strictly necessary: you can cap the number of ticks/cycles a script is allocated on a deterministic reference machine. Surely there'd be a number of technical and economic challenges to be overcome, but Bitcoin itself is an example of how a good-enough solution may be hiding in plain sight.

pcwalton 13y ago

LLVM would be exceedingly bad due to its undefined behavior. A malicious actor could easily fork the block chain.

ars_technician 13y ago
>LLVM would be exceedingly bad due to its undefined behavior. A malicious actor could easily fork the block chain. There is nothing that indicates undefined behavior of LLVM would lead to a fork in the blockchain.
- tlrobinson 13y ago
  Why not? The rules for validating Bitcoin transactions and blocks must be completely specified and followed exactly by all implementations of the client software, otherwise you risk forks.
- nullc 13y ago
  Bitcoin is a consensus system. It is paramount that all participating nodes reach the exact same state. If undefined behavior could make some nodes accept a transaction while others reject it the state would become inconsistent and potentially mutually exclusive. From one currency, you'd have two and every coin could be spent twice.