* [bitcoin-dev] BIP proposal: Fee-redistribution contracts
@ 2023-02-27 13:32 Rastislav Budinsky
2023-02-27 21:41 ` HcaFc_jbe
2023-03-01 17:17 ` David A. Harding
0 siblings, 2 replies; 4+ messages in thread
From: Rastislav Budinsky @ 2023-02-27 13:32 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]
Hello,
I am working on my Bachelor's thesis, in which a new way of collecting
transaction fees is introduced or rather how they are distributed.
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.
This means no new Bitcoins are introduced, only the one collected from fees
are collected, averaged and rewarded back to the miner in a "smarter" way.
We can have multiple such contracts, where each averages the collected fees
over different time frames. I would like to refer you to our paper for more
details [1], which is not yet in the final form.
Benefits are discussed in the paper [1] as well, mainly it should make
mining more secure and predictable against drastic fluctuations in fees. I
personally do not think miners should oppose this solution as for most
miners it should make a better mining environment. Similarly in a sense to
what mining pools bring.
I would like to know your opinions about this proposal and we can also
discuss the needed parameters introduced with such a solution if you are in
favor of it or think it might be interesting.
Introducing this solution soon enough will not make a great difference to
miners with current block rewards and at the same time the contracts will
be adapted before transaction fees become the main source of income for
miners.
As I have very little to none developer experience from blockchain's point
(especially on Bitcoin), I am not sure if this would be possible as
soft-fork as scripts in Bitcoin are stateless I suppose.
However maybe a generally spendable script by anyone holding the funds is
created, which a miner of the block would be the one spending it, and the
correct logic of following the contracts is embedded into consensus nodes
themselves. Thus perhaps a less disruptive solution to hard-fork.
Once again, I would love to know your opinions about this & I apologize for
making this a bit less conventional BIP proposal.
[1] https://arxiv.org/abs/2302.04910
Best regards.
[-- Attachment #2: Type: text/html, Size: 2603 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Fee-redistribution contracts
2023-02-27 13:32 [bitcoin-dev] BIP proposal: Fee-redistribution contracts Rastislav Budinsky
@ 2023-02-27 21:41 ` HcaFc_jbe
2023-02-28 10:02 ` shymaa arafat
2023-03-01 17:17 ` David A. Harding
1 sibling, 1 reply; 4+ messages in thread
From: HcaFc_jbe @ 2023-02-27 21:41 UTC (permalink / raw)
To: Rastislav Budinsky, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4887 bytes --]
Greetings, Brno is a beautiful city.
Long term miner incentives remain an open question, and this is an interesting proposal, but it has flaws.
-----To intervene or not intervene
--No intervention: When block subsidies do run out, years from now, it's possible that we live in a world where ordinals, LN-settlements, and on-chain transactions will be filling block space to the extent that miners are incentivized to continue mining. --Intervention: Tail-emissions? Demurrage? Fee-redistribution schemes like this one?
Really, it is too early to say whether mining incentives _will even_ be a problem, let alone _what_ the solution(s) should be.
This fee-redistribution scheme aims to solve
1. Undercutting attacks [which have been precluded AFAIK with anti fee-sniping
nLocktime since Core 0.11]
2. Fee-variance between blocks, whether due to the mining gap or variance in block
demand.
--Flaws
0. A miner in this world could be more aggressive in excluding certain blocks to the detriment of their counter parties. I.e. If a miner can ignore high-fee transactions, knowing they won't receive the _benefits_ of mining them [or less benefit], they can exclude these transactions without losing fees. E.g. if a miner is or represents a counterparty in a LN commitment transaction, and this counter party prefers that a time threshold is reached [so that they can mine a different version of the commitment transaction] then under this scheme they can avoid mining the first commitment transaction without really losing its fee, since it's fee is socialized anyway. This attack then becomes free or very cheap.
1. How would this smart-contract actually be constructed? The paper contains no references to op_codes or implementations. You do mention that you are not a bitcoin dev, so that's fair. AFAIK this isn't even _possible_ with the current Script, and could remain impossible. Maybe DLCs could be applied somehow. IDK.
2.0. I think it will be difficult to convince the ecosystem that the mining incentive structure should be changed from competitive to cooperative. This effectively changes the mining ecosystem into one giant mining pool. How would this affect mining centralization?
2.1. How do we achieve miner consensus in implementing the fee-redistribution scheme? And what is the consensus for updating?
---Paper-nits:
I believe the distribution in block creation is not exponential, but poisson -> on page two it's described as exponential.
Cheers,
-Paul
------- Original Message -------
On Monday, February 27th, 2023 at 8:32 AM, Rastislav Budinsky via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> Hello,
>
> I am working on my Bachelor's thesis, in which a new way of collecting transaction fees is introduced or rather how they are distributed.
>
> 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.
>
> This means no new Bitcoins are introduced, only the one collected from fees are collected, averaged and rewarded back to the miner in a "smarter" way.
>
> We can have multiple such contracts, where each averages the collected fees over different time frames. I would like to refer you to our paper for more details [1], which is not yet in the final form.
>
> Benefits are discussed in the paper [1] as well, mainly it should make mining more secure and predictable against drastic fluctuations in fees. I personally do not think miners should oppose this solution as for most miners it should make a better mining environment. Similarly in a sense to what mining pools bring.
>
> I would like to know your opinions about this proposal and we can also discuss the needed parameters introduced with such a solution if you are in favor of it or think it might be interesting.
>
> Introducing this solution soon enough will not make a great difference to miners with current block rewards and at the same time the contracts will be adapted before transaction fees become the main source of income for miners.
>
> As I have very little to none developer experience from blockchain's point (especially on Bitcoin), I am not sure if this would be possible as soft-fork as scripts in Bitcoin are stateless I suppose.
> However maybe a generally spendable script by anyone holding the funds is created, which a miner of the block would be the one spending it, and the correct logic of following the contracts is embedded into consensus nodes themselves. Thus perhaps a less disruptive solution to hard-fork.
>
> Once again, I would love to know your opinions about this & I apologize for making this a bit less conventional BIP proposal.
>
> [1] https://arxiv.org/abs/2302.04910
>
> Best regards.
[-- Attachment #2: Type: text/html, Size: 11303 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Fee-redistribution contracts
2023-02-27 21:41 ` HcaFc_jbe
@ 2023-02-28 10:02 ` shymaa arafat
0 siblings, 0 replies; 4+ messages in thread
From: shymaa arafat @ 2023-02-28 10:02 UTC (permalink / raw)
To: HcaFc_jbe, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6415 bytes --]
If you allow me to comment (just with a bird eye, have not read the paper
only the abstract)
I think the Bitcoin community may consider the intuition of somewhat
"Future Saving" through TX fees:
ie, the idea of saving a ratio of the fees (say half to be decreased to
half with each reward halving)is worth thinking of:
Keep in mind that the block reward problem will not start only in 2140, but
when the mining cost becomes comparable to the reward value (could this be
as near as 2040?I don't know, you know the answer better than me)
.
-So, why not start a fee splitting mechanism in analogy to reward
splitting mechanism
*(the saved ratio is half the total now, and to be halved with every
Bitcoin reward halving until a threshold is reached where the saved amounts
gets added to the low block reward)*
Ofcourse this is very rough, a game theoritic model has to be built with
the appropriate incentives and costs to get the exact numbers
.
Thank you for letting me comment in your list
.
Regards
.
Shymaa M Arafat
On Tue, Feb 28, 2023, 02:18 HcaFc_jbe via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Greetings, Brno is a beautiful city.
>
>
>
>
> Long term miner incentives remain an open question, and this is an
> interesting proposal, but it has flaws.
>
>
>
>
> -----To intervene or not intervene
>
> --No intervention: When block subsidies do run out, years from now, it's
> possible that we live in a world where ordinals, LN-settlements, and
> on-chain transactions will be filling block space to the extent that miners
> are incentivized to continue mining.
>
> --Intervention: Tail-emissions? Demurrage?
> Fee-redistribution schemes like this one?
>
> Really, it is too early to say whether mining incentives _will even_ be a
> problem, let alone _what_ the solution(s) should be.
>
> This fee-redistribution scheme aims to solve
>
> 1. Undercutting attacks [which have been precluded AFAIK with anti
> fee-sniping
>
> nLocktime since Core 0.11]
>
> 2. Fee-variance between blocks, whether due to the mining gap or
> variance in block
>
> demand.
>
>
>
> --Flaws
>
> 0. A miner in this world could be more aggressive in excluding certain
> blocks to the detriment of their counter parties. I.e. If a miner can
> ignore high-fee transactions, knowing they won't receive the _benefits_ of
> mining them [or less benefit], they can exclude these transactions without
> losing fees. E.g. if a miner is or represents a counterparty in a LN
> commitment transaction, and this counter party prefers that a time
> threshold is reached [so that they can mine a different version of the
> commitment transaction] then under this scheme they can avoid mining the
> first commitment transaction without really losing its fee, since it's fee
> is socialized anyway. This attack then becomes free or very cheap.
>
> 1. How would this smart-contract actually be constructed? The paper
> contains no references to op_codes or implementations. You do mention that
> you are not a bitcoin dev, so that's fair. AFAIK this isn't even _possible_
> with the current Script, and could remain impossible. Maybe DLCs could be
> applied somehow. IDK.
>
> 2.0. I think it will be difficult to convince the ecosystem that the
> mining incentive structure should be changed from competitive to
> cooperative. This effectively changes the mining ecosystem into one giant
> mining pool. How would this affect mining centralization?
>
> 2.1. How do we achieve miner consensus in implementing the
> fee-redistribution scheme? And what is the consensus for updating?
>
> ---Paper-nits:
>
> I believe the distribution in block creation is not exponential, but
> poisson -> on page two it's described as exponential.
>
> Cheers,
>
> -Paul
>
> ------- Original Message -------
> On Monday, February 27th, 2023 at 8:32 AM, Rastislav Budinsky via
> bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Hello,
>
> I am working on my Bachelor's thesis, in which a new way of collecting
> transaction fees is introduced or rather how they are distributed.
>
> 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.
>
> This means no new Bitcoins are introduced, only the one collected from
> fees are collected, averaged and rewarded back to the miner in a "smarter"
> way.
>
> We can have multiple such contracts, where each averages the collected
> fees over different time frames. I would like to refer you to our paper for
> more details [1], which is not yet in the final form.
>
> Benefits are discussed in the paper [1] as well, mainly it should make
> mining more secure and predictable against drastic fluctuations in fees. I
> personally do not think miners should oppose this solution as for most
> miners it should make a better mining environment. Similarly in a sense to
> what mining pools bring.
>
> I would like to know your opinions about this proposal and we can also
> discuss the needed parameters introduced with such a solution if you are in
> favor of it or think it might be interesting.
>
> Introducing this solution soon enough will not make a great difference to
> miners with current block rewards and at the same time the contracts will
> be adapted before transaction fees become the main source of income for
> miners.
>
> As I have very little to none developer experience from blockchain's point
> (especially on Bitcoin), I am not sure if this would be possible as
> soft-fork as scripts in Bitcoin are stateless I suppose.
> However maybe a generally spendable script by anyone holding the funds is
> created, which a miner of the block would be the one spending it, and the
> correct logic of following the contracts is embedded into consensus nodes
> themselves. Thus perhaps a less disruptive solution to hard-fork.
>
> Once again, I would love to know your opinions about this & I apologize
> for making this a bit less conventional BIP proposal.
>
> [1] https://arxiv.org/abs/2302.04910
>
> Best regards.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 13014 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] BIP proposal: Fee-redistribution contracts
2023-02-27 13:32 [bitcoin-dev] BIP proposal: Fee-redistribution contracts Rastislav Budinsky
2023-02-27 21:41 ` HcaFc_jbe
@ 2023-03-01 17:17 ` David A. Harding
1 sibling, 0 replies; 4+ messages in thread
From: David A. Harding @ 2023-03-01 17:17 UTC (permalink / raw)
To: Rastislav Budinsky, Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-03-01 17:18 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-27 13:32 [bitcoin-dev] BIP proposal: Fee-redistribution contracts 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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox