diff options
| author | Erik Aronesty <erik@q32.com> | 2023-05-09 12:32:09 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-05-09 16:32:21 +0000 |
| commit | d578203ac3e44e05493fd84f5da02da60e3b3622 (patch) | |
| tree | 17302ae635458a579fc63892b7e09dc8edc34fb4 | |
| parent | 093e5c0ea8f76174c407d8adceb25a10eddc82e2 (diff) | |
| download | pi-bitcoindev-d578203ac3e44e05493fd84f5da02da60e3b3622.tar.gz pi-bitcoindev-d578203ac3e44e05493fd84f5da02da60e3b3622.zip | |
Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
| -rw-r--r-- | e5/734bd9f84f46c945dc04f7698280741d1882a2 | 166 |
1 files changed, 166 insertions, 0 deletions
diff --git a/e5/734bd9f84f46c945dc04f7698280741d1882a2 b/e5/734bd9f84f46c945dc04f7698280741d1882a2 new file mode 100644 index 000000000..f3571bea5 --- /dev/null +++ b/e5/734bd9f84f46c945dc04f7698280741d1882a2 @@ -0,0 +1,166 @@ +Return-Path: <earonesty@gmail.com> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id DCA0BC002A + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 9 May 2023 16:32:21 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id AFCB28462D + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 9 May 2023 16:32:21 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org AFCB28462D +Authentication-Results: smtp1.osuosl.org; + dkim=pass (2048-bit key) header.d=q32-com.20221208.gappssmtp.com + header.i=@q32-com.20221208.gappssmtp.com header.a=rsa-sha256 + header.s=20221208 header.b=uYA1zARD +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.399 +X-Spam-Level: +X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, + HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, + RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] + autolearn=no autolearn_force=no +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 aGHbgLze4hCl + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 9 May 2023 16:32:21 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org CD76C8462A +Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com + [IPv6:2607:f8b0:4864:20::112f]) + by smtp1.osuosl.org (Postfix) with ESMTPS id CD76C8462A + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 9 May 2023 16:32:20 +0000 (UTC) +Received: by mail-yw1-x112f.google.com with SMTP id + 00721157ae682-54f9e2d0714so8289287b3.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 09 May 2023 09:32:20 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=q32-com.20221208.gappssmtp.com; s=20221208; t=1683649939; x=1686241939; + h=cc:to:subject:message-id:date:from:in-reply-to:references + :mime-version:from:to:cc:subject:date:message-id:reply-to; + bh=OcyRiMqAx00A/yT89kc4gae8SKZitwV1npcKj3EACeU=; + b=uYA1zARD49AUCFYtNAgegwzK7N2rTKhetN/JEysP8g+u7N0IkGfqUBiEVYOp3gnnW0 + 9+/gbT4Cu9DC/aU8U6URhWsyxE4duBN/xm+2qNite+UsCIIHJJprX+7aQm1oHt3VctEV + Jf0gVoJcaAZNkpFOESzOFVbkEN8egEMHbc8nRZl5TbgPulJZI9Xl2ckPhMW6SydPBuI1 + BVD+6D7Ps42V0jfhW/sidFwCsgWEifEuXDhSs9B5fst5UGoWVgM5aZuInvIxhVqfh8jb + 8E2cfnruKEK6Gf9OM/wPDiun4Wu88If7pu7despcah05L1EodOTAXIkFa8zVo1K32iFy + fcAg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20221208; t=1683649939; x=1686241939; + h=cc: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=OcyRiMqAx00A/yT89kc4gae8SKZitwV1npcKj3EACeU=; + b=d13akA4jGCrJyMsFWJCIe10oDteEoR4yzLijBkBEC519DVWbbqXJrQKQbS2RBSrf4j + mbsi/0wj3rk9Qzu+FD7TV62uP9seFE588H4wJUK32N243WjYqVjn+gKiPri9ScG+Enkj + 3p43eU+dR6NTsGH0G6GMB0YOaJibmADYXyIZePfygJOuHmuzbSMnw7tPA5kZi6CFg+fG + joMDWVLtbFnkwErgqlDguHD4eKLvxiWaX2KpWa6yX66S2x3SioYnXlR/NAlhdkMrgKns + uOYAlHdIE0ydnSKFwRm2Fprr92nWoarX4uJc1dlOqazYWWjVgGE+6/Z6Pvf7DNZLFYSx + Ao+A== +X-Gm-Message-State: AC+VfDzoQlIEWElc0oWY8+u+ee0JyP37zFykF7AiVeNnpfvf07WJzXsF + hxwSUpFnoXm88yetk9Y4i5ujeTN39qoHWtAsdsm791g= +X-Google-Smtp-Source: ACHHUZ6Xpr+vmh0s5X8GA/s0pWBxHbrgS8YSANBTgKbbZ1BhDCdjoLojH7N5tYEBYfVUL216mRl7msa3xKv+RdwKDqk= +X-Received: by 2002:a25:aac3:0:b0:b9e:76b4:df36 with SMTP id + t61-20020a25aac3000000b00b9e76b4df36mr14173324ybi.5.1683649939589; Tue, 09 + May 2023 09:32:19 -0700 (PDT) +MIME-Version: 1.0 +References: <Lm_5F74G9G21ydrFPovvmtHWpNXcbVzZibmU80oNqFRehJjcll89-t7OXqS5Fooe0cTNxGreIREMql3Li2xUCe2T5NVyss3-CrLzISO09HY=@notatether.com> + <0aea4ec5-7d6a-f358-3c20-854001588031@dashjr.org> + <ZFmNq6NzH4ruDsER@petertodd.org> +In-Reply-To: <ZFmNq6NzH4ruDsER@petertodd.org> +From: Erik Aronesty <erik@q32.com> +Date: Tue, 9 May 2023 12:32:09 -0400 +Message-ID: <CAJowKgLJ5WSVBKPzWEiZFUcB1jZG2PWBNMyMXRdHXaZdAsHeoQ@mail.gmail.com> +To: Peter Todd <pete@petertodd.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="00000000000093525f05fb454c1e" +X-Mailman-Approved-At: Tue, 09 May 2023 16:37:54 +0000 +Cc: Ali Sherief <ali@notatether.com> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Tue, 09 May 2023 16:32:22 -0000 + +--00000000000093525f05fb454c1e +Content-Type: text/plain; charset="UTF-8" + +> +> +> > 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 not +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) + +--00000000000093525f05fb454c1e +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot= +e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)= +;padding-left:1ex"><br>> no data at all</blockquote><div><br></div><div>= +exactly, which is why a relationship between "cpfp-inclusive outputs&q= +uot; and "fees" makes sense.=C2=A0 =C2=A0it's clear that'= +s a good definition of dust, and not too hard to get a working pr up for th= +e network-layer.=C2=A0 =C2=A0i get that your node will 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.</div><div><br></div><d= +iv>but that's the point of the discussion.=C2=A0 =C2=A0</div><div><br><= +/div><div>the question is whether breaking all non-economic use cases is th= +e right move, given the game-theory of what underpins bitcoin</div><div><br= +></div><div>i'm sad (honestly) to say that it might be</div><div><br></= +div><div>it may very well be that bitcoin *cannot* be a "global ledger= + of all things" in order to remain useful and decentralized, and inste= +ad the monetary use case must be it's only goal</div><div>=C2=A0</div><= +div>also, i'm not really advocating for this solution so much as i woul= +d like a=C2=A0</div><div><br></div><div>- rational=C2=A0conversation about = +the incentives=C2=A0</div><div>- whether this solution would be an effectiv= +e enough barrier to keep most non-economic tx off bitcoin</div><div><br></d= +iv><div>obviously it's easy enough to evade if every non-economic user = +simply keeps enough bitcoin around and sends it back to himself</div><div><= +br></div><div>so maybe it's a useless idea?=C2=A0 =C2=A0but maybe that&= +#39;s enough of a hassle to stop people (it certainly breaks ordinals, sinc= +e it can never be 1 sat)</div><div><br></div></div></div> + +--00000000000093525f05fb454c1e-- + |