From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id AB8C5C002F for ; Sat, 22 Jan 2022 00:19:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 92C7240143 for ; Sat, 22 Jan 2022 00:19:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=chia.net Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRkZQ5ghsyi2 for ; Sat, 22 Jan 2022 00:19:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by smtp2.osuosl.org (Postfix) with ESMTPS id E6535400D1 for ; Sat, 22 Jan 2022 00:19:20 +0000 (UTC) Received: by mail-lf1-x132.google.com with SMTP id u6so5370464lfm.10 for ; Fri, 21 Jan 2022 16:19:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chia.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vY3ePCFsY+BOU4LYVtgwAjI1MN3QauY3xxe26ul0MPI=; b=OBVFZSDiA8LPzAptmrUPFSzzTjFnvzswlBEi1RzlbItB1j41T6UPbK8Mj/ogWKUYm5 InGhGWQ8VzvwOOfm4vnNopg5zSkotADTIw4ZniAsD6V6e7D4Do1I9tZeLe14mmOS42d5 WWO+bh4VZEEuq9NvIhmqjcAv7HKPFt+66qLSij5y3gGEGzMe9s1j7cKa4VjCET1RNtCA oMFJdGnafUTsfftSECiFultN5vm0j0vpPi5lketmficwu7dwA6/w4V8crVUDWLWyTsqY 8OoPYp4v+ItjOII1zU36Mav15815eIsfUTaiOy6Oynbfvc4bw9dOEinkx0rg9PdgcvsE MbAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vY3ePCFsY+BOU4LYVtgwAjI1MN3QauY3xxe26ul0MPI=; b=AfyUaMHARnlcML1fNxDXP0ymzZ+6oxgkHyNz+QCChw8VCNYWEjFCI8aCsMGw/NnQsW 3q2VI9Weca7YC7kF8t4+CSm/7W+0RXCn5WwbvzuLpVuGpFxH7RireWzqiN6IXdqH/PAO kgB0A5CsWkmfmB1hMyrLie6sPs4qQmccfUVLQ2UrkQPUHH0/G/zefrvY5i3bRBYi/vd8 hOYWhHEC0tmCKzp70pwfk8ghfHDX9OAYn1QUwd4E4KsAJDqOVpmLZfw2HRzr5J0yB4Ld P1MqVsywUNfREpRq3u061DioF+T9QcrBnV4EcLNMGVuMI5YIw1r8vt463gKI/UltEAxG Kicg== X-Gm-Message-State: AOAM5322QNxT3sIeUEqLgES+OkQB4AZUGb0IkUZUaS2sA/QH1MRrgwbU 7jc41+UlIh5/T45anZ9x95f7/JD5G3VsEQmGmFA68g== X-Google-Smtp-Source: ABdhPJxtCUMy1OflibALPbx56friy1kKsz9DNEwwPMd6zURcM2IDtBHOmXOTPH5cKHVgMCabf7e6dhwzL1XNQDN/HrY= X-Received: by 2002:a05:6512:22c6:: with SMTP id g6mr5127426lfu.1.1642810758867; Fri, 21 Jan 2022 16:19:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Bram Cohen Date: Fri, 21 Jan 2022 16:19:07 -0800 Message-ID: To: Billy Tetrud Content-Type: multipart/alternative; boundary="000000000000b73e9805d620af9c" X-Mailman-Approved-At: Sat, 22 Jan 2022 01:56:48 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Covenants and capabilities in the UTXO model 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: Sat, 22 Jan 2022 00:19:22 -0000 --000000000000b73e9805d620af9c Content-Type: text/plain; charset="UTF-8" On Fri, Jan 21, 2022 at 9:32 AM Billy Tetrud wrote: > > Bitcoin doesn't have a strong single concept of a 'parent' > > I'm using the term "parent" loosely in context here to mean a relationship > where an input has constraints applied to an output (or outputs). > Yes and I'm using it more specifically to mean a single parent because the tricks for implementing capabilities I'm talking about don't work if you don't have a way of talking about 'my parent' as an unambiguously defined single UTXO. > > > verify the secure hash chain from its parent to itself so that it > knows what the parent looked like > > I guess I just don't understand why you would want to do it this way. > The idea here is to optimize for adding as little to the UXTO model as possible and doing everything with Bitcoin script additions. Some optional mappings of inputs to outputs in a transaction seem to be necessary but beyond that the current model can remain unchanged. > If you send to an address that has such a reverse-looking script, you > could brick funds that came from the wrong parent. With the reverse > mechanism, the transaction creating the child, you can prevent this from > happening by defining the transaction creating such a child as invalid > unless the child matches the covenant in the parent. > If you want to pay to a singleton you don't do it by paying to some scriptpubkey which represents that singleton, you pay to a scriptpubkey which says 'I can be spent in any transaction which includes singleton X' and it does the validation of that other UTXO being the current incarnation of the singleton using the capabilities validation tricks I mentioned before. > > > "you can only point back so far" leads to transactions becoming invalid, > which is something we've always strictly avoided because it can result in > huge problems during reorgs > > I'm surprised to hear you say that. I have tried to learn why valid > transactions that can become invalid is seen as such a problem. I've been > unsuccessful in finding much information about this. I tried to document > the full extent of my understanding in my proposal here > where > I actually have a quote from you where you said you don't think this is a > valid concern. Did something change your mind? Or did I misinterpret you? > What am I missing from that section I linked to? > It can be made so that if it goes past the time when the backpointer works then the transaction is still valid but its vbytes goes up because the referenced string needs to be repeated on the chain. I too am a bit on the fence about whether strict transaction monotinicity is absolutely necessary. The most plausible violation of it to add would be some kind of max height/age condition to go with the current min height/age restrictions. What scares me about that isn't so much the ability to replay reorgs getting messed up (those can be derailed by double spends anyway) but that either an intentional DOS or just a spike in transaction fees could cause a deadline to be passed and something to be bricked for completely technical reasons having nothing to do with its intended logic. The same type of functionality can be hacked by having an allowed spend whose only condition is a min height/age so that if the time has passed as long as someone isn't asleep at the wheel the transaction will switch to a new state which disallows whatever it is that was supposed to be disallowed at that time. Since there isn't any compelling bit of functionality which needs to violate monotinicity to be implemented I don't see any need to call for an end to it as a principle. It certainly makes mempool logic a lot simpler and more reliable. --000000000000b73e9805d620af9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 21, 2022 at 9:32 AM Billy Tet= rud <billy.tetrud@gmail.com> wrote:




It can be made so t= hat if it goes past the time when the backpointer works then the transactio= n is still valid but its vbytes goes up because the referenced string needs= to be repeated on the chain.

I too am a bit on th= e fence about whether strict transaction monotinicity=C2=A0is absolutely ne= cessary. The most plausible violation of it to add would be some kind of ma= x height/age condition to go with the current min height/age restrictions. = What scares me about that isn't so much the ability to replay reorgs ge= tting messed up (those can be derailed by double spends anyway) but that ei= ther an intentional DOS or just a spike in transaction fees could cause a d= eadline to be passed and something to be bricked for completely technical r= easons having nothing to do with its intended logic. The same type of funct= ionality can be hacked by having an allowed spend whose only condition is a= min height/age so that if the time has passed as long as someone isn't= asleep at the wheel the transaction will switch to a new state which disal= lows whatever it is that was supposed to be disallowed at that time.
<= div>
Since there isn't any compelling bit of functionalit= y which needs to violate monotinicity to be implemented I don't see any= need to call for an end to it as a principle. It certainly makes mempool l= ogic a lot simpler and more reliable.

--000000000000b73e9805d620af9c--