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
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
|
Return-Path: <luke.durback@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 85E45CFC
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Dec 2015 21:46:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f172.google.com (mail-io0-f172.google.com
[209.85.223.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B7867117
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Dec 2015 21:46:04 +0000 (UTC)
Received: by ioc74 with SMTP id 74so140455858ioc.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Dec 2015 13:46:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=JUI/VEwJnZ1RsjmFBHb5Lzoob5ats1Na6U6BnqZlV0I=;
b=voEOQBCdyURGGCcaq6P6inbqalaVyd+1BZ6cceKl2nCyfrX283DNdp2zolBISHTgle
p4Vsa7eXn+woOyHzaRaSql3XglYJcsagF3AxQiMVz2ouYn9UaRnPJjiMNK+hJDCEBRZp
AXk/Qps5F/bjiVPnFytZzmFI2qm5KLMgz530L7tEteFoYItee6A0APV0/j/F8Boprazr
xyXiRS1n6F/Qs15aZC/8N8IMfhNfF+/7VCmSMO8A9GD8Jxq4Lt7XoSTdnWsJWYuVO/Wa
dYau3dtyIRaXutVu6dM9TM5occFLHSRuWCxIdXWRJXEWWVabHKG2aMc0KeW8FVjzZf9/
T1ZA==
X-Received: by 10.107.148.8 with SMTP id w8mr18513382iod.3.1449870364179; Fri,
11 Dec 2015 13:46:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.12.177 with HTTP; Fri, 11 Dec 2015 13:45:44 -0800 (PST)
In-Reply-To: <CABm2gDr5rKNMerPebJ6b3ayJznEAAvu_zM76syooH-3MepSzXg@mail.gmail.com>
References: <CAEj3M+wYicoACcpG5YUU6vF8vg98XCcJWmgBiyrJj-xHHxrhig@mail.gmail.com>
<CABm2gDq3K2uUWx_itZQJH53EFOJKAWOLiy3NdHWGPvUOCm33wA@mail.gmail.com>
<CAEj3M+ze9HU1KWoWT2nugw9hYY97jk_xsL8WUWqThq_wrXSAVg@mail.gmail.com>
<CABm2gDr5rKNMerPebJ6b3ayJznEAAvu_zM76syooH-3MepSzXg@mail.gmail.com>
From: Luke Durback <luke.durback@gmail.com>
Date: Fri, 11 Dec 2015 16:45:44 -0500
Message-ID: <CAEj3M+yFPRA8iGzv-D+bQqchxwhqNEdLLwF_KNHGKqVBHNtTXQ@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=001a113fe51e0702e60526a640f2
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_LOW, URIBL_BLACK autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 11 Dec 2015 21:46:35 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standard BIP Draft: Turing Pseudo-Completeness
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Fri, 11 Dec 2015 21:46:05 -0000
--001a113fe51e0702e60526a640f2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
>If it's voting for something consensus, you will need something special.
If it's not consensus (ie external) thw voting doesn't have to hit the
chain at all.
I had in mind voting for something that can't be trusted if done
externally: Perhaps BIPs for instance. People would somehow "mark" their
BTC as being "For Proposition X" (as opposed to all other propositions) and
the vote would be canceled as soon as the BTC is spent again.
Unfortunately, I've spent the past 2 days trying to find a design that
would allow this (I don't think my original suggestion made sense in the
context of how transactions work), and I haven't gotten much yet.
>But each scriptSig is only executed once with its corresponding
scriptPubKey. Are you proposing we change that?
Sorry, I didn't understand Bitcoin's transaction model well enough when I
first made the proposal. If Turing Pseudo-Completeness is possible with
Bitcoin, then I understand now that it could not require you to execute a
script more than once. My current thought is that recursion can be
accomplished via checking if the next output's scriptPubKey is identical in
every way to the current scriptPubKey. Unfortunately, a lot more is needed
than just recursion in order to do on-chain BTC voting the way I have in
mind. I'll keep working on this.
On Fri, Dec 11, 2015 at 10:36 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote=
:
>
> On Dec 10, 2015 7:36 AM, "Luke Durback" <luke.durback@gmail.com> wrote:
> >
> > Tomorrow, I'll work on writing a way to do voting on proposals with BTC
> used as voting shares (This will be difficult as I do not know FORTH).
> That seems like a fairly simple, useful example that will require loops a=
nd
> reused functions. I'll add a fee that goes to the creator.
>
> If it's voting for something consensus, you will need something special.
> If it's not consensus (ie external) thw voting doesn't have to hit the
> chain at all.
> I don't see how "loops and reused functions" are needed in the scripting
> language for this use case, but I'm probably missing some details. Please=
,
> the more concrete you make your example, the easiest it will be for me to
> understand.
>
> > IMO, if you write a complicated system of scripts that's used
> frequently, it makes sense to charge a fee for its usage.
>
> But each scriptSig is only executed once with its corresponding
> scriptPubKey. Are you proposing we change that?
>
> > A decentralized exchange between colored coins, for instance might tak=
e
> a small fee on each trade.
>
> I've been researching the topic of decentralized exchange from before the
> term "colored coins" was first used (now there's multiple designs and
> implementations); contributed to and reviewed many designs: none of them
> (colored coins or not) required turing completeness.
> I'm sorry, but what you are saying here is too vague for me to concretely
> be able to refute the low level "needs" you claim your use cases to have.
>
> > On Dec 10, 2015 10:10 AM, "Luke Durback via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > This, combined with the ability to make new transactions arbitrarily
> would allow a function to pay its creator.
> >
> > I don't understand what you mean by "a function" in this context, I
> assume you mean a scriptSig, but then "paying its creator" doesn't make
> much sense to me .
> >
> > Could you provide some high level examples of the use cases you would
> like to support with this?
>
--001a113fe51e0702e60526a640f2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-size:12.8px">>If it's voting fo=
r something consensus, you will need something special. If it's not con=
sensus (ie external) thw voting doesn't have to hit the chain at all.</=
span><br><br>I had in mind voting for something that can't be trusted i=
f done externally: =C2=A0Perhaps BIPs for instance.=C2=A0 People would some=
how "mark" their BTC as being "For Proposition X" (as o=
pposed to all other propositions) and the vote would be canceled as soon as=
the BTC is spent again.<div><br></div><div>Unfortunately, I've spent t=
he past 2 days trying to find a design that would allow this (I don't t=
hink my original suggestion made sense in the context of how transactions w=
ork), and I haven't gotten much yet.<br><br>><span style=3D"font-siz=
e:12.8px">But each scriptSig is only executed once with its corresponding s=
criptPubKey. Are you proposing we change that?<br><br>Sorry, I didn't u=
nderstand Bitcoin's transaction model well enough when I first made the=
proposal.=C2=A0 If Turing Pseudo-Completeness is possible with Bitcoin, th=
en I understand now that it could not require you to execute a script more =
than once.=C2=A0 My current thought is that recursion can be accomplished v=
ia checking if the next output's scriptPubKey is identical in every way=
to the current scriptPubKey.=C2=A0 Unfortunately, a lot more is needed tha=
n just recursion in order to do on-chain BTC voting the way I have in mind.=
=C2=A0 I'll keep working on this.</span><span style=3D"font-size:12.8px=
"><br></span></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On Fri, Dec 11, 2015 at 10:36 AM, Jorge Tim=C3=B3n <span dir=3D"ltr=
"><<a href=3D"mailto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.c=
c</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">=
<p dir=3D"ltr"><br>
On Dec 10, 2015 7:36 AM, "Luke Durback" <<a href=3D"mailto:luk=
e.durback@gmail.com" target=3D"_blank">luke.durback@gmail.com</a>> wrote=
:<br>
><br>
> Tomorrow, I'll work on writing a way to do voting on proposals wit=
h BTC used as voting shares (This will be difficult as I do not know FORTH)=
.=C2=A0 That seems like a fairly simple, useful example that will require l=
oops and reused functions.=C2=A0 I'll add a fee that goes to the creato=
r.</p>
</span><p dir=3D"ltr">If it's voting for something consensus, you will =
need something special. If it's not consensus (ie external) thw voting =
doesn't have to hit the chain at all.<br>
I don't see how "loops and reused functions" are needed in th=
e scripting language for this use case, but I'm probably missing some d=
etails. Please, the more concrete you make your example, the easiest it wil=
l be for me to understand.</p><span class=3D"">
<p dir=3D"ltr">> IMO, if you write a complicated system of scripts that&=
#39;s used frequently, it makes sense to charge a fee for its usage.</p>
</span><p dir=3D"ltr">But each scriptSig is only executed once with its cor=
responding scriptPubKey. Are you proposing we change that?</p><span class=
=3D"">
<p dir=3D"ltr">>=C2=A0 A decentralized exchange between colored coins, f=
or instance might take a small fee on each trade.</p>
</span><p dir=3D"ltr">I've been researching the topic of decentralized =
exchange from before the term "colored coins" was first used (now=
there's multiple designs and implementations); contributed to and revi=
ewed many designs: none of them (colored coins or not) required turing comp=
leteness.<br>
I'm sorry, but what you are saying here is too vague for me to concrete=
ly be able to refute the low level "needs" you claim your use cas=
es to have.<br></p><div class=3D"HOEnZb"><div class=3D"h5">
<p dir=3D"ltr">> On Dec 10, 2015 10:10 AM, "Luke Durback via bitcoi=
n-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> > This, combined with the ability to make new transactions arbitrar=
ily would allow a function to pay its creator.<br>
><br>
> I don't understand what you mean by "a function" in this=
context, I assume you mean a scriptSig, but then "paying its creator&=
quot; doesn't make much sense to me .<br>
><br>
> Could you provide some high level examples of the use cases you would =
like to support with this?</p>
</div></div></blockquote></div><br></div>
--001a113fe51e0702e60526a640f2--
|
