summaryrefslogtreecommitdiff
path: root/26/636579ee56771d156513a1e4146df9527fc590
blob: 83f9f45f0a038773f5124e2ba677a6f723a62998 (plain)
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
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id BB5EF8FF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 30 Sep 2017 03:53:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f182.google.com (mail-ua0-f182.google.com
	[209.85.217.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3075B41E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 30 Sep 2017 03:53:02 +0000 (UTC)
Received: by mail-ua0-f182.google.com with SMTP id g34so797219uah.7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 29 Sep 2017 20:53:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=TfHmtY6NIH1X5PMaLLep9XGgQNqYJbVNGwgrxEHHovI=;
	b=bn5eJUoSU1umpVWABGdaW2yVdDM5fNwgYLIa4L8VasAiiPYDyRHf9PliMONrEYQ2PG
	EykQ1D7kpF+WlrZIQ9fh2iUrxdLvCUPhHepLblmIi4Q2Pg8MO0wd+GjBBl+RPK5BCrjg
	0UzoajkzgAJteuEJTbGojtM4uuxJzOCbpVUGB6EEAoiKEzid+2ln6M0rHmO0Ufoq3z3H
	Z7LfmOp6HJy/GmZCZbR+B/lsarsF/TsHj4Me/EziKGP02OauCNe2TBe9a4YJxMveE1T8
	3MbZ0AkozHuGQqr5vI64nnCHhLevFim79ARtCCxd7fUNHAQtcb4RRf6AgmC6i+3Dj+Dd
	SEwA==
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=TfHmtY6NIH1X5PMaLLep9XGgQNqYJbVNGwgrxEHHovI=;
	b=jPni0WZmxSDzcKXN3Ei/2altaaGWX5kBqvNR/+JCo7HmJUYWRkABuogJ4RxTT0iqTG
	BiqtFx413bub7T1LCTSWR3gralLzumSzZ7XLwvIEvvikQFx0QUYoj1KqaVhX8p+uw9a7
	2mKF5VMU6/K+e9pM/qqnFkugR2kN4vw9e9LtqKv9+m4BgNx/IT6nJQPWeHyAgQdkyzR+
	Ks6AfTxiRDzDMHl3iGfVIpMP+LV0FTxoWkZaMhGe8Xp7ORYi8vTTvkNhxUgab63Inm5q
	4fUoqiCpQGbO7Tmlc2f/qLnlpFuqVDHyNxupmIHeRlnZE8GkfGZoAL8XPnchDkbHQ7Gl
	3TZQ==
X-Gm-Message-State: AHPjjUjnLrz5hiOuGDwyzV8lVyy25F0my3OhH+563j5IP8oApUToUn1J
	ESFulk+gZdcgEz5ANiL3f6U3DX6uewM0mZAMWFXDTw==
X-Google-Smtp-Source: AOwi7QAD4/TOF0fLbJUMCNbozYnGVzOe7nafWVo9BabiNVZgBnawYoCOcTtCqaIVaPgXVD/edSF5oQNmg34BLVn2yJ0=
X-Received: by 10.176.74.8 with SMTP id q8mr5081949uae.129.1506743581146; Fri,
	29 Sep 2017 20:53:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.79.199 with HTTP; Fri, 29 Sep 2017 20:53:00 -0700 (PDT)
Received: by 10.31.79.199 with HTTP; Fri, 29 Sep 2017 20:53:00 -0700 (PDT)
In-Reply-To: <5F7A4F74-B108-4E30-A3F4-4125BBD0F819@friedenbach.org>
References: <CAEgR2PGCZ=F85yjAbZgC6NtzhpdgBL3n4M2jowN12wJ7x-Ai1A@mail.gmail.com>
	<CAEgR2PGrxDQE0k8WX4XXz9GN-RAL6JB51ST9Hdz=ba36gRCa6A@mail.gmail.com>
	<CAEgR2PFjt=ihzRBhNXbHTAJz1R+3vz8o-zRZkDA3iBo39x9cTQ@mail.gmail.com>
	<CAEgR2PFfSjJjkTYq+DAmTzmkHPxqhn6fUDoXTzrRebz+OoUgqw@mail.gmail.com>
	<CAEgR2PG5ZueHKDXbsPDEjQG7xAYBa_JAtPZo9n1V2=STC1srpA@mail.gmail.com>
	<CAEgR2PGPQ1e9SmoWOS3V+N9v+OWiM4g3nPN3d9urc+DfkWEJ7A@mail.gmail.com>
	<CAEgR2PEKkHH6+Sh8cQGF83-s1tpwQZgd0fiuNz_xyWu0mUPfCA@mail.gmail.com>
	<CAEgR2PEyWFO1RFohVEpcb-M7aM-8xjCFvDPeJPD4zF4yTCyZ0A@mail.gmail.com>
	<CAEgR2PGrf+4pQRyNC_xKVEKXimKTWveGK9q6YJeZkG0_r=8tkg@mail.gmail.com>
	<5F7A4F74-B108-4E30-A3F4-4125BBD0F819@friedenbach.org>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Sat, 30 Sep 2017 05:53:00 +0200
Message-ID: <CABm2gDqXXvNCZ7EyKuwudB5J0YDX7hNnXHPZNxTO0_JsM+yNHg@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Mark <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary="f403045f6d64ec220c055a60136d"
X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=disabled
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Daniele Pinna <daniele.pinna@gmail.com>
Subject: Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets
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: Sat, 30 Sep 2017 03:53:02 -0000

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

I really don't see how this "outlier behaviour" can be prevented. I think
it would be the norm even with your proposed "fix". Perhaps I'm missing
something too.

On 29 Sep 2017 5:24 pm, "Mark Friedenbach via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This is correct. Under assumptions of a continuous mempool model however
> this should be considered the outlier behavior, other than a little bit of
> empty space at the end, now and then. A maximum fee rate calculated as a
> filter over past block rates could constrain this outlier behavior from
> ever happening too.
>
> > On Sep 29, 2017, at 3:43 AM, Daniele Pinna <daniele.pinna@gmail.com>
> wrote:
> >
> > Maybe I'm getting this wrong but wouldn't this scheme imply that a miner
> is incentivized to limit the amount of transactions in a block to capture
> the maximum fee of the ones included?
> >
> > As an example, mined blocks currently carry ~0.8 btc in fees right now.
> If I were to submit a transaction paying 1 btc in maximal money fees, then
> the miner would be incentivized to include my transaction alone to avoid
> that lower fee paying transactions reduce the amount of fees he can earn
> from my transaction alone. This would mean that I could literally clog the
> network by paying 1btc every ten minutes.
> >
> > Am I missing something?
> >
> > Daniele
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto">I really don&#39;t see how this &quot;outlier behaviour&q=
uot; can be prevented. I think it would be the norm even with your proposed=
 &quot;fix&quot;. Perhaps I&#39;m missing something too.</div><div class=3D=
"gmail_extra"><br><div class=3D"gmail_quote">On 29 Sep 2017 5:24 pm, &quot;=
Mark Friedenbach via bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrot=
e:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is correct. =
Under assumptions of a continuous mempool model however this should be cons=
idered the outlier behavior, other than a little bit of empty space at the =
end, now and then. A maximum fee rate calculated as a filter over past bloc=
k rates could constrain this outlier behavior from ever happening too.<br>
<br>
&gt; On Sep 29, 2017, at 3:43 AM, Daniele Pinna &lt;<a href=3D"mailto:danie=
le.pinna@gmail.com">daniele.pinna@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Maybe I&#39;m getting this wrong but wouldn&#39;t this scheme imply th=
at a miner is incentivized to limit the amount of transactions in a block t=
o capture the maximum fee of the ones included?<br>
&gt;<br>
&gt; As an example, mined blocks currently carry ~0.8 btc in fees right now=
. If I were to submit a transaction paying 1 btc in maximal money fees, the=
n the miner would be incentivized to include my transaction alone to avoid =
that lower fee paying transactions reduce the amount of fees he can earn fr=
om my transaction alone. This would mean that I could literally clog the ne=
twork by paying 1btc every ten minutes.<br>
&gt;<br>
&gt; Am I missing something?<br>
&gt;<br>
&gt; Daniele<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div></div>

--f403045f6d64ec220c055a60136d--