Return-Path: <vjudeu@gazeta.pl>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B68CDC002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 11:03:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 7759960E61
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 11:03:10 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 7759960E61
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=oeni8/Dg
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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,
 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 8UP2XYRrG3Ea
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 11:03:08 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 3E28F60AE5
Received: from smtpa40.poczta.onet.pl (smtpa40.poczta.onet.pl [213.180.142.40])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 3E28F60AE5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 11:03:07 +0000 (UTC)
Received: from pmq2v.m5r2.onet (pmq2v.m5r2.onet [10.174.32.68])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4QH8BV62WjzlgPxj;
 Thu, 11 May 2023 13:02:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1683802978; bh=YetZSZ+FXsrPokdBdwB5KLtgmfR8ex8z54Z2mBX0KmE=;
 h=From:Cc:To:In-Reply-To:Date:Subject:From;
 b=oeni8/Dg142uU0Ffka40RwGNNrs/gyravT1Ry/t7SR/2qdf7+hUrckfUZeWbgiUaA
 Tz3noRIcOLbhGowKNdllVYjySiT2aseVnpFY+2j27DDsA7FmNqLCvXY4cYWhyhqfJP
 5+XQPp9SY1yKRRXCFIFoAm79LL6XYI6Y5f2CQcSc=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.232.218] by pmq2v.m5r2.onet via HTTP id ;
 Thu, 11 May 2023 13:02:58 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
To: Erik Aronesty <erik@q32.com>
In-Reply-To: <CAJowKgLx796AWaZAMOGVWFsT2LK8zvCvxiY-sv110gv1cewCwg@mail.gmail.com>
Date: Thu, 11 May 2023 13:02:57 +0200
Message-Id: <171698970-6184d5f773dee0589bf3373c44b9f21f@pmq2v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.232.218;PL;2
X-Mailman-Approved-At: Thu, 11 May 2023 11:54:39 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 11:03:10 -0000

> confused.   the rule was "cannot pay a fee > sum of outputs with consider=
ation 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 payi=
ng "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 t=
ransactions, so you will reach the same outcome, but splitted into more tra=
nsactions. That means, mempool will be even more congested, because for exa=
mple instead of 1kB transaction with huge fee, you will see 100 such transa=
ctions with smaller fees, that will add to the same amount, but will just c=
onsume 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 you mov=
e 1 BTC with 2 BTC fee, that will be rejected by your rules if and only if =
that will be done in a single transaction. But hey, the same owner can prep=
are N transactions upfront, and release them all at the same time, Segwit m=
akes 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, so th=
e 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 outpu=
ts 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 trans=
actions in that chain, could still pass your limits, but the whole tree wil=
l exceed that. If you have 1.5 BTC limit for that 3 BTC, then you could hav=
e 20 separate chains of transactions, each paying 0.1 BTC in fees, and it w=
ill 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 t=
he part of your protocol, and release all of them at once. You don't have t=
o maintain all UTXOs in between, you can create the whole transaction tree =
first, sign it, and broadcast everything at once. More than that: if you ha=
ve HD wallet, you only need to store a single key, and generate all address=
es in-between on-the-fly, as needed. Or even use some algorithm to determin=
istically recreate the whole transaction tree.



On 2023-05-10 19:42:49 user Erik Aronesty <erik@q32.com> wrote:
confused.=C2=A0 =C2=A0the 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"=C2=A0 which wouldn't be blo=
cked


note: again, i'm not a fan of this, i like the discussion=C2=A0of "bitcoin =
as 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 we ca=
n block it at the network or even the consensus layer, and leave anything b=
ut "non-monetary use cases" intact.=C2=A0 =C2=A0the only way around it is t=
o maintain balances and use change addresses.=C2=A0 =C2=A0which would force=
 nft and timestamp users to maintain these balances and would be a deterrent


im am much more in favor of=C2=A0doing=C2=A0something like op_ctv which all=
ows many users to pool fees and essentially "share" a single utxo.
.
=C2=A0=C2=A0


On Wed, May 10, 2023 at 12:19=E2=80=AFPM <vjudeu@gazeta.pl> wrote:

> possible to change tx "max fee"=C2=A0 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