1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
|
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 23DE9C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Aug 2022 17:07:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id E0310828DE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Aug 2022 17:07:19 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E0310828DE
Authentication-Results: smtp1.osuosl.org;
dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl
header.a=rsa-sha256 header.s=2013 header.b=qmBxFLmS
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id gsJD1btUp6p4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Aug 2022 17:07:19 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5FFA1828DD
Received: from smtpo115.poczta.onet.pl (smtpo115.poczta.onet.pl
[213.180.149.168])
by smtp1.osuosl.org (Postfix) with ESMTPS id 5FFA1828DD
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Aug 2022 17:07:17 +0000 (UTC)
Received: from pmq3v.m5r2.onet (pmq3v.m5r2.onet [10.174.32.69])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4LydZQ1kjHzlj670;
Wed, 3 Aug 2022 19:07:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
t=1659546430; bh=qUSOTSEz3ZewDSJeWtCZ34Iq5tNq2K9kscLJx5wBjaw=;
h=From:To:In-Reply-To:Date:Subject:From;
b=qmBxFLmSY/12J/I50U5FdNgGUlaFbu1rwAEkFGQRQQfRJPqqmkBxe7UFgFQCmOohm
dVcjndLss4zCXOLhe73QstStT3hUfXcOtFlzsm0O9Q18hakjQqIyM4QoeoFABVzMUL
89ceWg+tdkMBaiWXxqbJ6BsxaZS3ZtyIfozd1sgo=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.240.229] by pmq3v.m5r2.onet via HTTP id ;
Wed, 03 Aug 2022 19:07:10 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
To: "aaradhya@technovanti.co.in, Aaradhya Chauhan <chauhanansh.me@gmail.com>,
Bitcoin Protocol Discussion" <bitcoin-dev@lists.linuxfoundation.org>,
Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAGHFe1BsDnxn6nuoMwCtt56YjaXmT0mPZ6XnMJZpyC2Fa7e9aQ@mail.gmail.com>
Date: Wed, 03 Aug 2022 19:07:08 +0200
Message-Id: <166123291-fe0f05975e84c5e295606d87fdddcd64@pmq3v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.240.229;PL;2
X-Mailman-Approved-At: Wed, 03 Aug 2022 17:31:53 +0000
Subject: Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee
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: Wed, 03 Aug 2022 17:07:20 -0000
It is possible, because you can find nodes that accept low-fee transactions=
. And on some statistics, for example https://jochen-hoenicke.de/queue/#BTC=
,24h,weight,0 you can see that zero to one satoshi per virtual byte transac=
tions could take more space than other transactions. You can be convinced t=
hat those charts are not fake by running a full node and reaching some node=
s with different fee settings. If miners don't want to accept them, well, i=
t is their choice to leave that money on the table. As long as the basic bl=
ock reward is sufficient, they don't have to accept such low fee transactio=
ns, because they can wait instead, to receive them in some batched form.
Also, some miners could accept only 10 sats/vB or higher, because why not. =
As long as your transaction will reach enough nodes to be confirmed, you ca=
n safely pick lower fees. For now, de-facto standard is one satoshi per vir=
tual byte, but:
1) it is only declared, so you can rely only on declarations, not on hard c=
onsensus rules
2) there is no way to make sure if some transaction was truly rejected by s=
ome miner, or maybe it was saved somewhere
3) you can never be sure if some node is a miner and can enforce those diff=
erent fee rules or not
So, you can really judge only by how nodes behave, you cannot make sure in =
any way if anyone is running some additional rules. And fees are not a part=
of the consensus, so they can be freely adjusted by each node, and there i=
s no way to make sure, what rules are really executed, you can only assume =
that, based on what transactions are included in blocks.
On 2022-08-03 18:19:12 user Aaradhya Chauhan via bitcoin-dev <bitcoin-dev@l=
ists.linuxfoundation.org> wrote:
So, can we conclude by something, whether or not it would be possible and f=
easible in the future?
On Mon, 1 Aug 2022 at 19:08, Peter Todd via bitcoin-dev <bitcoin-dev@lists.=
linuxfoundation.org> wrote:
On Mon, Aug 01, 2022 at 01:19:05PM +0000, aliashraf.btc At protonmail wrote:
> > On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-dev wrot=
e:
> > like a hashcash-based alternative broadcast scheme.
> Hi Peter,
> I've been mulling the idea of attaching work to low fee txns, both as a c=
ompensation (e.g., in a sidechain, or an alt), and/or as a spam proof. Unfo=
rtunately, both suffer from ASICs:
> For spam proof case, the adversary can easily buy a used/obsolete device =
to produce lots of spam txns very cheaply, unless you put the bar very high=
, making it almost impossible for average users to even try.
> The compensation scenario is pretty off-topic, still, interesting enough =
for 1 min read:
> Wallets commit to the latest blockchain state in the transaction AND atta=
ch work.
> It is considered contribution to the security (illegitimate chains can't =
include the txn), hence isrewarded by fee discount/exemption depending on t=
he offset of the state they've committed to (the closer, the better) and th=
e amount of work attached.
> For this to work, block difficulty is calculated inclusive with the work =
embedded in the txns, it contains. Sophisticated and consequential, yet not=
infeasible per se.
>
> Unfortunately, this scheme is hard to balance with ASICs in the scene too=
, for instance, you can't subsidize wallets for their work like with a leve=
rge, because miners can easily do it locally, seizing the subsidies for the=
mselves, long story, not relevant just ignore it.
We're not talking about a consensus system here. Just a way to rate-limit
access to a broadcast network used by a small minority of nodes. It's
completely ok to simply change the PoW algorithm in the _highly_ unlikely e=
vent
someone bothers to build an ASIC for it. Since this isn't a consensu system,
it's totally ok if multiple versions of the scheme run in parallel.
|
