[bitcoin-dev] BIP - limiting OP_RETURN / HF

[bitcoin-dev] BIP - limiting OP_RETURN / HF

[Christopher Gilliard]

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

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

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

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

[Russell O'Connor]

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

Firstly, a minor point is that your proposal is a soft-fork, not a
hard-fork.

But more importantly, adding limitations on OP_RETURN transactions is not
helpful.  Users who want to embed arbitrary data in their transactions can
always do so by encoding their data inside the values of legacy
multi-signature scriptpubkeys (pubkeys can be generated without knowing the
private key in order to encode non-key related data).  Not only can users
do this, users have done this in the past.  However, this behaviour is
problematic because such multi-signature "data" scriptpubkeys are
indistinguishable from "real" multisignature scriptpubkeys, and thus must
be kept in the UTXO set.  This differs from outputs using OP_RETURN which
are provably unspendable, and therefore can be safely omitted from the UTXO
set.

Thus, given that it is otherwise impossible to stop people from putting
arbitrary data values into their transactions, then we rather encourage
people who are going to encode their arbitrary data in transaction to use
the OP_RETURN outputs in order to avoid UTXO bloat.

Also, as it stands, fees already nudge various participants to consolidate
their data in the way that you suggest they do.

On Fri, Apr 16, 2021 at 9:32 AM 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
>

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

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

[Christopher Gilliard]

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

>> But more importantly, adding limitations on OP_RETURN transactions is
not helpful.  Users who want to embed arbitrary data in their transactions
can always do so by encoding their data inside the values of legacy
multi-signature scriptpubkeys (pubkeys can be generated without knowing the
private key in order to encode non-key related data).  Not only can users
do this, users have done this in the past.  However, this behaviour is
problematic because such multi-signature "data" scriptpubkeys are
indistinguishable from "real" multisignature scriptpubkeys, and thus must
be kept in the UTXO set.  This differs from outputs using OP_RETURN which
are provably unspendable, and therefore can be safely omitted from the UTXO
set.

This sounds like a good justification to remove the legacy multi-signature
capabilities as well.

>> Thus, given that it is otherwise impossible to stop people from putting
arbitrary data values into their transactions, then we rather encourage
people who are going to encode their arbitrary data in transaction to use
the OP_RETURN outputs in order to avoid UTXO bloat.

You can't make it completely impossible to do that, but you can make it
harder and at the same time you can provide a solution for doing what they
want to do.

On Fri, Apr 16, 2021 at 1:56 PM Russell O'Connor <roconnor@blockstream.com>
wrote:

> Firstly, a minor point is that your proposal is a soft-fork, not a
> hard-fork.
>
> But more importantly, adding limitations on OP_RETURN transactions is not
> helpful.  Users who want to embed arbitrary data in their transactions can
> always do so by encoding their data inside the values of legacy
> multi-signature scriptpubkeys (pubkeys can be generated without knowing the
> private key in order to encode non-key related data).  Not only can users
> do this, users have done this in the past.  However, this behaviour is
> problematic because such multi-signature "data" scriptpubkeys are
> indistinguishable from "real" multisignature scriptpubkeys, and thus must
> be kept in the UTXO set.  This differs from outputs using OP_RETURN which
> are provably unspendable, and therefore can be safely omitted from the UTXO
> set.
>
> Thus, given that it is otherwise impossible to stop people from putting
> arbitrary data values into their transactions, then we rather encourage
> people who are going to encode their arbitrary data in transaction to use
> the OP_RETURN outputs in order to avoid UTXO bloat.
>
> Also, as it stands, fees already nudge various participants to consolidate
> their data in the way that you suggest they do.
>
> On Fri, Apr 16, 2021 at 9:32 AM 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
>>
>

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

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

[Andrew Poelstra]

On Fri, Apr 16, 2021 at 03:34:33PM +0000, Christopher Gilliard via bitcoin-dev wrote:
> This sounds like a good justification to remove the legacy multi-signature
> capabilities as well.
>

Doing so would confiscate coins, and also it is impossible to remove
legacy multisignatures in general without gutting almost all of Script.
 
> >> Thus, given that it is otherwise impossible to stop people from putting
> arbitrary data values into their transactions, then we rather encourage
> people who are going to encode their arbitrary data in transaction to use
> the OP_RETURN outputs in order to avoid UTXO bloat.
> 
> You can't make it completely impossible to do that, but you can make it
> harder and at the same time you can provide a solution for doing what they
> want to do.
>

I don't think you can even make it harder in a meaningful sense. There is
too much flexibility in transaction data.
 
-- 
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
    -Justin Lewis-Webster

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

[ZmnSCPxj]

Good morning Christopher,

> >> But more importantly, adding limitations on OP_RETURN transactions is not helpful.  Users who want to embed arbitrary data in their transactions can always do so by encoding their data inside the values of legacy multi-signature scriptpubkeys (pubkeys can be generated without knowing the private key in order to encode non-key related data).  Not only can users do this, users have done this in the past.  However, this behaviour is problematic because such multi-signature "data" scriptpubkeys are indistinguishable from "real" multisignature scriptpubkeys, and thus must be kept in the UTXO set.  This differs from outputs using OP_RETURN which are provably unspendable, and therefore can be safely omitted from the UTXO set.
>
> This sounds like a good justification to remove the legacy multi-signature capabilities as well.

The same technique can be used on P2PKH as well --- the "pubkey hash" need not be a hash of a public key, it can be a 20-byte commitment, or even an ASCII message like "ZmnSCPxj is the best" (20 characters, I counted).
There is nothing that *can* check if the hash of a public key is indeed the hash of a public key unless you actually reveal the public key.

If you need a 32-byte commitment, a P2WSH would work --- again the "script hash" need not be a hash of a script, it can be any 32-byte commitment.

In all these cases you have to waste 547 satoshi, but that tends to be small compared to tx fees currently.

Regards,
ZmnSCPxj

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

[Christopher Gilliard]

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

Thanks ZmnSCPxj. Yes, I agree there are many ways to embed arbitrary data
in the blockchain and it's not feasible to block all of them. That is why
it's important to, at the same time as limiting the OP_RETURN to one per
block, also propose and implement a layer 2 solution for timestamping
so people have a clear and simple upgrade path. That is what I will be
discussing in one of the BIPs I intend to release early next week.

On Fri, Apr 16, 2021 at 11:52 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Christopher,
>
> > >> But more importantly, adding limitations on OP_RETURN transactions is
> not helpful.  Users who want to embed arbitrary data in their transactions
> can always do so by encoding their data inside the values of legacy
> multi-signature scriptpubkeys (pubkeys can be generated without knowing the
> private key in order to encode non-key related data).  Not only can users
> do this, users have done this in the past.  However, this behaviour is
> problematic because such multi-signature "data" scriptpubkeys are
> indistinguishable from "real" multisignature scriptpubkeys, and thus must
> be kept in the UTXO set.  This differs from outputs using OP_RETURN which
> are provably unspendable, and therefore can be safely omitted from the UTXO
> set.
> >
> > This sounds like a good justification to remove the legacy
> multi-signature capabilities as well.
>
> The same technique can be used on P2PKH as well --- the "pubkey hash" need
> not be a hash of a public key, it can be a 20-byte commitment, or even an
> ASCII message like "ZmnSCPxj is the best" (20 characters, I counted).
> There is nothing that *can* check if the hash of a public key is indeed
> the hash of a public key unless you actually reveal the public key.
>
> If you need a 32-byte commitment, a P2WSH would work --- again the "script
> hash" need not be a hash of a script, it can be any 32-byte commitment.
>
> In all these cases you have to waste 547 satoshi, but that tends to be
> small compared to tx fees currently.
>
> Regards,
> ZmnSCPxj
>

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

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

[Peter Todd]

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

On Sat, Apr 17, 2021 at 03:57:55AM +0000, Christopher Gilliard via bitcoin-dev wrote:
> Thanks ZmnSCPxj. Yes, I agree there are many ways to embed arbitrary data
> in the blockchain and it's not feasible to block all of them. That is why
> it's important to, at the same time as limiting the OP_RETURN to one per
> block, also propose and implement a layer 2 solution for timestamping
> so people have a clear and simple upgrade path. That is what I will be
> discussing in one of the BIPs I intend to release early next week.

Note that an aggregated timestamping service already exists:

https://petertodd.org/2016/opentimestamps-announcement

But timestamping is useless for most things people want to do, as it can't
commit to a unique history. It merely proves something existed in the past. For
uniqueness, you need something like:

https://petertodd.org/2017/scalable-single-use-seal-asset-transfer


Anyway, at current fees being what they are there's no compelling reason to try
to prevent people from embedding data in the Bitcoin block chain with consensus
changes. Economics is preventing that just fine.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Christopher Gilliard]

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

