From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Jeremy Rubin <jeremy.l.rubin@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Spookchains: Drivechain Analog with One-Time Trusted Setup & APO
Date: Mon, 19 Sep 2022 22:43:44 +0000 [thread overview]
Message-ID: <iy7h2Ef6lbbHkutZVhZQZgPo9FPKIsGWJwAiO1CnSdj6ljY884qlURJDP3ifnPHxK169_FY1Vi48-3kvuNO-Ekt6gz4uNQv66BE4mUDuWOY=@protonmail.com> (raw)
In-Reply-To: <CAD5xwhgKGMx79+RLpb-hjd3Gc=EKxTVzkpME-=KuM_C5+d7mRQ@mail.gmail.com>
Good morning Jeremy,
Excellent work!
> # Terminal States / Thresholds
>
> When a counter reaches the Nth state, it represents a certain amount
> of accumulated work over a period where progress was agreed on for
> some outcome.
>
> There should be some viable state transition at this point.
>
> One solution would be to have the money at this point sent to an
> `OP_TRUE` output, which the miner incrementing that state is
> responsible for following the rules of the spookchain.
This is not quite Drivechain, as Drivechains precommit to the final state transition when the counter reaches threshold and mainchain-level rules prevent the miner who does the final increment from "swerving the car" to a different output, whereas use of `OP_TRUE` would not prevent this; the Spookchain could vote for one transition, and then the lucky last miner can output a different one, and only other miners interested in the sidechain would reject them (whereas in the Drivechain case, even nodes that do not care about the sidechain would reject).
Still, it does come awfully close, and the "ultimate threat" ("nuclear option") in Drivechains is always that everyone upgrades sidechain rules to mainchain rules, which would still work for Spookchains.
Not sure how comfortable Drivechain proponents would be with this, though.
(But given the demonstrated difficulty in getting consensus changes for the blockchain, I wonder if this nuclear option is even a viable threat)
> Or, it could be
> specified to be some administrator key / federation for convenience,
> with a N block timeout that degrades it to fewer signers (eventually
> 0) if the federation is dead to allow recovery.
Seems similar to the Blockstream separation of the block-signing functionaries from the money-keeping functionaries.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2022-09-19 22:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-14 18:31 Jeremy Rubin
2022-09-19 22:43 ` ZmnSCPxj [this message]
2022-09-30 2:00 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='iy7h2Ef6lbbHkutZVhZQZgPo9FPKIsGWJwAiO1CnSdj6ljY884qlURJDP3ifnPHxK169_FY1Vi48-3kvuNO-Ekt6gz4uNQv66BE4mUDuWOY=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jeremy.l.rubin@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox