Published on: 2021-05-04T12:51:14+00:00
In a recent email exchange, Ruben Somsen and ZmnSCPxj discussed the concept of blind merged mining (BMM) and its potential drawbacks. They discussed how sidechain functionaries may not earn anything once there are multiple functionaries, as they do all the work but gain nothing in return. However, Ruben explained that if one entity consistently creates all the sidechain blocks without leaving any profit for others, it's easy for anyone to step in and outbid them if they try to abuse their position. He also highlighted the similarity between being a spacechain miner and a spacechain user, with the only difference being the availability of BTC to mine the block reward.The conversation also touched upon the use of the term "sidechain" and whether it accurately describes a chain with its own altcoin. Ruben preferred not to call it a "BMM chain" because, in his view, it's not a sidechain if it has its own altcoin. ZmnSCPxj expressed concern about BMM on the mainchain, stating that sidechain functionaries would not earn anything once there are multiple functionaries, and even with just one functionary, the entire sidechain would depend on that entity. The potential drawbacks of blind merged mining were explored, and the possibility of addressing some of these issues through the spacechain design was discussed.The conversation between Yanmaani and Ruben focused on merged mining. Ruben suggested that the current method of storing one hash for a merkle root in Coinbase is not "blind" and proposed a mechanism called the perpetual one-way peg to enable fair "spacecoin" creation by burning BTC to pay for fees. ZmnSCPxj expressed concern about BMM on the main chain, highlighting the issue of bidding wars among functionaries resulting in no earnings for sidechain functionaries. The dependence on a single sidechain functionary was seen as a potential problem. Ruben proposed a mechanism for blind merged mining using a native token called "spacecoin" and explained how it could avoid some of the issues associated with BMM.Zach Greenwood and Yanmaani discussed the issue of storing data on the blockchain, with Zach suggesting the need for a more efficient way to store data while still being almost as expensive per byte compared to using OP_RETURN. Yanmaani proposed adding rules to limit OP_RETURN transactions and committing data in the coinbase transaction to simplify merged mining. The question of payment handling and potential storage costs were raised. Chris responded, mentioning another email sent to the dev alias with additional BIPs and suggesting discussing those BIPs in a new thread.A message posted to the Bitcoin-dev mailing list proposed the development of a facility for more efficient and cost-effective storage of data on-chain. The post highlighted the limitations of using OP_RETURN and suggested a layer two solution for timestamping that integrates into other services. The existing aggregated timestamping service was mentioned, and the high transaction fees were seen as a deterrent to excessive data embedding in the Bitcoin blockchain.The concept of merged mining and the use of one hash per block were discussed. The issue of competition between users wanting to use the hash was raised, resulting in fee-bidding. The proposal included implementing rules to limit OP_RETURN transactions and committing data in the coinbase transaction. Payment handling and storage costs were also considered.The idea of replacing SHA-256d with another solution was explored, considering the malleability of calculating expensive Proof of Work (PoW) and the need to retool the Peer-to-Peer (P2P) protocol. Incentives for miners to upgrade were also discussed, highlighting the challenges of implementing changes without weaker hash power producing alternate chains that appear valid to old clients. The issues that need to be addressed before replacing SHA-256d were emphasized.Christopher Gilliard and Peter Todd discussed the proposal for a layer 2 solution for timestamping that integrates into other services. The limitations of timestamping for proving uniqueness were highlighted, and an existing aggregated timestamping service was mentioned. The need to prevent excessive data embedding through consensus changes and the current high transaction fees were also discussed.Christopher Gilliard's proposed Bitcoin Improvement Proposal (BIP) regarding OP_RETURN limitations was met with feedback and objections. The proposal suggests increasing the limit and implementing a layer two protocol for data aggregation using merkle trees. Concerns were raised about the need for a hard fork and the lack of detail in the proposal. Additional BIPs were mentioned as a response to address these concerns. Feedback included correcting the byte limit for OP_RETURN and discussing the need for incentives and flexibility in accommodating different use cases.The limitations on OP_RETURN transactions were seen as ineffective in blocking arbitrary data embedding on the blockchain. Encoding data inside legacy multi-signature scriptpubkeys was noted as a workaround, but it posed problems in terms of UTXO set management.
Updated on: 2023-08-02T03:36:18.290138+00:00