From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id A18BAC000E for ; Mon, 16 Aug 2021 11:48:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 84904403C4 for ; Mon, 16 Aug 2021 11:48:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.598 X-Spam-Level: * X-Spam-Status: No, score=1.598 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7XVhUvwtwnX for ; Mon, 16 Aug 2021 11:48:54 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch [185.70.40.141]) by smtp4.osuosl.org (Postfix) with ESMTPS id 9647A4039F for ; Mon, 16 Aug 2021 11:48:54 +0000 (UTC) Date: Mon, 16 Aug 2021 11:48:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1629114531; bh=walDjUhuZHarxt5DPInACk9xYBSv7lPIi4ED46dBcn4=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=u2p110BszejCuZjpTt9qg5LNqj8K02aVElItVFdvmRn3jabpPJhNrQDrPzjb1uvbP 4MAfTgrtGLoSniOamvwgjmImBrlYuHED9ZJj2lEDC53dDRTl8gUJ81ILAotoq8eyNa 6EO2zXgJ3Baf0U0j7QPq2SRxt9ZIr0Ge8z1mhZB8= To: Zac Greenwood From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <1qkQ1p1rAZApZhMKVFwQV6gfLyZxMYIUPrhcjtXNU4z0DBRwslPSbi76GnNnllpvPPfqt1bH3EyzJNhfK0Uxum7zJ_dh3H0DXqUpf2nmHyk=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 11:48:59 -0000 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 witho= ut making any changes to consensus. > > Your counterproposal is understandably more technical in nature because i= t explores an implementation on top of Bitcoin as-is. However I feel that f= or a fair comparison of the functionality of both proposals a purely functi= onal description of your proposal is essential. > > If I understand your proposal correctly, then I believe there are some ma= jor gaps between yours and mine: > > Keys for unrestricted spending: in my proposal, they never have to come o= nline unless spending more than the limit is desired. In your proposal, the= se 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 implemen= table 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=E2=80=99t su= ch presigning requirement be detrimental for the usability of your proposal= ? Does it mean that for instance the amount and window in which the transac= tion can be spent is determined at the time of signing? In my proposal, the= re 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 th= e remainder back to the same onchain keyset so it can access the funds in t= he future. Both cases are also available in your proposal, and the latter case (pay ou= t 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 pe= r window. > > Number of windows: limited in your proposal, unlimited in mine. Correct, though you can always have a fairly large number of windows ("640k= B ought to be enough for anybody"). > > There are probably additional gaps that I am currently not technically ab= le 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 o= ne-time onlining of the offline keys (or just print out the signatures on p= aper or display as a QR code, whatever) is acceptable. > I feel that the above gaps are significant enough to state that your prop= osal 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 feasibilit= y of implementing your counterproposal. > > I feel that your counterproposal has little chance of being implemented b= ecause of the still considerable effort required and the poor result in fun= ctional terms. I also wonder if your proposal is feasible considering walle= t 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 =C2=A0over = your counterproposal. > > I acknowledge that a consensus change takes years and is difficult to ach= ieve, 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 requir= ing presigning. Since the basic "just use `nSequence`" scheme already implements what you n= eed, 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 wit= h 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 motivat= ing examples for covenants in the first place. Regards, ZmnSCPxj