Date: Mon, 19 Sep 2022 22:43:44 +0000
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <iy7h2Ef6lbbHkutZVhZQZgPo9FPKIsGWJwAiO1CnSdj6ljY884qlURJDP3ifnPHxK169_FY1Vi48-3kvuNO-Ekt6gz4uNQv66BE4mUDuWOY=@protonmail.com>
In-Reply-To: <CAD5xwhgKGMx79+RLpb-hjd3Gc=EKxTVzkpME-=KuM_C5+d7mRQ@mail.gmail.com>
References: <CAD5xwhgKGMx79+RLpb-hjd3Gc=EKxTVzkpME-=KuM_C5+d7mRQ@mail.gmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Spookchains: Drivechain Analog with One-Time
	Trusted Setup & APO
Precedence: list

Good morning Jeremy,

Excellent work!


> # Terminal States / Thresholds
>=20
> 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.
>=20
> There should be some viable state transition at this point.
>=20
> 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 t=
ransition when the counter reaches threshold and mainchain-level rules prev=
ent the miner who does the final increment from "swerving the car" to a dif=
ferent output, whereas use of `OP_TRUE` would not prevent this; the Spookch=
ain 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 r=
eject them (whereas in the Drivechain case, even nodes that do not care abo=
ut the sidechain would reject).

Still, it does come awfully close, and the "ultimate threat" ("nuclear opti=
on") in Drivechains is always that everyone upgrades sidechain rules to mai=
nchain 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 functionar=
ies from the money-keeping functionaries.

Regards,
ZmnSCPxj