From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 53834C002A for ; Wed, 10 May 2023 20:44:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 2539941498 for ; Wed, 10 May 2023 20:44:21 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 2539941498 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=b8bQLgDo 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 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 mC8NxHWKWoCU for ; Wed, 10 May 2023 20:44:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 47A3B409A9 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) by smtp4.osuosl.org (Postfix) with ESMTPS id 47A3B409A9 for ; Wed, 10 May 2023 20:44:19 +0000 (UTC) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-3f315712406so261739435e9.0 for ; Wed, 10 May 2023 13:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683751457; x=1686343457; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=78w51nIUNtrGdDZLG2sVWjQQG+cyJInkxW6+lvQ1hOk=; b=b8bQLgDogdv1QgeoAjY7WQxwaMf1qfUfwpDVK+TCYqqTOPQmllrq66vDk6b17VzRjT 58P4b16WWV/z2EQ4+VJx0+ZarYU55kWuTVtfHdt+annvDkVAceTEuN3YBmI81atw3TSN XRn1trmWrEiCF3fb6mWrIb6NH/7O89KhyYAavQ7q5vTcG1sprjLoyLs0mljl7K+M3eMm XOp0z/KFlk0vFiir9oGI6OilavKWPObvLso3efLiLNUIrGauUwgIOjeWgZ0nvumwjtZr ERSlTIJugLMH1z1Dzp5Guw76UpqFLa+G9YaZwf6ktanYMMpDBQeUrnQ0PZM9+qC+Xi/M KYCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683751457; x=1686343457; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=78w51nIUNtrGdDZLG2sVWjQQG+cyJInkxW6+lvQ1hOk=; b=Cb2bsHti5rgH2aa0gQzVIPZWdqMuhp2Kd9tdNG2suDYpRzRiU4PU37sFg7z9XSXuSK rCcl+t4FbV7ZNQRm77FGlqKNwl/hTJEzpqjBXaCGYnXgQwz8E51C21eKMppz07s0Q0Nd UHI167QaGhNnHhxiV8pae8Rp3cmKmYXB7awlqH0CIlhG/mutpG5i+jKx9+r6H7gmSx95 IO+1puV7/u6pJlHalCpsZZQw6DldOwti2HImUp0X7gQvSUw/DpMSBDCOzISmIieYIfQ9 tDd24IObhRCBcewHJO7Rk/jf/KgOdgXPjlICoMuwU2pPrwxj+l2fm+DIN9o+a+QIcfNp jqAg== X-Gm-Message-State: AC+VfDyVGf3QHq0gTPQkeDHFKo9KASY8N7UaYn6yD2R2GT1Fr68m1jQN wyfn+ZjWn/3kjDg9Hu4+31nz70Zv+xtF3zEzrJL9ALmAOE8= X-Google-Smtp-Source: ACHHUZ6uuc+iKuo3/2qj3DkFbHTtdqdtoM+sSlXny2EWcrtXWT5ektE47qiAqLAroA1WZdBCPf2NEPQYjoC37L4tZqs= X-Received: by 2002:a5d:4b0f:0:b0:2cf:e313:2860 with SMTP id v15-20020a5d4b0f000000b002cfe3132860mr11043978wrq.33.1683751457031; Wed, 10 May 2023 13:44:17 -0700 (PDT) MIME-Version: 1.0 References: <0aea4ec5-7d6a-f358-3c20-854001588031@dashjr.org> In-Reply-To: From: Keagan McClelland Date: Wed, 10 May 2023 16:44:05 -0400 Message-ID: To: Erik Aronesty , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000007c8cb605fb5cefe7" X-Mailman-Approved-At: Thu, 11 May 2023 11:56:59 +0000 Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes? 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, 10 May 2023 20:44:21 -0000 --0000000000007c8cb605fb5cefe7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Erik, I'm curious about what you believe to be "non-economic" txs. As far as I can tell, any transaction included in the blockchain is economically motivated by the very evidence of fees paid. That said, for the sake of argument if we assume that there exists a category of information that constitutes "non-economic" information, then so long as there is any variance in the way to express a single economic intention, there exists a vector for including "non-economic" information. I'll add beyond this that there must always be variance in the way to express the same intent because the signature data must be indistinguishable from entropy for Bitcoin's security to hold. Even if we eliminate small UTXOs, OP_RETURN, or whatever other vector of the day that is currently being used to propagate such "non-economic" information, we will always have the potential variance in the signature data to do so. The best you can hope for is to make such means so inefficient that the real cost-per-bit is expensive enough that there are fewer distinct use cases. However, this isn't enough to actually *prevent* the "spam". By increasing the cost-per-bit, it may limit it to only "non-economic" information of extremely high value (note the contradiction), it limits the number of use cases while also increasing the impact of the use cases that make it past that threshold. Thus, it isn't the impact of spam that is being reduced so much as it is reducing the number of distinct use cases that result in "spam". Perhaps this is enough to make spam more intermittent, and maybe on those grounds alone it could be worth it, but I doubt it. IMO the proper way to handle things like this isn't to introduce consensus or relay policy to incentivize the expansion of the chain weight these "non-economic" use cases require, but rather to reduce the necessary chain footprint of supposed "economically motivated" transactions, which incidentally is the entire point of all layered scaling tech. The current fees we are experiencing are still significantly lower than they need to be if Bitcoin is going to survive in a post-subsidy era. If our layered protocols can't survive the current fee environment, the answer is to fix the layered protocols. Food for thought. Stay Inspired, Keags On Tue, May 9, 2023 at 12:38=E2=80=AFPM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > >> > no data at all > > > exactly, which is why a relationship between "cpfp-inclusive outputs" and > "fees" makes sense. it's clear that's a good definition of dust, and no= t > too hard to get a working pr up for the network-layer. i get that your > node will still route. i get that it would break timestamps, indeed, it > would break all non-economic use cases if we made it a consensus change. > > but that's the point of the discussion. > > the question is whether breaking all non-economic use cases is the right > move, given the game-theory of what underpins bitcoin > > i'm sad (honestly) to say that it might be > > it may very well be that bitcoin *cannot* be a "global ledger of all > things" in order to remain useful and decentralized, and instead the > monetary use case must be it's only goal > > also, i'm not really advocating for this solution so much as i would like > a > > - rational conversation about the incentives > - whether this solution would be an effective enough barrier to keep most > non-economic tx off bitcoin > > obviously it's easy enough to evade if every non-economic user simply > keeps enough bitcoin around and sends it back to himself > > so maybe it's a useless idea? but maybe that's enough of a hassle to > stop people (it certainly breaks ordinals, since it can never be 1 sat) > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000007c8cb605fb5cefe7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Erik,

