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 >