This is incompatible with bip-schnorr, which intentionally disallow such use by always committing to the public key: https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
With the recent fake Satoshi signature drama, and other potential ways to misuse and abuse, I think this is a better way to go, which unfortunately might disallow some legitimate applications. Covenants could be made using OP_CHECKSIGFROMSTACK (https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf) or OP_PUSHTXDATA (https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki). I think this is the next step following the taproot soft fork > On 28 Nov 2018, at 8:54 AM, Bob McElrath via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > I have been working on an experimental wallet that implements Bitcoin > Covenants/Vaults following a blog post I wrote about 2 years ago, using > "Pay-to-Timelock Signed Transaction" (P2TST). (Also mentioned recently by > kanzure in a talk somewheres...) The idea is that you deposit to an address > for > which you don't know the private key. Instead you construct a second > transaction sending that to a timelocked staging address for which you DO have > the privkey (it also has an IF/ELSE condition with a second spending condition > for use in case of theft attempt). In order to do this you either have to > delete the privkey of the deposit address (a difficult proposition to know > it's > actually been deleted), but instead one can construct a signature directly > using > a RNG, and use the SIGHASH to compute the corresponding pubkey via ECDSA > recover, from which you compute the corresponding address. In this way your > wallet is a set of P2TST transactions and a corresponding privkey, with a (set > of) emergency keys. > > This interacts with NOINPUT in the following way: if the input to the > transaction commits to the pubkey in any way, you have a circular dependency > on > the pubkey that could only be satisfied by breaking a hash function. This > occurs with standard sighash's which commit to the txid, which in turn commit > to > the address, which commits to the pubkey, so this construction of > covenants/vaults requires NOINPUT. > > AFAICT sipa's proposal is compatible with the above vaulted construction by > using SIGHASH_NOINPUT | SIGHASH_SCRIPTMASK to remove the > scriptPubKey/redeemScript from the sighash. Putting the > scriptPubKey/redeemScript in the sighash introduces the same circular > dependency, but SIGHASH_SCRIPTMASK removes it. > > One would probably want to provide the fee from a separate wallet so as to be > able to account for fluctuating fee pressures when the unvaulting occurs a > long > time after vaulting. Thus you'd want to use SIGHASH_SINGLE so that a > fee-wallet > can add fees (or for composability of P2TSTs), and SIGHASH_NOFEE as well. > > P.S. Also very excited to combine the above idea with > Taproot/Graftroot/g'Root. > > -- > Cheers, Bob McElrath > > "For every complex problem, there is a solution that is simple, neat, and > wrong." > -- H. L. Mencken > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
