Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6395AC002A for ; Thu, 11 May 2023 13:13:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 2E4A083CCA for ; Thu, 11 May 2023 13:13:02 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 2E4A083CCA Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=WsAQPne5 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, T_REMOTE_IMAGE=0.01] autolearn=ham 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 ZRq-Gm1BmRnG for ; Thu, 11 May 2023 13:13:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 2283983F83 Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) by smtp1.osuosl.org (Postfix) with ESMTPS id 2283983F83 for ; Thu, 11 May 2023 13:13:01 +0000 (UTC) Received: by mail-oi1-x230.google.com with SMTP id 5614622812f47-3945180bef1so344166b6e.1 for ; Thu, 11 May 2023 06:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683810780; x=1686402780; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=B/YRIDioPr4WAiqhf5HQaopxJE1J0oWavxiXZBCpN+s=; b=WsAQPne5XCzurrEswiv9ohVsROSk5r7KQQZ/jutfy5KKqxCgAS6ca8KSxlwDHizeHJ 9/FipDdH0oPDGTo6ZnmskyWyfGto36Li5OnubnRRyiNgyyE3zTlZo1vuAOw/RQlEoB5f 4XyD4EJ7mKzACu2lgkJ5CabUov51n/0ja8SAQ31+f1k1Qab3WVTqHJcqywxNobzzrxJc 1MUHwZMDF8f23MafoWdJJPTileJ49dO/vcE800VqjTHzmFj6okZr9xj08wMKRo7yZv+m AYwkyr1CtfpiwsP9pST0a7RYkoJQzG6KRJVX1ahD6GY3XNdSpCgYcDIk3InUAua1uLJh bZRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683810780; x=1686402780; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=B/YRIDioPr4WAiqhf5HQaopxJE1J0oWavxiXZBCpN+s=; b=AwFIadgNqnzn7NiJcBw20Q5f0KCqWaZFyC9omo+/8XQn3KlX+EFHTzNiWl55z31EXA SHfmj36CpMHUIYEmpHBE5jShNKYIZRrPaYA7JDwAMkIPKz7s3IhDxyJKaG6XDMoOELQN LaCbD/sxkbiOMWg2LBUEN+3urcayakqs86ISYpuVe2uaCY4Ywynw+BnVBVemuUAWvvV3 Om9zFdB73RtW8j1mITxYBU4wFGNYj0u0O9dDRiOB6CyIoMIDvDgHiGOohPmyz6jWfKB3 gAj6oOv48aZ2yt+QXg4xSA8WO+55HMk+Ts89AR9vQYGDP7LGybzYFnygEvnb3eaDi4A2 O7Nw== X-Gm-Message-State: AC+VfDxJGPlh83GlZ7vOkwSjRModiksMFPsZgK9VMV0EJhH/EjWa3Nly Zxmhc/Ap8SUG/6/S/ouYLBt2rg4p2HUdYGhYJdmM42vRYn+Ltg== X-Google-Smtp-Source: ACHHUZ5b7E6N9MY8Vv5e+dQLNl9YrVdTszgez6kAbrSeO2C8DlcuuhKSBsR/8Z5nbpYoFPN2S9tcsigzsDXTfOniYzc= X-Received: by 2002:aca:1305:0:b0:394:1187:1184 with SMTP id e5-20020aca1305000000b0039411871184mr4257141oii.14.1683810778566; Thu, 11 May 2023 06:12:58 -0700 (PDT) MIME-Version: 1.0 From: Aleksandr Kwaskoff Date: Thu, 11 May 2023 15:12:22 +0200 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="00000000000053557705fb6abf51" X-Mailman-Approved-At: Thu, 11 May 2023 13:27:30 +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: Thu, 11 May 2023 13:13:02 -0000 --00000000000053557705fb6abf51 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable if we forget about backward compatibility and the impact of other types of transactions, then the following two options would be possible: a) allocate only up to 10% of the space in the block for non-standard transactions - then all senders of non-standard transactions will compete with each other and it's only 10% with other types of transactions. In the absence of non-standard transactions, all space of the block will be given to standard ones. And in the absence of standard transactions - all space of the block will be given to non-standard ones. If bitcoin-chain was created primarily for standard transactions, then such a model will have to be supported by the majority. b) change the architecture in such a way that the onchain ordinals transaction became much more expensive, which would force them to go to their own type of the LN - this would be a kind of justice, like the displacement of small transactions from the onchain to the LN happening already now --=20 Thank you, we will succeed! | Dzi=C4=99kujemy, uda nam si=C4=99! President of NGO FinTechAssociation | Prezes organizacji pozarz=C4=85dowej FinTechStowarzyszenie *Dipl.-Ing. *Aleksandr Kwaskoff Telegram t.me/kwaskoff Poland, Warsaw | Polska, Warszawa [image: --] President of NGO FinTechAssociation Aleksandr Kwaskoff [image: https://]about.me/kwaskoff --00000000000053557705fb6abf51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
if we forget about backward compatibility and the impact of oth= er types=20 of transactions, then the following two options would be possible:
a) allocate only up to 10% of the space in the block for non-standard=20 transactions - then all senders of non-standard transactions will=20 compete with each other and it's only 10% with other types of=20 transactions. In the absence of non-standard transactions, all space of=20 the block will be given to standard ones. And in the absence of standard transactions - all space of the block will be given to non-standard=20 ones. If bitcoin-chain was created primarily for standard transactions,=20 then such a model will have to be supported by the majority.
b)=20 change the architecture in such a way that the onchain ordinals=20 transaction became much more expensive, which would force them to go to=20 their own type of the LN - this would be a kind of justice, like the=20 displacement of small transactions from the onchain to the LN happening=20 already now


--

Thank you, we will succeed! | Dzi=C4=99kujemy, uda nam si=C4=99!

= President of NGO FinTechAssociation | Prezes organizacji pozarz=C4=85dowej = FinTechStowarzyszenie

Dipl.-Ing. Aleksandr Kwaskoff

Telegram t.me/kwaskoff

Poland, Warsaw | Polska, Warszawa

=C2=A0
<= /tr>



3D"--"
3D""
=C2=A0
President of NGO Fi= nTechAssociation

Aleksandr Kwaskoff
3D"https://"about.me/kwaskoff
=
--00000000000053557705fb6abf51--