From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: Flame: confidential transactions with Bitcoin proof-of-burn consensus
Date: Sun, 4 Oct 2026 06:18:18 -0700 (PDT) [thread overview]
Message-ID: <ccb16c4b-ede1-41dc-acf1-d4c286181e7dn@googlegroups.com> (raw)
In-Reply-To: <7aa8774d-c650-457d-9013-dfb817b728d6n@googlegroups.com>
[-- 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 --]
prev parent reply other threads:[~2026-10-04 14:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 22:33 [bitcoindev] Flame: confidential transactions with Bitcoin proof-of-burn consensus Oleg Andreev
2026-10-04 13:18 ` waxwing/ AdamISZ [this message]
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=ccb16c4b-ede1-41dc-acf1-d4c286181e7dn@googlegroups.com \
--to=ekaggata@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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