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 CC0BFC000A for ; Wed, 24 Mar 2021 13:33:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 7EE7840EAD for ; Wed, 24 Mar 2021 13:33:20 +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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 q0-jAOTyTByu for ; Wed, 24 Mar 2021 13:33:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by smtp4.osuosl.org (Postfix) with ESMTPS id D2A8C40EAA for ; Wed, 24 Mar 2021 13:33:18 +0000 (UTC) Received: by mail-pg1-x52d.google.com with SMTP id v2so14642232pgk.11 for ; Wed, 24 Mar 2021 06:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=4Jr0vPnF8+IvxInSX+OsJJ7ICZrYcgrkySjDasNrowU=; b=E6/vPnqm8qaKnQLqE3MlxuWGN3ktZm/cJadXxkghxWsQLsF6MMrSwQ/++LCn6KjO6N cxHFWdgv//kCAAT5MlVzwfiruKd8IST+iorOf74tz0iXzTuTKHo8jDkkwy0BTaKwBKxt nCARpeDvztJLaNA6cqZJaAaa5wiVxmHdkMx0ZG0ZLV27FFM8wPweYnxJjfP6hb9O44sV rlj/9UMRj07DuD4JVEol/ZA1ZeioCVxMlwSFV4OYXw1Vn+nQG0nIE0cFMbEPIdHekDF7 Oxoj/wXxMcnxhfBDs0HnPZdDO/d+sLnpk6j3JXszzVMhviBc2O2V+sB16p1AvXJETANY kKXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=4Jr0vPnF8+IvxInSX+OsJJ7ICZrYcgrkySjDasNrowU=; b=jTQPQNo+9rgV0np0tSWM94xp7+GMTA3khB2oHH6FRTHEghjqtbv9KxbWfpoTPMsEbn brrw//wVBB23fAY1d698RbsC6OVQyLd81g4J+ZePkp0Qd/4yRASR4Ntd7QdUUSuWDM5a ik3M/U9NUJ6jPDIQEksI6wOA2igyul6oRgMrmCRO+GfnDuvogOVzp666G+eLIw5UPYFQ ZeVAofI7s+fRLadsukyMRRkxB/9b+8tEdTUcNHePRMcrXNVvq4I9MD8584gfL5f/n+g0 2X2B7OJBCzt9HwoXf89EcOaR+OV+arLP9p9U4XoninSxemQdZWkHjsXDWwkKNpxvLKKL /Bww== X-Gm-Message-State: AOAM532gNaDIZ9Y6pOe+G/qzLFrAqe3ke3qUIij5EVJV/LUMRQHEK4rR VeTQDGnVePwtfDbQFpgDy3kOCQV3gfcOrShfZrU= X-Google-Smtp-Source: ABdhPJxTMRgPeHU+Ym+n1tF4HmjX6+hzGJ7xzeasJgdDokQuBmZpW+JzgeGEusJNjgqChWr+YYFPkBW7s9iu0U+rrm8= X-Received: by 2002:a62:e708:0:b029:1f8:c092:ff93 with SMTP id s8-20020a62e7080000b02901f8c092ff93mr3236633pfh.21.1616592798156; Wed, 24 Mar 2021 06:33:18 -0700 (PDT) MIME-Version: 1.0 References: <_SJunY4b2FhUkCj49-C_D7Uj1VYlS8qqZuO2-NIAEAIkCIfWEWVVgx-pNN0ZXlujGKUiU_hfcV-aq9yK6LHjHoK_5E0pYncVWtW99regZnE=@protonmail.com> In-Reply-To: From: Guido Dassori Date: Wed, 24 Mar 2021 14:33:07 +0100 Message-ID: To: Jeremy , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000007b09cd05be48574a" X-Mailman-Approved-At: Wed, 24 Mar 2021 14:19:41 +0000 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: Wed, 24 Mar 2021 13:33:22 -0000 --0000000000007b09cd05be48574a Content-Type: text/plain; charset="UTF-8" Hello Jeremy, I find this a very interesting idea :-) Actually I implemented something similar a bit ago in a POC, available on GH since a while: https://github.com/gdassori/btc-bargain At this very moment we're working to make it production ready and cut our transaction fees (we run a 2-on-3 wallet with buy\sell features) down to ~5%. Guido https://twitter.com/khs9ne Il giorno mer 17 mar 2021 alle ore 07:30 Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> ha scritto: > ZmnSCPxj, > > The chief reason to use SIGHASH_NONE (or SIGHASH_SINGLE for partial funds > delegations) is to make it so that the delegator can dynamically choose > things like a change output. Otherwise you need to know exactly what you > want beforehand. > > I'd note that you can also achieve a decent amount of scripting capability > for fully pre-signed transactions using layered encryption. E.g., given > script Checksig(Alice) and Checksig(Bob), you can delegate to > 2 of CheckMulti(Carol, Dave, Eve) by (for example) encrypting either a > presigned txn or the actual sk's themselves with enc(Carol, enc(Dave, m)), > enc(Carol, enc(Eve, m)), enc(Dave, enc(Eve, m)). This allows you to > post-hoc delegate a presigned (or the keys -- which may or may not be safe > if they are from a HD wallet mind you). You can also do a variant of > timelock encryption by encrypting m using a verifiable delay function (this > actually permits a new kind of relative lock, depending on where you layer > the VDF enc, which would be N seconds from when the two parties agree to > decrypt). The general protocol can also be optimized by giving Carol > enc(Dave, m) and enc(Eve) but then you have to have a confidential channel > to each delegate. You can also do a ZKCP type thing if you prove that a txn > matching a specific format is encrypted with the preimage to a hash. > There's a lot you can do as improvement on simple "hand the key" -- this > sounds kinda similar to scriptless scripts? > > W.r.t. privacy, it certainly is a hit. But I think in situations where > privacy is a goal, then the delegation can contact the original signer and > ask to cooperate. However in some circumstances that won't be viable given > access to keys or whatnot. I would suggest in these cases that you can do a > hybrid: delegate to a script and provide a default sighash_all txn, and a > modifiable sighash_none/single. Then the delegates can decide what is best > to use and optimistically get the originals to sign off. > > Interestingly, there is a subset of cases where it is desirable to have > privacy *from the original script holder*. Conceivably the tx does need to > be public at some point, but for interest, once delegated to from S to S', > S' could show a signature covering a txn hash from S', and request that S > sign it. S' can reveal partial information -- e.g., which inputs are being > spent, but not which outputs are being created. Maybe not super useful, but > it is interesting to note of course. > > Best, > > Jeremy > -- > @JeremyRubin > > > > On Tue, Mar 16, 2021 at 1:36 AM ZmnSCPxj wrote: > >> Good morning Jeremy, >> >> Thank you. >> >> Assuming only keys, an easier way of delegating would be simply to give a >> copy 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, an 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 >> key plus some additional restrictions, it may be possible to sign with >> `SIGHASH_ALL` a transaction that spends A and D, and outputs to a singlesig >> of the delegatee key. >> This would avoid the use of `SIGHASH_NONE`, for a mild improvement in >> privacy. >> The output would still allow the delegatee to dispose of the funds by its >> unilateral 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 little value. >> >> In terms of offchain technology, if the delegator remains online, the >> delegatee may present a witness satisfying S to the delegator, and ask the >> delegator to provide an alternate transaction that spends A directly >> without spending 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 >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000007b09cd05be48574a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Jeremy,=C2=A0

