* [bitcoin-dev] BIP - limiting OP_RETURN / HF
@ 2021-04-16 7:45 Christopher Gilliard
2021-04-16 13:56 ` Russell O'Connor
` (4 more replies)
0 siblings, 5 replies; 25+ messages in thread
From: Christopher Gilliard @ 2021-04-16 7:45 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-16 7:45 [bitcoin-dev] BIP - limiting OP_RETURN / HF Christopher Gilliard @ 2021-04-16 13:56 ` Russell O'Connor 2021-04-16 15:34 ` Christopher Gilliard 2021-04-16 13:59 ` Clark Moody ` (3 subsequent siblings) 4 siblings, 1 reply; 25+ messages in thread From: Russell O'Connor @ 2021-04-16 13:56 UTC (permalink / raw) To: Christopher Gilliard, Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-16 13:56 ` Russell O'Connor @ 2021-04-16 15:34 ` Christopher Gilliard 2021-04-16 15:55 ` Andrew Poelstra 2021-04-16 23:52 ` ZmnSCPxj 0 siblings, 2 replies; 25+ messages in thread From: Christopher Gilliard @ 2021-04-16 15:34 UTC (permalink / raw) To: Russell O'Connor; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-16 15:34 ` Christopher Gilliard @ 2021-04-16 15:55 ` Andrew Poelstra 2021-04-16 23:52 ` ZmnSCPxj 1 sibling, 0 replies; 25+ messages in thread From: Andrew Poelstra @ 2021-04-16 15:55 UTC (permalink / raw) To: Christopher Gilliard, Bitcoin Protocol Discussion 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-16 15:34 ` Christopher Gilliard 2021-04-16 15:55 ` Andrew Poelstra @ 2021-04-16 23:52 ` ZmnSCPxj 2021-04-17 3:57 ` Christopher Gilliard 1 sibling, 1 reply; 25+ messages in thread From: ZmnSCPxj @ 2021-04-16 23:52 UTC (permalink / raw) To: Christopher Gilliard, Bitcoin Protocol Discussion 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-16 23:52 ` ZmnSCPxj @ 2021-04-17 3:57 ` Christopher Gilliard 2021-04-17 15:50 ` Peter Todd 0 siblings, 1 reply; 25+ messages in thread From: Christopher Gilliard @ 2021-04-17 3:57 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-17 3:57 ` Christopher Gilliard @ 2021-04-17 15:50 ` Peter Todd 2021-04-17 16:57 ` Christopher Gilliard 0 siblings, 1 reply; 25+ messages in thread From: Peter Todd @ 2021-04-17 15:50 UTC (permalink / raw) To: Christopher Gilliard, Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-17 15:50 ` Peter Todd @ 2021-04-17 16:57 ` Christopher Gilliard 0 siblings, 0 replies; 25+ messages in thread From: Christopher Gilliard @ 2021-04-17 16:57 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-16 7:45 [bitcoin-dev] BIP - limiting OP_RETURN / HF Christopher Gilliard 2021-04-16 13:56 ` Russell O'Connor @ 2021-04-16 13:59 ` Clark Moody 2021-04-16 15:33 ` Christopher Gilliard 2021-04-16 16:32 ` Jeremy ` (2 subsequent siblings) 4 siblings, 1 reply; 25+ messages in thread From: Clark Moody @ 2021-04-16 13:59 UTC (permalink / raw) To: Bitcoin Protocol Discussion, Christopher Gilliard [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-16 13:59 ` Clark Moody @ 2021-04-16 15:33 ` Christopher Gilliard 0 siblings, 0 replies; 25+ messages in thread From: Christopher Gilliard @ 2021-04-16 15:33 UTC (permalink / raw) To: Clark Moody; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-16 7:45 [bitcoin-dev] BIP - limiting OP_RETURN / HF Christopher Gilliard 2021-04-16 13:56 ` Russell O'Connor 2021-04-16 13:59 ` Clark Moody @ 2021-04-16 16:32 ` Jeremy 2021-04-16 17:05 ` Christopher Gilliard 2021-04-16 19:15 ` Kostas Karasavvas 2021-04-20 1:22 ` yanmaani 4 siblings, 1 reply; 25+ messages in thread From: Jeremy @ 2021-04-16 16:32 UTC (permalink / raw) To: Christopher Gilliard, Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-16 16:32 ` Jeremy @ 2021-04-16 17:05 ` Christopher Gilliard 2021-04-16 18:00 ` Jeremy 0 siblings, 1 reply; 25+ messages in thread From: Christopher Gilliard @ 2021-04-16 17:05 UTC (permalink / raw) To: Jeremy; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-16 17:05 ` Christopher Gilliard @ 2021-04-16 18:00 ` Jeremy 0 siblings, 0 replies; 25+ messages in thread From: Jeremy @ 2021-04-16 18:00 UTC (permalink / raw) To: Christopher Gilliard; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-16 7:45 [bitcoin-dev] BIP - limiting OP_RETURN / HF Christopher Gilliard ` (2 preceding siblings ...) 2021-04-16 16:32 ` Jeremy @ 2021-04-16 19:15 ` Kostas Karasavvas 2021-04-16 20:12 ` Christopher Gilliard 2021-04-16 20:30 ` Ruben Somsen 2021-04-20 1:22 ` yanmaani 4 siblings, 2 replies; 25+ messages in thread From: Kostas Karasavvas @ 2021-04-16 19:15 UTC (permalink / raw) To: Christopher Gilliard, Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-16 19:15 ` Kostas Karasavvas @ 2021-04-16 20:12 ` Christopher Gilliard 2021-04-17 7:41 ` Kostas Karasavvas 2021-04-16 20:30 ` Ruben Somsen 1 sibling, 1 reply; 25+ messages in thread From: Christopher Gilliard @ 2021-04-16 20:12 UTC (permalink / raw) To: Kostas Karasavvas; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-16 20:12 ` Christopher Gilliard @ 2021-04-17 7:41 ` Kostas Karasavvas 0 siblings, 0 replies; 25+ messages in thread From: Kostas Karasavvas @ 2021-04-17 7:41 UTC (permalink / raw) To: Christopher Gilliard; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-16 19:15 ` Kostas Karasavvas 2021-04-16 20:12 ` Christopher Gilliard @ 2021-04-16 20:30 ` Ruben Somsen 2021-04-16 21:09 ` Christopher Gilliard 2021-04-20 1:23 ` yanmaani 1 sibling, 2 replies; 25+ messages in thread From: Ruben Somsen @ 2021-04-16 20:30 UTC (permalink / raw) To: Bitcoin Protocol Discussion, christopher.gilliard [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-16 20:30 ` Ruben Somsen @ 2021-04-16 21:09 ` Christopher Gilliard 2021-04-20 1:23 ` yanmaani 1 sibling, 0 replies; 25+ messages in thread From: Christopher Gilliard @ 2021-04-16 21:09 UTC (permalink / raw) To: Ruben Somsen; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-16 20:30 ` Ruben Somsen 2021-04-16 21:09 ` Christopher Gilliard @ 2021-04-20 1:23 ` yanmaani 2021-04-20 8:45 ` Zach Greenwood 2021-04-20 19:07 ` Ruben Somsen 1 sibling, 2 replies; 25+ messages in thread From: yanmaani @ 2021-04-20 1:23 UTC (permalink / raw) To: Ruben Somsen, Bitcoin Protocol Discussion; +Cc: christopher.gilliard > 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-20 1:23 ` yanmaani @ 2021-04-20 8:45 ` Zach Greenwood 2021-04-20 17:12 ` Christopher Gilliard 2021-04-20 19:07 ` Ruben Somsen 1 sibling, 1 reply; 25+ messages in thread From: Zach Greenwood @ 2021-04-20 8:45 UTC (permalink / raw) To: yanmaani, Bitcoin Protocol Discussion; +Cc: christopher.gilliard [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-20 8:45 ` Zach Greenwood @ 2021-04-20 17:12 ` Christopher Gilliard 0 siblings, 0 replies; 25+ messages in thread From: Christopher Gilliard @ 2021-04-20 17:12 UTC (permalink / raw) To: Zach Greenwood; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-20 1:23 ` yanmaani 2021-04-20 8:45 ` Zach Greenwood @ 2021-04-20 19:07 ` Ruben Somsen 2021-05-03 5:17 ` ZmnSCPxj 1 sibling, 1 reply; 25+ messages in thread From: Ruben Somsen @ 2021-04-20 19:07 UTC (permalink / raw) To: yanmaani; +Cc: Bitcoin Protocol Discussion, christopher.gilliard [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-20 19:07 ` Ruben Somsen @ 2021-05-03 5:17 ` ZmnSCPxj 2021-05-04 12:51 ` Ruben Somsen 0 siblings, 1 reply; 25+ messages in thread From: ZmnSCPxj @ 2021-05-03 5:17 UTC (permalink / raw) To: Ruben Somsen, Bitcoin Protocol Discussion; +Cc: christopher.gilliard 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-05-03 5:17 ` ZmnSCPxj @ 2021-05-04 12:51 ` Ruben Somsen 0 siblings, 0 replies; 25+ messages in thread From: Ruben Somsen @ 2021-05-04 12:51 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion, christopher.gilliard [-- 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 --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF 2021-04-16 7:45 [bitcoin-dev] BIP - limiting OP_RETURN / HF Christopher Gilliard ` (3 preceding siblings ...) 2021-04-16 19:15 ` Kostas Karasavvas @ 2021-04-20 1:22 ` yanmaani 4 siblings, 0 replies; 25+ messages in thread From: yanmaani @ 2021-04-20 1:22 UTC (permalink / raw) To: Christopher Gilliard, Bitcoin Protocol Discussion 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). ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2021-05-04 12:51 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-04-16 7:45 [bitcoin-dev] BIP - limiting OP_RETURN / HF Christopher Gilliard 2021-04-16 13:56 ` Russell O'Connor 2021-04-16 15:34 ` Christopher Gilliard 2021-04-16 15:55 ` Andrew Poelstra 2021-04-16 23:52 ` ZmnSCPxj 2021-04-17 3:57 ` Christopher Gilliard 2021-04-17 15:50 ` Peter Todd 2021-04-17 16:57 ` Christopher Gilliard 2021-04-16 13:59 ` Clark Moody 2021-04-16 15:33 ` Christopher Gilliard 2021-04-16 16:32 ` Jeremy 2021-04-16 17:05 ` Christopher Gilliard 2021-04-16 18:00 ` Jeremy 2021-04-16 19:15 ` Kostas Karasavvas 2021-04-16 20:12 ` Christopher Gilliard 2021-04-17 7:41 ` Kostas Karasavvas 2021-04-16 20:30 ` Ruben Somsen 2021-04-16 21:09 ` Christopher Gilliard 2021-04-20 1:23 ` yanmaani 2021-04-20 8:45 ` Zach Greenwood 2021-04-20 17:12 ` Christopher Gilliard 2021-04-20 19:07 ` Ruben Somsen 2021-05-03 5:17 ` ZmnSCPxj 2021-05-04 12:51 ` Ruben Somsen 2021-04-20 1:22 ` yanmaani
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox