Published on: 2022-07-19T23:13:41+00:00
In a recent email exchange on the Bitcoin-dev mailing list, Ruben Somsen proposed a new method for burning multiple amounts in a single OP_RETURN. He suggested using a merkle sum tree with two levels, where the top level represents the total amount burned and the bottom level represents the specific use cases for the funds. However, this method is only practical when burning significantly less than a transaction fee. ZmnSCPxj raised concerns about the atomicity issue and the risk being moved to the seller side. Ruben argued that the lack of an opening of the commitment means the buyer cannot prove the commitment, giving them an incentive to actually pay.The conversation between Ruben and ZmnSCPxj delved into the concept of commitment in cryptography. ZmnSCPxj pointed out that Ruben's proposal did not qualify as a true commitment since it could easily be opened to an uncommitted value. He suggested using Pedersen commitments instead, where only someone who knows 'k' can open the commitment. ZmnSCPxj also explained the merkle sum tree property missing from Ruben's proposal, which allows for the possibility of "double spending" a burn. They also discussed the atomicity issue, where the risk is shifted to the seller if the buyer refuses to finalize the purchase after the on-chain commitment is made. ZmnSCPxj noted that without an opening of the commitment, the buyer cannot prove the commitment and therefore has an incentive to pay.On the bitcoin-dev mailing list, ZmnSCPxj proposed a method for committing to multiple burns in a single transaction using a basic merkle sum tree. To prevent double spending, the leaf hash would need to commit to the intent or recipient of the burn. ZmnSCPxj also suggested outsourcing the burn to an aggregating third party and paying them over Lightning Network (LN), but acknowledged that this would not be atomic. To address this, he proposed an alternative method using private keys and sum commitments. However, ZmnSCPxj cautioned that this approach could have cryptographic failures.Veleslav posted on the mailing list seeking a solution to the proof of burn problem. He suggested using OP_RETURN with application-specific data as the current working solution, but noted the scalability constraint due to finite block space. Veleslav proposed a second layer protocol similar to Lightning Network for public evidence of burns. However, he has not found a solution to the double-spend problem yet. Ruben responded by suggesting a basic merkle sum tree that commits to the intent or recipient of the burn. He also mentioned the possibility of outsourcing the burn to an aggregating third party, but warned about the atomicity issue. Ruben further suggested placing the root hash in a double taproot commitment in the change output, and performing the burn on a spacechain to avoid using mainchain block space and improve scalability. He believes this approach could revitalize the original hashcash use case and combat spam.In conclusion, Veleslav is looking for a solution to the scalability constraint in proof-of-burn use cases. The current solution of using OP_RETURN has limitations, and Veleslav is considering a second layer protocol similar to Lightning Network. However, a reliable solution has not been found yet, and pre-committing burns in the blockchain with additional outputs presents challenges with double spending. Veleslav also explores the possibility of using a liquid type sidechain to fix burns back into the main chain within a Merkel tree proof structure. The goal is to enable micro-burns through the Lightning network and quickly obtain valid burn proofs that are cost-effective to verify.
Updated on: 2023-08-02T07:01:57.518257+00:00