MIME-Version: 1.0
References: <CAK=nyAxOa8fsVfxucH7WTTMn25BCzgQ28h_sNsunedpCoRXjjQ@mail.gmail.com>
 <CABE6yHscUPAcyK58DvqhOnxSOoPMBAy9aMUmReJYSkBit-Mekg@mail.gmail.com>
 <CAPv7Tja=4ZFm5+gHw+wMcZyPEqeQiVx-AjyXsRn0T8a+tXHb1A@mail.gmail.com>
In-Reply-To: <CAPv7Tja=4ZFm5+gHw+wMcZyPEqeQiVx-AjyXsRn0T8a+tXHb1A@mail.gmail.com>
From: Christopher Gilliard <christopher.gilliard@gmail.com>
Date: Fri, 16 Apr 2021 21:09:25 +0000
Message-ID: <CAK=nyAynHnv_WmgkZecCXBGdJCbZ1s3jJf66g0gTSf8oJnH7ZA@mail.gmail.com>
To: Ruben Somsen <rsomsen@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000af7a0505c01d65ac"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF
Precedence: list

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

Thanks for the feedback. I will take at the links and the video and see if
there's anything that I can incorporate to the BIPs.

On Fri, Apr 16, 2021 at 8:30 PM Ruben Somsen <rsomsen@gmail.com> wrote:

> Hi Chris,
>
> I agree with all the points that were made by others. You should also be
> aware that layer two ideas like yours have already been explored, both by
> myself and others. Allowing one hash per block allows for what I call
> "fee-bidding Blind Merged-Mining" (BMM), which as far as I know was first
> proposed by Paul Storc for Drivechains.[0]
>
> 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"), while the Bitcoin miners =
do
> not have to be aware of this other chain ("blind"). There are also non
> fee-bidding variants that function e.g. by burning or locking up bitcoins
> in order to create consensus.
>
> As it turns out, fee-bidding BMM can be achieved using only a covenant
> structure for transactions.[1] You'd have to create a sequence of
> transactions (one per block), to which a hash can be attached. These can
> simply be pre-signed transactions (requires forgetting a key, but the wor=
st
> that can happen is that the chain halts), or an actual covenant using
> either sighash_anyprevout or op_ctv (we don't have these yet) =E2=80=93 n=
o
> specialized soft fork (or hard fork) is required.
>
> You might think any decentralized alternative chain requires an altcoin,
> but this can also be avoided with a perpetual one-way peg.[2] For more
> details, I recommend watching this video of the full concept, which I cal=
l
> "spacechains": https://youtu.be/N2ow4Q34Jeg
>
> -- Ruben Somsen
>
>
>
> [0] Blind Merged-Mining for Drivechains:
> https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki
>
> [1] Fee-bidding Blind Merged-Mining with covenants:
> https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5
>
> [2] Perpetual one-way peg:
> https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechain=
s-the-perpetual-one-way-peg-96cb2f8ac302
>
> On Fri, Apr 16, 2021 at 9:33 PM Kostas Karasavvas via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Christopher,
>>
>> Some feedback:
>>
>> "OP_RETURN is limited to 40 bytes of data."
>> It is 80 bytes.
>>
>> "A future BIP proposing such a layer two protocol will be forthcoming."
>> So what is this BIP about? Just saying that it would be a nice idea? Thi=
s
>> BIP should be the one that would go through this L2 suggestion. If one r=
oot
>> OP_RETURN substitutes all the rest it should say how that would be done.=
..
>> where would the merkle proofs be stored, what are the trust
>> assumptions that we need to make, etc.
>>
>> "Objections to this proposal" section
>> I agree with others re hard-fork, which would be a good thing of course.
>> My main objection with this proposal is that I don't see a proposal. It
>> seems like wishful thinking... if only we could substitute all the
>> OP_RETURNs with one :-)
>>
>> We have to make sure that a proposal like this (L2, etc.) would make sur=
e
>> that there are incentives that justify the added complexity for the user=
s.
>> Multisig is not the only way data could be stored the wrong way; P2PK,
>> P2PKH, P2SH, P2WPKH, P2WSH can also be used. If the incentives are not g=
ood
>> enough people would start using these UTXO-bloat-heavy alternatives.
>>
>> There are a multitude of L2's (kind-of) that do this 'aggregation' of
>> data hashes using merkle trees. Factom is adding a single merkle root pe=
r
>> bitcoin block for the millions upon millions of records (of thousand of
>> users) that they keep in their network. Opentimestamps, tierion,
>> blockstacks and others do a similar thing. I have investigated several o=
f
>> those in the past, for one of my projects, but I ended up using plain ol=
d
>> OP_RETURN because the overhead of their (L2-like) solution and trust
>> assumptions where not to my liking; at least for my use case. They were
>> pretty solid/useful for other use cases.
>>
>> Unless the proposed L2 is flexible/generic enough it would really
>> prohibit this L2 innovation that OP_RETURN allowed (see above).
>>
>>
>>
>> On Fri, Apr 16, 2021 at 4:32 PM Christopher Gilliard via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> I have created a BIP which can be found here:
>>> https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki
>>>
>>> I'm sending this email to start the discussion regarding this proposal.
>>> If there are any comments/suggestions, please let me know.
>>>
>>> Regards,
>>> Chris
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> --
>> Konstantinos A. Karasavvas
>> Software Architect, Blockchain Engineer, Researcher, Educator
>> https://twitter.com/kkarasavvas
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

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

