Re: [bitcoin-dev] Standard BIP Draft: Turing Pseudo-Completeness

["Jorge Timón" <jtimon@jtimon.cc>]

[-- Attachment #1: Type: text/plain, Size: 2266 bytes --]

well "only executed once" (every time someone verifies that transaction)...
On Dec 11, 2015 4:36 PM, "Jorge Timón" <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 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
> 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 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 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?
>

[-- Attachment #2: Type: text/html, Size: 2830 bytes --]