From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 82FECDE0 for ; Fri, 11 Dec 2015 15:38:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com [209.85.213.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C596D135 for ; Fri, 11 Dec 2015 15:38:38 +0000 (UTC) Received: by vkay187 with SMTP id y187so117792817vka.3 for ; Fri, 11 Dec 2015 07:38:38 -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; bh=6V0jzD5haFETGfSxM48Gp7XmYyJI7UUe/bcEMp05vA0=; b=jeIJYeLFKQF4xB1fM13HwZr24RKtLlIQ/doMgvq0XjxQAL+GOguJF3mPFNeWxu/IJS MfGMgpZo2JBfYlnA4EauBcTRI7roofjSPvQwivCXe0mvrzGzSgsAc9AqGRPUUCdqS2y7 LHjkc3EZKbYQr4JwTQkDfW57aU+xSx0vqswDMtAeFNfZXwKeVBgOBESdjgpE44SDJcU+ +y4/KJ23/tDvOgXIlegFCmtDwrqMPl6ZTYMOwABPjVvMf0A96JC2pumQxwHncBtRYbRI crEufWyB3lXilZTNt+cDx8LswOUQYvG7XumE1YEIN4z63yvLwcJN9EQojhihcdsN1MHR QUHw== 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; bh=6V0jzD5haFETGfSxM48Gp7XmYyJI7UUe/bcEMp05vA0=; b=J6Lyd1+vLveilBBXOabXd+bfZXJR49ew1icAjOiu/oO8RnWwSVL/5QA0xbxAHL5Sr2 kKnuY8xePH1a9g/iy/9gcy6EGDRrPT1zA+42BRLSD5KerIG/3O/P+KBNcVACNx+YfuWH szQ/g6RKtzuTwpVBKXTB6Plk7zcyt/ghVnpZnK11H+1cDd8eH3KcQlWhw9O2UNae4k/t KWSDtedus9jer/WfC1DWAlTVGnHYrIQ3sSTJrRT/02X4IP5oHF4Zrjdxaci0YZTW2Chj SyAnFjYfbzXtGiYeboz2Z/XTkV1rWRvAekAEsSCmdyjRajormKyUORI6l2zzy0isfKWU Wg9A== X-Gm-Message-State: ALoCoQlOQNGKjBYC7FU2N7usZ9zEQUmyFr5YMzAnKlpT/rR12kkaQ4Kkh56Qf3a8Ol/yaAd+fDxRbGPfMzHtYY+8/RoDb/X63Q== MIME-Version: 1.0 X-Received: by 10.31.34.196 with SMTP id i187mr14963389vki.2.1449848318051; Fri, 11 Dec 2015 07:38:38 -0800 (PST) Received: by 10.31.236.70 with HTTP; Fri, 11 Dec 2015 07:38:37 -0800 (PST) Received: by 10.31.236.70 with HTTP; Fri, 11 Dec 2015 07:38:37 -0800 (PST) In-Reply-To: References: Date: Fri, 11 Dec 2015 16:38:37 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Luke Durback Content-Type: multipart/alternative; boundary=001a113daab6f9d97e0526a11d53 X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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: Fri, 11 Dec 2015 15:38:39 -0000 --001a113daab6f9d97e0526a11d53 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable well "only executed once" (every time someone verifies that transaction)... On Dec 11, 2015 4:36 PM, "Jorge Tim=C3=B3n" wrote: > > 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 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? > --001a113daab6f9d97e0526a11d53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

well "only executed once" (every time someone veri= fies that transaction)...

On Dec 11, 2015 4:36 PM, "Jorge Tim=C3=B3n&= quot; <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 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.

If it's voting for something consensus, you will need so= mething special. If it's not consensus (ie external) thw voting doesn&#= 39;t have to hit the chain at all.
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.

> IMO, if you write a complicated system of scripts that&= #39;s used frequently, it makes sense to charge a fee for its usage.

But each scriptSig is only executed once with its correspond= ing scriptPubKey. Are you proposing we change that?

>=C2=A0 A decentralized exchange between colored coins, f= or instance might take a small fee on each trade.

I've been researching the topic of decentralized exchang= e from before the term "colored coins" was first used (now there&= #39;s multiple designs and implementations); contributed to and reviewed ma= ny designs: none of them (colored coins or not) required turing completenes= s.
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.

> On Dec 10, 2015 10:10 AM, "Luke Durback via bitcoi= n-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > This, combined with the ability to make new transactions arbitrar= ily 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&= quot; 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?

--001a113daab6f9d97e0526a11d53--