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 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 >> >