From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 03377C000A for ; Tue, 16 Mar 2021 08:36:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id DCFCD4EC0E for ; Tue, 16 Mar 2021 08:36:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 OgNwyrAovl3c for ; Tue, 16 Mar 2021 08:36:17 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) by smtp4.osuosl.org (Postfix) with ESMTPS id 0156E4EC03 for ; Tue, 16 Mar 2021 08:36:16 +0000 (UTC) Date: Tue, 16 Mar 2021 08:36:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1615883772; bh=O4Tc3/hbFVNHKxgj1Oey2+x2C9Qts74lTchau3mQQNY=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=Vaifkyivu4/dg4QCZ/laStbxNwJQbdGfdM3R+iDdwHiiJ8nMaUuXDGtHn/LAv8dER kVMxVbdkg8cgbb4uJPqQeDqBiErQkb/QEf/eCqqSFkks+ibAbGZm55YbDWdFJlvhnm TgF/ZS9egIzmOOOrJycZvCrv1U6Nw2QM48nJKpnc= To: Jeremy From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <_SJunY4b2FhUkCj49-C_D7Uj1VYlS8qqZuO2-NIAEAIkCIfWEWVVgx-pNN0ZXlujGKUiU_hfcV-aq9yK6LHjHoK_5E0pYncVWtW99regZnE=@protonmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required 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: Tue, 16 Mar 2021 08:36:19 -0000 Good morning Jeremy, Thank you. Assuming only keys, an easier way of delegating would be simply to give a c= opy of the privkey outright to the delegatee. However, an advantage of this technique you described is that the delegator= can impose additional restrictions that are programmable via any SCRIPT, a= n ability that merely handing over the privkey cannot do. Thus the technique has an ability that mere handover cannot achieve. If the delegatee is a known single entity, and S is simply the delegatee ke= y plus some additional restrictions, it may be possible to sign with `SIGHA= SH_ALL` a transaction that spends A and D, and outputs to a singlesig of th= e delegatee key. This would avoid the use of `SIGHASH_NONE`, for a mild improvement in priva= cy. The output would still allow the delegatee to dispose of the funds by its u= nilateral decision subject to the fulfillment of the script S (at the cost = of yet another transaction). On the other hand, if S is unusual enough, the enhanced privacy may be moot= (the S already marks the transaction as unusual), so this variation has li= ttle value. In terms of offchain technology, if the delegator remains online, the deleg= atee may present a witness satisfying S to the delegator, and ask the deleg= ator to provide an alternate transaction that spends A directly without spe= nding D and outputs to whatever the delegatee wants. The delegator cannot refuse since the delegatee can always use the `SIGHASH= _NONE` signature and spend to whatever it decides provided it can present a= witness satisfying S. This is basically a typical "close transaction" for layer 2 technology. On the other hand, one generalized use-case for delegation would be if the = delegator suspects it may not be online or able to sign with the delegator = key, so this variation has reduced value as well. Regards, ZmnSCPxj