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

["Emin Gün Sirer" <el33th4x0r@gmail.com>]

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

.,
,
/.
, /,

,.
   / ,
..
,,,  . // .,      .

_. ...  ..   ._.

,    _


,



,
,
  , , ...     _  _.

,.

.  ,.,    _.
.,    ,  ..
,

,,

._

.  .

_
.
,
,     ,    ,   /..,,

/ ,

.     .

_
.,. _.. ,
,

.. _
   ..

,.,, _
, _
,
///
. ,

   / . ,.
  ,
,.,
. ,
, .,   ,. ._ ,  ,,,//

,        ,
.

,

,
  . . ,

, //  .
,  ,
/

      _,.

, . ,, .

..
  /,/ .
.


  .   .,,_//
,,
.,  .

.  /_. ,
/
.
  /
.._
.
,, / .
   . _ ,
,  ,
/     ,    _ .,
, ,,, ..  ,
  ,

  /.,.
  /. /
. ,/  ,

. .   /,
/,
._
   ,/.
_
.,
,//
, .,,, , ,    , ,
,

,.   ,.,.  .

,  .    ,.  .,   ,
/   _
.
/
  ,.,. ,
,._


,,

, _ _ ,

,
. ,,   ,  _


_..,

  ,
// ,
__ /
!;"$'''. 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.durback@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 <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?
> >
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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