From: "David A. Harding" <dave@dtrt•org>
To: Rastislav Budinsky <rastislavbudinsky@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Fee-redistribution contracts
Date: Wed, 01 Mar 2023 07:17:58 -1000 [thread overview]
Message-ID: <ce27590b79ab63b632428cdf582335b0@dtrt.org> (raw)
In-Reply-To: <CACVgDWbZKzmq+j0Hu-k5fW3J+ni-nasq74Ad+a0mkZJE_mPwSQ@mail.gmail.com>
On 2023-02-27 03:32, Rastislav Budinsky via bitcoin-dev wrote:
> When a miner mines a block he takes all the fees currently. However
> with the proposed solution he takes only fraction M and remaining
> fraction C is sent to one of more contracts. One contract at its
> simplest collects fees from the miner and at the same time
> redistributes it back to the miner.
Hi Rastislav,
I think you've incorrectly made the assumption that the only way a miner
can profit from confirming a transaction is by collecting its
transaction fees. Miners can (and many have) accept payment through
alternative means, which the Bitcoin technical community often calls
"out-of-band fees".[1] For example, some miners have provided a
"transaction accelerator" service that accepts fiat-denominated credit
cards to increase their prioritization of certain transactions and I'm
personally aware of a large web wallet provider that would occasionally
pay miners out of band to confirm hundreds or thousands of transactions
rather than fix its broken fee estimation.
Out-of-band fees aren't frequently used in Bitcoin today because they
have no advantage over correctly estimated in-band fees, and good fee
estimation is very accessible to modern wallets. However, if the
consensus rules are changed to require each miner pay a percentage of
its in-band fees to future miners, then there would be a strong
incentive for them to prefer out-of-band fees that weren't subject to
this redistribution scheme.
I think may have seen a variation on the scheme you propose play out in
real life. Here's how it works where I live: the government imposes
taxes on goods, services, and income. Ostensibly, it redistributes the
collected funds back to citizens in the future by providing government
services. When I go to pay someone who trusts my discretion, they often
offer me a discounted rate if I pay in a way that isn't reported to the
government (e.g., I pay with cash); even with the discount provided to
me, they get to keep more of their income than if they had reported the
transaction to the government.
In the case of a government, tax evasion can be reduced by the
deployment of investigators and enforcers. In Bitcoin, we have no
control over activity that happens outside of the protocol and so even a
modest incentive to pay fees out of band might quickly lead to almost
all fees being paid out of band. This prevents the effective
redistribution of fees as in your proposal. Additionally, previous
discussions on this mailing list about paying out-of-band fees have
highlighted that larger miners have an advantage over smaller miners in
collecting miner-specific fee payments, undermining the essential
decentralization of Bitcoin's transaction confirmation mechanism (moreso
than it is already weakened by fundamental economies of scale in
mining).
In short, I think serious consideration of your proposal can only
proceed if it adequately addresses the problem of out-of-band fees.
That said, thank you and your co-authors for putting serious thought
into Bitcoin's long-term economic incentives.
-Dave
[1] https://bitcoinsearch.xyz/?q=out%20of%20band%20fees&size=n_50_n
prev parent reply other threads:[~2023-03-01 17:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-27 13:32 Rastislav Budinsky
2023-02-27 21:41 ` HcaFc_jbe
2023-02-28 10:02 ` shymaa arafat
2023-03-01 17:17 ` David A. Harding [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ce27590b79ab63b632428cdf582335b0@dtrt.org \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rastislavbudinsky@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox