path: root/f4/856a7e3a3f8081cd406bc968dc69a36d78eaf8

Return-Path: <earonesty@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CA74EC002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 May 2023 17:42:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 9752261663
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 May 2023 17:42:50 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 9752261663
Authentication-Results: smtp3.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=gzEdQma0
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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id le2YhjKEt9tv
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 May 2023 17:42:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 438A8614ED
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com
 [IPv6:2607:f8b0:4864:20::b2f])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 438A8614ED
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 May 2023 17:42:49 +0000 (UTC)
Received: by mail-yb1-xb2f.google.com with SMTP id
 3f1490d57ef6-b9e61ad0caeso1688491276.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 10 May 2023 10:42:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20221208.gappssmtp.com; s=20221208; t=1683740568; x=1686332568;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=qCN9JP9jvdAdHu97vS1BOKtAslIMaUfKrKS5ECjygOY=;
 b=gzEdQma080iFZM8Z9oThk16nFhoE08cHJwsk2KYkQiTSUG193YxwZo42srhlMFlyGN
 0e680TL6LQ3LNGhy0oMNn3kAU1gmUiOmVP5NDxsWiV9ZABaCxBWKv7UPbCdJnCkIhWAx
 8s8rbZoFc1fUWQH3xGSxKlWSISdymbHcATyJnybQ8+qmOMXWbwlydpdioXCnXlNdToRD
 ZMwbnesOfHj/NCU2gSetYxx4urbjc9exY3l71hFJyG43kqejZKJUzlWhtVx1kCYd6gCF
 yUDLJMobt1ooaxtJgT6OxOv0NF6PatYBVRVhrq/BMye12t51nUWVW5e8XfPO+0CI1P3p
 /CSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1683740568; x=1686332568;
 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=qCN9JP9jvdAdHu97vS1BOKtAslIMaUfKrKS5ECjygOY=;
 b=lkDuBGV7wPgvSSQOL03Sa/dfCK2JdAbl2Mlcf/suxuivjmTEIHFH6ql38rDQgrA4mL
 oUYjG4BzVgpCVDoE3wJfASUGJ/1G4jkGT5WTVJvU7ESxkcxkO2oq6TQeHlvQY4D27Re6
 cYDfOBpIwkHNe083P/c32VO2fodiITYJate2F4muapze1KmMebtSf6vYVoS6JtYMykbU
 sZeXL9pIJuF8iLCMr1KlWVWUriE8i1F1EVBMSP5ltZoaVwMhUZws438IhNzCvo8jj8dk
 S8S8RduV7Eodwg6zEHuss+q3+HsKlnyRy3k8Z551rd07U+NRyZtBbAuj1MOKSkwpdFt5
 w6VA==
X-Gm-Message-State: AC+VfDwfJDYP+rabJGx0xfHTa6/bJBwRi9NaIBN+ouk8CE5Z6R4+NKLv
 wxcWIQRWSaUak9Lmf8tJGhBB220u5pqXxSwd98pvpe/bYX6eJWY=
X-Google-Smtp-Source: ACHHUZ6Nq228D9365XKkx822vxTdOukyUg5GAY1i6R6wgj14Cl5aNsTxdwIWkgEOD+/XgCnApOUEomvmgKzjN7J7Nh0=
X-Received: by 2002:a25:c5d4:0:b0:b9d:b22e:b9b0 with SMTP id
 v203-20020a25c5d4000000b00b9db22eb9b0mr19080153ybe.3.1683740567962; Wed, 10
 May 2023 10:42:47 -0700 (PDT)
