From: Anthony Towns <aj@erisian•com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Cc: Casey Rodarmor <casey@rodarmor•com>
Subject: Re: [bitcoin-dev] Purely off-chain coin colouring
Date: Fri, 17 Nov 2023 17:58:34 +1000 [thread overview]
Message-ID: <ZVcdKupXU+wjawRI@erisian.com.au> (raw)
In-Reply-To: <Y941vsOOsZJHdnKT@erisian.com.au>
On Sat, Feb 04, 2023 at 08:38:54PM +1000, Anthony Towns via bitcoin-dev wrote:
> > AJ Towns writes:
> > > I think, however, that you can move inscriptions entirely off-chain. I
> > > wrote a little on this idea on twitter already [1], but after a bit more
> > > thought, I think pushing things even further off-chain would be plausible.
Oh, you could also do inscriptions minimally on-chain. Rather than
posting the inscription on-chain per se, take a hash of the data you
want to inscribe, and then do a sign-to-contract commitment of that
hash.
That reduces your on-chain overhead for creating an inscription to
approximately zero (you're just signing a transaction), so can be much
cheaper, and also can't be blocked or front run by mempool observers. But
obviously means the inscription must be announced off-chain for anyone to
know about it. Of course, that could be seen as a benefit: you can now
have a private inscription, that's still transferable via the regular
ordinals protocol.
OTOH, there's no way to definitvely say "this tx is the Nth inscription
that matches pattern X", as there may be many earlier sign-to-contract
inscriptions that match that pattern that simply haven't been publicly
revealed yet. So that wouldn't be compatible with "inscription numbers"
or "first X inscripts count as minting token Y".
If you go one step further and allow the sign-to-contract to be the
merkle root of many inscriptions, then you've effectively reinvented
timestamping. (You can't outsource inscriptions to a timestamp server,
because you'd fail to own the ordinal that indicates "ownership" of
the inscription, however you could provide timestamping services as a
value-add while creating inscriptions)
Sign-to-contract looks like:
* generate a secret random nonce r0
* calculate the public version R0 = r0*G
* calculate a derived nonce r = r0 + SHA256(R0, data), where "data"
is what you want to commit to
* generate your signature using public nonce R=r*G as usual
To be able to verify sign-to-contract, you reveal R0 and data, and the
verification is just checking that R=R0+SHA256(R0, data)*G. That works
with both ecdsa and schnorr signatures, so doesn't require any advance
preparation.
While it's not widely supported, sign-to-contract is a useful feature
in general for anti-exfil (eg, preventing a malicious hardware wallet
from leaking your secret key when signing txs).
Some references:
https://www.reddit.com/r/Bitcoin/comments/d3lffo/technical_paytocontract_and_signtocontract/
https://github.com/BlockstreamResearch/secp256k1-zkp/blob/d22774e248c703a191049b78f8d04f37d6fcfa05/include/secp256k1_ecdsa_s2c.h
https://github.com/bitcoin-core/secp256k1/pull/1140
https://wally.readthedocs.io/en/release_0.8.9/anti_exfil_protocol/
https://github.com/opentimestamps/python-opentimestamps/pull/14
Cheers,
aj
next prev parent reply other threads:[~2023-11-17 7:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-03 6:39 Casey Rodarmor
2023-02-04 10:38 ` Anthony Towns
2023-02-04 11:36 ` Aymeric Vitte
2023-02-04 13:02 ` alicexbt
2023-02-04 13:06 ` Peter Todd
2023-11-17 7:58 ` Anthony Towns [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-11-20 19:47 vjudeu
2023-02-02 9:15 Anthony Towns
2023-02-02 12:19 ` Aymeric Vitte
2023-02-02 13:46 ` Rijndael
2023-02-02 14:22 ` alicexbt
2023-02-02 14:30 ` Peter Todd
2023-02-02 16:06 ` Aymeric Vitte
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=ZVcdKupXU+wjawRI@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=casey@rodarmor$(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