MIME-Version: 1.0
References: <CAK=nyAxOa8fsVfxucH7WTTMn25BCzgQ28h_sNsunedpCoRXjjQ@mail.gmail.com>
 <CAMZUoKmR6ZU6mAgEhKDD5cTMuja_OC0_Sz3x4UND=E-g1PkgsQ@mail.gmail.com>
 <CAK=nyAz5+yMUA=XDcunA1eeachSisaJoYE2_yzTLj=B0r4=w5A@mail.gmail.com>
 <iU2J5dWMIgqAf312ZCNmx38_hcYsKrcuqx84kniWeEdb0wP8jPZPvwHK3P-q1yvmQ5OtdMCwMFqPgwmsL7BUfE8PGUlrxW4rOM3slwHun3E=@protonmail.com>
 <CAK=nyAxJ_XYDhTE6pNHqWOQ-cLgqc_f-fbQ+EHTkxyiYOhOPUQ@mail.gmail.com>
 <20210417155008.GA3373@petertodd.org>
In-Reply-To: <20210417155008.GA3373@petertodd.org>
From: Christopher Gilliard <christopher.gilliard@gmail.com>
Date: Sat, 17 Apr 2021 16:57:34 +0000
Message-ID: <CAK=nyAzZ5zXt3e68coXMYBhLri4FcCr=kAAo05oiGPVoGH4Ujg@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="000000000000d6bd6005c02dfede"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF
Precedence: list

--000000000000d6bd6005c02dfede
Content-Type: text/plain; charset="UTF-8"

Peter, thanks for the links. I'm aware that there are other timestamping
aggregation services that already exist, but I had some different ideas
that integrate into some other services. Also thanks for sending the link
to the single use seal asset transfer. I will take a look at that.

On Sat, Apr 17, 2021 at 3:50 PM Peter Todd <pete@petertodd.org> wrote:

> On Sat, Apr 17, 2021 at 03:57:55AM +0000, Christopher Gilliard via
> bitcoin-dev wrote:
> > Thanks ZmnSCPxj. Yes, I agree there are many ways to embed arbitrary data
> > in the blockchain and it's not feasible to block all of them. That is why
> > it's important to, at the same time as limiting the OP_RETURN to one per
> > block, also propose and implement a layer 2 solution for timestamping
> > so people have a clear and simple upgrade path. That is what I will be
> > discussing in one of the BIPs I intend to release early next week.
>
> Note that an aggregated timestamping service already exists:
>
> https://petertodd.org/2016/opentimestamps-announcement
>
> But timestamping is useless for most things people want to do, as it can't
> commit to a unique history. It merely proves something existed in the
> past. For
> uniqueness, you need something like:
>
> https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
>
>
> Anyway, at current fees being what they are there's no compelling reason
> to try
> to prevent people from embedding data in the Bitcoin block chain with
> consensus
> changes. Economics is preventing that just fine.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

--000000000000d6bd6005c02dfede
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Peter, thanks for the links. I&#39;m aware that there are =
other timestamping aggregation services that already exist, but I had some =
different ideas that integrate into some other services. Also thanks for se=
nding the link to the single use seal asset transfer. I will take a look at=
 that.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">On Sat, Apr 17, 2021 at 3:50 PM Peter Todd &lt;<a href=3D"mailto:pete=
@petertodd.org">pete@petertodd.org</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">On Sat, Apr 17, 2021 at 03:57:55AM +0000,=
 Christopher Gilliard via bitcoin-dev wrote:<br>
&gt; Thanks ZmnSCPxj. Yes, I agree there are many ways to embed arbitrary d=
ata<br>
&gt; in the blockchain and it&#39;s not feasible to block all of them. That=
 is why<br>
&gt; it&#39;s important to, at the same time as limiting the OP_RETURN to o=
ne per<br>
&gt; block, also propose and implement a layer 2 solution for timestamping<=
br>
&gt; so people have a clear and simple upgrade path. That is what I will be=
<br>
&gt; discussing in one of the BIPs I intend to release early next week.<br>
<br>
Note that an aggregated timestamping service already exists:<br>
<br>
<a href=3D"https://petertodd.org/2016/opentimestamps-announcement" rel=3D"n=
oreferrer" target=3D"_blank">https://petertodd.org/2016/opentimestamps-anno=
uncement</a><br>
<br>
But timestamping is useless for most things people want to do, as it can=
9;t<br>
commit to a unique history. It merely proves something existed in the past.=
 For<br>
uniqueness, you need something like:<br>
<br>
<a href=3D"https://petertodd.org/2017/scalable-single-use-seal-asset-transf=
er" rel=3D"noreferrer" target=3D"_blank">https://petertodd.org/2017/scalabl=
e-single-use-seal-asset-transfer</a><br>
<br>
<br>
Anyway, at current fees being what they are there&#39;s no compelling reaso=
n to try<br>
to prevent people from embedding data in the Bitcoin block chain with conse=
nsus<br>
changes. Economics is preventing that just fine.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</blockquote></div>

--000000000000d6bd6005c02dfede--