MIME-Version: 1.0
References: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com>
 <Ysyb4T/36oXeAH+z@petertodd.org>
In-Reply-To: <Ysyb4T/36oXeAH+z@petertodd.org>
From: Bram Cohen <bram@chia.net>
Date: Mon, 11 Jul 2022 19:47:43 -0700
Message-ID: <CAHUJnBA+gb0AnGDRB9iA99R6=L0Y5DffB7aE2x+9dU9vyOoXmw@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="000000000000021ea305e392b212"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Security problems with relying on transaction
 fees for security
Precedence: list

--000000000000021ea305e392b212
Content-Type: text/plain; charset="UTF-8"

On Mon, Jul 11, 2022 at 2:53 PM Peter Todd <pete@petertodd.org> wrote:

>
> The only type of fee-smoothing scheme that is feasible is to smooth an
> entirely
> separate category of fees that are made mandatory. For example, you could
> achieve the economic impact of inflation by having a fixed value*time
> based fee
> that goes to timelocked anyone-can-spend outputs in the coinbase to push
> the
> fee forward to other miners.
>

I'm not sure what the implications would be of charging coins for moving
based on their value times how long since they last moved would be (I
*think* that's what you're suggesting). It isn't obviously bad, but feels
weird to me.

That said, a scheme which would work would be to have a fixed minimum fee
of satoshis/vbyte which is required to be repaid out by the miner into a
pool and they get back a fixed fraction of what was in that pool. The pool
could simply be a rolling coin which keeps the balance. That's still a bit
ugly but doesn't lessen block size significantly, is fairly coherent, and
is a soft fork. It's the best emergency measure I'm aware of.

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

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Jul 11, 2022 at 2:53 PM Peter Tod=
d &lt;<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; wrot=
e:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><br>
The only type of fee-smoothing scheme that is feasible is to smooth an enti=
rely<br>
separate category of fees that are made mandatory. For example, you could<b=
r>
achieve the economic impact of inflation by having a fixed value*time based=
 fee<br>
that goes to timelocked anyone-can-spend outputs in the coinbase to push th=
e<br>
fee forward to other miners.<br></blockquote><div><br></div><div>I&#39;m no=
t sure what the implications would be of charging coins for moving based on=
 their value times how long since they last moved would be (I *think* that&=
#39;s what you&#39;re suggesting). It isn&#39;t obviously bad, but feels we=
ird to me.</div><div><br></div><div>That said, a scheme which would work wo=
uld be to have a fixed minimum fee of satoshis/vbyte which is required to b=
e repaid out by the miner into a pool and they get back a fixed fraction of=
 what was in that pool. The pool could simply be a rolling coin which keeps=
 the balance. That&#39;s still a bit ugly but doesn&#39;t lessen block size=
 significantly, is fairly coherent, and is a soft fork. It&#39;s the best e=
mergency measure I&#39;m aware of.</div></div></div>

--000000000000021ea305e392b212--