Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8BC2ED4B for ; Sat, 12 Dec 2015 21:01:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4664689 for ; Sat, 12 Dec 2015 21:01:57 +0000 (UTC) Received: by qgfb51 with SMTP id b51so19357318qgf.3 for ; Sat, 12 Dec 2015 13:01:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=eZlDLspXH0M8mzSTHGmnqB/kOoSH8FwQO4kO6cew07s=; b=yX9BMsKr+vAaqug205+pfHOtKj1Dh3LeWkzaxTR6n0A5Y+ZthvD4r0IG0XbrufzQhL hYaLV6WbWzBlK2tt/mbhMgi/7j51aqXUoXW28hO+QcdDiJl5O1NvWhRe4cx+l/ljVi7Z nqF+Um3eay4k4aEbTU86mzyNatNAStzoFd7rWNVtpuz7Xtx/Fce/9AWB7NVB/iubWhzY Q8hnl+Hn1wN52KKXzQaD+GVyISYUuluJt7rrlCVsXQpT3IKNKfqKcP9tfcqGEKTlNy79 qogJ1sIn44WXFActCTyDXVhlnnJ7+C/NZzXIK/a5Hlfhj8GM0k1G+HsB92iKP8O0EmO8 Y/bg== X-Received: by 10.140.42.108 with SMTP id b99mr32050529qga.67.1449954116546; Sat, 12 Dec 2015 13:01:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Emin_G=C3=BCn_Sirer?= Date: Sat, 12 Dec 2015 21:01:45 +0000 Message-ID: To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= , Luke Durback Content-Type: multipart/alternative; boundary=001a11c118d80eb9530526b9c050 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 Cc: Bitcoin Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2015 21:01:58 -0000 --001a11c118d80eb9530526b9c050 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ., , /. , /, ,. / , .. ,,, . // ., . _. ... .. ._. , _ , , , , , ... _ _. ,. . ,., _. ., , .. , ,, ._ . . _ . , , , , /..,, / , . . _ .,. _.. , , .. _ .. ,.,, _ , _ , /// . , / . ,. , ,., . , , ., ,. ._ , ,,,// , , . , , . . , , // . , , / _,. , . ,, . .. /,/ . . . .,,_// ,, ., . . /_. , / . / .._ . ,, / . . _ , , , / , _ ., , ,,, .. , , /.,. /. / . ,/ , . . /, /, ._ ,/. _ ., ,// , .,,, , , , , , ,. ,.,. . , . ,. ., , / _ . / ,.,. , ,._ ,, , _ _ , , . ,, , _ _.., , // , __ / !;"$'''. b __ On Sat, Dec 12, 2015, 3:01 PM Jorge Tim=C3=B3n < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Fri, Dec 11, 2015 at 10:45 PM, Luke Durback > wrote: > >>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. > > 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 wit= h > > 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 identica= l > 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 i= n > > 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 w= rote: > >> > >> > >> On Dec 10, 2015 7:36 AM, "Luke Durback" 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 specia= l. > >> 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 scripti= ng > >> 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 > take > >> > 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 th= em > >> (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" > >> > wrote: > >> > > This, combined with the ability to make new transactions arbitrari= ly > >> > > 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 woul= d > >> > like to support with this? > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a11c118d80eb9530526b9c050 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


.,
,
/.
, /,

,.
=C2=A0=C2=A0 / ,
..
,,,=C2=A0 . // .,=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .

_. ...=C2=A0 ..=C2=A0=C2=A0 ._.

,=C2=A0=C2=A0=C2=A0 _


,


=C2=A0
,
,
=C2=A0 , , ...=C2=A0=C2=A0=C2=A0=C2=A0 _=C2=A0 _.

,.

.=C2=A0 ,.,=C2=A0=C2=A0=C2=A0 _.
.,=C2=A0=C2=A0=C2=A0 ,=C2=A0 ..=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
,
=C2=A0=C2=A0
,,
=C2=A0
._

.=C2=A0 .

_
.
,
,=C2=A0=C2=A0=C2=A0=C2=A0 ,=C2=A0=C2=A0=C2=A0 ,=C2=A0=C2=A0 /..,,=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0

/ ,=C2=A0

.=C2=A0=C2=A0=C2=A0=C2=A0 .=C2=A0

_
.,. _.. ,
,

.. _=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0 ..=C2=A0
=C2=A0
,.,, _
, _
,=C2=A0=C2=A0=C2=A0=C2=A0
///
. ,
=C2=A0
=C2=A0=C2=A0 / . ,.
=C2=A0 ,
,.,
. ,=C2=A0
, .,=C2=A0=C2=A0 ,. ._ ,=C2=A0 ,,,//=C2=A0
=C2=A0=C2=A0=C2=A0
,=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ,
.

