From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id AE156C0001 for ; Mon, 3 May 2021 02:30:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 903484040C for ; Mon, 3 May 2021 02:30:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com 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 uDmz7n4Y6vUD for ; Mon, 3 May 2021 02:30:15 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch [185.70.40.138]) by smtp2.osuosl.org (Postfix) with ESMTPS id 898C3400C6 for ; Mon, 3 May 2021 02:30:15 +0000 (UTC) Date: Mon, 03 May 2021 02:30:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1620009011; bh=G1U1DKLWwrOMMaveb77zVEoXX3klJBdBTUQzY78ryg0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=ioQCaoHk76Y63DsXTG4Rc1I0Uc2sAHwcUXPAbgNXFHA6dUTXl5mXm6kY7fVrGUQ6d BVVpUokPgRG08IxnEQtYCHUJ2AcHxYCMvKMaY+FHNEbl0gaR2mzVuzXqtaxfbOXGTp nHiSR/O37XWDsGHcZK2mjvFx7PxSxMzK5fYUCVqU= To: ZmnSCPxj , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <3mg9xnvKEhrXuQ5QriYQcLKmrhdYpO0hlxyRpJwZJZInyHCtva208PTZlIxglcq4afO8ftTFRBjRfG0ZEVPvIqxMJhHnFYpnPYTo_mp3qA0=@protonmail.com> References: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@friedenbach.org> <9FD4AF03-28A5-4B8A-9C12-CBCB1BC2E22C@friedenbach.org> <3mg9xnvKEhrXuQ5QriYQcLKmrhdYpO0hlxyRpJwZJZInyHCtva208PTZlIxglcq4afO8ftTFRBjRfG0ZEVPvIqxMJhHnFYpnPYTo_mp3qA0=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Billy Tetrud Subject: Re: [bitcoin-dev] maximum block height on transaction 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, 03 May 2021 02:30:17 -0000 Good morning Billy, and list, > - Using an opcode would greatly increase CPU usage because the script c= ache would need to be reworked (and probably cannot be made to work). > - Adding a field would greatly increase the code complexity to the leve= l of SegWit, without all the important bugfixes+features (tx malleability, = quadratic sighash, well-defined extensible outputs) that SegWit provides. Sometimes, the only way out is through. A general idea to get around this would be: * Define a "hidden" field of a transaction, which is not existent in *any* = serialization of the transaction. * Set a default value for this field that would be compatible with pre-soft= fork rules. * Have an opcode that manipulates this field, carefully designed so it is i= dempotent. The above general idea is not original to me, I believe. I think I have seen it elsewhere on the list, possibly in discussions aroun= d sidechains, though my primary cache is unable to fetch and additional sea= rches through unindexed storage is taking too long. So, for this particular case, here is a (non-serious) proposal to implement= a maximum block height on transactions. * Create a new field `u32 nMaxHeight` on `CTransaction` that is not seriali= zed in any transaction format. * A block is not valid if any transaction in it has an `nMaxHeight` large= r than the block height of the block. * Default value is `0xFFFFFFFF`. * Add a new opcode `OP_SETMAXHEIGHT` that replaces an existing `OP_NOP`. * The opcode must be followed by an `OP_PUSH` of a 32-bit value, else scr= ipt validation fails. * This prevents using a computed value, instead the value must be given= as a constant in the script text. This is a precaution to reduce the risk that execution of the script = at a different time or different computer or etc will result in a different= value that the `OP_SETMAXHEIGHT` opcode uses, which can cause consensus di= vergence. If we figure out later that this precaution is not necessary, we can = just use another `OP_NOP` for `OP_SETMAXHEIGHTFROMSTACK`. * If the current `nMaxHeight` is larger than the given value, then the `n= MaxHeight` is set to the given value. The above avoids issues with opcodes --- the script interpreter can continu= e to be executed in the only place it is in, i.e. at entry into the mempool= . It also avoids some of the code complexity with fields, since the field is = non-existent in any serialization of the transaction, but is instead implie= d by the scripts that the transaction causes to be executed, reducing the n= eed to identify pre-softfork peers and baby-talk to them --- the baby-talk = simply contains "parental bonuses" that are understood by upgraded nodes wh= o are "in the know". Additional complications, such as the need for an index of `nMaxHeight` for= transactions in the mempool (to remove transactions whose `nMaxHeight` is = now in the past), and the additional checks needed when receiving an in-blo= ck transaction that is not in the mempool, are left to the reader. Similar field and opcode for `CTransactionInput` for a relative-time max he= ight are also left as an exercise to the reader. > - You can do what you want with a second `nLockTime`d transaction that = spends the output anyway. The advantage of this functionality is that you can be safely offline at th= e time the timeout occurs in any complicated timeout-based contract. Typically, when using say an HTLC, the contractor who holds lien on the tim= elock branch, has to be online at the time the timelock becomes valid, in o= rder to impose a timeout on the hashlock branch. However, if instead the hashlock branch includes an `OP_SETMAXHEIGHT`, then= the contractor holding lien on the timelock branch does not have this risk= . However, the contractor holding the lien on the hashlock branch now has inc= reased risk. If the timeout is approaching, and suddenly there is high mempool usage at = the time, then a claim of the hashlock branch may fall off the mempool due = to `nMaxHeight` violation. But the transaction claiming the hashlock branch has been published and the= preimage has been published in mempools all over the world, thus the contr= actor holding lien on the hashlock branch risks not being compensated for r= evelation of the preimage. Whereas with the current way things are, the timelock-holder is at risk, an= d the hashlock-holder has reduced risk since even if the timeout arrives, t= here is still the possibility that the hashlock branch is what gets confirm= ed, whereas with `OP_SETMAXHEIGHT` the hashlock-holder has 0 chance of gett= ing the hashlock branch confirmed in case of sudden spike in onchain usaage= . Thus it seems to me that this scheme does not really *improve* Bitcoin sign= ificantly, it only moves risks from one participant to another in a two-par= ticipant contract. Thus, this proposal is not particularly serious. Regards, ZmnSCPxj