From: Luke Durback <luke.durback@gmail•com>
To: "Jorge Timón" <jtimon@jtimon•cc>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standard BIP Draft: Turing Pseudo-Completeness
Date: Fri, 11 Dec 2015 16:45:44 -0500 [thread overview]
Message-ID: <CAEj3M+yFPRA8iGzv-D+bQqchxwhqNEdLLwF_KNHGKqVBHNtTXQ@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDr5rKNMerPebJ6b3ayJznEAAvu_zM76syooH-3MepSzXg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3534 bytes --]
>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.
>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 needed
than just recursion in order to do on-chain BTC voting the way I have in
mind. I'll keep working on this.
On Fri, Dec 11, 2015 at 10:36 AM, 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: 4502 bytes --]
next prev parent reply other threads:[~2015-12-11 21:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-10 1:35 Luke Durback
2015-12-10 4:03 ` Jeff Garzik
2015-12-10 4:23 ` Luke Durback
2015-12-10 5:38 ` Jorge Timón
2015-12-10 6:36 ` Luke Durback
2015-12-11 15:36 ` Jorge Timón
2015-12-11 15:38 ` Jorge Timón
2015-12-11 21:45 ` Luke Durback [this message]
2015-12-12 20:00 ` Jorge Timón
2015-12-12 21:01 ` Emin Gün Sirer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEj3M+yFPRA8iGzv-D+bQqchxwhqNEdLLwF_KNHGKqVBHNtTXQ@mail.gmail.com \
--to=luke.durback@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jtimon@jtimon$(echo .)cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox