Published on: 2021-03-24T13:33:07+00:00
Guido mentioned that he implemented a similar idea in a POC available on GH since a while and they are working to make it production ready. They run a 2-on-3 wallet with buy/sell features and aim to cut their transaction fees down to ~5%.In the context of delegating funds, Jeremy Rubin notes that SIGHASH_NONE or SIGHASH_SINGLE can be used to allow the delegator to dynamically choose things like a change output. Jeremy also mentions that layered encryption can enable a decent amount of scripting capability for fully pre-signed transactions. He suggests that in cases where privacy is a goal, delegates can contact the original signer and ask to cooperate. However, in some circumstances this may not be viable given access to keys or whatnot.A hybrid approach can be taken where the user delegates to a script and provides a default sighash_all txn, and a modifiable sighash_none/single. Interestingly, there is a subset of cases where it is desirable to have privacy from the original script holder. ZmnSCPxj notes that an advantage of the technique that Jeremy 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.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. 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.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.The conversation between Jeremy Rubin and ZmnSCPxj discusses the advantages of using SIGHASH_NONE and SIGHASH_SINGLE for partial funds delegations. This allows the delegator to dynamically choose certain factors like a change output, which cannot be achieved by simply handing over the privkey. Additionally, layered encryption can be used to delegate to multiple parties using Checksig scripts and presigned transactions. However, this may compromise privacy, and in situations where privacy is a goal, the delegation can contact the original signer for cooperation. A hybrid approach could also be used, where delegates are provided with a default sighash_all txn and a modifiable sighash_none/single, allowing them to decide what is best to use. Another interesting point discussed is the subset of cases where it is desirable to have privacy from the original script holder. Overall, the conversation delves into various aspects and use-cases of delegation and highlights its advantages and limitations.The technique of delegating through additional restrictions programmable via any SCRIPT has an advantage over simply handing over the privkey to the delegatee. It allows for the imposition of further restrictions that cannot be achieved through mere handover. If the delegatee is a known single entity and S is the delegatee key plus some additional restrictions, it is possible to sign with `SIGHASH_ALL` a transaction that spends A and D and outputs to a singlesig of the delegatee key, which improves privacy. However, if S is already unusual enough, this variation may have 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 for an alternate transaction that spends A directly without spending D and outputs to whatever the delegatee wants. This is a typical "close transaction" for layer 2 technology.In this email conversation, ZmnSCPxj and JeremyRubin discuss various ideas related to Bitcoin transaction delegation. One idea discussed is the use of multiple delegates with independent scripts to enforce disparate conditions. This can be useful in cases where one delegate requires a relative height lock while another requires a relative time lock. Another idea discussed is sequenced contingent delegation, which involves constructing a specific TXID to delegate coins, making their delegation contingent on some other contract reaching a particular state. However, this model requires coordination between the main and observing contracts as each coin delegate can only be claimed once. Lastly, they discuss redelegating, where A delegates to S, who then delegates to S', allowing the original owner to still control the coin.The email discusses three different mechanisms for delegating coins in a Bitcoin transaction. The first mechanism, multiple delegates, involves signing a transaction with several delegate outputs to enforce multiple conditions.
Updated on: 2023-08-02T03:23:46.918380+00:00