Delivery-date: Mon, 23 Jun 2025 02:13:24 -0700 Received: from mail-yb1-f185.google.com ([209.85.219.185]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uTdEx-00046o-PY for bitcoindev@gnusha.org; Mon, 23 Jun 2025 02:13:24 -0700 Received: by mail-yb1-f185.google.com with SMTP id 3f1490d57ef6-e7d971b6398sf4314754276.2 for ; Mon, 23 Jun 2025 02:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1750669997; x=1751274797; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=bNCQGtDt2DFHgOZj1vJrpyAnI9ULnndqFRyv88PO3oU=; b=IEG6/epfpTBWzYs2dymXSIcr1Snvo8DP332ZJixrdbpnIMt81b/CI5qWy2VRStThe7 fwn6Eu71xmCC1ymB37HDv9NswNx8aUkscunnHp7TZdVg4na8PGzB6+66QP7Zt/DxjQHm Wv+xftRY+VKNxTFysHDQkd0x9PoHfjG5fMy7hdlNxOoU3CfGd28HeZQzkB88kKg1nWHK +UdvbXB9bIIfFB3Fimqf9wKP8rwFAVYAvodrAkzasiwn8f6MjOzXVR4OGhL3rumbvW2P hA7YRIxX59weS6mHZZankh1Frl4xJHCe2BuZnMEz1r5ZsVjkDySHaj/osqc9989n0fC0 OHPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750669997; x=1751274797; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=bNCQGtDt2DFHgOZj1vJrpyAnI9ULnndqFRyv88PO3oU=; b=L9NPmER7/aHy7o5QQc5VTBCWFMZy5RD/PudeAmoLTWkixHH+NtIAnMkJChJPNuFefn 0FVavmTfYgJpnMP7iRGIbfPXaKdi8i8uCtSuKT2NCNYcJ72/WdZhqskP1TD6yy/Rc0A8 SM2CZA0ozQyNDv1ugzMfS6p8sOAbjS+FSrDHdRDVt9cvU0TEQ0P5A1etRtb4j0RflkcH sg9Gv007B4AAgVE2Eh6ZvdFnH0RLJBQEkZdgmtlBrBV5/650Vp8VCUGEQpnFuFnTpEs9 BaE0e9/Es8sGV+El6GY10rL2Th78OTK1SvMhU73eOyi7QNUln1hPGxPIcnNw1dbyFA2/ jpiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750669997; x=1751274797; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=bNCQGtDt2DFHgOZj1vJrpyAnI9ULnndqFRyv88PO3oU=; b=G5QHZlZiLZwcNHWUKD2kgQnMu5xPItLjA8cIREOyWlDH5zMgJJSVypSp8X3XVpZpMo lVZKtW4GHgUZIOM0/10mvbalMYGt0jpwOpjCoHJ0Z3uCGDKg7YzXxTzgFrXl2tKgxRgS AoAobSvQW6N9ZyE58/UMaz23i4v69FD32jkE23zOr5G8wHULDDzoQZD46JrtmAoE8go8 RziKDlY+DFKX99VVPFS8RZd5OfM2Xg1aP5QQgAGIz8j1ABSERxru+evml6UWLuaP2SGp eQkOROKvwLqMg1u2ZAGdN7PqGNvasa1gU6F/XZ4HSKb4Lr1H3GOKvl5mTERITrf/l7K0 3Z3Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWBT5daX44mK0Ea6RJPyFMyi4gWgdhOW4Es5uVht/G2/qwX9VfftZMn+qsjPLHC5wDcv3eLTjiMZfGP@gnusha.org X-Gm-Message-State: AOJu0YyAb+Lx1f9s9RQYvazbf1zrz0hPcFkqrbSN9LJ+QV1nrmO6Cq8X XH7fnc9XxuaaISb2j+oiF3ESxzdSJOuQfzs2vPc/xCHk1bGdBlDCBMEt X-Google-Smtp-Source: AGHT+IHb0XQc+4yHEokMNiZyD52sczgp8Z6+pUBt53lWwgK6aHTsrQHD1tTN36gGm7BpXKCacFM3aQ== X-Received: by 2002:a05:6902:1203:b0:e81:84ac:cd9 with SMTP id 3f1490d57ef6-e842bc887d8mr14794371276.16.1750669997300; Mon, 23 Jun 2025 02:13:17 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcJIgiTRzwxigZRKwp08biWj5XR0cIV7u/lCM2HN4ReXg== Received: by 2002:a25:6ac3:0:b0:e84:d706:629f with SMTP id 3f1490d57ef6-e84d7066492ls709227276.1.-pod-prod-09-us; Mon, 23 Jun 2025 02:13:13 -0700 (PDT) X-Received: by 2002:a05:690c:6d0b:b0:712:d70b:45d5 with SMTP id 00721157ae682-712d70b47e1mr106267337b3.33.1750669992999; Mon, 23 Jun 2025 02:13:12 -0700 (PDT) Received: by 2002:a81:b548:0:b0:710:fccf:6901 with SMTP id 00721157ae682-712a570c57dms7b3; Sat, 21 Jun 2025 05:07:00 -0700 (PDT) X-Received: by 2002:a05:690c:4b90:b0:712:c55c:4e48 with SMTP id 00721157ae682-712c631235cmr88525977b3.8.1750507619621; Sat, 21 Jun 2025 05:06:59 -0700 (PDT) Date: Sat, 21 Jun 2025 05:06:59 -0700 (PDT) From: fiatjaf To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <035f8b9c-9711-4edb-9d01-bef4a96320e1@roose.io> Subject: Re: [bitcoindev] CTV + CSFS: a letter MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_207940_334775785.1750507619333" X-Original-Sender: fiatjaf@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_207940_334775785.1750507619333 Content-Type: multipart/alternative; boundary="----=_Part_207941_1216264320.1750507619333" ------=_Part_207941_1216264320.1750507619333 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good morning, I'm nobody and I certainly haven't ever contributed to=20 Bitcoin Core, but I still wanted to say, just because no one mentioned=20 these things, that CTV+CSFS would be great to enable the Spacechains and=20 Statechains constructs. On the spacechain front I've worked on two proof-of-concepts in the past,= =20 https://github.com/fiatjaf/simple-ctv-spacechain and=20 https://github.com/nbd-wtf-soma and I know of at least two companies that= =20 showed interest in deploying decentralized spacechains, one was ZEBEDEE who= =20 wanted to sponsor a decentralized and open blockchain for asset transfers= =20 at the time I worked there, the other was Tether who was interested in an= =20 open blockchain dedicated to USDT. Of course these companies never made any= =20 real moves (besides ZEBEDEE sponsoring me for working on Soma after the=20 fact) towards implementing any of these things because it was known at the= =20 time that the soft-forks required at the time (around 2020~2023) were all= =20 perceived to be "many years away". Today I learned that Tether has deployed some kind of shit-chain called=20 "usdt0" that isn't the same thing as a spacechain but has some overlap and= =20 likely wouldn=E2=80=99t exist today if a USDT spacechain had been available= . There=20 is also a very clear argument that if we had some kind of=20 spacechain-for-assets deployed some years ago the entire utxoset-spam that= =20 came from the BRC-20 protocol would have not happened -- and arguably we=20 could have perhaps saved at least some of the development efforts that went= =20 into the less bad alternative asset transfer protocols like Runes, RGB,=20 Tap-ass and whatnot. On the statechain front I have followed the development of Mercury wallet= =20 v1 (at some point I launched the "statecoin torch" -- to not say I didn't= =20 do anything) and later of the Mercury Layer=20 blind-signing-server+client-side-statechain construct, and I still think it= =20 would have been a great protocol for transfer of Bitcoin value in many=20 circumstances, but the fact that these statechains had a fixed lifespan=20 given by nLockTime (a limitation required by the lack of APO or CTV+CSFS)= =20 certainly made it much less interesting. I'm not claiming that if we'd had a covenant-enabling soft-fork available= =20 some years ago we would have spacechains thriving today and adding to the= =20 security budget and awareness of Bitcoin without causing any harm or using= =20 excessive blockspace and that blind statechains would be widely adopted for= =20 payments or inter-institution settlements, I am just telling some small=20 anecdotes of some possibilities that we may have lost. I'm also not saying that this soft-fork, if merged today, will cause people= =20 to work on these things, because probably these ships have already sailed,= =20 I'm merely highlighting that not doing anything has costs in lost=20 opportunities and invisible risks, and that we don't know what ships=20 haven't sailed yet or what we're losing today by postponing things again. --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= a1859d47-59f9-42ea-832a-ae03db33738en%40googlegroups.com. ------=_Part_207941_1216264320.1750507619333 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good morning, I'm nobody and I certainly haven't ever contributed to Bitcoi= n Core, but I still wanted to say, just because no one mentioned these thin= gs, that CTV+CSFS would be great to enable the Spacechains and Statechains = constructs.

On the spacechain front I've worked on two proof-of-= concepts in the past, https://github.com/fiatjaf/simple-ctv-spacechain and = https://github.com/nbd-wtf-soma and I know of at least two companies that s= howed interest in deploying decentralized spacechains, one was ZEBEDEE who = wanted to sponsor a decentralized and open blockchain for asset transfers a= t the time I worked there, the other was Tether who was interested in an op= en blockchain dedicated to USDT. Of course these companies never made any r= eal moves (besides ZEBEDEE sponsoring me for working on Soma after the fact= ) towards implementing any of these things because it was known at the time= that the soft-forks required at the time (around 2020~2023) were all perce= ived to be "many years away".

Today I learned that Tether has de= ployed some kind of shit-chain called "usdt0" that isn't the same thing as = a spacechain but has some overlap and likely wouldn=E2=80=99t exist today i= f a USDT spacechain had been available. There is also a very clear argument= that if we had some kind of spacechain-for-assets deployed some years ago = the entire utxoset-spam that came from the BRC-20 protocol would have not h= appened -- and arguably we could have perhaps saved at least some of the de= velopment efforts that went into the less bad alternative asset transfer pr= otocols like Runes, RGB, Tap-ass and whatnot.

On the statechain = front I have followed the development of Mercury wallet v1 (at some point I= launched the "statecoin torch" -- to not say I didn't do anything) and lat= er of the Mercury Layer blind-signing-server+client-side-statechain constru= ct, and I still think it would have been a great protocol for transfer of B= itcoin value in many circumstances, but the fact that these statechains had= a fixed lifespan given by nLockTime (a limitation required by the lack of = APO or CTV+CSFS) certainly made it much less interesting.

I'm no= t claiming that if we'd had a covenant-enabling soft-fork available some ye= ars ago we would have spacechains thriving today and adding to the security= budget and awareness of Bitcoin without causing any harm or using excessiv= e blockspace and that blind statechains would be widely adopted for payment= s or inter-institution settlements, I am just telling some small anecdotes = of some possibilities that we may have lost.

I'm also not saying= that this soft-fork, if merged today, will cause people to work on these t= hings, because probably these ships have already sailed, I'm merely highlig= hting that not doing anything has costs in lost opportunities and invisible= risks, and that we don't know what ships haven't sailed yet or what we're = losing today by postponing things again.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/a1859d47-59f9-42ea-832a-ae03db33738en%40googlegroups.com.
------=_Part_207941_1216264320.1750507619333-- ------=_Part_207940_334775785.1750507619333--