Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9ACBBC0033; Sun, 20 Feb 2022 16:29:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 89974813BC; Sun, 20 Feb 2022 16:29: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 q02EpUmvAneR; Sun, 20 Feb 2022 16:29:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by smtp1.osuosl.org (Postfix) with ESMTPS id 78B5E81376; Sun, 20 Feb 2022 16:29:48 +0000 (UTC) Received: by mail-lj1-x22f.google.com with SMTP id e2so7926633ljq.12; Sun, 20 Feb 2022 08:29: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=FQ5Ht9zNc6ROFAM7V9ZrvPPAnGk9ISOQzdRbPn4uDFI=; b=VhipUlnytfT3x8zOhuntSTdV8F4mkCfq8hXs9DZmgecIpV/04Gnn/w7xBtPbtVDP5H zIf9MZFZ46xSYjS07vvM0H8+Av3fbdcu28jZJ0S7+zcp9swjwXMDVCUTDrbr1x0Mge3Y 7+3ZoOVrW/dK2+VDSwWBqlxzyGyNvoBJwMw8idZnP6NyFoCGJwsSSfzy/7hzLwnpbyrx 5lXHRqqMITToRU33ZcEYlMNK/HEzZavQgS1Coo27/r8CZMrI/woLUjIUEsa+USDAnTNa O/Eo4fabwDVY3LZ+JgaYwy4pDkXu1mvSEvYqGq4/2gLUnNoH1YQNtW2sTYa9dWgcQGji fouQ== 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=FQ5Ht9zNc6ROFAM7V9ZrvPPAnGk9ISOQzdRbPn4uDFI=; b=j7gIDpzGUl8Yt6lPdzz6SwWscNXHblG1WiB9dLVrTdfFnkBplutC2imJoK78dEtiVc i3muhMdkoYFHrUH9PccHb/ulQvQo8N9zY7sO42zkRZ6MVsnfhwvETKfpzrf/MpctsUFQ PUE3neWVEBi5CPX9VyqJaR4PkkiRJxcoGQD+xx93CzICZEWHkaS90pUOf25gNGBjRAwu RijHsQ305yzFUYYL3xi2ArqUpeO4mHlUgVozbZ5baFsntAbBC/YeH809hWFMRSaMo4eu JKe3t7ATIlArlLwYKcjURkSXq/J/WYI+jZK8atrpqbXCkke3AbfTKE8CX+ndaLpX8pfn AjOA== X-Gm-Message-State: AOAM533wUd8eSr2agrHtadpBnA69AuoMid4MxaWZxhrtVzDQVa3nOiDx wSWhNtMsrHJFa6ipXBzQxTeg/EGFDAMXm0f9CCBfhVqqQ2TQGA== X-Google-Smtp-Source: ABdhPJz7U3o35G9PcWNSXbMYJWCzcjXhYZ3mCp+kFHj+sm51zq/hYdgK3jDlvQWN0PcNsZE4exNOXBZ+WCrI7THfaHA= X-Received: by 2002:a2e:b16e:0:b0:23b:92f0:9191 with SMTP id a14-20020a2eb16e000000b0023b92f09191mr11418514ljm.57.1645374586386; Sun, 20 Feb 2022 08:29:46 -0800 (PST) MIME-Version: 1.0 References: <590cf52920040c9cf7517b219624bbb5@willtech.com.au> In-Reply-To: From: Jeremy Rubin Date: Sun, 20 Feb 2022 08:29:35 -0800 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="000000000000be7bc905d8759f3c" Cc: Bitcoin Protocol Discussion , 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:29:49 -0000 --000000000000be7bc905d8759f3c Content-Type: text/plain; charset="UTF-8" opt-in or explicit tagging of fee account is a bad design IMO. As pointed out by James O'Beirne in the other email, having an explicit key required means you have to pre-plan.... suppose you're building a vault meant to distribute funds over many years, do you really want a *specific* precommitted key you have to maintain? What happens to your ability to bump should it be compromised (which may be more likely if it's intended to be a hot-wallet function for bumping). Furthermore, it's quite often the case that someone might do a transaction that pays you that is low fee that you want to bump but they choose to opt-out... then what? It's better that you should always be able to fee bump. -- @JeremyRubin On Sun, Feb 20, 2022 at 6:24 AM ZmnSCPxj wrote: > Good morning DA, > > > > Agreed, you cannot rely on a replacement transaction would somehow > > invalidate a previous version of it, it has been spoken into the gossip > > and exists there in mempools somewhere if it does, there is no guarantee > > that anyone has ever heard of the replacement transaction as there is no > > consensus about either the previous version of the transaction or its > > replacement until one of them is mined and the block accepted. -DA. > > As I understand from the followup from Peter, the point is not "this > should never happen", rather the point is "this should not happen *more > often*." > > Regards, > ZmnSCPxj > --000000000000be7bc905d8759f3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
opt-in or explicit tagging of fee account is a bad design IMO.

As pointed= out by James O'Beirne in the other email, having an explicit key requi= red means you have to pre-plan.... suppose you're building a vault mean= t to distribute funds over many years, do you really want a *specific* prec= ommitted=C2=A0key you have to maintain? What happens to your ability to bum= p should it be compromised (which may be more likely if it's intended t= o be a hot-wallet function for bumping).
=
Furthermore, it's quite often th= e case that someone might do a transaction that pays you that is low fee th= at you want to bump but they choose to opt-out... then what? It's bette= r that you should always be able to fee bump.


<= div>


On Sun, Feb 20, = 2022 at 6:24 AM ZmnSCPxj <Zmn= SCPxj@protonmail.com> wrote:
Good morning = DA,


> Agreed, you cannot rely on a replacement transaction would somehow
> invalidate a previous version of it, it has been spoken into the gossi= p
> and exists there in mempools somewhere if it does, there is no guarant= ee
> that anyone has ever heard of the replacement transaction as there is = no
> consensus about either the previous version of the transaction or its<= br> > replacement until one of them is mined and the block accepted. -DA.
As I understand from the followup from Peter, the point is not "this s= hould never happen", rather the point is "this should not happen = *more often*."

Regards,
ZmnSCPxj
--000000000000be7bc905d8759f3c--