path: root/0e/4949d079723bad32d8fa3bb9d89fc691e56846

Return-Path: <kalle@rosenbaum.se>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8F1ACC002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 12:32:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 5D3914063E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 12:32:15 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 5D3914063E
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=rosenbaum-se.20221208.gappssmtp.com
 header.i=@rosenbaum-se.20221208.gappssmtp.com header.a=rsa-sha256
 header.s=20221208 header.b=TLGvw6DU
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
 autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 2oIar7J0MXYE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 12:32:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1897F400CB
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com
 [IPv6:2607:f8b0:4864:20::102f])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 1897F400CB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 12:32:13 +0000 (UTC)
Received: by mail-pj1-x102f.google.com with SMTP id
 98e67ed59e1d1-24def967c6cso1344174a91.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 05:32:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=rosenbaum-se.20221208.gappssmtp.com; s=20221208; t=1683808333; x=1686400333; 
 h=content-transfer-encoding:cc:to:subject:message-id:date:from
 :in-reply-to:references:mime-version:from:to:cc:subject:date
 :message-id:reply-to;
 bh=FphE8gxt6fwfdTvYe4vyYR64M0xdkBSOhQgS2gfHN9w=;
 b=TLGvw6DUmG0WDjDscfUlOrfv7JhXlJcOv6i6iUl5Z0OSfdPo5P25ySn/IonQXspCCp
 JpHV0XfJddZNEUum2Cl9QZaAGRPKHV/EOT/ECbDxntuAzV5nsdgacAZT/DL9nWGUxGn0
 OP4Q0dnTz1Ah9Z7YQbjGjZ4Kmb/rN1hNG3uKul7kRGLsK2XUCmXLoT3Mscpgt024Jksr
 4GA8r+rnxBRnCG6Yew7oYMQKhux4jNplXr0Mou57IpVxn9cWbSH07OdKxIjO9V3Of43z
 YDwAeSHHvFHk3Nz+Zg1JqSo+KmHADW6oM49cdb8eEjlBY1Q0WtRiwaqsrOG3AxPVDCsI
 dd+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1683808333; x=1686400333;
 h=content-transfer-encoding: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=FphE8gxt6fwfdTvYe4vyYR64M0xdkBSOhQgS2gfHN9w=;
 b=AFv3NTx+ECeYqsrE2HOi+MTHtjWvpIzSDEw5Ff3HiFY7AQNMlFi2G3fCM4AMxDRy8N
 Wf9Rjk6SMWy6g/gOAtjDhKwh17fYMOX6+q4WKAWWN6mdGQUQvFiZWi4psrKldFjUe2GJ
 ECJ1vTVJYr4juMZI95qt6u+OxgKZeRm3MGOz1TpBEKyMk8uHiPEaupxWKYsq0owiSeAl
 vxCVOqXtegM0D/6UXyPWUKOR+SYcIc8Swzc/CLW6F10IjHDKj8ParRIb+yxUMT8rg3zh
 54cjjz09gm439orDIfeHfYSKdf1qQurbqBQDNind+prUohrMqzvhVsfwGOtamBXdctSb
 6qwg==
X-Gm-Message-State: AC+VfDwfSNDty4/mqwbCqA/HhhPEY6gEQppImekDMSD6JPZmgOZ2EIus
 gPDdwXNjzLPEfq+bQbK3PSn8PRhvJUjw/xjOnn4l0w==
X-Google-Smtp-Source: ACHHUZ76G3wXwI9j8ukQUvX2yBXL4b0FdC/FtZrORttfxaFH1YSvYDxIj5a3Bg6Qx2jh3621uhXy1b9Wls5vC3MEwX0=
X-Received: by 2002:a17:90b:17c1:b0:252:85ab:41d1 with SMTP id
 me1-20020a17090b17c100b0025285ab41d1mr2718069pjb.3.1683808333182; Thu, 11 May
 2023 05:32:13 -0700 (PDT)
MIME-Version: 1.0
References: <CAJowKgLx796AWaZAMOGVWFsT2LK8zvCvxiY-sv110gv1cewCwg@mail.gmail.com>
 <171698970-6184d5f773dee0589bf3373c44b9f21f@pmq2v.m5r2.onet>
In-Reply-To: <171698970-6184d5f773dee0589bf3373c44b9f21f@pmq2v.m5r2.onet>
From: Kalle Rosenbaum <kalle@rosenbaum.se>
Date: Thu, 11 May 2023 14:32:01 +0200
Message-ID: <CAPswA9wXFzXmkVvczidt=2Eah0dNgRHdMwgvT22m=m6ffPxb9w@mail.gmail.com>
To: vjudeu@gazeta.pl, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 11 May 2023 13:27:30 +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 12:32:15 -0000

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 consid=
eration of cpfp in the mempool"
> > your example is of someone paying a fee "< sum"  which wouldn't be bloc=
ked
>
> Every transaction paying "fee > sum" can be replaced by N transactions pa=
ying "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 into more t=
ransactions. That means, mempool will be even more congested, because for e=
xample instead of 1kB transaction with huge fee, you will see 100 such tran=
sactions with smaller fees, that will add to the 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 and p=
ay almost 1 BTC as fees. But again, assuming that you have 3 BTC, and you m=
ove 1 BTC with 2 BTC fee, that will be rejected by your rules if and only i=
f that will be done in a single transaction. But hey, the same owner can pr=
epare 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, 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 out=
puts could be used, or they could be wired a bit differently, and then if y=
ou will look at the last transaction, the sum of all fees from 10 or 15 tra=
nsactions in that chain, could still pass your limits, but the whole tree w=
ill exceed that. If you have 1.5 BTC limit for that 3 BTC, then you could h=
ave 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 addresses=
.   which would force nft and timestamp users to maintain these balances an=
d 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 transaction tre=
e 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 addre=
sses in-between on-the-fly, as needed. Or even use some algorithm to determ=
inistically 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 consider=
ation of cpfp in the mempool"
>
>
> your example is of someone paying a fee "< sum"  which wouldn't be blocke=
d
>
>
> 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 mainta=
in 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 lo=
wer 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, men=
tioned in other posts, like this one: https://lists.linuxfoundation.org/pip=
ermail/bitcoin-dev/2023-May/021626.html
>
> > 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 c=
reates 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 dist=
ributed 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 def=
ined? 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 tra=
nsactions, each paying one satoshi per virtual byte, and then instead of co=
nsuming 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@li=
sts.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
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev