Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

[Christopher Gilliard <christopher.gilliard@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5325 bytes --]

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 worst
> 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) – no
> 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 call
> "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-sidechains-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? 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 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 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; P2PK,
>> P2PKH, P2SH, P2WPKH, P2WSH can also be used. If the incentives are not good
>> 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 per
>> 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 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) 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
>>
>

[-- Attachment #2: Type: text/html, Size: 7578 bytes --]