Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id D0978C000B for ; Wed, 16 Feb 2022 19:19:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id B8A94408A1 for ; Wed, 16 Feb 2022 19:19:00 +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: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gMbCI0rrAQd1 for ; Wed, 16 Feb 2022 19:19:00 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) by smtp4.osuosl.org (Postfix) with ESMTPS id F216E41677 for ; Wed, 16 Feb 2022 19:18:59 +0000 (UTC) Received: by mail-yb1-xb2b.google.com with SMTP id bt13so8270730ybb.2 for ; Wed, 16 Feb 2022 11:18:59 -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=6Ys/HnIWKvesQnNG8Hz8tTjvgZsEJ0W2ri+W+1xYR1U=; b=RfWe2+76a/OzAU8lJ+fUiPClCzIY1gq+l048H8yx0hmKLbSoOcoBlh8UxA6BTjGsW5 ryAU9lXUdBOwGRWQg113bUeffiBIi85ympSM5JsDcwjklg1pTvpqyOmazqzkYWk5PWv0 7AxeqKdS428RceJX2I8XFRtyRLjvc0xpcpVeCPFUsZq/1xkKHR7NpKf+aHf1uh4W2R1c 08IjIHNUxsRHA2blPiRb5Ih1bEPquSaw7J7QQ3uXanF4+GtvMZXGHpzfEO1AZMhq6uLR aVBDPXovo6usmnjAIHATZCrusmLkdTkWFmc1bK/9p6grn70phlDLt5t/KZlDu0bTVEXr pJ0g== 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=6Ys/HnIWKvesQnNG8Hz8tTjvgZsEJ0W2ri+W+1xYR1U=; b=QUfWaV7YU2vGw43sYoJCon1DgTAxNlLbRAMAPO0Czrv+0tN120KADpYGbWnm32ykP1 sDEF5DfurhT5Jbz5p6zsxbSjDJe6cqxmYLUPrsgq1A3IVLgdJcOluZKNaO+81qMl/94j NypJcic3Up2Po9B8X94jH5UJVJSTBUV9HgfdqheaviswNwGusPvMJOFIWGrRSK0QHKgp PG1ZqyxR/CPu6IuNFJKnJU6sZfSsdmSBBiKkKrCv2nvTvL9vNcdVTPV+Xs3dgg5Zyg+m uz4CpIWgJJxiGLbPmrMDxZs6VyeZxExOisIfLVRU81+fGFeWITtkGj6/Rc7shtnXiH8X pirA== X-Gm-Message-State: AOAM531xr9yJMSH5Lu7mchX2YQq1l0I5OqNIe9jPNfh7du82qLDnPBn8 sE5lB1gVj9r1gDszekP1QZ9KQh4jvpRldsfWe1s= X-Google-Smtp-Source: ABdhPJxHqJi19ySdXtCQNZtFlT7e9yYb8/gwuSHTuC6XxJAEME76pOtMicDyucUnzFKQ7sUPquX2GW38rk2LB4QvceI= X-Received: by 2002:a25:76d1:0:b0:622:6d1c:ab0e with SMTP id r200-20020a2576d1000000b006226d1cab0emr3758214ybc.680.1645039138850; Wed, 16 Feb 2022 11:18:58 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "James O'Beirne" Date: Wed, 16 Feb 2022 14:18:47 -0500 Message-ID: To: Billy Tetrud , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000834f3505d82785b9" 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: Wed, 16 Feb 2022 19:19:00 -0000 --000000000000834f3505d82785b9 Content-Type: text/plain; charset="UTF-8" > What do you mean by monotone in the context of sponsor transactions? I take this to mean that the validity of a sponsor txn is "monotonically" true at any point after the inclusion of the sponsored txn in a block. > And when you say tx-index, do you mean an index for looking up a > transaction by its ID? Is that not already something nodes do? Indeed, not all nodes have this ability. Each bitcoind node has a map of unspent coins which can be referenced by outpoint i.e.(txid, index), but the same isn't true for all historical transactions. I (embarrassingly) forgot this in the prior post. The map of (txid -> transaction) for all time is a separate index that must be enabled via the `-txindex=1` flag; it isn't enabled by default because it isn't required for consensus and its growth is unbounded. > > The current consensus threshold for transactions to become invalid > > is a 100 block reorg > > What do you mean by this? The only 100 block period I'm aware of is > the coinbase cooldown period. If there were a reorg deeper than 100 blocks, it would permanently invalidate any transactions spending the recently-matured coinbase subsidy in any block between $new_reorg_tip and ($former_tip_height - 100). These invalidated spends would not be able to be reorganized into a new replacement chain. How this differs in practice or principle from a "regular" double-spend via reorg I'll leave for another message. I'm not sure that I understand that myself. Personally I think if we hit a >100 block reorg, we've got bigger issues than coinbase invalidation. --000000000000834f3505d82785b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> What do you mean by monotone in the = context of sponsor transactions?

I take this to mean that the validi= ty of a sponsor txn is
"monotonically" true at any point after= the inclusion of the sponsored
txn in a block.

> And when you= say tx-index, do you mean an index for looking up a
> transaction by= its ID? Is that not already something nodes do?

Indeed, not all no= des have this ability. Each bitcoind node has a map
of unspent coins whi= ch can be referenced by outpoint i.e.(txid, index),
but the same isn'= ;t true for all historical transactions. I
(embarrassingly) forgot this= in the prior post.

The map of (txid -> transaction) for all tim= e is a separate index that
must be enabled via the `-txindex=3D1` flag; = it isn't enabled by default
because it isn't required for consen= sus and its growth is unbounded.

> > The current consensus thr= eshold for transactions to become invalid
> > is a 100 block reorg=
>
> What do you mean by this? The only 100 block period I'= ;m aware of is
> the coinbase cooldown period.

If there were = a reorg deeper than 100 blocks, it would permanently
invalidate any tran= sactions spending the recently-matured coinbase
subsidy in any block bet= ween $new_reorg_tip and ($former_tip_height -
100). These invalidated sp= ends would not be able to be reorganized
into a new replacement chain.
How this differs in practice or principle from a "regular" = double-spend
via reorg I'll leave for another message. I'm not s= ure that I understand
that myself. Personally I think if we hit a >10= 0 block reorg, we've got
bigger issues than coinbase invalidation.
--000000000000834f3505d82785b9--