path: root/d0/db426e25d59fd2e4c34a0711c3e722747aa8e4

Return-Path: <andrew.baine@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 547C9C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 15:21:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 300FC847E9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 15:21:01 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 300FC847E9
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=oPIAyCJ7
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 smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 69GR2-uNnc1l
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 15:20:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org B514B84678
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [IPv6:2a00:1450:4864:20::629])
 by smtp1.osuosl.org (Postfix) with ESMTPS id B514B84678
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 15:20:56 +0000 (UTC)
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-96622bca286so1222110366b.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 08:20:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1683818455; x=1686410455;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=wdUzfmQzq+80MOrfAecXnFky4BgTE1cSW4tHN4wJSnc=;
 b=oPIAyCJ7L3l5VtWLljlgXxuuY0X5+yhHCJwtBT8WSZF4cLdr/Y8umaJ/xpCpfNjUqq
 miuUOrpP4fWfk7cGSVNq0i4gD4UuyJCIxAmNQFf+VGQc0dWfEs/NHU5qQAirQlpYA6n0
 z53WnpC/X0ES2ad82LUKVPITOn2PS932mOBH2GZ4uwImQDeYzHz+90wync9vfwtZP+xq
 9rzn8esvfEPdTlUG1WowW3w4VeB0gdGGbRUr1/NbWGT4TIJZq2b+4MD4kKpFspSnzr0U
 bu6/FykFa6hvSEJFbDQQYGSAr1neuAWxm6MBYw8Dl/JTp+io3MlMRk7+zJEuudgsa99v
 tMdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1683818455; x=1686410455;
 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=wdUzfmQzq+80MOrfAecXnFky4BgTE1cSW4tHN4wJSnc=;
 b=ekDVJRSI0mXrNsu5y9xRraaIm8pkMtkvpewFAFXOEXCTTFt5KGs1GZ5JLTTudDZ4QG
 oJ92GLa/0Qcrj/fhwML2aymq1+dWhqyZT/MXY/yVuiTqwx1TZBCXgbrF6AydV5JPFj8k
 o1N19xQTBwA4ddML1sABiDxqxW9yge/xY9CFqu9NbO9cW+XEJUcl5Rv9K73FMbuqRRSj
 0Ml4Y9CXnsZ/iYEWA5lz4S3mWWW7OIkRCqoL2nuPv0EHDGZyCEVqptoYl/n+nw7vIKUK
 XK4fWBl4QH/sekX5+ljpJDRDr5tUfF/CaNqtLLiY2i2pKJgN8bqzYhXoS8TVC2Op/V5K
 MLPw==
X-Gm-Message-State: AC+VfDzX/QupqpPSAZD0tC1namje7P+KJ7zhglboig00+I61DDolZBYN
 06JVUkT6jBoiiMVRMoYUEuVIHo/d6GhU8IvPXZjbW/WAt5YKqA==
X-Google-Smtp-Source: ACHHUZ4PwW+lTbSyh1ZhbpBk++cT28Pjr6JmzEfjGJ0GjvOH/m5T/t1rxFdpYT3qZCXnA1XlrMAGXCb8zqoB2THJPjY=
X-Received: by 2002:a17:907:9285:b0:966:484a:3350 with SMTP id
 bw5-20020a170907928500b00966484a3350mr12865649ejc.35.1683818454651; Thu, 11
 May 2023 08:20:54 -0700 (PDT)
MIME-Version: 1.0
References: <CAJowKgLx796AWaZAMOGVWFsT2LK8zvCvxiY-sv110gv1cewCwg@mail.gmail.com>
 <171698970-6184d5f773dee0589bf3373c44b9f21f@pmq2v.m5r2.onet>
 <CAPswA9wXFzXmkVvczidt=2Eah0dNgRHdMwgvT22m=m6ffPxb9w@mail.gmail.com>