I'm curious about what you be= lieve to be "non-economic" txs. As far as I can tell, any transac= tion included in the blockchain is economically motivated by the very evide= nce of fees paid. That said, for the sake of argument if we assume that the= re exists a category of information that constitutes "non-economic&quo= t; information, then so long as there is any variance in the way to express= =C2=A0a single economic intention, there exists a vector for including &quo= t;non-economic" information. I'll add beyond this that there must = always be variance in the way to express the same intent because the signat= ure data must be indistinguishable from entropy for Bitcoin's security = to hold.

Even if we eliminate small UTXOs, OP_RETU= RN, or whatever other vector of the day that is currently being used to pro= pagate such "non-economic" information, we will always have the p= otential variance in the signature data to do so. The best you can hope for= is to make such means so inefficient that the real cost-per-bit is expensi= ve enough that there are fewer distinct use cases. However, this isn't = enough to actually prevent the "spam". By increasing the c= ost-per-bit, it may limit it to only "non-economic" information o= f extremely high value (note the contradiction), it limits the number of us= e cases while also increasing the impact of the use cases that make it past= that threshold. Thus, it isn't the impact of spam that is being reduce= d so much as it is reducing the number of distinct use cases that result in= "spam". Perhaps this is enough to make spam more intermittent, a= nd maybe on those grounds alone it could be worth it, but I doubt it.
=

IMO the proper way to handle things like this isn't= to introduce consensus or relay policy to incentivize the expansion of the= chain weight these "non-economic" use cases require, but rather = to reduce the necessary chain footprint of supposed "economically moti= vated" transactions, which incidentally is the entire point of all lay= ered scaling tech. The current fees we are experiencing are still significa= ntly lower than they need to be if Bitcoin is going to survive in a post-su= bsidy era. If our layered protocols can't survive the current fee envir= onment, the answer is to fix the layered protocols.

Food for thought.

Stay Inspired,
Keags=

On Tue, May 9, 2023 at 12:38=E2=80=AFPM Erik Aronesty via bitcoin-dev= <bitcoin-dev@l= ists.linuxfoundation.org> wrote:

> no data at all

exactly, which is why a relationship between "= cpfp-inclusive outputs" and "fees" makes sense.=C2=A0 =C2=A0= it's clear that's a good definition of dust, and not too hard to ge= t a working pr up for the network-layer.=C2=A0 =C2=A0i get that your node w= ill still route.=C2=A0 =C2=A0i get that it would break timestamps, indeed, = it would break all non-economic use cases if we made it a consensus change.=

but that's the point of the discussion.=C2=A0= =C2=A0

the question is whether breaking all non-e= conomic use cases is the right move, given the game-theory of what underpin= s bitcoin

i'm sad (honestly) to say that it mi= ght be

it may very well be that bitcoin *cannot* b= e a "global ledger of all things" in order to remain useful and d= ecentralized, and instead the monetary use case must be it's only goal<= /div>
=C2=A0
also, i'm not really advocating for this sol= ution so much as i would like a=C2=A0

- rational= =C2=A0conversation about the incentives=C2=A0
- whether this solu= tion would be an effective enough barrier to keep most non-economic tx off = bitcoin

obviously it's easy enough to evade if= every non-economic user simply keeps enough bitcoin around and sends it ba= ck to himself

so maybe it's a useless idea?=C2= =A0 =C2=A0but maybe that's enough of a hassle to stop people (it certai= nly breaks ordinals, since it can never be 1 sat)

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000007c8cb605fb5cefe7--