1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A6485941
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jun 2016 11:21:27 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149095.authsmtp.com (outmail149095.authsmtp.com
[62.13.149.95])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id C7B2AE0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jun 2016 11:21:26 +0000 (UTC)
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt24.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u5NBLNlp053697;
Thu, 23 Jun 2016 12:21:23 +0100 (BST)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u5NBLL2O019587
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Thu, 23 Jun 2016 12:21:22 +0100 (BST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id B75FB4010C;
Thu, 23 Jun 2016 11:19:16 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id 1C34C20217; Thu, 23 Jun 2016 07:21:16 -0400 (EDT)
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)
X-Server-Quench: 9d860f68-3934-11e6-829e-00151795d556
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAEUEkAaAgsB AmAbWlZeUlx7W2E7 bghPaBtcak9QXgdq
T0pMXVMcUQAWc2B9 BGEeUxB3fwIIcHdy ZQhrCnhdXBJ8fVt+
S01QCGwHMGF9YGIW BV1YdwJRcQRDe0tA b1YxNiYHcQ5VPz4z
GA41ejw8IwAXAjlU Rg0MK11aa0IMFT0n DxcMVSkvEAU+Wywv
IlQDI1UcHUAcemwq KUEmUFkYewMVaEV1 GEdWDSlCOkJp
X-Authentic-SMTP: 61633532353630.1037:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Building Blocks of the State Machine Approach to
Consensus
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jun 2016 11:21:27 -0000
--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--
|
