path: root/f2/e2673e88d162b6c4f556612806e2de5a761758

Return-Path: <rastislavbudinsky@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C4F1EC002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 27 Feb 2023 13:32:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 9244F40924
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 27 Feb 2023 13:32:16 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 9244F40924
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=jMJ78QEx
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-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 hIw4bWAAk5cc
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 27 Feb 2023 13:32:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 87C29401A1
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com
 [IPv6:2607:f8b0:4864:20::131])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 87C29401A1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 27 Feb 2023 13:32:15 +0000 (UTC)
Received: by mail-il1-x131.google.com with SMTP id b12so3922748ils.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 27 Feb 2023 05:32:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=wEFoesZtNb4M3+hdkr6F2FshxdwL5JiND0bfCs50CBk=;
 b=jMJ78QExrC8Yi7L2UOaz07ATJ/n+ocffvSHUdaSxHO/+yIXShiILtxTEIwpR7QfLgI
 slegu5lWA+plRI1yAdz6j/QUYNEebPtI/dr1z3pVQchs/E5U5SbOmMcGvfqPdIHlBkhn
 Tn8Le47m3styjEgxw/3NeQBL6AiJ1EDEAyVmKzc+GPsESBh/sXNp4uTPjktzhuqJgvKr
 T3+VxSP78Dpij/HgXSCZ0oX/7kSHgHDg6qa/1kOXf9oC5RigAJxSle5R7iV8ilY/h9V4
 AAwSfeVQIyobUQLYEKXqGhyp4agCued1AYNLQbTvugIE7y7zrGHs8daRkzCDEHtfsa01
 NWCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=wEFoesZtNb4M3+hdkr6F2FshxdwL5JiND0bfCs50CBk=;
 b=VCJrFDPHUTbRqTcX6/B7j1uyH4h3EOsEFoQInFmqCapwPXUt4P2PMznpzTIfCPv1Cc
 qfCpZRKTDKD7gBlnDU3NEGfdy8m4sZ6gN71FXLXVYoBZzYNxGvMHtYSiU+v4PrCRhZf5
 46RINe2w/cWW3VQ4kWDl1BYoXOHVkJ9+c9amaXet039VyPeJMuJsa2NJrsAFrYFaBvrk
 azOwU3uzfWOZb8IfMz5xuTr28P1kU7RRdoEs39aMD1HLhVoRg3fMxroEGBEv/Yu+qoqz
 JQ3B2dDDEVb/UFjVVgXhLv6v5xsbo9GJ0zGBiwwNIMe6ViU/2on0VuXZISaCgJ1gAT2n
 Wurg==
X-Gm-Message-State: AO0yUKV+/l+E9Y3zYIu1x0Qj0uzLY1eukhrLbP7XnaZHuH/A4GqaQlvI
 8VRPhT0Bmttgk6vdIK0u0zgAQ2VB4IMstYoC8gGBoP7i
X-Google-Smtp-Source: AK7set/QQ87q49DZo7KOAe/WIkr51oNgn4PfE0RCtDwsoiJVZnXMLwEPAxXqSvex57PdB4kt7/kqFIUQpQkM+GxcWqg=
X-Received: by 2002:a92:1812:0:b0:313:fad9:a014 with SMTP id
 18-20020a921812000000b00313fad9a014mr1516807ily.5.1677504733782; Mon, 27 Feb
 2023 05:32:13 -0800 (PST)
MIME-Version: 1.0
From: Rastislav Budinsky <rastislavbudinsky@gmail.com>
Date: Mon, 27 Feb 2023 14:32:01 +0100
Message-ID: <CACVgDWbZKzmq+j0Hu-k5fW3J+ni-nasq74Ad+a0mkZJE_mPwSQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="000000000000c4279905f5ae8162"
X-Mailman-Approved-At: Mon, 27 Feb 2023 14:02:54 +0000
Subject: [bitcoin-dev] BIP proposal: Fee-redistribution contracts
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: Mon, 27 Feb 2023 13:32:16 -0000

--000000000000c4279905f5ae8162
Content-Type: text/plain; charset="UTF-8"

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.

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

<div dir=3D"ltr">Hello,<div><br></div><div>I am working on my Bachelor&#39;=
s thesis, in which a new way of collecting transaction fees is introduced o=
r rather how they are distributed.</div><div><br></div><div>When a miner mi=
nes a block he takes all the fees currently. However with the proposed solu=
tion he takes only fraction M and remaining fraction C is sent to one of mo=
re contracts. One contract at its simplest collects fees from the miner and=
 at the same time redistributes it back to the miner.</div><div><br></div><=
div><div>This means no new Bitcoins are introduced, only the one collected =
from fees are collected, averaged and rewarded back to the miner in a &quot=
;smarter&quot; way.</div></div><div><br></div><div>We can have multiple suc=
h contracts, where each averages the collected fees over different time fra=
mes. I would like to refer you to our paper for more details [1], which is =
not yet in the final form.<br></div><div><br></div><div>Benefits are discus=
sed=C2=A0in 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 brin=
g.</div><div><br></div><div>I would like to know your opinions about this p=
roposal 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.</div=
><div><br></div><div>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 sourc=
e of income for miners.</div><div><br></div><div>As I have very little to n=
one developer experience from blockchain&#39;s point (especially on Bitcoin=
), I am not sure if this would be possible as soft-fork as scripts in Bitco=
in are stateless I suppose.</div><div>However maybe a generally spendable s=
cript by anyone holding the funds is created, which a miner of the block wo=
uld be the one spending it, and the correct logic of following the contract=
s is embedded into consensus nodes themselves. Thus perhaps a less disrupti=
ve solution to hard-fork.</div><div><br></div><div>Once again, I would love=
 to know your opinions about this &amp; I apologize for making this a bit l=
ess conventional BIP proposal.</div><div><br></div><div>[1]=C2=A0<a href=3D=
"https://arxiv.org/abs/2302.04910" target=3D"_blank">https://arxiv.org/abs/=
2302.04910</a></div><div><br></div><div>Best regards.</div></div>

--000000000000c4279905f5ae8162--