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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <stephencalebmorse@gmail.com>) id 1Z5bCW-000836-Od
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 14:53:56 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.176 as permitted sender)
client-ip=209.85.160.176;
envelope-from=stephencalebmorse@gmail.com;
helo=mail-yk0-f176.google.com;
Received: from mail-yk0-f176.google.com ([209.85.160.176])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z5bCR-0003Yb-Sz
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 14:53:56 +0000
Received: by ykfl8 with SMTP id l8so68102014ykf.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Jun 2015 07:53:46 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.170.75.194 with SMTP id r185mr13887485ykr.69.1434639226356;
Thu, 18 Jun 2015 07:53:46 -0700 (PDT)
Received: by 10.37.203.13 with HTTP; Thu, 18 Jun 2015 07:53:46 -0700 (PDT)
In-Reply-To: <CAMmvJxGioDZ7WbwyeLgh9+PNgvKmrxjrqTFjgT0WJ7LCO+0QOQ@mail.gmail.com>
References: <CAMmvJxGioDZ7WbwyeLgh9+PNgvKmrxjrqTFjgT0WJ7LCO+0QOQ@mail.gmail.com>
Date: Thu, 18 Jun 2015 10:53:46 -0400
Message-ID: <CABHVRKSc_bzxhu57P3BmYPON+LrTmeKMruAup78eGuvecrGjfQ@mail.gmail.com>
From: Stephen Morse <stephencalebmorse@gmail.com>
To: Team Ninki <admin@ninkip2p.com>
Content-Type: multipart/alternative; boundary=001a1139bbe277c7500518cbf9e8
X-Spam-Score: -0.6 (/)
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
(stephencalebmorse[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
X-Headers-End: 1Z5bCR-0003Yb-Sz
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Ninki Wallet view on blocksize debate
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: Thu, 18 Jun 2015 14:53:56 -0000
--001a1139bbe277c7500518cbf9e8
Content-Type: text/plain; charset=UTF-8
Ben,
How does your wallet calculate the fee that should be paid to miners? Do
they automatically adjust when transactions take a long time to be
confirmed? And how does it respond when transactions are not mined
successfully, such as when blocks are full?
I strongly urge Gavin to withdraw from this standoff and work with the
> bitcoin core devs via the existing and successful bip process.
>
The BIP process has not resulted in any hard forks, so this is a little
different. While I don't like M&G's proposed solution of convincing miners
and services to switch to Bitcoin-XT, I recognize that it is done out of a
sense of urgency. These types of changes take a long time to roll out, and
we should start them before it is too late.
This whole debate comes down to: what is more risky, a consensus hard fork
or letting bitcoin exceed its imposed capacity limits? The former could
result in many services not being compatible and even loss of funds. The
latter could result in software failures, instability, and inability to
transact: essentially, what bitcoin is supposed to be good at. Both are
dangerous and could result in a significant loss of public confidence.
Something needs to be done, that's for sure. In the short term, I think we
need to do one of two things:
1. All miners and wallet developers need to upgrade to support
first-safe RBF, to allow for double spending one's own transactions when
they lack sufficient fees to merit confirmations. Wallets also need to
randomly request transactions from blocks to see what kind of fees are
being paid to get confirmations, so that fees can be paid dynamically
instead of with hard-coded values.
2. We can implement either Gavin's or Jeff Garzik's proposal to change
the consensus parameters around the block size limit.
So Ben, if really don't think that going with #2 is the right way to go
(even though everyone agrees that we will need to increase the block size
limit eventually anyway, why not now?), then I hope you start to work hard
on implementing #1 so that your wallet software can handle hitting capacity
limits gracefully.
Best,
Stephen
--001a1139bbe277c7500518cbf9e8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">Ben,=
</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">How d=
oes your wallet calculate the fee that should be paid to miners? Do they au=
tomatically adjust when transactions take a long time to be confirmed? And =
how does it respond when transactions are not mined successfully, such as w=
hen blocks are full?=C2=A0</div><div class=3D"gmail_quote"><br><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"><div dir=3D"ltr"><div style=3D"font-size:12.8000001907349px">I strongl=
y urge Gavin to withdraw from this standoff and work with the bitcoin core =
devs via the existing and successful bip process.</div></div></blockquote><=
div>=C2=A0</div><div>The BIP process has not resulted in any hard forks, so=
this is a little different. While I don't like M&G's proposed =
solution of convincing miners and services to switch to Bitcoin-XT, I recog=
nize that it is done out of a sense of urgency. These types of changes take=
a long time to roll out, and we should start them before it is too late.</=
div><div><br></div><div>This whole debate comes down to: what is more risky=
, a consensus hard fork or letting bitcoin exceed its imposed capacity limi=
ts? The former could result in many services not being compatible and even =
loss of funds. The latter could result in software failures, instability, a=
nd inability to transact: essentially, what bitcoin is supposed to be good =
at. Both are dangerous and could result in a significant loss of public con=
fidence.=C2=A0</div><div><br></div><div>Something needs to be done, that=
9;s for sure. In the short term, I think we need to do one of two things:</=
div><div><ol><li>All miners and wallet developers need to upgrade to suppor=
t first-safe RBF, to allow for double spending one's own transactions w=
hen they lack sufficient fees to merit confirmations. Wallets also need to =
randomly request transactions from blocks to see what kind of fees are bein=
g paid to get confirmations, so that fees can be paid dynamically instead o=
f with hard-coded values.</li><li>We can implement either Gavin's or Je=
ff Garzik's proposal to change the consensus parameters around the bloc=
k size limit.</li></ol><div>So Ben, if really don't think that going wi=
th #2 is the right way to go (even though everyone agrees that we will need=
to increase the block size limit eventually anyway, why not now?), then I =
hope you start to work hard on implementing #1 so that your wallet software=
can handle hitting capacity limits gracefully.</div></div><div><br></div><=
div>Best,<br>Stephen</div><div><br></div></div></div></div>
--001a1139bbe277c7500518cbf9e8--
|
