On Mon, Jun 20, 2016 at 01:26:22PM +0000, Police Terror via bitcoin-dev wrote:
> Bitcoin could embed a lisp interpreter such as Scheme, reverse engineer
> the current protocol into lisp (inside C++), run this alternative engine
> alongside the current one as an option for some years (only for fine
> tuning) then eventually fade this lisp written validation code instead
> of the current one.

You know, I'm kinda regretting not making it sufficiently clear that Dex isn't
Lisp... It may look like it with all the braces, but expressions in it are
evaluated without any global state (they can be evaluated in parallel) and I've
got a lot of work ahead of me in type safety.

> Scheme is small and minimal, and embeds easily in C++. This could be a
> better option than the libconsensus library - validation in a functional
> scripting language.

I'd be surprised if you could find a scheme interpreter that's sufficiently
well defined to be suitable for that; starting with an existing one and
whipping it into shape would very likely be more work than starting from
scratch.
 
> That doesn't mean people can't program the validation code in other
> languages (maybe they'd want to optimize), but this code would be the
> standard.

Yeah, in general I'd expect most of these systems to be layered to a degree;
after all even in something like MAST you need tooling to manage the fact that
the opcodes that end up public, on-chain, are only a subset of the script.

> I wouldn't be so quick to deride good engineering over systematic
> provable systems for all domains. Bitcoin being written in C++ is not a
> defect. It's actually a strong language for what it does. Especially
> when used correctly (which is not often and takes years to master).

It's probably the best of a lot of bad alternatives... We use C++ not because
it's good, but because there's no other option.

In particular, we have enormous cost and risk in moving to other things due to
consensus, so making use of other languages is very difficult; my work with
dex/proofchains does not have that constraint.

> With the seals idea- am I understand this correctly?: Every transaction
> has a number (essentially the index starting from 0 upwards) depending
> on where it is in the blockchain.
> 
> Then there is an array (probably an on disk array mapping transaction
> indexes to hashes). Each hash entry in the array must be unique (the
> hashes) otherwise the transaction will be denied. This is a great idea
> to solve transaction hash collisions and simple to implement.

No, I think you've very much misunderstood things. The abstract notion of a
single-use seal doesn't even need global consensus on anything to implement; it
does not require transactions to have "indexes"

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org