From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4C58FC000B for ; Tue, 15 Feb 2022 20:24:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 8BE2440236 for ; Tue, 15 Feb 2022 20:24:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=blockstream-com.20210112.gappssmtp.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AY6W9zxbOZ-F for ; Tue, 15 Feb 2022 20:24:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) by smtp2.osuosl.org (Postfix) with ESMTPS id 610A04017C for ; Tue, 15 Feb 2022 20:24:42 +0000 (UTC) Received: by mail-qt1-x830.google.com with SMTP id x5so19708155qtw.10 for ; Tue, 15 Feb 2022 12:24:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=KYPQbQ4/9Lc6PwiEGam7jTTxXNUPMmDY2Zk/vt4Eq84=; b=vNoD9WaRJFYzosxnrzXfPHS+TIuuQm3oCLEEEUjRK5mVxoXTKDKpXucyOykuzc0+ee jmcfIOj3b5DCoeM0W/eyoPOripki5crYZ53rX8hgMNLpMZ7SFOIvtdngh1Q7uxg5pgSx +iK9mcliZ1Smzrd92tskvBR5iKem7r9TgUUMP+5V09z3uCDxrtG146UD3mwI03StxY44 2YTvH8C3+7JAk5ZX9QN9nQfhB8gBVKJf2qJGvpctslE2vjSFe5Ur5Gu4OIWDvCGHMD4I /lI4aAOqOk1DQ9afKlNqQEeTbUNlazx18nQ3oc1rz6Pcsc1IOH26UH7822ygWo3qVlss CQOg== 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; bh=KYPQbQ4/9Lc6PwiEGam7jTTxXNUPMmDY2Zk/vt4Eq84=; b=mUqQosRS7Vn4KPLYqpBZ7D+ghH6f0cwfUKp/YWDESfaS7Gf6pFfngaTN9Zw2SSFeqn dZEUFFKRSpxsBUG4KB23Wi99teFPFd5JomzkbDfRUSrYYBi8f7lLb5xluHXB7ndFMxA6 3Bit4Ymcabac5nd2aWjyIt8ywydtbO04/gzUIeF41Y6WNeQsoAOKbJX66JawtFsK8N5j T9EVqYDUXey+q7uY5dcPiaoX3pIEkg6EHCmbO61v8D9Q03JnKbo3aBoR9CM6YPg5NK30 mkmR5LVS/EgfEWujsihzAawJBIsnPBTtdMAqGaRKKst9WkT01hXphNv90NDBAQNGE5/J eKyA== X-Gm-Message-State: AOAM533PRDaV2264tNzQ+1X8DhorsdOAPIb2r4kyTHSWbOLJo4NCynd9 jE1uvD7AjagRMtZCC9BFatbzfxXEiejHx9M+wmZB1z5c2qQ= X-Google-Smtp-Source: ABdhPJwcJT/e3Lw56qPx1VCSWVM5ARVi+WN82um7rhVwEFr2fx3r5zXnoAW5zFS+VacVUxAKf7IYMjHcOrodf8FMeBs= X-Received: by 2002:a05:622a:5ce:: with SMTP id d14mr690727qtb.642.1644956681096; Tue, 15 Feb 2022 12:24:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Russell O'Connor" Date: Tue, 15 Feb 2022 15:24:29 -0500 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000a5e02b05d81452ae" Subject: Re: [bitcoin-dev] Thoughts on fee bumping 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: Tue, 15 Feb 2022 20:24:44 -0000 --000000000000a5e02b05d81452ae Content-Type: text/plain; charset="UTF-8" > >> 2. (from Suhas) "once a valid transaction is created, it should not > become invalid later on unless the inputs are double-spent." > > This doesn't seem like a huge concern to me > > I agree that this shouldn't be a concern. In fact, I've asked numerous > people in numerous places what practical downside there is to transactions > that become invalid, and I've heard basically radio silence other than one > off hand remark by satoshi at the dawn of time which didn't seem to me to > have good reasoning. I haven't seen any downside whatsoever of transactions > that can become invalid for anyone waiting the standard 6 confirmations - > the reorg risks only exists for people not waiting for standard > finalization. So I don't think we should consider that aspect of a > sponsorship transaction that can only be mined with the transaction it > sponsors to be a problem unless a specific practical problem case can be > identified. Even if a significant such case was identified, an easy > solution would be to simply allow sponsorship transactions to be mined on > or after the sponsored transaction is mined. > The downside is that in a 6 block reorg any transaction that is moved past its expiration date becomes invalid and all its descendants become invalid too. The current consensus threshold for transactions to become invalid is a 100 block reorg, and I see no reason to change this threshold. I promise to personally build a wallet that always creates transactions on the verge of becoming invalid should anyone ever implement a feature that violates this tx validity principle. --000000000000a5e02b05d81452ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0
>> 2. (from= Suhas) "once a valid transaction is created, it should not become inv= alid later on unless the inputs are double-spent."
> This does= n't seem like a huge concern to me=C2=A0

I agree tha= t this shouldn't be a concern. In fact, I've asked numerous people = in numerous places what practical downside there is to transactions that be= come invalid, and I've heard basically radio silence other than one off= hand remark by satoshi at the dawn of time which didn't seem to me to = have good reasoning. I haven't seen any downside whatsoever of transact= ions that can become invalid for anyone waiting the standard 6 confirmation= s - the reorg risks only exists for people not waiting for standard finaliz= ation. So I don't think we should consider that aspect of a sponsorship= transaction that can only be mined with the transaction it sponsors to be = a problem unless a specific=C2=A0practical problem case can be identified. = Even if a significant such=C2=A0case was identified, an easy solution would= be to simply allow sponsorship transactions to be mined on or after the sp= onsored transaction is mined.

<= div>The downside is that in a 6 block reorg any transaction that is moved p= ast its expiration date becomes invalid and all its descendants become inva= lid too.

The current consensus threshold for t= ransactions to become invalid is a 100 block reorg, and I see no reason to = change this threshold.=C2=A0 I promise to personally build a wallet that al= ways creates transactions on the verge of becoming invalid should anyone ev= er implement a feature that violates this tx validity principle.
<= /div>
--000000000000a5e02b05d81452ae--