HcaFc_jbe [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2023-02-27 to 2023-02-27
💬 Posted a total of 1 messages
📚 Participated in the following categories:
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:19:53

- reply

📅 Original date posted:2023-02-27
🗒️ Summary of this message: A proposal for fee redistribution in Bitcoin mining aims to solve undercutting attacks and fee variance between blocks. However, flaws include potential miner aggression and difficulty in achieving consensus. Long-term mining incentives remain an open question.
📝 Original message: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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230227/bbfc0651/attachment-0001.html>

2023-06-07 23:19:53

- reply