From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Jeremy <jlrubin@mit•edu>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required
Date: Tue, 16 Mar 2021 08:36:09 +0000 [thread overview]
Message-ID: <_SJunY4b2FhUkCj49-C_D7Uj1VYlS8qqZuO2-NIAEAIkCIfWEWVVgx-pNN0ZXlujGKUiU_hfcV-aq9yK6LHjHoK_5E0pYncVWtW99regZnE=@protonmail.com> (raw)
In-Reply-To: <CAD5xwhhMjsYMRebN4Td614qOyAey24h7vQAjZjP_ETzvXJQBLw@mail.gmail.com>
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
next prev parent reply other threads:[~2021-03-16 8:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-10 23:55 Jeremy
2021-03-16 6:09 ` ZmnSCPxj
2021-03-16 6:16 ` Jeremy
2021-03-16 8:36 ` ZmnSCPxj [this message]
2021-03-17 6:30 ` Jeremy
2021-03-24 13:33 ` Guido Dassori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='_SJunY4b2FhUkCj49-C_D7Uj1VYlS8qqZuO2-NIAEAIkCIfWEWVVgx-pNN0ZXlujGKUiU_hfcV-aq9yK6LHjHoK_5E0pYncVWtW99regZnE=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jlrubin@mit$(echo .)edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox