Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 547C9C002A for ; 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 ; 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 ; 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 ; Thu, 11 May 2023 15:20:56 +0000 (UTC) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-96622bca286so1222110366b.1 for ; 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: <171698970-6184d5f773dee0589bf3373c44b9f21f@pmq2v.m5r2.onet> In-Reply-To: From: Andrew Baine Date: Thu, 11 May 2023 11:20:43 -0400 Message-ID: To: Kalle Rosenbaum , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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 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 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
Regardless of the submitter'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.

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 fe= es 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.=C2=A0 =C2=A0the rule was "cannot pay a fee > su= m of outputs with consideration of cpfp in the mempool"
> > your example is of someone paying a fee "< sum"=C2= =A0 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 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.
>
> > 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 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.
>
> 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 u= sed:
>
> +--------------------+--------------------+--------------------+
> | 3.0 BTC -> 0.5 BTC | 0.5 BTC -> 0.5 BTC | 0.5 BTC -> 0.5 BT= C |
> |=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 |
> |=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 +--------------------+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--------------------+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.5 BTC | 0.5 BTC -> 0.5= BTC |
> |=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 |
> +--------------------+--------------------+
>
> 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.
>
> > 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
>
> 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 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.
>
>
>
> 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 whi= ch 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 anyth= ing but "non-monetary use cases" 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
>
>
> im am much more in favor of doing something like op_ctv which allows m= any 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"=C2=A0 to output amounts= ?
>
> Is it possible? Yes. Should we do that? My first thought was "may= be", but after thinking more about it, I would say "no", her= e 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= 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/20= 23-May/021626.html
>
> > probably easier just to reject any transaction where the fee is h= igher 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 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.
> 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.
> ...
> 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.
>
> Before thinking about improving that system, consider one simple thing= : is it possible to avoid "max fee rule", no matter in what way i= t will be defined? Because as shown above, the answer seems to be "yes= ", 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. >
>
>
> 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"=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 certa= in 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/mail= man/listinfo/bitcoin-dev
--000000000000db16a705fb6c883e--