Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0DA65C0033; Sun, 20 Feb 2022 16:45:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id DADE981462; Sun, 20 Feb 2022 16:45:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QKF2KGmJP2h; Sun, 20 Feb 2022 16:45:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by smtp1.osuosl.org (Postfix) with ESMTPS id 0238181451; Sun, 20 Feb 2022 16:45:48 +0000 (UTC) Received: by mail-lf1-x134.google.com with SMTP id b11so14353033lfb.12; Sun, 20 Feb 2022 08:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9ypqYFq6n1M/1lSZR7uAC8tCwVIoardhol8QV6hpE+g=; b=Ttq23W6nz/8H1QHAL5xgt4d2P7QcxHwU7hrqsHN6sMR1Yozzao5lmCpjUpDc0wFMRe zpClEUPVRkv6DyG6pltCN7VD3/j1LEJRWPWBxmtId+9M0d4q3PXB/0MF79f5ZQyOSMTz ZhhO65E75qF3G/TeSpuEPsoa5X/R5gLlSE5lg1Sb/oDh79vBQeTOWyU7dHfAtIHNiQEB LGadDSMSvtgIsRMvebqmiVVjqEfWbL9fP8BULszrBCEo1m2x4o3ZuOlO/AyqyjedcoYv W7wKQIoRV4/dSvOMt0u5UayJ52mgWG/UZbYmLsUt0pXmYBikpqGq7qzCCnYDEzyEX1SS 3A+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9ypqYFq6n1M/1lSZR7uAC8tCwVIoardhol8QV6hpE+g=; b=A6ku8O15Sc4i5JApLzk4JYddqMJ9l47YHnFJ6FNnSXDsVVThh7wvxSYx6TPbqyyM6+ cCdBdbeMVkPYS356Tmw3AXbYXX8sEyKTyHuFIhqQjk0GskiFlMjDoR5F17DUR5+X4Fz8 KdKfXEGhcHGR52flNEFVoEOJ1gBFvb/8nO3UCeMXnAHiTdljehRulkrfpdIYVoMg8Vc/ gmBs+N9NYA8ZC+BfJX/AuNR/Y5c0eTSq87sB53/OKp0q+1twA1rm/FnLXFlE7abK4G87 /LM9KyHuDNeRNC4nuHcFT21zLoE10AaleepZ8nurcMPWJSw5yiRL78YivrMHaYvpMbqT DrIA== X-Gm-Message-State: AOAM531NFDHOcrnQlbNw0DtAnEepACJqHJx8ZEYdnEnFUyk9LcqkbB0I 1vAS367GXW3IdWrB6HKBBpQ8aAaujVBYCE1opYU= X-Google-Smtp-Source: ABdhPJyTg2xlETejbZOb0OSHDxMJpKYTZR3NUYXB2BkWi+TgczYIwa4P+OzsnAPyW4xyqu7iA6kNZfZ6Ry/nPvLQwhI= X-Received: by 2002:ac2:539b:0:b0:443:db38:ac87 with SMTP id g27-20020ac2539b000000b00443db38ac87mr3632895lfh.247.1645375546901; Sun, 20 Feb 2022 08:45:46 -0800 (PST) MIME-Version: 1.0 References: <590cf52920040c9cf7517b219624bbb5@willtech.com.au> In-Reply-To: From: Jeremy Rubin Date: Sun, 20 Feb 2022 08:45:35 -0800 Message-ID: To: ZmnSCPxj , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000fec68105d875d8bb" Cc: lightning-dev Subject: Re: [bitcoin-dev] [Lightning-dev] [Pre-BIP] Fee Accounts X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2022 16:45:50 -0000 --000000000000fec68105d875d8bb Content-Type: text/plain; charset="UTF-8" Morning! > > For the latter case, CPFP would work and already exists. > **Unless** you are doing something complicated and offchain-y and involves > relative locktimes, of course. > > The "usual" design I recommend for Vaults contains something that is like: { CSV CHECKSIG, CHECKSIG} or { CSV CHECKSIG, CHECKSIG)> CTV} where after an output is created, it has to hit maturity before hot spendable but can be kicked to recovery any time before (optional: use CTV to actually transition on chain removing hot wallet, if cold key is hard to access). Not that this means if you're waiting for one of these outputs to be created on chain, you cannot spend from the hot key since it needs to confirm on chain first. Spending from the cold key for CPFP'ing the hot is an 'invalid move' (emergency key for non emergency sitch) Thus in order to CPFP, you would need a separate output just for CPFPing that is not subject to these restrictions, or some sort of RBF-able addable input/output. Or, Sponsors. Jeremy --000000000000fec68105d875d8bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Morning!

For the latter case, CPFP would work and already exists.
**Unless** you are doing something complicated and offchain-y and involves = relative locktimes, of course.


The "usual" design I recommend for Vau= lts contains something that is like:

{<maturity> CSV <pk_hot> CHECKSIG, <pk_cold> CH= ECKSIG}
or
{<maturity= > CSV <pk_hot> CHECKSIG, <H(tx to: <pk_cold> CHECKSIG)>= ; CTV}

=
where after an output is created, it has t= o hit maturity before hot spendable but can be kicked to recovery any time = before (optional: use CTV to actually transition on chain removing hot wall= et, if cold key is hard to access).


Not that this means if you'r= e waiting for one of these outputs to be created on chain, you cannot spend= from the hot key since it needs to confirm on chain first. Spending from t= he cold key for CPFP'ing the hot is an 'invalid move' (emergenc= y key for non emergency sitch)

Thus in order to CPFP, you would need a separate output just for C= PFPing that is not subject to these restrictions, or some sort of RBF-able = addable input/output. Or, Sponsors.


Jeremy
<= br>
--000000000000fec68105d875d8bb--