<div dir=3D"ltr">Thanks for the feedback. I will take at the links and the =
video and see if there&#39;s anything that I can incorporate to the BIPs.</=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On=
 Fri, Apr 16, 2021 at 8:30 PM Ruben Somsen &lt;<a href=3D"mailto:rsomsen@gm=
ail.com">rsomsen@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr">Hi Chris,<div><br></div><div>I a=
gree with all the points that were made by others. You should also be aware=
 that layer two ideas like yours have already been explored, both by myself=
 and others. Allowing one hash per block allows for what I call &quot;fee-b=
idding Blind Merged-Mining&quot; (BMM), which as far as I know was first pr=
oposed by Paul Storc for Drivechains.[0]</div><div><br></div><div>If only o=
ne hash is allowed per block, then those who wish to utilize the hash will =
have to out-bid each other (&quot;fee-bidding&quot;). This hash can then be=
 used to create another chain (&quot;merged-mining&quot;), while the Bitcoi=
n miners do not have to be aware of this other chain (&quot;blind&quot;). T=
here are also non fee-bidding variants that function e.g. by burning or loc=
king up bitcoins in order to create consensus.</div><div><br></div><div>As =
it turns out, fee-bidding BMM can be achieved using only a covenant structu=
re for transactions.[1]

 You&#39;d have to create a sequence of transactions (one per block), to wh=
