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

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

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

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: 2442 bytes --]