In-Reply-To: <CAPswA9wXFzXmkVvczidt=2Eah0dNgRHdMwgvT22m=m6ffPxb9w@mail.gmail.com>
From: Andrew Baine <andrew.baine@gmail.com>
Date: Thu, 11 May 2023 11:20:43 -0400
Message-ID: <CAJxsMutH_QN8pEQFv0y8771goJWuP0ZJiV9fWZX_SH1kdTf6Cg@mail.gmail.com>
To: Kalle Rosenbaum <kalle@rosenbaum.se>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000db16a705fb6c883e"
X-Mailman-Approved-At: Thu, 11 May 2023 15:56:55 +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: Thu, 11 May 2023 15:21:01 -0000

--000000000000db16a705fb6c883e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Regardless of the submitter's rationale, it is easy to work around any rule
that denies mempool inclusion based on fee proportion: if you have plenty,
add inputs from your own wallet and return to yourself; if not, borrow them
and return to the lender, maybe with interest.

On Thu, May 11, 2023 at 9:27=E2=80=AFAM Kalle Rosenbaum via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Another use case for paying more fees than outputs is to incentivize
> honest mining when Bitcoin is under a state-level censorship attack.
> If it's really important to me that my transaction goes through, I
> might be willing to set a fee at 99x the output value. It's the only
> way bitcoin could work in an adversarial environment.
>
> /Kalle
>
> On Thu, 11 May 2023 at 13:55, vjudeu via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > confused.   the rule was "cannot pay a fee > sum of outputs with
> consideration of cpfp in the mempool"
> > > your example is of someone paying a fee "< sum"  which wouldn't be
> blocked
> >
> > Every transaction paying "fee > sum" can be replaced by N transactions
> paying "fee <=3D sum", where the sum of all fees will be the same. That
> means, someone will still do the same thing, but it will be just expanded
> into N transactions, so you will reach the same outcome, but splitted int=
o
> more transactions. That means, mempool will be even more congested, becau=
se
> for example instead of 1kB transaction with huge fee, you will see 100 su=
ch
> transactions with smaller fees, that will add to the same amount, but wil=
l
> just consume more space.
> >
> > > show me how someone could move 1 btc and pay 2 btc as fees...
> >
> > In the previous example, I explained how someone could move 1k sats and
> pay almost 1 BTC as fees. But again, assuming that you have 3 BTC, and yo=
u
> move 1 BTC with 2 BTC fee, that will be rejected by your rules if and onl=
y
> if that will be done in a single transaction. But hey, the same owner can
> prepare N transactions upfront, and release them all at the same time,
> Segwit makes it possible without worrying about malleability.
> >
> > So, instead of:
> >
> > 3 BTC -> 1 BTC
> >
> > You can see this:
> >
> > 3 BTC -> 2 BTC -> 1 BTC
> >
> > If that second transaction will not pass CPFP, more outputs could be
> used:
> >
> > +--------------------+--------------------+--------------------+
> > | 3.0 BTC -> 0.5 BTC | 0.5 BTC -> 0.5 BTC | 0.5 BTC -> 0.5 BTC |
> > |            0.5 BTC | 0.5 BTC    0.5 BTC | 0.5 BTC            |
> > |            0.5 BTC | 0.5 BTC            +--------------------+
> > |                    +--------------------+
> > |            0.5 BTC | 0.5 BTC -> 0.5 BTC |
> > |            0.5 BTC | 0.5 BTC            |
> > +--------------------+--------------------+
> >
> > As you can see, there are four transactions, each paying 0.5 BTC fee, s=
o
> the total fee is 2 BTC. However, even if you count it as CPFP, you will g=
et
> 1.5 BTC in fees for the third transaction in the chain. Note that more
> outputs could be used, or they could be wired a bit differently, and then
> if you will look at the last transaction, the sum of all fees from 10 or =
15
> transactions in that chain, could still pass your limits, but the whole
> tree will exceed that. If you have 1.5 BTC limit for that 3 BTC, then you
> could have 20 separate chains of transactions, each paying 0.1 BTC in fee=
s,
> and it will still sum up to 2 BTC.
> >
> > > the only way around it is to maintain balances and use change
> addresses.   which would force nft and timestamp users to maintain these
> balances and would be a deterrent
> >
> > Not really, because you can prepare all of those transactions upfront,
> as the part of your protocol, and release all of them at once. You don't
> have to maintain all UTXOs in between, you can create the whole transacti=
on
> tree first, sign it, and broadcast everything at once. More than that: if
> you have HD wallet, you only need to store a single key, and generate all
> addresses in-between on-the-fly, as needed. Or even use some algorithm to
> deterministically recreate the whole transaction tree.
> >
> >
> >
> > On 2023-05-10 19:42:49 user Erik Aronesty <erik@q32.com> wrote:
> > confused.   the rule was "cannot pay a fee > sum of outputs with
> consideration of cpfp in the mempool"
> >
> >
> > your example is of someone paying a fee "< sum"  which wouldn't be
> blocked
> >
> >
> > note: again, i'm not a fan of this, i like the discussion of "bitcoin a=
s
> money only" and using fee as a lever to do that
> >
> >
> > show me how someone could move 1 btc and pay 2 btc as fees... i think w=
e
> can block it at the network or even the consensus layer, and leave anythi=
ng
> but "non-monetary use cases" intact.   the only way around it is to
> maintain balances and use change addresses.   which would force nft and
> timestamp users to maintain these balances and would be a deterrent
> >
> >
> > im am much more in favor of doing something like op_ctv which allows
> many users to pool fees and essentially "share" a single utxo.
> > .
> >
> >
> >
> > On Wed, May 10, 2023 at 12:19=E2=80=AFPM <vjudeu@gazeta.pl> wrote:
> >
> > > possible to change tx "max fee"  to output amounts?
> >
> > Is it possible? Yes. Should we do that? My first thought was "maybe",
> but after 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 ar=
e
> lower and depend on address type, but let's say it is 1k sats to make
> things simpler).
> >
> > And then, there is a room for other solutions, for example your rule,
> mentioned in other posts, like this one:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021626.h=
tml
> >
> > > probably easier just to reject any transaction where the fee is highe=
r
> than 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 transactio=
n
> creates 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 s=
ee
> another transaction, creating 0.25 BTC output, and paying 0.25 BTC fee.
> > ...
> > N) Your proposal replaced one transaction, consuming maybe one kilobyte=
,
> with a lot of transactions, doing exactly the same, but where fees are
> distributed 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
> defined? Because as shown above, the answer seems to be "yes", because yo=
u
> can always replace a single transaction moving 1 BTC as fees with multipl=
e
> transactions, each paying one satoshi per virtual byte, and then instead =
of
> consuming around one kilobyte, it would consume around 1 MvB per 0.01 BTC=
,
> so 100 MvB per 1 BTC mentioned in the example above.
> >
> >
> >
> > On 2023-05-08 13:55:18 user Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > possible to change tx "max fee"  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 certai=
n
> attacks
> >
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000db16a705fb6c883e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>Regardless of the submitter&#39;s ra=
tionale, it is easy
 to work around any rule that denies mempool inclusion based on fee=20
proportion: if you have plenty, add inputs from your own wallet and=20
return to yourself; if not, borrow them and return to the lender, maybe=20
with interest.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" c=
lass=3D"gmail_attr">On Thu, May 11, 2023 at 9:27=E2=80=AFAM Kalle Rosenbaum=
 via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">Another use case for paying more fe=
es than outputs is to incentivize<br>
honest mining when Bitcoin is under a state-level censorship attack.<br>
If it&#39;s really important to me that my transaction goes through, I<br>
might be willing to set a fee at 99x the output value. It&#39;s the only<br=
>
way bitcoin could work in an adversarial environment.<br>
<br>
/Kalle<br>
<br>
On Thu, 11 May 2023 at 13:55, vjudeu via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; confused.=C2=A0 =C2=A0the rule was &quot;cannot pay a fee &gt; su=
m of outputs with consideration of cpfp in the mempool&quot;<br>
&gt; &gt; your example is of someone paying a fee &quot;&lt; sum&quot;=C2=
=A0 which wouldn&#39;t be blocked<br>
&gt;<br>
&gt; Every transaction paying &quot;fee &gt; sum&quot; can be replaced by N=
 transactions paying &quot;fee &lt;=3D sum&quot;, where the sum of all fees=
 will be the same. That means, someone will still do the same thing, but it=
 will be just expanded into N transactions, so you will reach the same outc=
