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