馃搮 Original date posted:2015-12-12
馃摑 Original message:On Fri, Dec 11, 2015 at 10:45 PM, Luke Durback <luke.durback at 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 at jtimon.cc> wrote:
>>
>>
>> On Dec 10, 2015 7:36 AM, "Luke Durback" <luke.durback at 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 at 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?
>
>
Jorge Tim贸n [ARCHIVE] /
npub1fx鈥l2d8
2023-06-07 17:46:05
in reply to nevent1q鈥ar8
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 17:46:05Event JSON
{
"id": "4c844620fdfa69c7fd93e60aff82551269fb0ea1b91e17b5054a3ea17f56cdca",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686159965,
"kind": 1,
"tags": [
[
"e",
"222d7f1447c79c7bd03d52a3ac1fcb5d7a050853159c3b87005c48d185fcc44f",
"",
"root"
],
[
"e",
"c2841de97a466bf08e4e2114dcfe26d5e826a1b401fb4cf537f615071442afe9",
"",
"reply"
],
[
"p",
"9f11973b1ce067814f4bf55fbd6406a01494abb5c0c6a9d04bc84445f226f677"
]
],
"content": "馃搮 Original date posted:2015-12-12\n馃摑 Original message:On Fri, Dec 11, 2015 at 10:45 PM, Luke Durback \u003cluke.durback at gmail.com\u003e wrote:\n\u003e\u003eIf it's voting for something consensus, you will need something special. If\n\u003e\u003e it's not consensus (ie external) thw voting doesn't have to hit the chain at\n\u003e\u003e all.\n\u003e\n\u003e I had in mind voting for something that can't be trusted if done externally:\n\u003e Perhaps BIPs for instance. People would somehow \"mark\" their BTC as being\n\u003e \"For Proposition X\" (as opposed to all other propositions) and the vote\n\u003e would be canceled as soon as the BTC is spent again.\n\u003e\n\u003e Unfortunately, I've spent the past 2 days trying to find a design that would\n\u003e allow this (I don't think my original suggestion made sense in the context\n\u003e of how transactions work), and I haven't gotten much yet.\n\nWell, as said, if it's for consensus, you will need to adapt the\nsystem in a special way anyway, but I still don't see why turing\ncompleteness is required.\nThis type of idea is not new. Since miners can censor votes (and\nthat's undetectable for consensus), several solutions have been\nproposed, time lock the votes, for example.\n\n\u003e\u003eBut each scriptSig is only executed once with its corresponding\n\u003e\u003e scriptPubKey. Are you proposing we change that?\n\u003e\n\u003e Sorry, I didn't understand Bitcoin's transaction model well enough when I\n\u003e first made the proposal. If Turing Pseudo-Completeness is possible with\n\u003e Bitcoin, then I understand now that it could not require you to execute a\n\u003e script more than once. My current thought is that recursion can be\n\u003e accomplished via checking if the next output's scriptPubKey is identical in\n\u003e every way to the current scriptPubKey. Unfortunately, a lot more is needed\n\u003e than just recursion in order to do on-chain BTC voting the way I have in\n\u003e mind. I'll keep working on this.\n\nWhat you call \"recursion\" seems similar to what we usually call \"covenants\", see\n\nhttps://bitcointalk.org/index.php?topic=278122.0\n\nAlthough the thread says \"an amusingly bad idea\", I think it's\nactually a great idea and there's some use cases that are very hard to\nsupport without covenants.\nAgain, no Turing completeness required for this.\n\n\u003e On Fri, Dec 11, 2015 at 10:36 AM, Jorge Tim贸n \u003cjtimon at jtimon.cc\u003e wrote:\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Dec 10, 2015 7:36 AM, \"Luke Durback\" \u003cluke.durback at gmail.com\u003e wrote:\n\u003e\u003e \u003e\n\u003e\u003e \u003e Tomorrow, I'll work on writing a way to do voting on proposals with BTC\n\u003e\u003e \u003e used as voting shares (This will be difficult as I do not know FORTH). That\n\u003e\u003e \u003e seems like a fairly simple, useful example that will require loops and\n\u003e\u003e \u003e reused functions. I'll add a fee that goes to the creator.\n\u003e\u003e\n\u003e\u003e If it's voting for something consensus, you will need something special.\n\u003e\u003e If it's not consensus (ie external) thw voting doesn't have to hit the chain\n\u003e\u003e at all.\n\u003e\u003e I don't see how \"loops and reused functions\" are needed in the scripting\n\u003e\u003e language for this use case, but I'm probably missing some details. Please,\n\u003e\u003e the more concrete you make your example, the easiest it will be for me to\n\u003e\u003e understand.\n\u003e\u003e\n\u003e\u003e \u003e IMO, if you write a complicated system of scripts that's used\n\u003e\u003e \u003e frequently, it makes sense to charge a fee for its usage.\n\u003e\u003e\n\u003e\u003e But each scriptSig is only executed once with its corresponding\n\u003e\u003e scriptPubKey. Are you proposing we change that?\n\u003e\u003e\n\u003e\u003e \u003e A decentralized exchange between colored coins, for instance might take\n\u003e\u003e \u003e a small fee on each trade.\n\u003e\u003e\n\u003e\u003e I've been researching the topic of decentralized exchange from before the\n\u003e\u003e term \"colored coins\" was first used (now there's multiple designs and\n\u003e\u003e implementations); contributed to and reviewed many designs: none of them\n\u003e\u003e (colored coins or not) required turing completeness.\n\u003e\u003e I'm sorry, but what you are saying here is too vague for me to concretely\n\u003e\u003e be able to refute the low level \"needs\" you claim your use cases to have.\n\u003e\u003e\n\u003e\u003e \u003e On Dec 10, 2015 10:10 AM, \"Luke Durback via bitcoin-dev\"\n\u003e\u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \u003e \u003e This, combined with the ability to make new transactions arbitrarily\n\u003e\u003e \u003e \u003e would allow a function to pay its creator.\n\u003e\u003e \u003e\n\u003e\u003e \u003e I don't understand what you mean by \"a function\" in this context, I\n\u003e\u003e \u003e assume you mean a scriptSig, but then \"paying its creator\" doesn't make much\n\u003e\u003e \u003e sense to me .\n\u003e\u003e \u003e\n\u003e\u003e \u003e Could you provide some high level examples of the use cases you would\n\u003e\u003e \u003e like to support with this?\n\u003e\n\u003e",
"sig": "56ff72410b0a74887d879884c04f97a454839fa05eddaa50cfe03e9edd2b63c4153176951e823700cf5ae211176a0cc549075fc8a26388abca0557f8c37c2d20"
}