,

,
=C2=A0 . . ,=C2=A0=C2=A0=C2=A0=C2=A0

, //=C2=A0 .=C2=A0
,=C2=A0 ,
/=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _,.

, . ,, .

..=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0 /,/ .
.
=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0 .=C2=A0=C2=A0 .,,_//
,,
.,=C2=A0 .

.=C2=A0 /_. ,
/
.=C2=A0
=C2=A0 /
.._
.
,, / .
=C2=A0=C2=A0 . _ ,
,=C2=A0 ,=C2=A0
/=C2=A0=C2=A0=C2=A0=C2=A0 ,=C2=A0=C2=A0=C2=A0 _ .,
, ,,, ..=C2=A0 ,
=C2=A0 ,
=C2=A0=C2=A0=C2=A0
=C2=A0 /.,.
=C2=A0 /. /
. ,/=C2=A0 ,

. .=C2=A0=C2=A0 /,
/,
._
=C2=A0=C2=A0 ,/.=C2=A0
_
.,
,//
, .,,, , ,=C2=A0=C2=A0=C2=A0 , ,
,

,.=C2=A0=C2=A0 ,.,.=C2=A0 .

,=C2=A0 .=C2=A0=C2=A0=C2=A0 ,.=C2=A0 .,=C2=A0=C2=A0 ,
/=C2=A0=C2=A0 _
.
/
=C2=A0 ,.,. ,=C2=A0
,._

=C2=A0
,,=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0
, _ _ ,=C2=A0=C2=A0
=C2=A0=C2=A0
,
. ,,=C2=A0=C2=A0 ,=C2=A0 _

=C2=A0
_..,

=C2=A0 ,
// ,
__ /
!;"$'''. b
=C2=A0=C2=A0=C2=A0 __


On Sat, Dec 12, 2015, 3:01 = PM=C2=A0Jorge Tim=C3=B3n <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Fri, Dec 11, 2015 at 10:45 PM, Luke Durback= <luke.durba= ck@gmail.com> wrote:
>>If it's voting for something consensus, you will need something= special. If
>> it's not consensus (ie external) thw voting doesn't have t= o hit the chain at
>> all.
>
> I had in mind voting for something that can't be trusted if done e= xternally:
> Perhaps BIPs for instance.=C2=A0 People would somehow "mark"= their BTC as being
> "For Proposition X" (as opposed to all other propositions) a= nd 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.

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 en= ough when I
> first made the proposal.=C2=A0 If Turing Pseudo-Completeness is possib= le with
> Bitcoin, then I understand now that it could not require you to execut= e a
> script more than once.=C2=A0 My current thought is that recursion can = be
> accomplished via checking if the next output's scriptPubKey is ide= ntical in
> every way to the current scriptPubKey.=C2=A0 Unfortunately, a lot more= is needed
> than just recursion in order to do on-chain BTC voting the way I have = in
> mind.=C2=A0 I'll keep working on this.

What you call "recursion" seems similar to what we usually call &= quot;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<= br> 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.c= c> wrote:
>>
>>
>> On Dec 10, 2015 7:36 AM, "Luke Durback" <luke.durback@gmail.com&= gt; wrote:
>> >
>> > Tomorrow, I'll work on writing a way to do voting on prop= osals with BTC
>> > used as voting shares (This will be difficult as I do not kno= w FORTH).=C2=A0 That
>> > seems like a fairly simple, useful example that will require = loops and
>> > reused functions.=C2=A0 I'll add a fee that goes to the c= reator.
>>
>> If it's voting for something consensus, you will need somethin= g special.
>> If it's not consensus (ie external) thw voting doesn't hav= e to hit the chain
>> at all.
>> I don't see how "loops and reused functions" are nee= ded in the scripting
>> language for this use case, but I'm probably missing some deta= ils. Please,
>> the more concrete you make your example, the easiest it will be fo= r 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?
>>
>> >=C2=A0 A decentralized exchange between colored coins, for ins= tance might take
>> > 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 mul= tiple designs and
>> implementations); contributed to and reviewed many designs: none o= f 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 u= se cases to have.
>>
>> > On Dec 10, 2015 10:10 AM, "Luke Durback via bitcoin-dev&= quot;
>> > <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 creato= r" doesn't make much
>> > sense to me .
>> >
>> > Could you provide some high level examples of the use cases y= ou would
>> > like to support with this?
>
>
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--001a11c118d80eb9530526b9c050--