.,
,
/.
, /,
,.
/ ,
..
,,, . // ., .
_. ... .. ._.
, _
,
,
,
, , ... _ _.
,.
. ,., _.
., , ..
,
,,
._
. .
_
.
,
, , , /..,,
/ ,
. .
_
.,. _.. ,
,
.. _
..
,.,, _
, _
,
///
. ,
/ . ,.
,
,.,
. ,
, ., ,. ._ , ,,,//
, ,
.
,
,
. . ,
, // .
, ,
/
_,.
, . ,, .
..
/,/ .
.
. .,,_//
,,
., .
. /_. ,
/
.
/
.._
.
,, / .
. _ ,
, ,
/ , _ .,
, ,,, .. ,
,
/.,.
/. /
. ,/ ,
. . /,
/,
._
,/.
_
.,
,//
, .,,, , , , ,
,
,. ,.,. .
, . ,. ., ,
/ _
.
/
,.,. ,
,._
,,
, _ _ ,
,
. ,, , _
_..,
,
// ,
__ /
!;"$'''. b
__
On Sat, Dec 12, 2015, 3:01 PM Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Fri, Dec 11, 2015 at 10:45 PM, Luke Durback <luke.durb...@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 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 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.
>
> What you call "recursion" seems similar to what we usually call
> "covenants", see
>
> https://bitcointalk.org/index.php?topic=278122.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ón <jti...@jtimon.cc> wrote:
> >>
> >>
> >> On Dec 10, 2015 7:36 AM, "Luke Durback" <luke.durb...@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?
> >
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
