From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Jonathan Voss <k98kurz@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Post-Quantum commit / reveal Fawkescoin variant as a soft fork
Date: Thu, 05 Jun 2025 14:33:53 +0000 [thread overview]
Message-ID: <rS9T4wK6hYkXYD2kPYsaEsFIZbSR5uLGk639NXHaV5s75GjO61P2u4xDwWgNIjvF6g9DLZA4HXOpPWCTMmriWUKM_CnQuP_RxKcSeEW7MGY=@proton.me> (raw)
In-Reply-To: <16f0f405-3f39-498e-9399-a6050773c4c7n@googlegroups.com>
[-- Attachment #1.1: Type: text/plain, Size: 4740 bytes --]
Hi Jonathan,
I feel you're making a bigger deal of this than it needs to be.
We're talking about a way for laggards to rescue money locked in
quantum-vulnerable hashed addresses. I don't think anyone wants
a commit/reveal protocol to become the sole primary method of
transferring BTC.
We're more or less designing a system for a wallet which wakes up
after a years-long coma to find quantum computers are a threat.
This wallet can make a single "commitment transaction" followed
by a single "reveal transaction", and this dance moves all of
the funds in the wallet to a new (yet to be defined)
quantum-resistant script. After that, sending Bitcoin should work
mostly as normal.
Even if you're still hard-line opposed to the idea of
requiring a post-quantum UTXO to recover pre-quantum UTXOs,
it's still completely possible to use commit/reveal protocols
without out-of-band purchase of new BTC: You can simply spend
a very small pre-quantum UTXO to create the commitment. A UTXO
worth only a few thousand sats, for instance. This would be
uneconomical for the quantum attacker to double spend, and
so you'd most likely get your commitment mined safely without
buying new BTC. The only situation in which this is not possible
would be for a party with only very high-value pre-quantum UTXOs,
and no small UTXOs. These parties would need to buy a new (small)
UTXO out-of-band.
regards,
conduition
On Wednesday, June 4th, 2025 at 2:56 AM, Jonathan Voss <k98kurz@gmail•com> wrote:
> If using a monetary network requires out-of-band payments, then that severely limits the actual utility of the monetary network as a medium of exchange. Imagine if the only way to make a bank transfer was to first go in-person to the bank of the recipient of the transfer to give them something that then allowed your bank to make the transfer -- it would be an unworkable monetary system. Similarly, if future Bitcoin transactions require making out-of-band payments, then it has failed as a monetary network with an endogenous unit of account. The whole system has to work without reliance upon exogenous monetary media or mechanisms. As such, the commit-and-reveal scheme fails to maintain the monetary properties of the network as a whole unless we assert reliance upon altruism to get the commitments into the blockchain, which instead breaks the incentive-based game theoretic design. Maybe it would work as a stop-gap solution in the event of the advent of a relevant quantum computer, but it is certainly not a good long-term plan as currently formulated.
> Recall the original premise: "Bitcoin: A Peer-to-Peer Electronic Cash System". If you can't transact with it as cash, i.e. as the ultimate endogenous settlement mechanism, then it is no longer Bitcoin. Requiring an exogenous system fundamentally breaks the model.
>
> -- Jonathan
> On Monday, June 2, 2025 at 9:53:55 AM UTC-4 Peter Todd wrote:
>
> > On Fri, May 30, 2025 at 03:00:41PM -0700, Jonathan Voss wrote:
> > > As far as I can tell, the main flaw in commit/reveal protocols is in the
> > > commit phase: if revealing a commitment with N confirmations is required to
> > > spend bitcoins, then, without spending any bitcoins, how do you get the
> > > commitment into the blockchain in the first place? Maybe I am just
> > > misunderstanding this. If so, then a commit/reveal scheme may be a workable
> > > solution.
> >
> > You can always purchase new BTC to perform the commitment.
> >
> > Indeed, this problem is often seen in alt-coins where fees must be paid in a
> > native asset, while users are trying to send some kind of tokenized asset like
> > a USD token. You can have funds that you can't move because you don't have the
> > correct asset. While annoying, this isn't a fatal problem.
> >
> > --
> > https://petertodd.org 'peter'[:-1]@petertodd.org
>
> --
> 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/16f0f405-3f39-498e-9399-a6050773c4c7n%40googlegroups.com.
--
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/rS9T4wK6hYkXYD2kPYsaEsFIZbSR5uLGk639NXHaV5s75GjO61P2u4xDwWgNIjvF6g9DLZA4HXOpPWCTMmriWUKM_CnQuP_RxKcSeEW7MGY%3D%40proton.me.
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
next prev parent reply other threads:[~2025-06-05 14:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-28 17:14 Tadge Dryja
2025-05-28 18:20 ` Sergio Demian Lerner
2025-05-28 20:24 ` Nagaev Boris
2025-05-30 22:00 ` Jonathan Voss
2025-06-02 11:24 ` Peter Todd
2025-06-02 15:50 ` Q C
2025-06-02 18:54 ` Jonathan Voss
2025-06-05 14:33 ` 'conduition' via Bitcoin Development Mailing List [this message]
2025-06-02 17:38 ` waxwing/ AdamISZ
2025-06-02 19:34 ` 'conduition' via Bitcoin Development Mailing List
2025-06-02 22:50 ` Nagaev Boris
2025-05-31 16:07 ` [bitcoindev] " waxwing/ AdamISZ
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='rS9T4wK6hYkXYD2kPYsaEsFIZbSR5uLGk639NXHaV5s75GjO61P2u4xDwWgNIjvF6g9DLZA4HXOpPWCTMmriWUKM_CnQuP_RxKcSeEW7MGY=@proton.me' \
--to=bitcoindev@googlegroups.com \
--cc=conduition@proton$(echo .)me \
--cc=k98kurz@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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