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
|
Return-Path: <petdog@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3075D8D7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 24 Dec 2017 13:59:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f182.google.com (mail-qt0-f182.google.com
[209.85.216.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 83DA9403
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 24 Dec 2017 13:59:25 +0000 (UTC)
Received: by mail-qt0-f182.google.com with SMTP id m59so41015247qte.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 24 Dec 2017 05:59:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=YGxpG72mxiSWeC5NZ8JCz6aOFURZ+c9p37y6MvM+O88=;
b=Gerket2q0iXyTWLj6bFp1TClJCfgRQv51QDmXS1jwZtH9jBp8W47jIdQ4eFVi5vB+v
TRyg2slgi59pK+ruFcuVlyzz7CFffKDFDmFi4I+Nly6WUxsOzicJ1Ke1YcORI7uUi20E
A3L4YtRAXngNCBpBDC3JPSfdKXmzEuPvfirkbiPJ8vI1i9sM9OxhpShYUPuUYrtqYO//
g3MrqHaMsOIGPq4SznAPrRltj7+vCTwfyYhjE1/SI7Suwr/Smqr5vWYS7FOGBZ7PErlw
g9JztU8H13+5z9uUYTqZOT9nAxt7ZatQTOT7bKjhvDW3MU5d0dZPwAmbrVGLLkgllO3x
6ZEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=YGxpG72mxiSWeC5NZ8JCz6aOFURZ+c9p37y6MvM+O88=;
b=MeJtar+ywHs7Ey1q9MfmIm2aKOm+iIpZ6LXUknYbRWBqiB7RrJszlh3Ai13VnySHcN
jN6I3YhUv9X4SKOjPlvA6mvHoEsNAMw8mCUEut2tjkEsSLm6YNx/JrnMNYK4ixrNdQJa
0YvXCgfp7ye6bw0bZ7xcWwPm1lUOe+OyGLtTLSipswfCMzNWWf5XMQBiXn6O1bygPBKK
EinEFfqFcX3u8WAJcXvJ2HNwCShPaTbKoNaZbMe8mOGilbuulvVWXgzKUpj8H3yqW6DG
wPYyxWzx2IDO4UDvRh+z70A6PNsCzFQNv0fnJt9Y3dUVnASGp0Lk6hJtb3FeEdhzFnax
pilw==
X-Gm-Message-State: AKGB3mKt/7myfWHWdq+EQf80A31L4fv+WNqcAFXO33IPmG5iCSqL9EA9
XmxgrvWiayI8Ftodj4nE6iQ3XcaOPluDZTRBFuw=
X-Google-Smtp-Source: ACJfBouBIi7qXfrUzzhvFSVuv6CN/TYuCBxkDKe6EdOLd3LoJTWg9txq7FVfSF4sKEpeuIPvZM0v08fU/iENIvB79gQ=
X-Received: by 10.200.51.143 with SMTP id c15mr27773801qtb.46.1514123964460;
Sun, 24 Dec 2017 05:59:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.157.9 with HTTP; Sun, 24 Dec 2017 05:59:23 -0800 (PST)
In-Reply-To: <PS2P216MB0179A68450E8AA5E4E77915B9D000@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
References: <CAMjoVH+5W+1pO2bJSPNr20sGJDVvwrKS85KZZYsSdXjSL65jLA@mail.gmail.com>
<PS2P216MB0179A68450E8AA5E4E77915B9D000@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
From: oscar <petdog@gmail.com>
Date: Sun, 24 Dec 2017 14:59:23 +0100
Message-ID: <CAMjoVH+qEOgMSLmoJ+1qcbiKJ0L2pcr_48Sn5AOttXg+hReHxg@mail.gmail.com>
To: Damian Williamson <willtech@live.com.au>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 24 Dec 2017 22:40:25 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] what do you think about having a maximum fee rate?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Sun, 24 Dec 2017 13:59:26 -0000
On Sun, Dec 24, 2017 at 2:13 AM, Damian Williamson <willtech@live.com.au> wrote:
> If all transactions pay the proposed max then fee there are still going to
> be an awful lot of never confirming transactions once the transaction
> bandwidth limit is surpassed
Yes obviously. That would be the unequivocal sign that it's time to
bump the block size.
Why not just bump now then? My main worry is that wasting space should
not be profitable for anybody. If it is, it's an encouragement to
waste space, and imho we have such an encouragement in place.
Fees should be allowed to get high enough as to discourage wasteful
usage of blockchain space, but not high enough as to make it
*profitable* to waste space, if you are a sufficiently big miner. The
fact that it is now profitable, and that such big miners exist, makes
me believe that a lot of blockchain space is wasted on purpose.
> This is what I have been working on as an alternative:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015371.html
I read your proposal, but the value that I see in mine is that it is
extremely simple. It would be trivial to have nodes stop propagating
transactions with fees over the max, and miners can trivially reject
blocks where coinbase > block reward + max fee rate * block size, if
they are on board.
It would also be quite simple to adapt wallets, given that the fee
range is fixed. If nodes had an rpc method giving you some mempool
statistics, it would also be simple to correctly recommend fees
according to the time expected to first confirmation.
Sure, at some point, if there is real congestion, it would just start
always recommending the max fee. Again, this means that it's time to
bump the block size. I think this is ultimately unavoidable, but I
understand the reservations, and I agree that increasing the block
size without incentivizing efficient usage would be counterproductive.
I think the current fees are certainly incentivizing efficient usage
to users, but not to miners. My (maybe naive) idea is that it would be
possible to find an appropriate maximum fee value that would move
things towards efficient usage by both users and big miners.
This would work very well if coupled with some proposals I've read to
slowly increase the block size with a process similar to difficulty
adjustment, like adding 100kb if 95% of the last 2016 blocks were
full. Without max fees, a big miner could easily destroy this strategy
by always applying just enough pressure as to always skyrocket fees
and profit, while the blocksize slowly increases.
The way I see it, unbounded fees together with small blocks and big
miners introduce a terrible flaw in the incentives equilibrium.
I would really like an open discussion on this topic.
|
