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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <voisine@gmail.com>) id 1YqrUi-0000Rk-2z
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 23:15:48 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.49 as permitted sender)
client-ip=209.85.192.49; envelope-from=voisine@gmail.com;
helo=mail-qg0-f49.google.com;
Received: from mail-qg0-f49.google.com ([209.85.192.49])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YqrUg-0007VG-Nl
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 23:15:48 +0000
Received: by qgeb100 with SMTP id b100so43823599qge.3
for <bitcoin-development@lists.sourceforge.net>;
Fri, 08 May 2015 16:15:41 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.31.7 with SMTP id f7mr799270qkf.9.1431126941345; Fri, 08
May 2015 16:15:41 -0700 (PDT)
Received: by 10.140.91.37 with HTTP; Fri, 8 May 2015 16:15:41 -0700 (PDT)
In-Reply-To: <CAOG=w-tBokq6FQkEbH-w0oF0Mg7EG=Qmo7G_WAxvK2K06trQZw@mail.gmail.com>
References: <16096345.A1MpJQQkRW@crushinator>
<CAOG=w-szbLgc1jLpkE_uMa3bkFTi-RiBEaQ6Y-u5aKLBC2HvUg@mail.gmail.com>
<CACq0ZD6hkyU0ABmM6FDKxTszjYk=5zrhkWn2-9RAtzcbyydokg@mail.gmail.com>
<CAOG=w-tBokq6FQkEbH-w0oF0Mg7EG=Qmo7G_WAxvK2K06trQZw@mail.gmail.com>
Date: Fri, 8 May 2015 16:15:41 -0700
Message-ID: <CACq0ZD7hm5_moqkBOPDRUTnQf16rPggRiLf5ZwBNLbrrgajttA@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=001a1147bae2f7af9f05159a34b2
X-Spam-Score: 0.1 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(voisine[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.7 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YqrUg-0007VG-Nl
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 23:15:48 -0000
--001a1147bae2f7af9f05159a34b2
Content-Type: text/plain; charset=UTF-8
That's fair, and we've implemented child-pays-for-parent for spending
unconfirmed inputs in breadwallet. But what should the behavior be when
those options aren't understood/implemented/used?
My argument is that the less risky, more conservative default fallback
behavior should be either non-propagation or delayed confirmation, which is
generally what we have now, until we hit the block size limit. We still
have lots of safe, non-controversial, easy to experiment with options to
add fee pressure, causing users to economize on block space without
resorting to dropping transactions after a prolonged delay.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Fri, May 8, 2015 at 3:45 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:
> 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.
>
--001a1147bae2f7af9f05159a34b2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">That's fair, and we've implemented child-pays-for-=
parent for spending unconfirmed inputs in breadwallet. But what should the =
behavior be when those options aren't understood/implemented/used?<div>=
<br></div><div>My argument is that the less risky, more conservative defaul=
t fallback behavior should be either non-propagation or delayed confirmatio=
n, which is generally what we have now, until we hit the block size limit. =
We still have lots of safe, non-controversial, easy to experiment with opti=
ons to add fee pressure, causing users to economize on block space without =
resorting to dropping transactions after a prolonged delay.</div><div class=
=3D"gmail_extra"><br><div><div class=3D"gmail_signature"><div dir=3D"ltr"><=
div><div dir=3D"ltr"><div>Aaron Voisine</div><div>co-founder and CEO<br><a =
href=3D"http://breadwallet.com" target=3D"_blank">breadwallet.com</a></div>=
</div></div></div></div></div>
<br><div class=3D"gmail_quote">On Fri, May 8, 2015 at 3:45 PM, Mark Frieden=
bach <span dir=3D"ltr"><<a href=3D"mailto:mark@friedenbach.org" target=
=3D"_blank">mark@friedenbach.org</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><span class=3D"">On Fri, May 8, 2015 at 3:43=
PM, Aaron Voisine <span dir=3D"ltr"><<a href=3D"mailto:voisine@gmail.co=
m" target=3D"_blank">voisine@gmail.com</a>></span> wrote:<br></span><div=
class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">This is a clever way to tie block s=
ize to fees.<div><br></div><div>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.</div></div></blockquote><=
div><br></div></span><div>There are already solutions to this which are wai=
ting to be deployed as default policy to bitcoind, and need to be implement=
ed in other clients: replace-by-fee and child-pays-for-parent. <br></div></=
div></div></div>
</blockquote></div><br></div></div>
--001a1147bae2f7af9f05159a34b2--
|
