From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3BD20C000B for ; Tue, 20 Apr 2021 19:07:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 2F67340475 for ; Tue, 20 Apr 2021 19:07:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 IITYIPVfIT5C for ; Tue, 20 Apr 2021 19:07:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) by smtp2.osuosl.org (Postfix) with ESMTPS id 82CD3402A4 for ; Tue, 20 Apr 2021 19:07:14 +0000 (UTC) Received: by mail-ed1-x529.google.com with SMTP id cq11so2767329edb.0 for ; Tue, 20 Apr 2021 12:07:14 -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=c4s2A6VEpdSxYreOprBBY64VflqVxNmbXqYEAwHLCZY=; b=YqhMDugi8n78aZVNV2+7o1TwNZ2PUOuFhZbGoCPswuf9qnV5E69pbMt8UnxiqcAgzb oCRXJLGCVT8ka7aWwCNA07i8sxW/P77eQdB0RlHqraLTfHaY7Qfry+shoyo3d4LvnIqZ xy96epLa3p1NZ149E6CIg3tPymxH8acRYTtnonEVoD7mtoc0VWEyDUBfbuEozqNF6Haa 032ewhop/dQB6o4fU/6GM/JwR/mE/iYkMUUVOigqs9JgxpYq8mt5esl+27ihB+rvjjAv W6XEf/WJduLCfSJk63Xf2KCTC/gprEELlEL4tHiNzLZHxsrZvkrZAgKbBOrQV7ejdlSv pBbg== 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=c4s2A6VEpdSxYreOprBBY64VflqVxNmbXqYEAwHLCZY=; b=te351sHXX7PQgOOeSgL7W2cVeylB7bVOZIYA0CX7rgPzXRvm4vkAUdPPhetnsKYWD2 GLVhzSJTmlgw5k+Z6iDo6nK46n3kL6DKu4gtFeygZnRTdue+PHLyT0gu5ObR0auUbnPk IRIwQtMaOAEsRkNZDNeFu/OHxkLh/xpVsBXb0uXuemciscF1rnqcxoVrsjGoUGwd0UB5 8fgfxS5ymEMju6IRlDwYcPz6ZUMio6NXh9hFGKyYVTnsQxbBCVvZKh1JJO4vRlt++Kok nd9sjiGDAUX9ZZB4XJIL3j4jAVM8QI9XiA1IUMdGEZvqRvji7ndNhjLEEpOGKWoKaSLm /Qxw== X-Gm-Message-State: AOAM530wSXKbfVTX0IodOBrVbQsBMfTvPkZ65RvecVybSrcMImaQAtbL x/DieDMZdo8O/2wBDUK28dJh7qwYkjYojlg3qQk= X-Google-Smtp-Source: ABdhPJxoOKSEaqEGJaDMrggjntQG3WXCu9jE7aKywNVyNQ4ye1ge5uWsj9dFn0UMGiufB6oZU4pc0XQY9cS7gw/gVcM= X-Received: by 2002:a05:6402:706:: with SMTP id w6mr26968028edx.15.1618945632860; Tue, 20 Apr 2021 12:07:12 -0700 (PDT) MIME-Version: 1.0 References: <050674b8bc51cff11e0a6e105880b647@cock.li> In-Reply-To: <050674b8bc51cff11e0a6e105880b647@cock.li> From: Ruben Somsen Date: Tue, 20 Apr 2021 21:07:00 +0200 Message-ID: To: yanmaani@cock.li Content-Type: multipart/alternative; boundary="0000000000005b7ed105c06c278f" X-Mailman-Approved-At: Tue, 20 Apr 2021 19:08:11 +0000 Cc: Bitcoin Protocol Discussion , 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 19:07:19 -0000 --0000000000005b7ed105c06c278f Content-Type: text/plain; charset="UTF-8" Hi Yanmaani, >Merged mining at present only needs one hash for a merkle root, and that's stored in the coinbase. Yes, but that method is not "blind", meaning BTC miners have to validate the merged-mined chain, which is a significant downside. >It would be even simpler to add the following rules That would require a specific soft fork, whereas the method described in my post avoids doing that. >do I need to put in a transaction that burns bitcoins for the tx fee The blind merged-mined chain (which I call a "spacechain") needs its own native token in order to pay for fees. The mechanism I proposed for that is the perpetual one-way peg, which allows fair "spacecoin" creation by burning BTC, and circumvents creating bad speculative altcoin incentives. Anyone can create a spacechain block and take the fees, and then try to get BTC miners to include it by paying a higher fee than others (via RBF). >That isn't free in terms of storage It's not necessary for everyone to burn individually. My preferred design is to only let BMM block creators burn BTC, then others will have to buy spacecoins from them. This limits the potential burn outputs to one per block (likely much less, because BTC will logically only get burned when spacecoin demand increases). It's also possible to create more spacechains inside the initial spacechain, at no additional storage cost to Bitcoin. I highly recommend checking out the links in my prior post if you wish to learn more, particularly the video . Cheers, Ruben On Tue, Apr 20, 2021 at 3:23 AM 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. > --0000000000005b7ed105c06c278f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yanmaani,

>Merged mining at= present only needs one hash for a merkle root, and that's stored in th= e coinbase.

Yes, but that method is not "blind"= ;, meaning BTC miners have to validate=C2=A0the merged-mined chain, which i= s a significant downside.

>It would be even sim= pler to add the following rules

That would require= a specific soft fork, whereas the method described in my post avoids doing= that.

>do I need to put in a transaction that = burns bitcoins for the tx fee

The blind merged-min= ed chain (which I call a "spacechain") needs its own native token= in order to pay for fees. The mechanism I proposed for that is the perpetu= al one-way peg, which allows fair "spacecoin" creation by burning= BTC, and circumvents creating bad speculative altcoin incentives. Anyone c= an create a spacechain block and take the fees, and then try to get BTC min= ers to include it by paying a higher fee than others (via RBF).
<= br>
>That isn't free in terms of storage

It's not necessary for everyone to burn individually. My preferred des= ign is to only=C2=A0let BMM block creators burn BTC, then others will have = to buy spacecoins from them. This limits the potential burn outputs to one = per block (likely much less, because BTC will logically only get burned whe= n spacecoin demand increases). It's also possible to create more spacec= hains inside the initial spacechain, at no additional storage cost to Bitco= in.

I highly recommend checking out the links in <= a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-Apri= l/018803.html">my prior post if you wish to learn more, particularly th= e video.

Cheers,
Ruben

<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Apr 20, 2021 at 3:23 AM <yanmaani@cock.li> 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"). 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.
--0000000000005b7ed105c06c278f--