From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0ADA4C0019 for ; Sat, 17 Apr 2021 16:57:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id E86A283CB3 for ; Sat, 17 Apr 2021 16:57:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fahp4xiInf9z for ; Sat, 17 Apr 2021 16:57:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) by smtp1.osuosl.org (Postfix) with ESMTPS id 137B683827 for ; Sat, 17 Apr 2021 16:57:45 +0000 (UTC) Received: by mail-oi1-x22b.google.com with SMTP id e66so15892747oif.11 for ; Sat, 17 Apr 2021 09:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AboiUqFqt+B/HoyDKC6JMFPUxdV1/ErVKPYAoqqW5+c=; b=e5OFaNnb2h99qz8oZD3EBjmD3BtpQToJ3HR69zAIHyXnbGefalmrDzd2cxDs42VHsi eqURl2Y+sFZYLN1qzLH82mTQPZNnGYs8eXapNe0xh+huyLL6bDZ60piJ5eurkTOQfiFA pGOxydJ+CWoDGIKzn5IX2VIoxIVveS81YLv3SWUsw3BvLF1/eALto153bC9LdzctRrm0 Lg6/0DBNkkXN9EQAOVujQDn8kfBPVgZ6LHhsZscK7IUa1dL/XsoUufu//qOWAXehwLVk b7fCdAYqn4vV2+3feCYqHm7VDR9GJ4UC3UNA17+x8k6Iv2kgLi2iZEqoaoNrqf2XGyQ9 b+NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AboiUqFqt+B/HoyDKC6JMFPUxdV1/ErVKPYAoqqW5+c=; b=s9L1/BZ2XQx2go2TZVQsy+E4pJarS0zT24Uv+6N2Mq1zYCIQNjaorZRvXGOt8wkYli GjhXFivcHIoQ1XX6RTkaOdsibzTH0a2IqfnnJL09TGic676Sw7nMD1ywc7WojxJR/dQd iKuN5Xd+cPkkVDezEzdAUdObFY+nrU/TBWKNg2iKCOLu0rjZgd8r9PMyclgNRidz0Yfi zvOxhFTNoG1DrhmN57g+3vFrrO93J7vxKDk4u2g2BEBb+8vDBJDc0k+/kkekF8jZMtT/ AFM4Di9w3jR9kHgq/x18M7nepQ10ZKsMxTyngKXi9RSFNeKGSf1EJBGKVGkdEpKNnZml vghA== X-Gm-Message-State: AOAM533fNManZax33h7AUzuB344cm3O7TD2ae8o73DBzRZuGSGxhQHkP hh93XiVvZ0FsmVfFa9QJVVeWuaHtQ51lOVbfeN8= X-Google-Smtp-Source: ABdhPJw4+ZORkzx1RJro2QMKgyZ4B3906ZGmdh5FHxiQDnF/qBngw0Fg0W5DhLoK6P7jIiAFmzc38EkdBvdJ1NikOQU= X-Received: by 2002:aca:5e55:: with SMTP id s82mr10528323oib.9.1618678665099; Sat, 17 Apr 2021 09:57:45 -0700 (PDT) MIME-Version: 1.0 References: <20210417155008.GA3373@petertodd.org> In-Reply-To: <20210417155008.GA3373@petertodd.org> From: Christopher Gilliard Date: Sat, 17 Apr 2021 16:57:34 +0000 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary="000000000000d6bd6005c02dfede" X-Mailman-Approved-At: Sat, 17 Apr 2021 18:16:26 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Apr 2021 16:57:49 -0000 --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 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
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 se= nding 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 d= ata
> 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 o= ne per
> block, also propose and implement a layer 2 solution for timestamping<= br> > 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-anno= uncement

But timestamping is useless for most things people want to do, as it can= 9;t
commit to a unique history. It merely proves something existed in the past.= For
uniqueness, you need something like:

https://petertodd.org/2017/scalabl= e-single-use-seal-asset-transfer


Anyway, at current fees being what they are there's no compelling reaso= n to try
to prevent people from embedding data in the Bitcoin block chain with conse= nsus
changes. Economics is preventing that just fine.

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org
--000000000000d6bd6005c02dfede--