<p dir="ltr"><br>
., <br>
,<br>
/. <br>
, /,</p>
<p dir="ltr"> ,.<br>
/ ,<br>
.. <br>
,,, . // ., . </p>
<p dir="ltr"> _. ... .. ._. </p>
<p dir="ltr"> , _<br>
<br></p>
<p dir="ltr"> <br>
, </p>
<p dir="ltr"> <br>
<br>
, <br>
, <br>
, , ... _ _.</p>
<p dir="ltr">,.</p>
<p dir="ltr">. ,., _. <br>
., , .. <br>
, <br>
<br>
,, <br>
<br>
._</p>
<p dir="ltr"> . . </p>
<p dir="ltr">_<br>
. <br>
,<br>
, , , /..,, </p>
<p dir="ltr"> / , </p>
<p dir="ltr">. . <br>
<br>
_<br>
.,. _.. ,<br>
,<br></p>
<p dir="ltr"> .. _ <br>
.. <br>
<br>
,.,, _<br>
, _ <br>
, <br>
/// <br>
. ,<br>
<br>
/ . ,.<br>
,<br>
,.,<br>
. , <br>
, ., ,. ._ , ,,,// <br>
<br>
, , <br>
.</p>
<p dir="ltr">, <br>
<br>
, <br>
. . , </p>
<p dir="ltr">, // . <br>
, ,<br>
/ </p>
<p dir="ltr"> _,. </p>
<p dir="ltr">, . ,, .<br>
</p>
<p dir="ltr">.. <br>
/,/ .<br>
.<br>
</p>
<p dir="ltr"> . .,,_//<br>
,, <br>
., .<br><br></p>
<p dir="ltr">. /_. ,<br>
/ <br>
. <br>
/ <br>
.._<br>
.<br>
,, / .<br>
. _ ,<br>
, , <br>
/ , _ ., <br>
, ,,, .. ,<br>
,<br>
<br>
/.,.<br>
/. / <br>
. ,/ ,<br>
<br>
. . /,<br>
/,<br>
._<br>
,/. <br>
_<br>
., <br>
,// <br>
, .,,, , , , , <br>
,<br></p>
<p dir="ltr"> ,. ,.,. . </p>
<p dir="ltr">, . ,. ., ,<br>
/ _<br>
.<br>
/<br>
,.,. , <br>
,._<br>
<br>
<br>
,, <br>
<br>
, _ _ , <br>
<br>
,<br>
. ,, , _</p>
<p dir="ltr"> <br>
_..,<br><br></p>
<p dir="ltr"> , <br>
// , <br>
__ /<br>
!;"$'''. b<br>
__ </p>
<br><div class="gmail_quote"><div dir="ltr">On Sat, Dec 12, 2015, 3:01 PM Jorge Timón <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Dec 11, 2015 at 10:45 PM, Luke Durback <<a href="mailto:luke.durback@gmail.com" target="_blank">luke.durback@gmail.com</a>> wrote:<br>
>>If it's voting for something consensus, you will need something special. If<br>
>> it's not consensus (ie external) thw voting doesn't have to hit the chain at<br>
>> all.<br>
><br>
> I had in mind voting for something that can't be trusted if done externally:<br>
> Perhaps BIPs for instance. People would somehow "mark" their BTC as being<br>
> "For Proposition X" (as opposed to all other propositions) and the vote<br>
> would be canceled as soon as the BTC is spent again.<br>
><br>
> Unfortunately, I've spent the past 2 days trying to find a design that would<br>
> allow this (I don't think my original suggestion made sense in the context<br>
> of how transactions work), and I haven't gotten much yet.<br>
<br>
Well, as said, if it's for consensus, you will need to adapt the<br>
system in a special way anyway, but I still don't see why turing<br>
completeness is required.<br>
This type of idea is not new. Since miners can censor votes (and<br>
that's undetectable for consensus), several solutions have been<br>
proposed, time lock the votes, for example.<br>
<br>
>>But each scriptSig is only executed once with its corresponding<br>
>> scriptPubKey. Are you proposing we change that?<br>
><br>
> Sorry, I didn't understand Bitcoin's transaction model well enough when I<br>
> first made the proposal. If Turing Pseudo-Completeness is possible with<br>
> Bitcoin, then I understand now that it could not require you to execute a<br>
> script more than once. My current thought is that recursion can be<br>
> accomplished via checking if the next output's scriptPubKey is identical in<br>
> every way to the current scriptPubKey. Unfortunately, a lot more is needed<br>
> than just recursion in order to do on-chain BTC voting the way I have in<br>
> mind. I'll keep working on this.<br>
<br>
What you call "recursion" seems similar to what we usually call "covenants", see<br>
<br>
<a href="https://bitcointalk.org/index.php?topic=278122.0" rel="noreferrer" target="_blank">https://bitcointalk.org/index.php?topic=278122.0</a><br>
<br>
Although the thread says "an amusingly bad idea", I think it's<br>
actually a great idea and there's some use cases that are very hard to<br>
support without covenants.<br>
Again, no Turing completeness required for this.<br>
<br>
> On Fri, Dec 11, 2015 at 10:36 AM, Jorge Timón <jtimon@jtimon.cc> wrote:<br>
>><br>
>><br>
>> On Dec 10, 2015 7:36 AM, "Luke Durback" <<a href="mailto:luke.durback@gmail.com" target="_blank">luke.durback@gmail.com</a>> wrote:<br>
>> ><br>
>> > Tomorrow, I'll work on writing a way to do voting on proposals with BTC<br>
>> > used as voting shares (This will be difficult as I do not know FORTH). That<br>
>> > seems like a fairly simple, useful example that will require loops and<br>
>> > reused functions. I'll add a fee that goes to the creator.<br>
>><br>
>> If it's voting for something consensus, you will need something special.<br>
>> If it's not consensus (ie external) thw voting doesn't have to hit the chain<br>
>> at all.<br>
>> I don't see how "loops and reused functions" are needed in the scripting<br>
>> language for this use case, but I'm probably missing some details. Please,<br>
>> the more concrete you make your example, the easiest it will be for me to<br>
>> understand.<br>
>><br>
>> > IMO, if you write a complicated system of scripts that's used<br>
>> > frequently, it makes sense to charge a fee for its usage.<br>
>><br>
>> But each scriptSig is only executed once with its corresponding<br>
>> scriptPubKey. Are you proposing we change that?<br>
>><br>
>> > A decentralized exchange between colored coins, for instance might take<br>
>> > a small fee on each trade.<br>
>><br>
>> I've been researching the topic of decentralized exchange from before the<br>
>> term "colored coins" was first used (now there's multiple designs and<br>
>> implementations); contributed to and reviewed many designs: none of them<br>
>> (colored coins or not) required turing completeness.<br>
>> I'm sorry, but what you are saying here is too vague for me to concretely<br>
>> be able to refute the low level "needs" you claim your use cases to have.<br>
>><br>
>> > On Dec 10, 2015 10:10 AM, "Luke Durback via bitcoin-dev"<br>
>> > <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
>> > > This, combined with the ability to make new transactions arbitrarily<br>
>> > > would allow a function to pay its creator.<br>
>> ><br>
>> > I don't understand what you mean by "a function" in this context, I<br>
>> > assume you mean a scriptSig, but then "paying its creator" doesn't make much<br>
>> > sense to me .<br>
>> ><br>
>> > Could you provide some high level examples of the use cases you would<br>
>> > like to support with this?<br>
><br>
><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>