Published on: 2021-09-01T15:15:30+00:00
The email thread discusses the implementation of a rate-limiting algorithm in a privacy-preserving manner. The proposed algorithm involves creating an output at a specific block height [h0] that serves as input and limits the maximum amount that can be sent. This rule is permanent and always copied over to a change output. At another block height [h1], a transaction occurs, spending a certain amount [h1_spent]. The payment output created at [h1] is not restricted, while the change output must be encumbered with a second transaction occurring at another block height [h2], spending a certain amount [h2_spent]. However, implementing this algorithm in a privacy-preserving way poses challenges, as it reduces the anonymity set for everyone and makes the payment and change outputs identifiable on-chain. The author suggests using clever MAST-fu in covenant schemes to address these challenges. Several proposals for such covenant schemes exist, but none have gained significant traction.In their email exchange, Zac and ZmnSCPxj discuss the potential reduction of privacy in a proposal due to the introduction of a new type of transaction. This would decrease the anonymity set for everyone and result in identifiable payment and change outputs. Zac proposes using clever MAST-fu to resolve these issues but lacks the technical skills to determine if it's possible. ZmnSCPxj directs Zac towards covenant efforts with MAST-integration developed by aj and RubenSomsen. While various proposals exist, ZmnSCPxj cannot pinpoint one that seems likely to gain significant traction.Zac expresses concerns about the privacy implications of a proposed algorithm that requires a new type of transaction and encumbered change outputs. ZmnSCPxj explains that this proposal would reduce privacy by decreasing the anonymity set for everyone, making payment and change outputs identifiable, and requiring visible on-chain specifics regarding how the output is encumbered. Zac believes that the functionality should not justify the privacy reductions unless these concerns can be addressed. ZmnSCPxj provides further details about the challenges involved in implementing the proposal, including explicit flagging and data storage requirements for each output. These challenges make implementation without consensus code changes difficult, but dropping the "change outputs must also be rate-limited" requirement could improve privacy and ease implementation.ZmnSCPxj's email discusses the potential costs and benefits of implementing a proposal. One issue is the need for explicit visibility to implement the "change outputs must also be rate-limited" requirement. Two options, allocating new SegWit versions or using anyone-can-spend `scriptPubKey` templates, have drawbacks related to privacy concerns. Another challenge is storing data with each output, which increases the size of stored outputs. Ideally, outputs should only contain commitments rather than actual data. However, explicit tagging is necessary to ensure rate-limiting of change outputs, which adds to the amount of data required. The residual limit also needs to be kept with the output. Dropping the "change outputs must also be rate-limited" requirement would address some gaps in the proposal but reduce privacy. Overall, the email highlights various challenges and considerations for implementing this proposal.Zac and ZmnSCPxj discuss the functionality of limiting the amount spent from an address within a certain timeframe. Zac proposes implementing consensus changes to support this functionality, while ZmnSCPxj suggests using covenant opcodes instead. However, there are multiple proposals with overlapping abilities and tradeoffs, potentially leading to disagreements. Zac requests more information on what is needed to implement his unmodified proposal so that the community can assess the cost versus the benefits. He acknowledges that consensus changes take years but believes it is essential to explore the appetite for the proposed functionality and possible technical solutions.Zac and ZmnSCPxj agree on the importance of determining whether the proposed functionality can be implemented without consensus changes. ZmnSCPxj presents a technical counterproposal that explores an implementation on top of the existing Bitcoin system. They discuss the differences between the proposals, highlighting significant gaps. Zac believes that the counterproposal does not meet the basic requirements of the original proposal and prefers implementing consensus changes to support the functionality. They suggest looking into covenant opcodes as an alternative to the counterproposal, as they closely align with one of the motivating examples for covenants. The conversation emphasizes the need to address the gaps between the proposals.In their conversation, Zac proposes functionality that allows control of a coin using two private keys, with spending limited over time for one key and unrestricted for the other. ZmnSCPxj presents a counterproposal using `nSequence` in relative-locktime mode but acknowledges its disadvantages, including obviousness and limits on the number of windows. Zac argues that implementing consensus changes to support the proposed functionality would be preferable over the counterproposal. However, ZmnSCPxj contends that the functionality can be implemented using `nSequence`-in-relative-locktime-mode without any consensus changes.
Updated on: 2023-08-02T04:27:02.335436+00:00