Peter, thanks for the links. I'm aware that there are other timestamping
aggregation services that already exist, but I had some different ideas
that integrate into some other services. Also thanks for sending the link
to the single use seal asset transfer. I will take a look at that.

On Sat, Apr 17, 2021 at 3:50 PM Peter Todd <pete@petertodd.org> wrote:

> On Sat, Apr 17, 2021 at 03:57:55AM +0000, Christopher Gilliard via
> bitcoin-dev wrote:
> > Thanks ZmnSCPxj. Yes, I agree there are many ways to embed arbitrary data
> > in the blockchain and it's not feasible to block all of them. That is why
> > it's important to, at the same time as limiting the OP_RETURN to one per
> > block, also propose and implement a layer 2 solution for timestamping
> > so people have a clear and simple upgrade path. That is what I will be
> > discussing in one of the BIPs I intend to release early next week.
>
> Note that an aggregated timestamping service already exists:
>
> https://petertodd.org/2016/opentimestamps-announcement
>
> But timestamping is useless for most things people want to do, as it can't
> commit to a unique history. It merely proves something existed in the
> past. For
> uniqueness, you need something like:
>
> https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
>
>
> Anyway, at current fees being what they are there's no compelling reason
> to try
> to prevent people from embedding data in the Bitcoin block chain with
> consensus
> changes. Economics is preventing that just fine.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

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

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

