[bitcoindev] Flame: confidential transactions with Bitcoin proof-of-burn consensus

[bitcoindev] Flame: confidential transactions with Bitcoin proof-of-burn consensus

[Oleg Andreev]

[-- Attachment #1.1: Type: text/plain, Size: 1893 bytes --]

I've been working on Flame, a Bitcoin "side chain", based on proof-of-burn 
consensus: a fully decentralized protocol in which nodes continuously burn 
bitcoins to protect against 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 network architecture combines proposals by Bitcoin developers and a few 
ideas from other networks, as well as my earlier work, which some of you 
may know from Chain's TxVM (2017) and Interstellar's ZkVM (2019). Flame 
provides transaction confidentiality with a programmable constraint system 
based on Bulletproofs and Ristretto, Taproot-based predicates, Utreexo 
storage for unspent outputs, and actors with leased storage. I've aimed for 
a balanced, practical solution for decentralized applications and privacy, 
with a security model as close to Bitcoin's as possible, while having a 
purely market-driven adoption strategy that does not require changes to 
Bitcoin'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-progress implementation:
https://github.com/runflame/flame-lib

The project is still under development. Mainnet launch is planned for 
January 2027.

Oleg.

-- 
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/7aa8774d-c650-457d-9013-dfb817b728d6n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 2231 bytes --]

[bitcoindev] Re: Flame: confidential transactions with Bitcoin proof-of-burn consensus

[waxwing/ AdamISZ]

[-- Attachment #1.1: Type: text/plain, Size: 5060 bytes --]

 

Hi Oleg,

Interesting work! Personally I like this general class of ideas. If we 
think 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 
proposed 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 thing. 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,  I put together a PoC of what I 
called "hodlchain" [2] which, apart from fancy theorizing about time value 
of money aspects, is basically just 'spacechains but with CLTV/fidelity 
bond style time locks instead of burn'. I liked this version because I saw 
it as an unlock of dormant value: the hodler gets rewarded for the positive 
externality of their behavior without having to change it.


With regard to your minting and supply as per your Section 3: yes I 
wrestled with that a bit in 'hodlchain' too. The reason I didn't like your 
minting 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: fixed minting lets the other side (burn) vary 
according to market's assessed value 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 the minting).


Also, it's unfair of me to compare: you're actually trying to build 
*consensus* from the burns; I wasn't bothering with that. That makes your 
design intuitively seem like it must be the correct one: proof of sacrifice 
of value ~= 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 
Bitcoin'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 
main thing that puts people off, though a counterpoint is, systems can get 
quite some interest if they have a speculative element from mining for 
new/minted 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 new features. And it's not hard to get your bitcoin back when you 
want to via swaps.

Cheers,

AdamISZ/waxwing

[1] https://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 PM UTC-3 Oleg Andreev wrote:

> I've been working on Flame, a Bitcoin "side chain", based on proof-of-burn 
> consensus: a fully decentralized protocol in which nodes continuously burn 
> bitcoins to protect against 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 network architecture combines proposals by Bitcoin developers and a 
> few ideas from other networks, as well as my earlier work, which some of 
> you may know from Chain's TxVM (2017) and Interstellar's ZkVM (2019). Flame 
> provides transaction confidentiality with a programmable constraint system 
> based on Bulletproofs and Ristretto, Taproot-based predicates, Utreexo 
> storage for unspent outputs, and actors with leased storage. I've aimed for 
> a balanced, practical solution for decentralized applications and privacy, 
> with a security model as close to Bitcoin's as possible, while having a 
> purely market-driven adoption strategy that does not require changes to 
> Bitcoin'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-progress implementation:
> https://github.com/runflame/flame-lib
>
> The project is still under development. Mainnet launch is planned for 
> January 2027.
>
> Oleg.
>

-- 
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ccb16c4b-ede1-41dc-acf1-d4c286181e7dn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 6052 bytes --]