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
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
Return-Path: <chrismoss411@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 04397C0012;
Thu, 9 Dec 2021 09:49:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id E272940146;
Thu, 9 Dec 2021 09:49:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id p80kYGUg43VR; Thu, 9 Dec 2021 09:49:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com
[IPv6:2607:f8b0:4864:20::934])
by smtp2.osuosl.org (Postfix) with ESMTPS id AE8FA40125;
Thu, 9 Dec 2021 09:49:23 +0000 (UTC)
Received: by mail-ua1-x934.google.com with SMTP id y5so9643008ual.7;
Thu, 09 Dec 2021 01:49:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=SzXngsdcFTIakgnZoZif5cvpCui+HhBfz+vKm/WT5eo=;
b=DWgJq9DjcYUGgMV7qzNCmTO0RUqBnWHWLAS5KonEtN5lFQNXg7aCoLMkMwnXVBKyje
ATKn92IGKKN8SH27vWWFBV+DCRMCzmO6NTJmwaRqc8NI/koWvQokW3Qlw4isP2Q5Guob
LaEuYXnzG8tdvE2XkgMrbhknmbP3NeG/biUgSVK3vqdZkLk5A2rVSmxgyS/EQiYHbYzV
jX6x6WxY4itFmCzO26rMWfaYHp8wAhRTykrGnijw973wfLot8B8nT5BJXtcMkBeUyioF
4b5sUqirc4Yo2hYrddwwE/VG1bKq56X/N74JlMAvk4dOo/ZWJaIYaqi34umQ/tta9K63
PiZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=SzXngsdcFTIakgnZoZif5cvpCui+HhBfz+vKm/WT5eo=;
b=hWTG0e+I/yqqZbNlCPPtZkWuGRoQEsuLRxreEQOfu5ikRxnKTQIJrxiW8OpUhPK1cr
q6qn5uav2QMksbG+eJOwxiZdb+zYGXiW3Xe/X2x6SjCTDDFUEfCj/a5JZSazbG5y6AYv
9CBcst7VuOw6gG9m451GVaPylDkkYNbdkkBgWzNzZZA3HT8Rc6d1sC6+ZFh6h4HGbmwl
Pje/E2q3Ufs861vkETpOoLWk18QrexGLuLXqgOyoJ5H9Cca6YDj0zbeJ8eOpg+SlyT9N
S5Oavk8b5kaV4Yxqz1+uLuEqT3u+/YYUagcmS/Nrl1oqEgd5LdrSDrdYLTlkZL2ikOIg
ZRGQ==
X-Gm-Message-State: AOAM530ZLxYEpaK9RWdwojubduemTnQAxSJMNdxzqwT36KxlOveSyi7Q
O+2ou3voaIbYgyzz3DpErbIJy6+GRxafmhM6zNw=
X-Google-Smtp-Source: ABdhPJw8H7EVhC1HajAFw56XQm8zY+x09iFJEewxb44uWOLMs+i4rrreFBZZ/T6K2YrXfbFu7AhwIHI6Unp72jLXOig=
X-Received: by 2002:a05:6102:3029:: with SMTP id
v9mr6108334vsa.46.1639043362506;
Thu, 09 Dec 2021 01:49:22 -0800 (PST)
MIME-Version: 1.0
References: <DD7D5A8B-F61F-4302-ACF4-CE731843D97D@gmail.com>
<CALL-=e5mF9TqbbD=Cf-bawbw4dq2PGjC9W_nqAQeHsB829ZpNg@mail.gmail.com>
<CALkkCJas_pf7Un45CJyFg8j9cBk8PtKN4iYAL81TtLSRNnKqeg@mail.gmail.com>
<CANQKmgLyaYAjL_=LziTCFT=Ahc2SXjJrWc+RO59pxd3mnJApfQ@mail.gmail.com>
<YbHImwix1z8BgAc2@petertodd.org>
In-Reply-To: <YbHImwix1z8BgAc2@petertodd.org>
From: Christian Moss <chrismoss411@gmail.com>
Date: Thu, 9 Dec 2021 09:49:11 +0000
Message-ID: <CANQKmg+D22GrLFDBAawop1uha3GG5F4TmixMajcTPQUdTF4-PQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="00000000000064cb5705d2b3853b"
X-Mailman-Approved-At: Thu, 09 Dec 2021 09:56:14 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
=?UTF-8?Q?H=C3=A9ctor_Jos=C3=A9_C=C3=A1rdenas_Pacheco?=
<hcarpach@gmail.com>, lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin
Lightning
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: Thu, 09 Dec 2021 09:49:26 -0000
--00000000000064cb5705d2b3853b
Content-Type: text/plain; charset="UTF-8"
pete@petertodd.org, so single use seals require an onchain transaction to
post the proof of publication to the ledger (assuming bitcoin is used as
the ledger) when an asset is transferred, but it can scale because you can
batch many proofs (transfer of ownerships) into a merkle tree and just add
the merkle root into the single tx going into the ledger?
On Thu, Dec 9, 2021 at 9:13 AM Peter Todd <pete@petertodd.org> wrote:
> On Mon, Dec 06, 2021 at 04:35:19PM +0000, Christian Moss via bitcoin-dev
> wrote:
> > As far as I understand it, RGB doesn't scale NFTs as each
> > transaction to transfer ownership of an NFT would require an onchain
> > transaction
>
> RGB intends to scale NFTs and similar things in the future via scalable
> single-use-seals:
> https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--00000000000064cb5705d2b3853b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</=
a>, so single use seals require an onchain transaction to post the proof of=
publication to the ledger (assuming bitcoin is used as the ledger) when an=
asset is transferred, but it can scale because you can batch many proofs (=
transfer of ownerships) into a merkle tree and just add the merkle root int=
o the single tx going into the ledger?</div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, Dec 9, 2021 at 9:13 AM Peter =
Todd <<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>> w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, De=
c 06, 2021 at 04:35:19PM +0000, Christian Moss via bitcoin-dev wrote:<br>
> As far as I understand it, RGB doesn't scale NFTs as each<br>
> transaction to transfer ownership of an NFT would require an onchain<b=
r>
> transaction<br>
<br>
RGB intends to scale NFTs and similar things in the future via scalable<br>
single-use-seals: <a href=3D"https://petertodd.org/2017/scalable-single-use=
-seal-asset-transfer" rel=3D"noreferrer" target=3D"_blank">https://petertod=
d.org/2017/scalable-single-use-seal-asset-transfer</a><br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"=
rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</blockquote></div>
--00000000000064cb5705d2b3853b--
|