[Clark Moody]

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

Maybe I missed something, but why does this change require a hard fork?

You don't seem to provide any data as part of your rationale, so I'll
provide some context. As it stands, the chain size sits around 386 GB, with
OP_RETURN data accounting for 2.5 GB of that.

I'm also concerned about the coordination required to get into The One
OP_RETURN Per Block, as this certainly requires some measure of
centralization of that Merkle Tree construction.

Some of those OP_RETURN outputs have non-zero value. As such, those outputs
are provably unspendable, and they are essentially paying the rest of the
coin holders via supply deflation.

Finally, Bitcoin nodes may safely discard OP_RETURN outputs at any time,
since they are unspendable. Thus, nodes can clear a few GB of disk space
whenever they need it, but that data is less than 1% of the total chain
size at the time of writing.


-Clark


On Fri, Apr 16, 2021 at 8:32 AM 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
>

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

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

[Christopher Gilliard]

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

>>Maybe I missed something, but why does this change require a hard fork?

I guess you are right that it doesn't technically require a hard fork, but
I see this proposal as more likely being merged with other hard fork or
soft fork features. It depends on which upgrades are happening at the time.
If there's a specific soft fork being proposed to merge this proposal with,
I can update it.

>> I'm also concerned about the coordination required to get into The One
OP_RETURN Per Block, as this certainly requires some measure of
centralization of that Merkle Tree construction.

This will be discussed further in a future BIP, but the basic idea is that
each miner can run an additional piece of software that builds the tree
structure. It's much like submitting a transaction to the network today, if
one of the miners does not accept it, another likely will.

