path: root/3d/4df29aab6ec6b2f74e7a0d3293ca9948b837e7

Return-Path: <aj@erisian.com.au>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E7352C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Oct 2023 13:05:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id BD043410A1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Oct 2023 13:05:13 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org BD043410A1
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id kFpRazZUauDX
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Oct 2023 13:05:12 +0000 (UTC)
Received: from cerulean.erisian.com.au (azure.erisian.com.au [172.104.61.193])
 by smtp4.osuosl.org (Postfix) with ESMTPS id EED8140950
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Oct 2023 13:05:11 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org EED8140950
Received: from aj@azure.erisian.com.au
 by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2)
 (envelope-from <aj@erisian.com.au>)
 id 1qxoQb-0007mc-If; Tue, 31 Oct 2023 23:05:08 +1000
Received: by email (sSMTP sendmail emulation); Tue, 31 Oct 2023 23:05:01 +1000
Date: Tue, 31 Oct 2023 23:05:01 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Rusty Russell <rusty@rustcorp.com.au>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZUD7fZnrDb2GGvY5@erisian.com.au>
References: <ZTtgFPG4tTeZMnYn@erisian.com.au> <87r0lfz6zp.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87r0lfz6zp.fsf@rustcorp.com.au>
X-Spam_score: 0.0
X-Spam_bar: /
Subject: Re: [bitcoin-dev] Examining ScriptPubkeys in Bitcoin Script
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Oct 2023 13:05:14 -0000

On Sat, Oct 28, 2023 at 03:19:30PM +1030, Rusty Russell via bitcoin-dev wrote:

[Quoted text has been reordered]

> > I think there's two reasons to think about this approach:
> >  (a) we want to do vault operations specifically,

> I'm interested in vaults because they're a concrete example I can get my
> head around.  Not because I think they'll be widely used!

I don't think that's likely to make for a very productive discussion: we
shouldn't be changing consensus to support toy examples, after all. If
there's a *useful* thing to do that would be possible with similar
consensus changes, lets discuss that thing; if there's nothing useful
that needs these consensus changes, then lets discuss something useful
that doesn't need consensus changes instead.

To me, it seems pretty likely that if you're designing an API where
you don't expect anyone to actually use it for anything important, then
you're going to end up making pretty bad API -- after all, why put in
the effort to understand the use case and make a good API if you're sure
it will never be useful anyway?

There are some articles on API design that I quite like:

  https://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html
  https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html

I'd rate the "lets have a mass of incomprehensible script that no one
really understands and is incredibly dangerous to modify, and just make it
a template" approach as somewhere between "3. Read the documentation and
you'll get it right" (at best) and "-5 Do it right and it will sometimes
break at runtime" (more likely).

Anyway, for the specific examples:

> But AFAICT there are multiple perfectly reasonable variants of vaults,
> too.  One would be:
>
> 1. master key can do anything
> 2. OR normal key can send back to vault addr without delay
> 3. OR normal key can do anything else after a delay.

I don't think there's any point having (2) here unless you're allowing for
consolidation transactions (two or more vault inputs spending to a single
output that's the same vault), which you've dismissed as a party trick.

> Another would be:
> 1. normal key can send to P2WPKH(master)
> 2. OR normal key can send to P2WPKH(normal key) after a delay.

I don't think there's any meaningful difference here between (2) here
and (3) above -- after the delay, you post one transaction spending
to p2wpkh(normal) signed by the normal key, then immediately post a
second transaction spending that new output, which is also signed with
the normal key, so you've just found a way of saying "normal key can do
anything else after a delay" that takes up more blockspace.

Both these approaches mirror the model that kanzure posted about in 2018
[0] (which can already be done via presigned transactions) and they share
the same fundamental flaw [1], namely that once someone compromises the
"normal key", all they have to do is wait for the legitimate owner to
trigger a spend, at which point they can steal the funds by racing the
owner, with the owner having no recourse beyond burning most of the
vault's funds to fees.

(I think the above two variants are meaningfully worse than kanzure's
in that someone with the normal key just needs to wait for the vault
utxo to age, at which point they can steal the funds immediately. In
kanzure's model, you first need to broadcast a trigger transaction,
then wait for it to age before funds can be stolen, which isn't the
greatest protection, but it at least adds some difficulty)

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017229.html
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017231.html
    also, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020284.html

If you don't mind that flaw, you can setup a vault along the lines of
kanzure's design with BIP 345 fairly simply:

  A: ipk=master,
     tapscript=<normal> SWAP OVER CHECKSIGVERIFY 1 "CHECKSIGVERIFY 144 CSV" OP_VAULT
       (witness values: <revault-amt> <revault-idx> <spend-idx> <sig>)

  B: ipk=master
     tapscript=<normal> CHECKSIGVERIFY 144 CSV

You put funds into the vault by creating a utxo with address "A", at which
point you can do anything with the funds via the master key, or you can
trigger an unvault via the normal key, moving funds to address "B", which
then has a 144 block delay before it can be spent via the normal key.

That also natively supports vault spends that only include part of the
vault value, or that combine two or more (compatible) vaults into a
single payment.

To avoid the flaw, you need to precommit to the spend that you're
authorising, while still allowing clawback/recovery by the owner. One
way to make that work with BIP 345 is using BIP 119's CTV to force a
precommitment to the spend:

  A: ipk=master,
     tapscript=<masterspkhash> OP_VAULT_RECOVER
     tapscript=<normal> CHECKSIGVERIFY 1 "CTV DROP 144 CSV" OP_VAULT
       (witness values: <revault-amt> <revault-idx> <spend-idx> <spendcommit> <sig>)

  B: ipk=master
     tapscript=<masterspkhash> OP_VAULT_RECOVER
     tapscript=<spendcommit> CTV DROP 144 CSV

Once you have funds in the vault in address A, you can spend them directly
via a key path spend with the master private key, or you can make
them only spendable via the master key via the OP_VAULT_RECOVER path,
or you can do a precommitted spend via the OP_VAULT path by including
"spendcommit", the CTV hash of where you want to send funds to. That
moves funds into address B, which again can be recovered to the master
key via the first two paths, or after a day you can use the CTV path to
complete the vault withdrawal.

Again, that natively supports vault spends that only include part of
the vault value, or that combine two or more (compatible) vaults into
a single payment.

> Oh, oracles like this are the first CSFS use case I've heard of that
> doesn't seem like abusing signatures to do hashing; nice!
>
> (Seems like there should be a way to do this without CSFS, but I can't
> see it...)

It's not really a novel observation: oracles are the third item listed
on the optech topic page for CSFS [2]...

The scriptless way of getting similar functionality is via discreet
log contracts [3], where the oracle with public key P, picks an event,
publishes a unique (hardened) public key R for that event, and when
the outcome of the event (m) is known, publishes 's' such that sG = R +
H(R,P,m)*P, so that (R,s) is a valid BIP 340 schnorr signature for
message m and pubkey P. That can then be used via an adaptor signature
eg to make on-chain contracts [4], eg.

[2] https://bitcoinops.org/en/topics/op_checksigfromstack/

[3] https://www.dlc.wiki/
    https://bitcoinops.org/en/topics/discreet-log-contracts/

[4] https://suredbits.com/category/discreet-log-contracts/
    https://atomic.finance/blog/discreet-log-contracts/

Cheers,
aj