., , /. , /, ,. / , .. ,,, . // ., . _. ... .. ._. , _ , , , , , ... _ _. ,. . ,., _. ., , .. , ,, ._ . . _ . , , , , /..,, / , . . _ .,. _.. , , .. _ .. ,.,, _ , _ , /// . , / . ,. , ,., . , , ., ,. ._ , ,,,// , , . , , . . , , // . , , / _,. , . ,, . .. /,/ . . . .,,_// ,, ., . . /_. , / . / .._ . ,, / . . _ , , , / , _ ., , ,,, .. , , /.,. /. / . ,/ , . . /, /, ._ ,/. _ ., ,// , .,,, , , , , , ,. ,.,. . , . ,. ., , / _ . / ,.,. , ,._ ,, , _ _ , , . ,, , _ _.., , // , __ / !;"$'''. 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 > 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 wrote: > >> > >> > >> On Dec 10, 2015 7:36 AM, "Luke Durback" 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" > >> > 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 >