>> Some of those OP_RETURN outputs have non-zero value. As such, those
outputs are provably unspendable, and they are essentially paying the rest
of the coin holders via supply deflation.

Good point, there are other ways to do proof of burn.

>> Finally, Bitcoin nodes may safely discard OP_RETURN outputs at any time,
since they are unspendable. Thus, nodes can clear a few GB of disk space
whenever they need it, but that data is less than 1% of the total chain
size at the time of writing.

Yes, but that doesn't affect IBD.

On Fri, Apr 16, 2021 at 1:59 PM Clark Moody <clark@clarkmoody.com> wrote:

> Maybe I missed something, but why does this change require a hard fork?
>
> You don't seem to provide any data as part of your rationale, so I'll
> provide some context. As it stands, the chain size sits around 386 GB, with
> OP_RETURN data accounting for 2.5 GB of that.
>
> I'm also concerned about the coordination required to get into The One
> OP_RETURN Per Block, as this certainly requires some measure of
> centralization of that Merkle Tree construction.
>
> Some of those OP_RETURN outputs have non-zero value. As such, those
> outputs are provably unspendable, and they are essentially paying the rest
> of the coin holders via supply deflation.
>
> Finally, Bitcoin nodes may safely discard OP_RETURN outputs at any time,
> since they are unspendable. Thus, nodes can clear a few GB of disk space
> whenever they need it, but that data is less than 1% of the total chain
> size at the time of writing.
>
>
> -Clark
>
>
> On Fri, Apr 16, 2021 at 8:32 AM 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
>>
>

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

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

[Jeremy]

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

NACK -- I happen to have a vault where I made emergency backup pre-signed
transactions containing two OP_RETURN outputs and have subsequently lost
the private key in an unfortunate boating incident.

This proposed rule change would serve to confiscate my funds.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Fri, Apr 16, 2021 at 6:32 AM 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
>

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

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

[Christopher Gilliard]

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

Hah! Very funny! 😁 I am certain that this proposal can be implemented in a
way that doesn't confiscate your "long lost" stash and I may even be
willing to fund a bounty for a deep sea diving expedition to find those
keys for a unit test.

On Fri, Apr 16, 2021 at 4:32 PM Jeremy <jlrubin@mit.edu> wrote:

> NACK -- I happen to have a vault where I made emergency backup pre-signed
> transactions containing two OP_RETURN outputs and have subsequently lost
> the private key in an unfortunate boating incident.
>
> This proposed rule change would serve to confiscate my funds.
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Fri, Apr 16, 2021 at 6:32 AM 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
>>
>

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

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

[Jeremy]

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

For every workaround, someone may have a long lost stash that you'd be
confiscating :)

https://bitcoin.stackexchange.com/questions/90127/why-does-this-coinbase-transaction-have-two-op-return-outputs

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

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

[Kostas Karasavvas]

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

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

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

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

[Christopher Gilliard]

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

Thanks for the feedback. Will update the 40 bytes to 80 bytes (40 bytes was
the previous value, but it has since been updated to 80 so that's correct).
Regarding the L2 proposal. I think the BIPs I am working on will address
your questions and I'm hoping to have two more out early next week so
please stay tuned. I'm open to merging those BIPs into this BIP or
vice-versa, but for the sake of making things more readable I broke them
down into several BIPs for the time being.

On Fri, Apr 16, 2021 at 7:15 PM Kostas Karasavvas <kkarasavvas@gmail.com>
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
>

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

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

[Kostas Karasavvas]

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

Indeed, it was 40 then 80 then 40 again and then 80 at the end (or
something like this.. not sure about the exact history!).

Looking forward to the proposal(s).

On Fri, Apr 16, 2021 at 11:12 PM Christopher Gilliard <
christopher.gilliard@gmail.com> wrote:

> Thanks for the feedback. Will update the 40 bytes to 80 bytes (40 bytes
> was the previous value, but it has since been updated to 80 so that's
> correct). Regarding the L2 proposal. I think the BIPs I am working on will
> address your questions and I'm hoping to have two more out early next week
> so please stay tuned. I'm open to merging those BIPs into this BIP or
> vice-versa, but for the sake of making things more readable I broke them
> down into several BIPs for the time being.
>
> On Fri, Apr 16, 2021 at 7:15 PM Kostas Karasavvas <kkarasavvas@gmail.com>
> 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
>>
>

-- 
Konstantinos A. Karasavvas
Software Architect, Blockchain Engineer, Researcher, Educator
https://twitter.com/kkarasavvas

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

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

[Ruben Somsen]

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

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: 7015 bytes --]

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

