On Mon, Aug 12, 2019 at 10:01 AM Peter Todd <p...@petertodd.org> wrote:
> The key difference being it's not important that this be a *public* > notification: that the public can see just happens to be an (unfortunate) > implementation detail. For example, you could imagine a system where the > "prepare to spend" tx is indistinguishable from any other transaction. > True, I did not intend for everyone to know the meaning of the observed transaction. It turns out to not be too useful to the scheme anyway, unless you're interested in protecting against an adversary dumb enough to tell you he has stolen your key before spending your coins. To reiterate my other follow-up email, the best you can do (... or the best I can do right now) is limit losses to k% where k is selected by the user, e.g. 1 input 100 outputs each with succesively increasing timeouts allowing the rotten non-rotated(pre-inserted) key to spend, and instant spending by a recovery flow. Once the attacker steals any one of the k% outputs, you know to not let the outputs timeout to that key in the future. Unfortunately, without an opcode-style covenant, the only way to know if a stale hot key is stolen is to observe an unexpected spend or, if you're lucky, observe an unexpected signature otherwise unassociated with a transaction. > > * Nuclear abort key: Also unnecessary. This is a key for which only a > single > Obviously normally to provably destroy coins you'd spend to an OP_RETURN > output, or if miner censorship was an issue, a pay-to-script-hash of an > OP_RETURN <nonce> script. > Oh, right. Well, that works. > > Delete the key (for pre-signed transactions) > > ============================================ > > > > The delete-the-key trick is simple. The idea is to pre-sign at least one > > transaction and then delete the private key, thus locking in that course > of > > action. > > > > Unfortunately, delete-the-key doesn't really work for multisig scenarios > > because nobody would trust that anyone else in the scheme has actually > deleted > > the secret. If they haven't deleted the secret, then they have full > unilateral > > control to sign anything in that branch of the transaction tree. The > only time > > that delete-the-key might be appropriate would be where the user who > deletes > > the key and controls the key during the setup process is also the sole > > beneficiary of the entire setup with the multisig participants. > > > > Alternative fee rates are easier to deal with using delete-the-key, > compared to > > a technique where the private key never existed which can only be used > to sign > > one fee rate per public key, requiring an entirely new vault subtree for > each > > alternative fee rate. With delete-the-key, the alternative fee rates are > signed > > with the private key before the private key is deleted. > > I think this could use a bit more analysis here: why can't delete the > *keys* > work, with each party deleting a separate private key that's used in an > m-of-n > fashion? So long as at least n-m+1 parties actually deleted their keys > IIUC it > should be secure. > I was thinking about another construction where you pick a key as a group (separate from the multisig setup) and sign with that. But in practice, as you have pointed out, you would do the delete-the-key trick on the multisig construction itself with each party contributing their own pubkey, requiring 1/n honest deletes. > > Multisig gated by ECDSA pubkey recovery for provably-unknown keys > > ================================================================= > > > > A group can participate in a multisig scheme with provably-unknown ECDSA > keys. > > Instead of deleting the key, the idea is to agree on a blockheight and > then > > select the blockhash (or some function of the chosen blockhash like > > H(H(H(blockhash)))) as the signature. Next, the group agrees on a > transaction > > and they recover the public key from the signature using ECDSA pubkey > recovery. > > Could you explain in more detail why you're deriving this from a blockhash? > Well you need to pick an entropy source, and I wouldn't want to tell people to just trust the first party to tell you a good sequence of bytes. - Bryan http://heybryan.org/ 1 512 203 0507
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
