Published on: 2021-11-01T01:19:42+00:00
The conversation begins with Billy explaining the benefits of a 2-key wallet vault using OP_CD over a normal 2-of-2 multisig wallet. He highlights that with a wallet vault, only one key is needed to spend funds, but an attacker would need to steal two or more keys. This provides better redundancy and security. Billy also shares a link to a wallet vault design that utilizes OP_CD and discusses his vision for creating highly secure wallets.The discussion then shifts to implementing a mechanism to limit the maximum amount that can be sent from an address. Billy suggests designing a system where coins are combined in a single output and encumbered with a script that allows a limited amount to be sent while requiring the remaining bitcoins to be returned to the sender. He emphasizes the effectiveness of such a system in preventing theft. Zac further elaborates on how this mechanism might work in a typical use case scenario and proposes rate-limiting parameters that could be implemented.Next, the optimization of Bitcoin transactions is discussed. Jeremy suggests splitting up the fee limiting functionality from OP_CD into a separate opcode called OP_LIMITFEECONTRIBUTION. Billy acknowledges the considerations involved in this approach, including evaluating input addresses without knowing their contribution amounts. He also suggests allowing the omission of an output value in cases where the entire output amount is contributed by that input to reduce transaction size.The conversations highlight the benefits, limitations, and considerations related to optimizing Bitcoin transactions, implementing mechanisms to limit the maximum amount sent from an address, and creating secure wallet vaults using covenant opcodes like OP_CD. They also discuss the potential impact on transaction size, security, and user experience.Another topic of discussion is the manipulation of fee rates in Bitcoin transactions by miners. It is estimated that filling 15% of each block with self-pay transactions could raise median fees by approximately 5%. However, this type of attack may not be profitable for dishonest miners due to the large number of transactions needed. The proposed use case for wallet vaults is also discussed, aiming to limit the amount that can be stolen through fees by attackers. Concerns are raised about miners abusing the fee limit mechanism in multi-party scenarios.In an email exchange, Billy suggests calculating the median fee rate for each block and taking the average of those stored per-block median numbers. However, Dave disagrees and believes that miners may have the opportunity to raise the fee rate in certain situations. It is emphasized that every miner is also a user of Bitcoin, and every Bitcoin user may eventually become a miner. Dave provides an example where an attacker could work with a cartel of miners to raise the median fee rate and take all of someone's coins in fees.The proposal being discussed involves constraining the amount of fee that an output can contribute. MedianFeeRate and maxFeeContribution are defined as mechanisms to calculate and limit fees. Storing the feerate for every transaction in a 3,000 block window is considered impractical, so it is suggested to find the median fee-rate for each block instead. Concerns are expressed regarding the effect of this proposal on miner incentives and the redundancy of the fee mechanism.Finally, the OP_CONSTRAINDESTINATION opcode is proposed as a solution to restrict the destination address that an output's coins can be directed to. This opcode allows for step-wise covenant scripts and aims to create more flexible wallet vaults compared to OP_CHECKTEMPLATEVERIFY. The proposal can be found on Github, and feedback is welcomed to improve its presentation or identify any issues.
Updated on: 2023-08-02T04:24:39.456958+00:00