From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id EDEC6C0011 for ; Wed, 16 Feb 2022 20:36:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id CDF1F83E4B for ; Wed, 16 Feb 2022 20:36:24 +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 e8klL0tUXDY4 for ; Wed, 16 Feb 2022 20:36:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by smtp1.osuosl.org (Postfix) with ESMTPS id EED3283E4A for ; Wed, 16 Feb 2022 20:36:23 +0000 (UTC) Received: by mail-ej1-x62d.google.com with SMTP id gb39so1984894ejc.1 for ; Wed, 16 Feb 2022 12:36:23 -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=baXYUtudHNIkHDqDva+P9NYfj+RWGqKDqWA8lhkg1gs=; b=U9WhCqO6qxTkNKBEkdAj1SGttjokAYoJkBinYC++gj7ArttjB5hEn+ZCHTJ5A2isU3 VRlIHbLmdDcGzug4ObteJf7OmCY3duerCRecJsphTllhQDb6XO22I2TtOqsiE39L5Erd T/NSk5rblNMNDkVW2+8Y4RAIfT4caT9MLBfHyyWEVgfcrYJyNKUck98mRi2oaFr9rxc4 zOclUxwkYy/c5+OQR8xpKKZA3+Zy6y2Q+52PVQ3qQpNbmtR8+hBaxdaCrLKHNmYQamJF Eb88IwNy8VfkzJTI0IsyNYJh6KpHQbbUW/1ZnBUvylJTKtfdgu0p+RALG08AIxIh4QZ/ /CBg== 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=baXYUtudHNIkHDqDva+P9NYfj+RWGqKDqWA8lhkg1gs=; b=l/UY9JlhIMAaeqp7VHH+Kg9UIn8Zb59fqUn7KMx/UHXvi06R0NHRWdQN7wJ0ddYdiu Xq1vu2iPFILE3mlAEEJC+Am/vkyVueh44bMyWb1HIqKKFJWys3YZVmOfnB1zwFK/MDA1 AL2Qyrj57njiu587hG2Iwgl+pU7YqFBHrspmf0gqBZUUd63jtG+ps67pKK1EGZ074dsI KYo2/xzZRD7iRS5oZx2Pp5+nyKvHzpAqpIgzGDLZcxMo5gAymOvqeE6rRXGVgZBe7lEI HtLO1IvK6xlywpT0CBKuru1If7/XRvOPoFk2TTu+vzebFLuBgs0KcnQ9ZRYKFJyJS+2r M3kA== X-Gm-Message-State: AOAM533caIZXijbyrHy5s0Dd/3lg7j/KhAXhwb2+Nu65UOgz38tVCo3C 5D4k3kTX+Djc6jw9yMbeP3tvcasg6kIzkY/A8KanrXatlyY= X-Google-Smtp-Source: ABdhPJxFf5UFbRBMwhY/Ip3YOHxyB8San4w/Mfp9pJ44BALrXLpjl/5SVvon+DxfARDSw7Lli0/RXDd2tY+w40zL2x8= X-Received: by 2002:a17:906:80c7:b0:6cf:9c76:1404 with SMTP id a7-20020a17090680c700b006cf9c761404mr3631653ejx.207.1645043781852; Wed, 16 Feb 2022 12:36:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Billy Tetrud Date: Wed, 16 Feb 2022 14:36:04 -0600 Message-ID: To: "James O'Beirne" Content-Type: multipart/alternative; boundary="00000000000041e3be05d8289a8f" X-Mailman-Approved-At: Wed, 16 Feb 2022 20:41:08 +0000 Cc: Bitcoin Protocol Discussion 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 20:36:25 -0000 --00000000000041e3be05d8289a8f Content-Type: text/plain; charset="UTF-8" > the validity of a sponsor txn is "monotonically" true at any point after the inclusion of the sponsored txn in a block. Oh I see his point now. If sponsors were valid at any point in the future, not only would a utxo index be needed but an index of all transactions. Yeah, that wouldn't be good. And the solution of bounding the sponsor transaction to be valid in some window after the transaction is included doesn't solve the original point of making sponsor transactions never become invalid. Thanks for the clarification James, and good point Jeremy. On Wed, Feb 16, 2022 at 1:19 PM James O'Beirne wrote: > > 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. > --00000000000041e3be05d8289a8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0 the validity of a sponsor txn is "monotonically" true at any poin= t after the inclusion of the sponsored txn in a block.

O= h I see his point now. If sponsors=C2=A0were valid at any point in the futu= re, not only would a utxo index be needed but an index of all transactions.= Yeah, that wouldn't be good. And the solution of bounding the sponsor = transaction to be valid in some window after the transaction=C2=A0is includ= ed doesn't solve the original point of making sponsor transactions=C2= =A0never become invalid. Thanks for the clarification James, and good point= Jeremy.

On Wed, Feb 16, 2022 at 1:19 PM James O'Beirne <james.obeirne@gmail.com> wrot= e:
> What do you mean by monotone in the context of sp= onsor transactions?

I take this to mean that the validity of a spons= or txn is
"monotonically" true at any point after the inclusio= n 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 t= hat not already something nodes do?

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

The map of (txid -> transaction) for all time is a separa= te index that
must be enabled via the `-txindex=3D1` flag; it isn't = enabled by default
because it isn't required for consensus and its g= rowth is unbounded.

> > The current consensus threshold for tr= ansactions to become invalid
> > is a 100 block reorg
>
= > What do you mean by this? The only 100 block period I'm aware of i= s
> the coinbase cooldown period.

If there were a reorg deepe= r than 100 blocks, it would permanently
invalidate any transactions spen= ding the recently-matured coinbase
subsidy in any block between $new_reo= rg_tip and ($former_tip_height -
100). These invalidated spends would no= t be able to be reorganized
into a new replacement chain.

How thi= s differs in practice or principle from a "regular" double-spend<= br>via reorg I'll leave for another message. I'm not sure that I un= derstand
that myself. Personally I think if we hit a >100 block reorg= , we've got
bigger issues than coinbase invalidation.
--00000000000041e3be05d8289a8f--