[Christopher Gilliard]

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

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

[yanmaani]

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

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

[Zach Greenwood]

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

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

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

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

[Christopher Gilliard]

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

Zach,

Thanks for the comments. I just sent out another email to the dev alias
with the other two BIPs that I mentioned last week. It is pending approval
now. I think it will talk about some of the things you mentioned. To avoid
having a lot of comments about those BIPs on this thread, let's use the new
thread for discussing those BIPs.

--Chris

On Tue, Apr 20, 2021 at 1:45 AM Zach Greenwood <zachgrw@gmail.com> wrote:

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

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

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

[Ruben Somsen]

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

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
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018803.html>
if you wish to learn more, particularly the video
<https://youtu.be/N2ow4Q34Jeg>.

Cheers,
Ruben

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"). 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.
>

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

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

[ZmnSCPxj]

Good morning Ruben,

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

What bothers me about BMM is the B.

Mainchain miners assume that sidechain functionaries check the sidechain rules.
Their rule is that if the sidechain functionary is willing to pay an amount, then obviously the sidechain functionary must benefit by at *least* that amount (if not, the sidechain functionary is losing funds over time and will go out of business at some point).
Thus the BMM is an economic incentive for sidechain functionaries to be honest, because dishonesty means that sidechain nodes will reject their blocks and they will have earned nothing in the sidechain that is of equal or greater value than what they spend on the mainchain.

But the BMM on mainchain is done by bidding.
Suppose a sidechain functionary creates a block where it gets S fees, and it pays (times any exchange rates that arise due to differing security profiles of mainchain vs sidechain) M in fess to mainchain miners to get its commitment on the mainchain.
Then any other competing sidechain functionary can create the same block except the S fees go to itself, and paying M+1 in fees to mainchain miners to get *that* commitment mainchain.
This triggers a bidding war.
Logically, further sidechain functionaries will now bid M+2 etc. until M=S (times exchange rates) and the highest bidder earns nothing.

That means that sidechain functionaries will not earn anything once there are at least 2 functionaries, because if there are two sidechain functionaries then they will start the above bidding war and all earnings go to mainchain miners, who are not actually validating anything in the sidechain.
So they are doing all this work of validating the sidechain blocks, but gain nothing thereby, and are thus not much better than fullnodes.

Even if you argue that the sidechain functionaries might gain economic benefit from the existence of the sidechain, that economic benefit can be quantified as some economic value, that can be exchanged at some exchange rate with some number of mainchain tokens, so M just rises above S by that economic benefit and sidechain functionaries will still end up earning 0 money.

If there is only one sidechain functionary the above bidding war does not occur, but then the entire sidechain depends on this one sidechain functionary.

So it does not seem to me that blinded merge mining would work at scale.
Maybe.

Regards,
ZmnSCPxj

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

[Ruben Somsen]

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

Good evening ZmnSCPxj,

Thanks for thinking it through. I appreciate the time and effort.

>sidechain functionaries will not earn anything once there are at least 2
functionaries [...] they are doing all this work of validating the
sidechain blocks, but gain nothing [...] the entire sidechain depends on
this one sidechain functionary

I think your description is accurate, and while it may intuitively sound
problematic, it turns out it does not actually cause any issues.

