From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 243F7C000B for ; Tue, 20 Apr 2021 08:45:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 129A96063F for ; Tue, 20 Apr 2021 08:45:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7PV23Q9FNUL for ; Tue, 20 Apr 2021 08:45:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) by smtp3.osuosl.org (Postfix) with ESMTPS id D9ED760663 for ; Tue, 20 Apr 2021 08:45:43 +0000 (UTC) Received: by mail-qv1-xf36.google.com with SMTP id l2so311087qvb.7 for ; Tue, 20 Apr 2021 01:45:43 -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=+6tTORajqh/CDpYEahe6Ln45spOxe0t2hKq4TrYGT/0=; b=YifbGJoWX9ZyaCBSkpl5/wdNsWG9ECNnI5IMCJ7nMNA0cgEYRv3m9R3HgWQiCzBF5M ArcYAuQiyy6JKYG4pFHK+BP1Ac+2phHU0rO0ze4JANckCzyobc+ZveRRecc1kpxhiKu2 LBee0j8jjki8puzMYXiSVkwvyU3k1OVRffKLbtO2oOxvFZbp7yWpcEA+GEB1QqL1EIfz 5ySBZmjwOjEvGbsp1c422s8wISlmiQsKqY5cIJGcf++cBANKlC4e2ABsceBkzCGxozg0 8PELIRTrjxQUlfIdC8ao4rnLsE5a9gmYd+mcK7XYB6Aa0vB6n80VfEVprf6wC+TIuDGU Hgaw== 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=+6tTORajqh/CDpYEahe6Ln45spOxe0t2hKq4TrYGT/0=; b=SGL8msO2bKgpDMNDHkWYVevRxnCORHpKkfs00iM75iYGeCx6LjLIeul8/x/lcA1JfC yglhtKJCb9aIKabqWA7btrE6MCaGupl6tpCu+tgLSfugRKeoipT6Bu/UDZpQXhhX6m6V ksrlHuN4b4gXQsUffLGeXsV6WCg8q354aT0vXzb6t4XlpImcLQKvRaQSPdPFjKw67AWY +J/w/5owOwI/Us1+IJyiZ3f60gufmXuCjGw6W2UuDPXZY5iaeAhFwtN9Yguzau+mAPrX F08J0A3PXjJBntlDMgauhroSHAC3yBglsH37XW84KPEauf/Lz5rhkToNjSdIlV9uOMnJ Wasg== X-Gm-Message-State: AOAM532SGioiE2PVL/KpQ2tNY8fSZwpPaqkNV4rkPMgfNa1gt/XjN6tb rLTa//LCd4L0oSA3gXSeQuCxEGmEBXdOxuDyBsk= X-Google-Smtp-Source: ABdhPJwwQby1Pfhze5zoyzrFINvrvoDWZvQHbVPSJ4nvbNCd1kzrhe12K8esj9/vfZVfRsVH0/UXTcp3nG5rOKZtK14= X-Received: by 2002:a0c:e2c5:: with SMTP id t5mr25549380qvl.27.1618908342623; Tue, 20 Apr 2021 01:45:42 -0700 (PDT) MIME-Version: 1.0 References: <050674b8bc51cff11e0a6e105880b647@cock.li> In-Reply-To: <050674b8bc51cff11e0a6e105880b647@cock.li> From: Zach Greenwood Date: Tue, 20 Apr 2021 10:45:31 +0200 Message-ID: To: yanmaani@cock.li, Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000afa21005c0637864" X-Mailman-Approved-At: Tue, 20 Apr 2021 09:58:09 +0000 Cc: christopher.gilliard@gmail.com 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: Tue, 20 Apr 2021 08:45:48 -0000 --000000000000afa21005c0637864 Content-Type: text/plain; charset="UTF-8" [Note: this is my first post to the list] Businesses storing data on-chain is undesirable but sadly unavoidable. Therefore one might as well *facilitate* data storage beyond just OP_RETURN by offering a more efficient way to store data on-chain, while still being almost as expensive in use per byte of payload (i.e., data) compared to using OP_RETURN. Storing data using OP_RETURN is still inefficient per byte of payload so a more efficient dedicated data storing facility might be created that stores more payload data per on-chain byte. Such a facility should be (marginally) cheaper to use per payload byte compared to using a hack such as OP_RETURN. This would encourage the use of this facility in favor of OP_RETURN or other hacks, while at the same time dramatically reducing the footprint of storing data on-chain. Zac On Tue, Apr 20, 2021 at 4:29 AM yanmaani--- via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > If only one hash is allowed per block, then those who wish to utilize > > the hash will have to out-bid each other ("fee-bidding"). This hash can > > then be used to create another chain ("merged-mining") > > Merged mining at present only needs one hash for a merkle root, and > that's stored in the coinbase. It would be even simpler to add the > following rules: > > 1) No OP_RETURN transactions allowed at all > 2) If you want to commit data, do so in that one transaction in the > coinbase > > Also curious about how you'd handle the payment - do I need to put in a > transaction that burns bitcoins for the tx fee? That isn't free in terms > of storage either. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000afa21005c0637864 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[Note: this is my first post to the list]

Businesses storing data on-chain is undesirable but sadly unavoidable. T= herefore one might as well *facilitate* data storage beyond just OP_RETURN = by offering a more efficient way to store data on-chain, while still being = almost as expensive in use per byte of payload (i.e., data) compared to usi= ng OP_RETURN.

Storing data using OP_RETURN is stil= l inefficient per byte of payload so a more efficient dedicated data storin= g facility might be created that stores more payload data per on-chain byte= . Such a facility should be (marginally) cheaper to use per payload byte co= mpared to using a hack such as OP_RETURN. This would encourage the use of t= his facility in favor of OP_RETURN or other hacks, while at the same time d= ramatically reducing the footprint of storing data on-chain.

=
Zac

On Tue, Apr 20, 2021 at 4:29 AM yanmaani--- via bitcoin= -dev <bitcoin-d= ev@lists.linuxfoundation.org> wrote:
> If only one hash is allowed per block, the= n those who wish to utilize
> the hash will have to out-bid each other ("fee-bidding"). Th= is hash can
> then be used to create another chain ("merged-mining")

Merged mining at present only needs one hash for a merkle root, and
that's stored in the coinbase. It would be even simpler to add the
following rules:

1) No OP_RETURN transactions allowed at all
2) If you want to commit data, do so in that one transaction in the
coinbase

Also curious about how you'd handle the payment - do I need to put in a=
transaction that burns bitcoins for the tx fee? That isn't free in term= s
of storage either.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000afa21005c0637864--