I find this a very = interesting idea :-)
Actually I implemented something similar a bit ago= in a POC, available on GH since a while: https://github.com/gdassori/btc-bargain=C2=A0
<= div>
At this very moment we're working to make it product= ion ready and cut our transaction fees (we run a 2-on-3 wallet with buy\sel= l features) down to ~5%.

Guido

Il = giorno mer 17 mar 2021 alle ore 07:30 Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfound= ation.org> ha scritto:
ZmnSCPxj,

The chief reason to use SIGHASH_NONE (or SIG= HASH_SINGLE for partial funds delegations) is to make it so that the delega= tor can dynamically choose things like a change output. Otherwise you need = to know exactly what you want beforehand.

I'd note that= you can also achieve a decent amount of scripting capability for fully pre= -signed transactions using layered encryption. E.g., given script Checksig(= Alice) and Checksig(Bob), you can delegate to
2 of CheckMulti(Carol, Dave, Eve) by (for example) encrypt= ing either a presigned txn or the actual sk's themselves with enc(Carol= , enc(Dave, m)), enc(Carol, enc(Eve, m)), enc(Dave, enc(Eve, m)). This allo= ws you to post-hoc delegate a presigned (or the keys -- which may or may no= t be safe if they are from a HD wallet mind you). You can also do a variant= of timelock encryption by encrypting m using a verifiable delay function (= this actually permits a new kind of relative lock, depending on where you l= ayer the VDF enc, which would be N seconds from when the two parties agree = to decrypt). The general protocol can also be optimized by giving Carol enc= (Dave, m) and enc(Eve) but then you have to have a confidential channel to = each delegate. You can also do a ZKCP type thing if you prove that a txn ma= tching a specific format is encrypted with the preimage to a hash. There= 9;s a lot you can do as improvement on simple "hand the key" -- t= his sounds kinda similar to scriptless scripts?

W.r.t. priv= acy, it certainly is a hit. But I think in situations where privacy is a go= al, then the delegation can contact the original signer and ask to cooperat= e. However in some circumstances that won't be viable given access to k= eys or whatnot. I would suggest in these cases that you can do a hybrid: de= legate to a script and provide a default sighash_all txn, and a modifiable = sighash_none/single. Then the delegates can decide what is best to use and = optimistically get the originals to sign off.

Interestingly, th= ere is a subset of cases where it is desirable to have privacy *from the or= iginal script holder*. Conceivably the tx does need to be public at some po= int, but for interest, once delegated to from S to S', S' could sho= w a signature covering a txn hash from S', and request that S sign it. = S' can reveal partial information -- e.g., which inputs are being spent= , but not which outputs are being created. Maybe not super useful, but it i= s interesting to note of course.

Best,

Jeremy
<= /div>

On Tue, Mar 16, 2021 at 1:36 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wro= te:
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 techn= ology.
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
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000007b09cd05be48574a--