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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mark@friedenbach.org>) id 1Yqr1d-0003uF-M9
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 22:45:45 +0000
X-ACL-Warn:
Received: from mail-ig0-f170.google.com ([209.85.213.170])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yqr1c-00045t-LY
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 22:45:45 +0000
Received: by igbsb11 with SMTP id sb11so33535271igb.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 08 May 2015 15:45:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=xp7NZ2wCo3pepInmtij1/SV/WKBHuwkC0e+FDGjriYk=;
b=THWvd1OJjWMQV5sKjr3DtByRMKSw2Tqa8J6H7MfWaJG/dJbFn5XzlN1hZd8UC2VFo6
9isJwyJxZAKt3NcDM1h2YAbTANYa0D4jGxy2bm0LE3BTJhYkSom6kIhY1xo9g4qNtmc0
44ytqYeHQdQTdILrNKPppcMHeQ8ZlqyINZ6jvUKDBbIujAsCCZEOxVyTqr4V7CZvcB9q
rpEKlpprti6O/gjiDlhMTTgqUmBMU7dBFYHq/YES1BRMsatAmwteE2nbuK2XxXhNVTci
3AaWKT40nTJrmAu9LqRjVX1rFzrNsZrVrDAbJJ7dZEhzxZlx8ssWlBfIMSTlUuF6b0g0
4R6g==
X-Gm-Message-State: ALoCoQmE46tj7SBkrx3Ut04cZHAWf8XosDK3nb1uV1zDXD5Fql90K2OhwGvyYcLvEPfDKMxGVKnI
X-Received: by 10.50.21.1 with SMTP id r1mr1780455ige.46.1431125139370; Fri,
08 May 2015 15:45:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.25.203 with HTTP; Fri, 8 May 2015 15:45:19 -0700 (PDT)
X-Originating-IP: [173.228.107.141]
In-Reply-To: <CACq0ZD6hkyU0ABmM6FDKxTszjYk=5zrhkWn2-9RAtzcbyydokg@mail.gmail.com>
References: <16096345.A1MpJQQkRW@crushinator>
<CAOG=w-szbLgc1jLpkE_uMa3bkFTi-RiBEaQ6Y-u5aKLBC2HvUg@mail.gmail.com>
<CACq0ZD6hkyU0ABmM6FDKxTszjYk=5zrhkWn2-9RAtzcbyydokg@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Fri, 8 May 2015 15:45:19 -0700
Message-ID: <CAOG=w-tBokq6FQkEbH-w0oF0Mg7EG=Qmo7G_WAxvK2K06trQZw@mail.gmail.com>
To: Aaron Voisine <voisine@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b6d8f948fc9f1051599c970
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Yqr1c-00045t-LY
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
function
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2015 22:45:45 -0000
--047d7b6d8f948fc9f1051599c970
Content-Type: text/plain; charset=UTF-8
On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine <voisine@gmail.com> wrote:
> This is a clever way to tie block size to fees.
>
> I would just like to point out though that it still fundamentally is using
> hard block size limits to enforce scarcity. Transactions with below market
> fees will hang in limbo for days and fail, instead of failing immediately
> by not propagating, or seeing degraded, long confirmation times followed by
> eventual success.
>
There are already solutions to this which are waiting to be deployed as
default policy to bitcoind, and need to be implemented in other clients:
replace-by-fee and child-pays-for-parent.
--047d7b6d8f948fc9f1051599c970
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine <span dir=3D=
"ltr"><<a href=3D"mailto:voisine@gmail.com" target=3D"_blank">voisine@gm=
ail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">This is a cleve=
r way to tie block size to fees.<div><br></div><div>I would just like to po=
int out though that it still fundamentally is using hard block size limits =
to enforce scarcity. Transactions with below market fees will hang in limbo=
for days and fail, instead of failing immediately by not propagating, or s=
eeing degraded, long confirmation times followed by eventual success.</div>=
</div></blockquote><div><br></div><div>There are already solutions to this =
which are waiting to be deployed as default policy to bitcoind, and need to=
be implemented in other clients: replace-by-fee and child-pays-for-parent.=
<br></div></div></div></div>
--047d7b6d8f948fc9f1051599c970--
|
