path: root/ba/d69c32f17ff729b8cf0bebbe3f4ada43dd84ac

Return-Path: <guido.dassori@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CC0BFC000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 24 Mar 2021 13:33:18 +0000 (UTC)
Received: by mail-pg1-x52d.google.com with SMTP id v2so14642232pgk.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAD5xwhhC1Y13p7KazfUOXFZ5vi5MA9EQ-scyafv4aNkjskoXBg@mail.gmail.com>
 <plFEi9xoSnZ0TDJ7wH2dJx1F727FCSBrPsa2-26AXtveHKolt9bzTE1tiGIoPSjhgBfToVID2YHEaMGwwVU5dZ3Sozmz9UO-6HvbEDmm67I=@protonmail.com>
 <CAD5xwhhMjsYMRebN4Td614qOyAey24h7vQAjZjP_ETzvXJQBLw@mail.gmail.com>
 <_SJunY4b2FhUkCj49-C_D7Uj1VYlS8qqZuO2-NIAEAIkCIfWEWVVgx-pNN0ZXlujGKUiU_hfcV-aq9yK6LHjHoK_5E0pYncVWtW99regZnE=@protonmail.com>
 <CAD5xwhj73Uq6j_Wu2e6-4VA_-=50mwK4G-Mf24mC87CFvF-LnA@mail.gmail.com>
In-Reply-To: <CAD5xwhj73Uq6j_Wu2e6-4VA_-=50mwK4G-Mf24mC87CFvF-LnA@mail.gmail.com>
From: Guido Dassori <guido.dassori@gmail.com>
Date: Wed, 24 Mar 2021 14:33:07 +0100
Message-ID: <CAJ_Ap8g6-TR0k7g9-KbxW-4N92kyL6yktVN2jboVNo8sPj7a9w@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Tue, Mar 16, 2021 at 1:36 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> 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

<div dir=3D"ltr">Hello Jeremy,=C2=A0<div><br></div><div>I find this a very =
interesting idea :-)<div>Actually I implemented something similar a bit ago=
 in a POC, available on GH since a while: <a href=3D"https://github.com/gda=
ssori/btc-bargain">https://github.com/gdassori/btc-bargain</a>=C2=A0</div><=
div><br></div><div>At this very moment we&#39;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%.</div><div><br></div></div><div>Guido</div><div><a =
href=3D"https://twitter.com/khs9ne">https://twitter.com/khs9ne</a></div></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Il =
giorno mer 17 mar 2021 alle ore 07:30 Jeremy via bitcoin-dev &lt;<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfound=
ation.org</a>&gt; ha scritto:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)">ZmnSCPxj,</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)">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.<br></div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I&#39;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 <br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)">2 of CheckMulti(Carol, Dave, Eve) by (for example) encrypt=
ing either a presigned txn or the actual sk&#39;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&#3=
9;s a lot you can do as improvement on simple &quot;hand the key&quot; -- t=
his sounds kinda similar to scriptless scripts?<br></div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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&#39;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.</div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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&#39;, S&#39; could sho=
w a signature covering a txn hash from S&#39;, and request that S sign it. =
S&#39; 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.<br></div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)">Best,</div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Jeremy<b=
r clear=3D"all"></div><div><div dir=3D"ltr"><div dir=3D"ltr">--<br><a href=
=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a h=
ref=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div><=
/div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma=
il_attr">On Tue, Mar 16, 2021 at 1:36 AM ZmnSCPxj &lt;<a href=3D"mailto:Zmn=
SCPxj@protonmail.com" target=3D"_blank">ZmnSCPxj@protonmail.com</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning=
 Jeremy,<br>
<br>
Thank you.<br>
<br>
Assuming only keys, an easier way of delegating would be simply to give a c=
opy of the privkey outright to the delegatee.<br>
<br>
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.<br>
Thus the technique has an ability that mere handover cannot achieve.<br>
<br>
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.<br>
This would avoid the use of `SIGHASH_NONE`, for a mild improvement in priva=
cy.<br>
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).<br>
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.<br>
<br>
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.<br>
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.<br>
This is basically a typical &quot;close transaction&quot; for layer 2 techn=
ology.<br>
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.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000007b09cd05be48574a--