diff options
| author | vjudeu <vjudeu@gazeta.pl> | 2023-05-10 18:19:01 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-05-10 16:19:12 +0000 |
| commit | aae4c4dbb5af88b4b0282876c03d55d29e26cfd5 (patch) | |
| tree | f60ed8713929cf5cab2f07a4911d32e07d42af66 | |
| parent | 48f66af9785e2399942cb7acbc91e300830a9743 (diff) | |
| download | pi-bitcoindev-aae4c4dbb5af88b4b0282876c03d55d29e26cfd5.tar.gz pi-bitcoindev-aae4c4dbb5af88b4b0282876c03d55d29e26cfd5.zip | |
Re: [bitcoin-dev] tx max fee
| -rw-r--r-- | bc/5a900e011f1cb4f1161bc545e02b4a623dce2e | 127 |
1 files changed, 127 insertions, 0 deletions
diff --git a/bc/5a900e011f1cb4f1161bc545e02b4a623dce2e b/bc/5a900e011f1cb4f1161bc545e02b4a623dce2e new file mode 100644 index 000000000..3a9baa581 --- /dev/null +++ b/bc/5a900e011f1cb4f1161bc545e02b4a623dce2e @@ -0,0 +1,127 @@ +Return-Path: <vjudeu@gazeta.pl> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 76146C002A + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 10 May 2023 16:19:12 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id 435556144D + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 10 May 2023 16:19:12 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 435556144D +Authentication-Results: smtp3.osuosl.org; + dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl + header.a=rsa-sha256 header.s=2013 header.b=E0Ao6UX5 +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -0.7 +X-Spam-Level: +X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 + tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, + SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Received: from smtp3.osuosl.org ([127.0.0.1]) + by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 8HGwAgtFC4t9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 10 May 2023 16:19:11 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B4BCB610F8 +Received: from smtpa40.poczta.onet.pl (smtpa40.poczta.onet.pl [213.180.142.40]) + by smtp3.osuosl.org (Postfix) with ESMTPS id B4BCB610F8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 10 May 2023 16:19:10 +0000 (UTC) +Received: from pmq8v.m5r2.onet (pmq8v.m5r2.onet [10.174.35.145]) + by smtp.poczta.onet.pl (Onet) with ESMTP id 4QGgFg30GfzlhVZY; + Wed, 10 May 2023 18:19:03 +0200 (CEST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; + t=1683735543; bh=5ZtW/Dkwh1YF/LcuTkCfOeaccF0iub2yrPXHSHd0Kbc=; + h=From:To:Date:Subject:From; + b=E0Ao6UX50s4PsYO/81Iwt/Oc0JnH66pGznb/oM2PDuB72Jr5GRZH5WiWn1uefnn4S + YTxfcHpJ1w09JVg/e/96kwDh/YmfMKDH+St1qeR7eJbuL0skByZ3bN66EKxY0zRROM + B98Ih2/1MR1NIXH55EMCRm3jOSw17CWHi4w+lHf8= +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: quoted-printable +Received: from [5.173.248.149] by pmq8v.m5r2.onet via HTTP id ; + Wed, 10 May 2023 18:19:03 +0200 +From: vjudeu@gazeta.pl +X-Priority: 3 +To: Erik Aronesty <erik@q32.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Date: Wed, 10 May 2023 18:19:01 +0200 +Message-Id: <158873530-26c4ca5223c12fad28089c0ab56e9528@pmq8v.m5r2.onet> +X-Mailer: onet.poczta +X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.248.149;PL;2 +X-Mailman-Approved-At: Wed, 10 May 2023 16:51:14 +0000 +Subject: Re: [bitcoin-dev] tx max fee +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: Wed, 10 May 2023 16:19:12 -0000 + +> possible to change tx "max fee" to output amounts? + +Is it possible? Yes. Should we do that? My first thought was "maybe", but a= +fter thinking more about it, I would say "no", here is why: + +Starting point: 1 BTC on some output. +Current situation: A single transaction moving 0.99999000 BTC as fees, and = +creating 1000 satoshis as some output (I know, allowed dust values are lowe= +r and depend on address type, but let's say it is 1k sats to make things si= +mpler). + +And then, there is a room for other solutions, for example your rule, menti= +oned in other posts, like this one: https://lists.linuxfoundation.org/piper= +mail/bitcoin-dev/2023-May/021626.html + +> probably easier just to reject any transaction where the fee is higher th= +an the sum of the outputs + +Possible situation after introducing your proposal, step-by-step: + +1) Someone wants to move 1 BTC, and someone wants to pay 0.99999000 BTC as = +fees. Assuming your rules are on consensus level, the first transaction cre= +ates 0.5 BTC output and 0.5 BTC fee. +2) That person still wants to move 0.5 remaining BTC, and still is willing = +to pay 0.49999000 BTC as fees. Guess what will happen: you will see another= + transaction, creating 0.25 BTC output, and paying 0.25 BTC fee. +... +N) Your proposal replaced one transaction, consuming maybe one kilobyte, wi= +th a lot of transactions, doing exactly the same, but where fees are distri= +buted between many transactions. + +Before thinking about improving that system, consider one simple thing: is = +it possible to avoid "max fee rule", no matter in what way it will be defin= +ed? Because as shown above, the answer seems to be "yes", because you can a= +lways replace a single transaction moving 1 BTC as fees with multiple trans= +actions, each paying one satoshi per virtual byte, and then instead of cons= +uming around one kilobyte, it would consume around 1 MvB per 0.01 BTC, so 1= +00 MvB per 1 BTC mentioned in the example above. + + + +On 2023-05-08 13:55:18 user Erik Aronesty via bitcoin-dev <bitcoin-dev@list= +s.linuxfoundation.org> wrote: +possible to change tx "max fee"=C2=A0 to output amounts? + + +seems like the only use case that would support such a tx is spam/dos type = +stuff that satoshi warned about + + +its not a fix for everything, but it seems could help a bit with certain at= +tacks=C2=A0 + + + + |