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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0CF85C81
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 12 Dec 2015 20:00:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com
[209.85.213.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 672B0141
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 12 Dec 2015 20:00:44 +0000 (UTC)
Received: by vkca188 with SMTP id a188so134955758vkc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 12 Dec 2015 12:00:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type:content-transfer-encoding;
bh=TSeByZkFvUQzYWc8o0DRVI0Zap+HhKuReYHg/KLl/KI=;
b=uha1GPbM0Cwu0OV1XxtDAJwkKAhbHJmMHzfVkNQv1iAI2wa7Zjtov8iXSiPAQ2/bdd
MkrvkdWHL7Mb2sc4yqofFdxKfT11prckEIHZPermCocxQ3FId0jcSxgqEpclA4e2NBjz
OBOv3UKFSx2RCZAsYj2ne34JDMHZqP0+FDVjxZuuDKZ16PDuHIHDSUDgpDcEBPiuqm/T
Ys9nhVY66Jk/1QvMrXfylas98FNiJubdTDZowuxwWf1CVWUW8BssLFMpI8AQc6BbfvsJ
AxjgjnHMvVY1N1XXoRowmg2JZdY1ELGyp1hrtijlyIrQTdQLn64zGzQNn3wAcuO/ugzL
cq5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=TSeByZkFvUQzYWc8o0DRVI0Zap+HhKuReYHg/KLl/KI=;
b=DYiMzCd9U93Il2PWPpUy/RKbN7l04ibxBk0V+fG/UNhuwMzEmzhjS8NU0tqIQ4ujRq
Mia6dY3G4Q+EiZpAvI5gx0OJfW2e05CIC8Ou8vkz1VuwRZ5AvCaWT+4KVFVolpa5s3j0
u6T1Sw25OZ41SEKmDlDcaLR+mSnny/gEheAM0WhidpC+bIfd6Xd6IEyqitmBUo8tf36C
aDgQa4C+WEG9DAWuN8BwLZRrn9C26P4cdPVszOfRPXB4G22aUvCPk+NdqLYh9ODFHv38
tKYAnrXFO/AcaQnuW/UZGJi44h3pR4vtJImy3Jmtes5tb/nNGTBCu9iL9EQQ9V/XwEeh
SG9Q==
X-Gm-Message-State: ALoCoQniwTi9yH7/2YnFDEKIjKohwyEM5h2tnun2cwRgq2Pm4c6NBTWyLxRk/GWL2Q5Shmiv/hVgNmyID96PiFR6ZE0taVgFQQ==
MIME-Version: 1.0
X-Received: by 10.31.154.213 with SMTP id c204mr19196696vke.38.1449950443390;
Sat, 12 Dec 2015 12:00:43 -0800 (PST)
Received: by 10.31.236.70 with HTTP; Sat, 12 Dec 2015 12:00:43 -0800 (PST)
In-Reply-To: <CAEj3M+yFPRA8iGzv-D+bQqchxwhqNEdLLwF_KNHGKqVBHNtTXQ@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>
<CAEj3M+yFPRA8iGzv-D+bQqchxwhqNEdLLwF_KNHGKqVBHNtTXQ@mail.gmail.com>
Date: Sat, 12 Dec 2015 21:00:43 +0100
Message-ID: <CABm2gDp--7Hkecop2h7yZNnJ5D0HnGF6t+uWK_G6-tHkC9q4Fg@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Luke Durback <luke.durback@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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
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: Sat, 12 Dec 2015 20:00:45 -0000
On Fri, Dec 11, 2015 at 10:45 PM, Luke Durback <luke.durback@gmail.com> wro=
te:
>>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 chai=
n at
>> all.
>
> I had in mind voting for something that can't be trusted if done external=
ly:
> Perhaps BIPs for instance. People would somehow "mark" their BTC as bein=
g
> "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 wo=
uld
> allow this (I don't think my original suggestion made sense in the contex=
t
> of how transactions work), and I haven't gotten much yet.
Well, as said, if it's for consensus, you will need to adapt the
system in a special way anyway, but I still don't see why turing
completeness is required.
This type of idea is not new. Since miners can censor votes (and
that's undetectable for consensus), several solutions have been
proposed, time lock the votes, for example.
>>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 need=
ed
> than just recursion in order to do on-chain BTC voting the way I have in
> mind. I'll keep working on this.
What you call "recursion" seems similar to what we usually call "covenants"=
, see
https://bitcointalk.org/index.php?topic=3D278122.0
Although the thread says "an amusingly bad idea", I think it's
actually a great idea and there's some use cases that are very hard to
support without covenants.
Again, no Turing completeness required for this.
> On Fri, Dec 11, 2015 at 10:36 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wro=
te:
>>
>>
>> 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 BT=
C
>> > 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 and
>> > 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 c=
hain
>> 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. Pleas=
e,
>> the more concrete you make your example, the easiest it will be for me t=
o
>> 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 ta=
ke
>> > a small fee on each trade.
>>
>> I've been researching the topic of decentralized exchange from before th=
e
>> 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 concretel=
y
>> 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 mak=
e much
>> > sense to me .
>> >
>> > Could you provide some high level examples of the use cases you would
>> > like to support with this?
>
>
|
