Good morning Zac, > Thank you for your counterproposal. I fully agree that as a first step we > must establish whether the proposed functionality can be implemented without > making any changes to consensus. > > Your counterproposal is understandably more technical in nature because it > explores an implementation on top of Bitcoin as-is. However I feel that for a > fair comparison of the functionality of both proposals a purely functional > description of your proposal is essential. > > If I understand your proposal correctly, then I believe there are some major > gaps between yours and mine: > > Keys for unrestricted spending: in my proposal, they never have to come > online unless spending more than the limit is desired. In your proposal, > these keys are required to come online in several situations.
Correct, that is indeed a weakness. It is helpful to see https://zmnscpxj.github.io/bitcoin/unchained.html Basically: any quorum of signers can impose any rules that are not implementable on the base layer, including the rules you desire. That quorum is the "offline keyset" in my proposal. > > Presigning transactions: not required in my proposal. Wouldn’t such > presigning requirement be detrimental for the usability of your proposal? > Does it mean that for instance the amount and window in which the transaction > can be spent is determined at the time of signing? In my proposal, there is > no limit in the number of transactions per window. No. Remember, the output is a simple 1-of-1 or k-of-n of the online keyset. The online keyset can spend that wherever and however, including paying it out to N parties, or paying part of the limit to 1 party and then paying the remainder back to the same onchain keyset so it can access the funds in the future. Both cases are also available in your proposal, and the latter case (pay out part of the limit to a single output, then keep the rest back to the same onchain keyset) can be used to add an indefinite number of transactions per window. > > Number of windows: limited in your proposal, unlimited in mine. Correct, though you can always have a fairly large number of windows ("640kB ought to be enough for anybody"). > > There are probably additional gaps that I am currently not technically able > to recognize. It requires a fair amount of storage for the signatures at minimum, though that may be as small as 64 bytes per window. 1Mb of storage for signatures would allow 16,384 windows, assuming you use 1-day windows that is about 44.88 years, probably more than enough that a one-time onlining of the offline keys (or just print out the signatures on paper or display as a QR code, whatever) is acceptable. > I feel that the above gaps are significant enough to state that your proposal > does not meet the basic requirements of my proposal. > > Next to consider is whether the gap is acceptable, weighing the effort to > implement the required consensus changes against the effort and feasibility > of implementing your counterproposal. > > I feel that your counterproposal has little chance of being implemented > because of the still considerable effort required and the poor result in > functional terms. I also wonder if your proposal is feasible considering > wallet operability. See above, particularly the gap that does not, in fact, exist. > > Considering all the above, I believe that implementing consensus changes in > order to support the proposed functionality would preferable over your > counterproposal. > > I acknowledge that a consensus change takes years and is difficult to > achieve, but that should not be any reason to stop exploring the appetite for > the proposed functionality and perhaps start looking at possible technical > solutions. You can also look into the "covenant" opcodes (`OP_CHECKSIGFROMSTACK`, `OP_CHECKTEMPLATEVERIFY`, etc.), I think JeremyRubin has a bunch of them listed somewhere, which may be used to implement something similar without requiring presigning. Since the basic "just use `nSequence`" scheme already implements what you need, what the covenant opcodes buy you is that you do not need the offline keyset to be onlined and there is no need to keep signatures, removing the remaining gaps you identified. With a proper looping covenant opcode, there is also no limit on the number of windows. The issue with the covenant opcodes is that there are several proposals with overlapping abilities and different tradeoffs. This is the sort of thing that invites bikeshed-painting. I suggest looking into the covenant opcodes and supporting those instead of your own proposal, as your application is very close to one of the motivating examples for covenants in the first place. Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