ome, but splitted into more transactions. That means, mempool will be even =
more congested, because for example instead of 1kB transaction with huge fe=
e, you will see 100 such transactions with smaller fees, that will add to t=
he same amount, but will just consume more space.<br>
&gt;<br>
&gt; &gt; show me how someone could move 1 btc and pay 2 btc as fees...<br>
&gt;<br>
&gt; In the previous example, I explained how someone could move 1k sats an=
d pay almost 1 BTC as fees. But again, assuming that you have 3 BTC, and yo=
u move 1 BTC with 2 BTC fee, that will be rejected by your rules if and onl=
y if that will be done in a single transaction. But hey, the same owner can=
 prepare N transactions upfront, and release them all at the same time, Seg=
wit makes it possible without worrying about malleability.<br>
&gt;<br>
&gt; So, instead of:<br>
&gt;<br>
&gt; 3 BTC -&gt; 1 BTC<br>
&gt;<br>
&gt; You can see this:<br>
&gt;<br>
&gt; 3 BTC -&gt; 2 BTC -&gt; 1 BTC<br>
&gt;<br>
&gt; If that second transaction will not pass CPFP, more outputs could be u=
sed:<br>
&gt;<br>
&gt; +--------------------+--------------------+--------------------+<br>
&gt; | 3.0 BTC -&gt; 0.5 BTC | 0.5 BTC -&gt; 0.5 BTC | 0.5 BTC -&gt; 0.5 BT=
C |<br>
&gt; |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.5 BTC | 0.5 BTC=C2=A0 =C2=
=A0 0.5 BTC | 0.5 BTC=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
&gt; |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.5 BTC | 0.5 BTC=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------------------+<br>
&gt; |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 +--------------------+<br>
&gt; |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.5 BTC | 0.5 BTC -&gt; 0.5=
 BTC |<br>
&gt; |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.5 BTC | 0.5 BTC=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
&gt; +--------------------+--------------------+<br>
&gt;<br>
&gt; As you can see, there are four transactions, each paying 0.5 BTC fee, =
so the total fee is 2 BTC. However, even if you count it as CPFP, you will =
get 1.5 BTC in fees for the third transaction in the chain. Note that more =
outputs could be used, or they could be wired a bit differently, and then i=
f you will look at the last transaction, the sum of all fees from 10 or 15 =
transactions in that chain, could still pass your limits, but the whole tre=
e will exceed that. If you have 1.5 BTC limit for that 3 BTC, then you coul=
d have 20 separate chains of transactions, each paying 0.1 BTC in fees, and=
 it will still sum up to 2 BTC.<br>
&gt;<br>
&gt; &gt; the only way around it is to maintain balances and use change add=
resses.=C2=A0 =C2=A0which would force nft and timestamp users to maintain t=
hese balances and would be a deterrent<br>
&gt;<br>
&gt; Not really, because you can prepare all of those transactions upfront,=
 as the part of your protocol, and release all of them at once. You don&#39=
;t have to maintain all UTXOs in between, you can create the whole transact=
ion tree first, sign it, and broadcast everything at once. More than that: =
if you have HD wallet, you only need to store a single key, and generate al=
l addresses in-between on-the-fly, as needed. Or even use some algorithm to=
 deterministically recreate the whole transaction tree.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On 2023-05-10 19:42:49 user Erik Aronesty &lt;<a href=3D"mailto:erik@q=
