1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
|
Return-Path: <aj@erisian.com.au>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 803A0C0039
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 17 Nov 2023 07:58:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 55D3F42C8D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 17 Nov 2023 07:58:46 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 55D3F42C8D
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id pW6JSGkazOLl
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 17 Nov 2023 07:58:45 +0000 (UTC)
Received: from cerulean.erisian.com.au (azure.erisian.com.au [172.104.61.193])
by smtp4.osuosl.org (Postfix) with ESMTPS id 1762F42C58
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 17 Nov 2023 07:58:44 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1762F42C58
Received: from aj@azure.erisian.com.au
by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2)
(envelope-from <aj@erisian.com.au>)
id 1r3tkN-0002qB-TD; Fri, 17 Nov 2023 17:58:42 +1000
Received: by email (sSMTP sendmail emulation); Fri, 17 Nov 2023 17:58:34 +1000
Date: Fri, 17 Nov 2023 17:58:34 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZVcdKupXU+wjawRI@erisian.com.au>
References: <CANLPe+Pa-D=JB8N5Qeokoyp=mRA3LLM=mtvvwPkpbHvV_bmEXQ@mail.gmail.com>
<Y941vsOOsZJHdnKT@erisian.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y941vsOOsZJHdnKT@erisian.com.au>
X-Spam_score: -0.0
X-Spam_bar: /
Cc: Casey Rodarmor <casey@rodarmor.com>
Subject: Re: [bitcoin-dev] Purely off-chain coin colouring
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Nov 2023 07:58:46 -0000
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
|