ich a hash can be attached. These can simply be pre-signed transactions (re=
quires forgetting a key, but the worst that can happen is that the chain ha=
lts), or an actual covenant using either sighash_anyprevout or op_ctv (we d=
on&#39;t have these yet) =E2=80=93 no specialized soft fork (or hard fork) =
is required.</div><div><br></div><div>You might think any decentralized alt=
ernative chain requires an altcoin, but this can also be avoided with a per=
petual one-way peg.[2] For more details, I recommend watching this video of=
 the full concept, which I call &quot;spacechains&quot;:=C2=A0<a href=3D"ht=
tps://youtu.be/N2ow4Q34Jeg" target=3D"_blank">https://youtu.be/N2ow4Q34Jeg<=
/a></div><div><br></div><div>-- Ruben Somsen</div><div><br></div><div><br><=
/div><div><br></div><div>[0] Blind Merged-Mining for Drivechains:=C2=A0<a h=
ref=3D"https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki" targ=
et=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-0301.mediawik=
i</a></div><div><br></div><div>[1] Fee-bidding Blind Merged-Mining with cov=
enants: <a href=3D"https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d=
8b34906b16a5" target=3D"_blank">https://gist.github.com/RubenSomsen/5e4be6d=
18e5fa526b17d8b34906b16a5</a></div><div><br></div><div>[2] Perpetual one-wa=
y peg:=C2=A0<a href=3D"https://medium.com/@RubenSomsen/21-million-bitcoins-=
to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302" target=3D"_b=
lank">https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidec=
hains-the-perpetual-one-way-peg-96cb2f8ac302</a></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 16, 2021=
 at 9:33 PM Kostas Karasavvas via bitcoin-dev &lt;<a href=3D"mailto:bitcoin=
-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr">Hi Christopher,<div><br></div><div>Some feedba=
ck:</div><div><br></div><div>&quot;OP_RETURN is limited to 40 bytes of data=
.&quot;</div><div>It is 80 bytes.</div><div><br></div><div>&quot;A future B=
IP proposing such a layer two protocol will be forthcoming.&quot;</div><div=
>So what is this BIP about? Just saying that it would be a nice idea? This =
BIP should be the one that would go through this L2 suggestion. If one root=
 OP_RETURN substitutes all the rest it should say how that would be done...=
 where would the merkle proofs be stored, what are the trust assumptions=C2=
=A0that we need to make, etc.</div><div><br></div><div>&quot;Objections to =
this proposal&quot; section</div><div>I agree with others re hard-fork, whi=
ch would be a good thing of course.=C2=A0 My main objection with this propo=
sal is that I don&#39;t see a proposal. It seems like wishful thinking... i=
f only we could substitute all the OP_RETURNs with one :-)</div><div><br></=
div><div>We have to make sure that a proposal like this (L2, etc.) would ma=
ke sure that there are incentives that justify the added complexity for the=
 users. Multisig is not the only way data could be stored the wrong way; P2=
PK, P2PKH, P2SH, P2WPKH, P2WSH can also be used. If the incentives are not =
good enough people would start using these UTXO-bloat-heavy alternatives.</=
div><div><br></div><div>There are a multitude of L2&#39;s (kind-of) that do=
 this &#39;aggregation&#39; of data hashes using merkle trees. Factom is ad=
ding a single=C2=A0merkle root per bitcoin block for the millions upon mill=
ions of records (of thousand of users) that they keep in their network. Ope=
ntimestamps, tierion, blockstacks and others do a similar thing. I have inv=
estigated several of those in the past, for one of my projects, but I ended=
 up using plain old OP_RETURN because the overhead of their (L2-like) solut=
ion and trust assumptions where not to my liking; at least for my use case.=
 They were pretty solid/useful for other use cases.</div><div><br></div><di=
v>Unless the proposed L2 is flexible/generic enough it would really prohibi=
t this L2 innovation that OP_RETURN allowed (see above).=C2=A0</div><div><b=
r></div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Fri, Apr 16, 2021 at 4:32 PM Christopher Gilliard=
 via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=
I have created a BIP which can be found here:=C2=A0<a href=3D"https://githu=
b.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki" target=3D"_blank=
">https://github.com/cgilliard/bips/blob/notarization/bip-XXXX.mediawiki</a=
><div><br></div><div>I&#39;m sending this email to start the discussion reg=
arding this proposal. If there are any comments/suggestions, please let me =
know.</div><div><br></div><div>Regards,</div><div>Chris</div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
><div dir=3D"ltr"><div><div>Konstantinos A. Karasavvas</div><div>Software A=
rchitect, Blockchain Engineer, Researcher, Educator</div><div dir=3D"ltr"><=
a href=3D"https://twitter.com/kkarasavvas" target=3D"_blank">https://twitte=
r.com/kkarasavvas</a><br></div></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>

--000000000000af7a0505c01d65ac--