Date: Thu, 23 Jun 2016 07:21:16 -0400
From: Peter Todd <pete@petertodd.org>
To: Police Terror <PoliceTerror@dyne.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20160623112116.GA19556@fedora-21-dvm>
References: <20160620085649.GA29964@fedora-21-dvm> <5767EEFE.7060103@dyne.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o"
Content-Disposition: inline
In-Reply-To: <5767EEFE.7060103@dyne.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [bitcoin-dev] Building Blocks of the State Machine Approach to
 Consensus
Precedence: list


--IS0zKkzwUGydFO0o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 20, 2016 at 01:26:22PM +0000, Police Terror via bitcoin-dev wro=
te:
> 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 is=
n'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.
=20
> 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 t=
hat
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 becau=
se
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.
>=20
> 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"

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

--IS0zKkzwUGydFO0o
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJXa8YpAAoJEGOZARBE6K+yVaQH/32hYdD0dDq6A4sWyD1zNRg7
NWa2wZw3c/pLg2GlF/YnuBjEiGcmT19xWXWerdcqjQriul9FGVV3j6FPmcMQ3nyP
nlb74VzZh9V6pT7VPAOQMV/j2wTBdK0/zBTzGP/XKo0opCIt95KUjt+i/qx3EToS
PtEmNZawFf6dfE3P+WY44HLQOx+6BGr/UsXIqOcd8+VpSldXI7Pcntvc6Otip9Q6
Diwv5ddBX+GpEHxcZSaHlY/McSYRMQTpA1eUBx+X4JoM1GLtAh4rmf2+LlozszsT
ji7oZwrg54eRBFuWDGhf6BuvnyWQH6rvdxYlndq3/LPSIaJnju9WvvUIfxUa0gA=
=CS+5
-----END PGP SIGNATURE-----

--IS0zKkzwUGydFO0o--