32.com" target=3D"_blank">erik@q32.com</a>&gt; wrote:<br>
&gt; confused.=C2=A0 =C2=A0the rule was &quot;cannot pay a fee &gt; sum of =
outputs with consideration of cpfp in the mempool&quot;<br>
&gt;<br>
&gt;<br>
&gt; your example is of someone paying a fee &quot;&lt; sum&quot;=C2=A0 whi=
ch wouldn&#39;t be blocked<br>
&gt;<br>
&gt;<br>
&gt; note: again, i&#39;m not a fan of this, i like the discussion of &quot=
;bitcoin as money only&quot; and using fee as a lever to do that<br>
&gt;<br>
&gt;<br>
&gt; show me how someone could move 1 btc and pay 2 btc as fees... i think =
we can block it at the network or even the consensus layer, and leave anyth=
ing but &quot;non-monetary use cases&quot; intact.=C2=A0 =C2=A0the only way=
 around it is to maintain balances and use change addresses.=C2=A0 =C2=A0wh=
ich would force nft and timestamp users to maintain these balances and woul=
d be a deterrent<br>
&gt;<br>
&gt;<br>
&gt; im am much more in favor of doing something like op_ctv which allows m=
any users to pool fees and essentially &quot;share&quot; a single utxo.<br>
&gt; .<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Wed, May 10, 2023 at 12:19=E2=80=AFPM &lt;<a href=3D"mailto:vjudeu@=
gazeta.pl" target=3D"_blank">vjudeu@gazeta.pl</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; possible to change tx &quot;max fee&quot;=C2=A0 to output amounts=
?<br>
&gt;<br>
&gt; Is it possible? Yes. Should we do that? My first thought was &quot;may=
be&quot;, but after thinking more about it, I would say &quot;no&quot;, her=
e is why:<br>
&gt;<br>
&gt; Starting point: 1 BTC on some output.<br>
&gt; Current situation: A single transaction moving 0.99999000 BTC as fees,=
 and creating 1000 satoshis as some output (I know, allowed dust values are=
 lower and depend on address type, but let&#39;s say it is 1k sats to make =
things simpler).<br>
&gt;<br>
&gt; And then, there is a room for other solutions, for example your rule, =
mentioned in other posts, like this one: <a href=3D"https://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2023-May/021626.html" rel=3D"noreferrer" t=
arget=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20=
23-May/021626.html</a><br>
&gt;<br>
&gt; &gt; probably easier just to reject any transaction where the fee is h=
igher than the sum of the outputs<br>
&gt;<br>
&gt; Possible situation after introducing your proposal, step-by-step:<br>
&gt;<br>
&gt; 1) Someone wants to move 1 BTC, and someone wants to pay 0.99999000 BT=
C as fees. Assuming your rules are on consensus level, the first transactio=
n creates 0.5 BTC output and 0.5 BTC fee.<br>
&gt; 2) That person still wants to move 0.5 remaining BTC, and still is wil=
ling to pay 0.49999000 BTC as fees. Guess what will happen: you will see an=
other transaction, creating 0.25 BTC output, and paying 0.25 BTC fee.<br>
&gt; ...<br>
&gt; N) Your proposal replaced one transaction, consuming maybe one kilobyt=
e, with a lot of transactions, doing exactly the same, but where fees are d=
istributed between many transactions.<br>
&gt;<br>
&gt; Before thinking about improving that system, consider one simple thing=
: is it possible to avoid &quot;max fee rule&quot;, no matter in what way i=
t will be defined? Because as shown above, the answer seems to be &quot;yes=
&quot;, because you can always replace a single transaction moving 1 BTC as=
 fees with multiple transactions, each paying one satoshi per virtual byte,=
 and then instead of consuming around one kilobyte, it would consume around=
 1 MvB per 0.01 BTC, so 100 MvB per 1 BTC mentioned in the example above.<b=
r>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On 2023-05-08 13:55:18 user Erik Aronesty via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; possible to change tx &quot;max fee&quot;=C2=A0 to output amounts?<br>
&gt;<br>
&gt;<br>
&gt; seems like the only use case that would support such a tx is spam/dos =
type stuff that satoshi warned about<br>
&gt;<br>
&gt;<br>
&gt; its not a fix for everything, but it seems could help a bit with certa=
in attacks<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--000000000000db16a705fb6c883e--