Even in a scenario where one entity is consistently creating all the
spacechain blocks, they can only do so as long as they consistently leave 0
profit on the table for others. This is actually perfectly acceptable,
because that means this entity is not censoring anyone. As soon as they try
to abuse their position with censorship, it's trivial for anyone to step in
and outbid them.

How trivial, you may wonder? Well, there is very little difference between
being a spacechain miner and a spacechain user. Both are expected to run
full nodes, the only difference is that the miner has some BTC available
and is willing to use it to "mine" the block reward in the spacechain. This
means that the barrier for users to act as miners is low to the point where
it may happen altruistically, and, interestingly, it also doubles as an
appealing way for users to purchase spacecoins in a decentralized fashion.

Btw, I personally prefer not to call a "BMM chain" a sidechain, because in
my eyes it's not a sidechain if the chain has its own altcoin. The
spacechain design (which avoids the use of an altcoin) comes closer to
being a sidechain in that regard, but even there the use of the term
"sidechain" is debatable.

I hope this clarifies things.

Cheers,
Ruben





On Mon, May 3, 2021 at 7:17 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Ruben,
>
> > 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).
>
> What bothers me about BMM is the B.
>
> Mainchain miners assume that sidechain functionaries check the sidechain
> rules.
> Their rule is that if the sidechain functionary is willing to pay an
> amount, then obviously the sidechain functionary must benefit by at *least*
> that amount (if not, the sidechain functionary is losing funds over time
> and will go out of business at some point).
> Thus the BMM is an economic incentive for sidechain functionaries to be
> honest, because dishonesty means that sidechain nodes will reject their
> blocks and they will have earned nothing in the sidechain that is of equal
> or greater value than what they spend on the mainchain.
>
> But the BMM on mainchain is done by bidding.
> Suppose a sidechain functionary creates a block where it gets S fees, and
> it pays (times any exchange rates that arise due to differing security
> profiles of mainchain vs sidechain) M in fess to mainchain miners to get
> its commitment on the mainchain.
> Then any other competing sidechain functionary can create the same block
> except the S fees go to itself, and paying M+1 in fees to mainchain miners
> to get *that* commitment mainchain.
> This triggers a bidding war.
> Logically, further sidechain functionaries will now bid M+2 etc. until M=S
> (times exchange rates) and the highest bidder earns nothing.
>
> That means that sidechain functionaries will not earn anything once there
> are at least 2 functionaries, because if there are two sidechain
> functionaries then they will start the above bidding war and all earnings
> go to mainchain miners, who are not actually validating anything in the
> sidechain.
> So they are doing all this work of validating the sidechain blocks, but
> gain nothing thereby, and are thus not much better than fullnodes.
>
> Even if you argue that the sidechain functionaries might gain economic
> benefit from the existence of the sidechain, that economic benefit can be
> quantified as some economic value, that can be exchanged at some exchange
> rate with some number of mainchain tokens, so M just rises above S by that
> economic benefit and sidechain functionaries will still end up earning 0
> money.
>
> If there is only one sidechain functionary the above bidding war does not
> occur, but then the entire sidechain depends on this one sidechain
> functionary.
>
> So it does not seem to me that blinded merge mining would work at scale.
> Maybe.
>
> Regards,
> ZmnSCPxj
>

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

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

[yanmaani]

This has already been discussed and proposed in various papers and 
articles, typically to replace SHA-256d with something else. It 
basically works, but there's a some tiny issues:

1) Who goes first?

If you first calculate the expensive PoW and then do a cheap SHA-256d 
around it, anyone can malleate it by changing the outer PoW.

If you first calculate the cheap SHA-256d and then do an expensive PoW 
around it, it would work, but then you would have to retool the P2P 
protocol.

2) What's the incentive for miners?

In a "normal" soft-fork, miners have the incentive to upgrade because 
their blocks will be orphaned if they don't, and even the old clients 
won't accept them.

Here, miners will be able to produce an alternate chain that will appear 
valid to old clients, and that the new miners won't be able to orphan 
(since their hash power is much weaker).