From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 04 Oct 2026 07:50:51 -0700 Received: from mail-ot1-f55.google.com ([209.85.210.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1xDNYA-0008Tn-BP for bitcoindev@gnusha.org; Sun, 04 Oct 2026 07:50:51 -0700 Received: by mail-ot1-f55.google.com with SMTP id 46e09a7af769-8241d159f80sf576567a34.3 for ; Sun, 04 Oct 2026 07:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1791125442; x=1791730242; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :sender:from:to:cc:subject:date:message-id:reply-to:content-type; bh=cUpzMOccgMrhrmu04EQbdaf6qw0xN+DRpIt0MumxmLg=; b=rfafhEpt51F7vymV/ZzummE2ufDjFJ0du4ZEpFXgh5mD6VNJEhfyL0IpryaN3S/xXB C7NNrHnEhkJwU00TGmM9qwAE1wXekWUoQmHNPPVwDSQlMENxQrMUvtnrv/3lvtnI0JqM K6JzYf1SLMy5f0tCMTk8NnBsVs10mqREHy11o37x2d21aFDx/tm67v2UlFQ5HmxlouWk BKDvKJJDYIn9j1Ml+RY7zjxyISQpUNwg6n/Su7LcL+B/968MnOYxAYraibBOqPBPKkel PCR8hlF0IEATkN+B5SQ9NJ765ZsI3kaNlyFiCJ7ZjQlDp+w7DDS7qTKxLNZTH00upK3R k6Xg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791125442; x=1791730242; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to:content-type; bh=cUpzMOccgMrhrmu04EQbdaf6qw0xN+DRpIt0MumxmLg=; b=eZNcFFNp1gNf49GF9UVR3IpUOQI4kWOSF81G3+BfsPpEkkoCDzG7dFxDEqT+KjJrNE I6kRa7BSpi7ymqc9JKEmtxD5CyooYNLsNzeIym51/ZeChmTEaZESohw7HRRY05TTEHCC mwi80cC/fFW+AqrcEj/WYfQdB6KXPclUgh+KHw5Nc9VRHpF5DO4yuG+LQ9U6JuFUbWy4 dHkgLflrr1jic2XXQvsqOji6lcLeNUB/4UD+vi9gJgc7wuqGz9rNrVDT25ej9tATnKIW jj2fOgZeGJToRbzExq/ZYg27mNAswlYl9mReHX9r7CaK1QP2NTqrSOp0m3x54aC81s/Q 2OgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791125442; x=1791730242; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :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:content-type; bh=cUpzMOccgMrhrmu04EQbdaf6qw0xN+DRpIt0MumxmLg=; b=VVBpdn65jOGOIcEQ3C0h4q+485RzGmMzh8s10FfetSeHJFVwGmRLWfB1K4HGusnXJP tuVYkWLviNMe+Sx8nuI2iH3eohqDLLNdwdheMXHodVJLlPFdEQv5wiGE1nsY8pKhbvUF I40bHJjogOQyKsgR8pZ4/7qSLbR3YhpKEXBVRlog9W4zmzewVvk9RqYNI4bsLwcqZgnJ QY2JJA/k2TA1tOxm0Oy+u8HlUOZ/SQo23HbhMNmQvipHJ53zLwC6x/B8i0W9WUmvPUcv NZ/jt0w1c9O3Zm6cGh4B64tu4uiZKAKSlyCXgcDNhM5JfW5WB3cCOK1hvKDk28VoBd5j zNiQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AKwUvBzRAbBfZ6O/O/1LhiSeXqi2RcWrJLcSS8lsGl+r7zNF5qmjtezBzcwMEYmXipnRjc4CessCuvkPJGK4@gnusha.org X-Gm-Message-State: AFuF++kuTTJNTXd4NbJsWYwpRx23snMFkwfrl1JMFT5KPtqXcwUKLyNM QJZiNb0pZjJf5RW1+clCbkQMsfeGdydd3Cq/n6slTo3t5UJx5aATCOgx X-Received: by 2002:a05:6870:9d18:b0:41c:bea3:236d with SMTP id 586e51a60fabf-49e15905448mr10123027fac.1.1791125442067; Sun, 04 Oct 2026 07:50:42 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdfAW3RS49FHR9SL6K7m5b2m029pV0KozN9y4P0p5QnKug==" Received: by 2002:a05:6870:c458:10b0:49e:1e26:d0ef with SMTP id 586e51a60fabf-49e1e28640als1469129fac.1.-pod-prod-01-us; Sun, 04 Oct 2026 07:50:36 -0700 (PDT) X-Received: by 2002:a05:6808:50a4:b0:4d6:92b3:c1b8 with SMTP id 5614622812f47-4f52afa3401mr7227180b6e.59.1791125435865; Sun, 04 Oct 2026 07:50:35 -0700 (PDT) Received: by 2002:a05:690c:c13:b0:8a6:990a:8ca5 with SMTP id 00721157ae682-8ae4d2110c2ms7b3; Sun, 4 Oct 2026 06:18:19 -0700 (PDT) X-Received: by 2002:a05:690c:348a:b0:8a0:76e8:c738 with SMTP id 00721157ae682-8ae33fe812cmr36944427b3.0.1791119898654; Sun, 04 Oct 2026 06:18:18 -0700 (PDT) Date: Sun, 4 Oct 2026 06:18:18 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <7aa8774d-c650-457d-9013-dfb817b728d6n@googlegroups.com> References: <7aa8774d-c650-457d-9013-dfb817b728d6n@googlegroups.com> Subject: [bitcoindev] Re: Flame: confidential transactions with Bitcoin proof-of-burn consensus MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_39714_1665055253.1791119898374" X-Original-Sender: ekaggata@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_39714_1665055253.1791119898374 Content-Type: multipart/alternative; boundary="----=_Part_39715_1308863639.1791119898374" ------=_Part_39715_1308863639.1791119898374 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 Hi Oleg, Interesting work! Personally I like this general class of ideas. If we=20 think about the simplest form of the idea: to enter the sidechain, you burn= =20 bitcoin, I believe its first proponent is Ruben Somsen with 'spacechains'= =20 [1]. I think you should compare your design with that? At the time he=20 proposed it I was less positive; the obvious question/problem is that=20 without the reverse path the 'coin' can't truly be called bitcoin, it's a= =20 different thing. And I also thought, it's hard to convince people a one way= =20 transfer is worth it (yeah, that's really vague; who knows; it's more just= =20 intuition, less fact). More recently, I put together a PoC of what I=20 called "hodlchain" [2] which, apart from fancy theorizing about time value= =20 of money aspects, is basically just 'spacechains but with CLTV/fidelity=20 bond style time locks instead of burn'. I liked this version because I saw= =20 it as an unlock of dormant value: the hodler gets rewarded for the positive= =20 externality of their behavior without having to change it. With regard to your minting and supply as per your Section 3: yes I=20 wrestled with that a bit in 'hodlchain' too. The reason I didn't like your= =20 minting schedule: fixed per epoch minting --- is that it doesn't feel like= =20 the fairest option for the ordinary user: they're forced into an=20 auction/market that they have to make a judgement about whether they're=20 going to get good value or not. But in holdchain I had another 'TVOM'=20 variable to play with (r) due to using locking. With burn, I guess your=20 choice must be right: fixed minting lets the other side (burn) vary=20 according to market's assessed value of flame; if you had a fixed rate of= =20 flame:btc in minting then if the market doesn't like it, the system doesn't= =20 work (your consensus relies on the minting). Also, it's unfair of me to compare: you're actually trying to build=20 *consensus* from the burns; I wasn't bothering with that. That makes your= =20 design intuitively seem like it must be the correct one: proof of sacrifice= =20 of value ~=3D proof of work. I guess it's 1-layer-down PoW in the sense of,= =20 it has PoW security assuming bitcoin's value and consistency, so, assuming= =20 Bitcoin's PoW security. I won't comment on the detailed design of the flame-sidechain itself. It=20 looks pretty interesting :) I think this 'it's not bitcoin' thing is the=20 main thing that puts people off, though a counterpoint is, systems can get= =20 quite some interest if they have a speculative element from mining for=20 new/minted coins. The problem with that angle is there are lots of other=20 places to put your bitcoin into another system, speculatively, with all=20 kinds of new features. And it's not hard to get your bitcoin back when you= =20 want to via swaps. Cheers, AdamISZ/waxwing [1] https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidecha= ins-the-perpetual-one-way-peg-96cb2f8ac302 [2] https://github.com/AdamISZ/hodlchain On Thursday, October 1, 2026 at 2:07:14=E2=80=AFPM UTC-3 Oleg Andreev wrote= : > I've been working on Flame, a Bitcoin "side chain", based on proof-of-bur= n=20 > consensus: a fully decentralized protocol in which nodes continuously bur= n=20 > bitcoins to protect against double-spending. I believe this approach avoi= ds=20 > shortcomings of proof-of-stake, merged mining, and alternative=20 > proof-of-work protocols. There are no special privileges for developers,= =20 > miners, or validators. > > The network architecture combines proposals by Bitcoin developers and a= =20 > few ideas from other networks, as well as my earlier work, which some of= =20 > you may know from Chain's TxVM (2017) and Interstellar's ZkVM (2019). Fla= me=20 > provides transaction confidentiality with a programmable constraint syste= m=20 > based on Bulletproofs and Ristretto, Taproot-based predicates, Utreexo=20 > storage for unspent outputs, and actors with leased storage. I've aimed f= or=20 > a balanced, practical solution for decentralized applications and privacy= ,=20 > with a security model as close to Bitcoin's as possible, while having a= =20 > purely market-driven adoption strategy that does not require changes to= =20 > Bitcoin's consensus rules. > > I suppose proof-of-burn system on top of Bitcoin creates some interesting= =20 > dynamics for Bitcoin economics: in terms of demand for block space and=20 > long-term relative effects on miners' rewards. > > The overview is available at: > https://runflame.org/flame.pdf > > The work-in-progress implementation: > https://github.com/runflame/flame-lib > > The project is still under development. Mainnet launch is planned for=20 > January 2027. > > Oleg. > --=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/= ccb16c4b-ede1-41dc-acf1-d4c286181e7dn%40googlegroups.com. ------=_Part_39715_1308863639.1791119898374 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Oleg,

Interesting work! Personally I like this general class of ideas. If we t= hink about the simplest form of the idea: to enter the sidechain, you burn = bitcoin, I believe its first proponent is Ruben Somsen with 'spacechains' [= 1]. I think you should compare your design with that? At the time he propos= ed it I was less positive; the obvious question/problem is that without the= reverse path the 'coin' can't truly be called bitcoin, it's a different th= ing. And I also thought, it's hard to convince people a one way transfer is= worth it (yeah, that's really vague; who knows; it's more just intuition, = less fact). More recently,=C2=A0 I put together a PoC of what I called "hod= lchain" [2] which, apart from fancy theorizing about time value of money as= pects, is basically just 'spacechains but with CLTV/fidelity bond style tim= e locks instead of burn'. I liked this version because I saw it as an unloc= k of dormant value: the hodler gets rewarded for the positive externality o= f their behavior without having to change it.


With regard to your minting and supply as per your Section 3: yes I wres= tled with that a bit in 'hodlchain' too. The reason I didn't like your mint= ing schedule: fixed per epoch minting --- is that it doesn't feel like the = fairest option for the ordinary user: they're forced into an auction/market= that they have to make a judgement about whether they're going to get good= value or not. But in holdchain I had another 'TVOM' variable to play with = (r) due to using locking. With burn, I guess your choice must be right: fix= ed minting lets the other side (burn) vary according to market's assessed v= alue of flame; if you had a fixed rate of flame:btc in minting then if the = market doesn't like it, the system doesn't work (your consensus relies on t= he minting).


Also, it's unfair of me to compare: you're actually trying to build *con= sensus* from the burns; I wasn't bothering with that. That makes your desig= n intuitively seem like it must be the correct one: proof of sacrifice of v= alue ~=3D proof of work. I guess it's 1-layer-down PoW in the sense of, it = has PoW security assuming bitcoin's value and consistency, so, assuming Bit= coin's PoW security.


I won't comment on the detailed design of the flame-sidechain itself. It= looks pretty interesting :) I think this 'it's not bitcoin' thing is the m= ain thing that puts people off, though a counterpoint is, systems can get q= uite some interest if they have a speculative element from mining for new/m= inted coins. The problem with that angle is there are lots of other places = to put your bitcoin into another system, speculatively, with all kinds of n= ew features. And it's not hard to get your bitcoin back when you want to vi= a swaps.

Cheers,

AdamISZ/waxwing

[1]=C2=A0https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all= -sidechains-the-perpetual-one-way-peg-96cb2f8ac302

[2] https://github.com/AdamISZ/hodlchain


On Thursday, October 1, 2026 at= 2:07:14=E2=80=AFPM UTC-3 Oleg Andreev wrote:
I've been working on Flame, a Bitcoi= n "side chain", based on proof-of-burn consensus: a fully decentr= alized protocol in which nodes continuously burn bitcoins to protect agains= t double-spending. I believe this approach avoids shortcomings of proof-of-= stake, merged mining, and alternative proof-of-work protocols. There are no= special privileges for developers, miners, or validators.

The netwo= rk architecture combines proposals by Bitcoin developers and a few ideas fr= om other networks, as well as my earlier work, which some of you may know f= rom Chain's TxVM (2017) and Interstellar's ZkVM (2019). Flame provi= des transaction confidentiality with a programmable constraint system based= on Bulletproofs and Ristretto, Taproot-based predicates, Utreexo storage f= or unspent outputs, and actors with leased storage. I've aimed for a ba= lanced, practical solution for decentralized applications and privacy, with= a security model as close to Bitcoin's as possible, while having a pur= ely market-driven adoption strategy that does not require changes to Bitcoi= n's consensus rules.

I suppose proof-of-burn system = on top of Bitcoin creates some interesting dynamics for Bitcoin economics: = in terms of demand for block space and long-term relative effects on miners= ' rewards.

The overview is available at:
https://runflame.org/flame.pdf

The work-in-prog= ress implementation:
https://github.com/runflame/flame-lib

The project is still unde= r development. Mainnet launch is planned for January 2027.

Oleg.
=

--
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/ccb16c4b-ede1-41dc-acf1-d4c286181e7dn%40googlegroups.com.
------=_Part_39715_1308863639.1791119898374-- ------=_Part_39714_1665055253.1791119898374--