MIME-Version: 1.0
References: <158873530-26c4ca5223c12fad28089c0ab56e9528@pmq8v.m5r2.onet>
In-Reply-To: <158873530-26c4ca5223c12fad28089c0ab56e9528@pmq8v.m5r2.onet>
From: Erik Aronesty <erik@q32.com>
Date: Wed, 10 May 2023 13:42:37 -0400
Message-ID: <CAJowKgLx796AWaZAMOGVWFsT2LK8zvCvxiY-sv110gv1cewCwg@mail.gmail.com>
To: vjudeu@gazeta.pl
Content-Type: multipart/alternative; boundary="000000000000728b6105fb5a6670"
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: Wed, 10 May 2023 17:42:50 -0000

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

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 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
can block it at the network or even the consensus layer, and leave anything
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, an=
d
> creating 1000 satoshis as some output (I know, allowed dust values are
> 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 higher
> 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 a=
s
> fees. Assuming your rules are on consensus level, the first transaction
> creates 0.5 BTC output and 0.5 BTC fee.
> 2) That person still wants to move 0.5 remaining BTC, and still is willin=
g
> to pay 0.49999000 BTC as fees. Guess what will happen: you will see anoth=
er
> 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: i=
s
> 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 typ=
e
> stuff that satoshi warned about
>
>
> its not a fix for everything, but it seems could help a bit with certain
> attacks
>
>
>
>

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

<div dir=3D"ltr">confused.=C2=A0 =C2=A0the rule was &quot;cannot pay a fee =
&gt; sum of outputs with consideration of cpfp in the mempool&quot;<div><br=
></div><div>your example is of someone paying a fee &quot;&lt; sum&quot;=C2=
=A0 which wouldn&#39;t be blocked</div><div><br></div><div>note: again, i&#=
39;m not a fan of this, i like the discussion=C2=A0of &quot;bitcoin as mone=
y only&quot; and using fee as a lever to do that</div><div><br></div><div>s=
how 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 anything bu=
t &quot;non-monetary use cases&quot; intact.=C2=A0 =C2=A0the only way aroun=
d it is to maintain balances and use change addresses.=C2=A0 =C2=A0which wo=
uld force nft and timestamp users to maintain these balances and would be a=
 deterrent</div><div><br></div><div>im am much more in favor of=C2=A0doing=
=C2=A0something like op_ctv which allows many users to pool fees and essent=
ially &quot;share&quot; a single utxo.</div><div>.</div><div>=C2=A0=C2=A0</=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Wed, May 10, 2023 at 12:19=E2=80=AFPM &lt;<a href=3D"mailto:vjudeu@g=
azeta.pl">vjudeu@gazeta.pl</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">&gt; possible to change tx &quot;max fee&quot;=C2=
=A0 to output amounts?<br>
<br>
Is it possible? Yes. Should we do that? My first thought was &quot;maybe&qu=
ot;, but after thinking more about it, I would say &quot;no&quot;, here is =
why:<br>
<br>
Starting point: 1 BTC on some output.<br>
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&#39;s say it is 1k sats to make thing=
s simpler).<br>
<br>
And then, there is a room for other solutions, for example your rule, menti=
oned in other posts, like this one: <a href=3D"https://lists.linuxfoundatio=
n.org/pipermail/bitcoin-dev/2023-May/021626.html" rel=3D"noreferrer" target=
=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-Ma=
y/021626.html</a><br>
<br>
&gt; probably easier just to reject any transaction where the fee is higher=
 than the sum of the outputs<br>
<br>
Possible situation after introducing your proposal, step-by-step:<br>
<br>
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.<br>
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.<br>
...<br>
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.<br>
<br>
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 it wil=
l 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 Mv=
B per 0.01 BTC, so 100 MvB per 1 BTC mentioned in the example above.<br>
<br>
<br>
<br>
On 2023-05-08 13:55:18 user Erik Aronesty via bitcoin-dev &lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@l=
ists.linuxfoundation.org</a>&gt; wrote:<br>
possible to change tx &quot;max fee&quot;=C2=A0 to output amounts?<br>
<br>
<br>
seems like the only use case that would support such a tx is spam/dos type =
stuff that satoshi warned about<br>
<br>
<br>
its not a fix for everything, but it seems could help a bit with certain at=
tacks=C2=A0<br>
<br>
<br>
<br>
</blockquote></div>

--000000000000728b6105fb5a6670--