Re: [bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required

From: Guido Dassori <guido.dassori@gmail•com>
To: Jeremy <jlrubin@mit•edu>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required
Date: Wed, 24 Mar 2021 14:33:07 +0100	[thread overview]
Message-ID: <CAJ_Ap8g6-TR0k7g9-KbxW-4N92kyL6yktVN2jboVNo8sPj7a9w@mail.gmail.com> (raw)
In-Reply-To: <CAD5xwhj73Uq6j_Wu2e6-4VA_-=50mwK4G-Mf24mC87CFvF-LnA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5333 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 8029 bytes --]