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
|
Return-Path: <jtwinslow@juno.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 044DC20C9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 19:24:47 +0000 (UTC)
X-Greylist: delayed 00:06:41 by SQLgrey-1.7.6
Received: from outbound-mail02.dca.untd.com (outbound-mail02.dca.untd.com
[64.136.47.36])
by smtp1.linuxfoundation.org (Postfix) with SMTP id 31D77134
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 19:24:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juno.com; s=alpha;
t=1443641085; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; l=0;
h=Subject:To:Cc:From:Message-ID:Date:Content-Type;
b=d15OnygTQwmQTwS2F737ar/112C4enYF9f6vuMlWAas4DS3eZYeF4nCtfKuwcoJc0
TCMpfdZ5uLdJi2864vd5hwtjMP93Ob02KTDy2x76pcJT/UC36ZUwUYjvRrDQLP1/nx
PA3pVtH3Umc+KDYgTEPT38h/FmVGQttIJd1mwfNM=
Received: from [192.168.19.2] (66-87-71-201.pools.spcsdns.net [66.87.71.201])
by smtpout04.dca.untd.com with SMTP id AABMA2PK2A432PVS
(sender <jtwinslow@juno.com>); Wed, 30 Sep 2015 12:17:12 -0700 (PDT)
To: =?UTF-8?Q?Jorge_Tim=c3=b3n?= <jtimon@jtimon.cc>,
Mike Hearn <hearn@vinumeris.com>
References: <20150927185031.GA20599@savin.petertodd.org>
<20150929200302.GA5051@amethyst.visucore.com>
<87wpv8ft61.fsf@rustcorp.com.au>
<CALqxMTGOmU76NHP8o7TyLq2t3EJTTyMoz4zCZQFczJX5+O=bOQ@mail.gmail.com>
<CA+w+GKRd69kOiDKE_56vnbZ=Hx4hhXqtzpsVT6Z+fx005zW_MQ@mail.gmail.com>
<CABm2gDqkTizK1TtGGM4fFp4xWMUhAstVOvnJ4_3VKaGNoSX0eg@mail.gmail.com>
From: John Winslow <jtwinslow@juno.com>
Message-ID: <560C3536.1070503@juno.com>
Date: Wed, 30 Sep 2015 12:17:10 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CABm2gDqkTizK1TtGGM4fFp4xWMUhAstVOvnJ4_3VKaGNoSX0eg@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-Ip: 66.87.71.201
X-UNTD-BodySize: 3203
X-ContentStamp: 21:10:270695597
X-MAIL-INFO: 0f10909510e9e9919020a0f020e4a055c171050d0d70a180f5a595b981953d60b990819595fd90208499913d9020e02900f400e14961a0f100f9
X-UNTD-OriginStamp: 3BHtMxlTjQpeqTE3t6I7r5ps6Aq/+SIJjWPIqkCt/oTWtbyL9SGNpA==
X-UNTD-Peer-Info: 10.171.42.34|smtpout04.dca.untd.com|smtpout04.dca.untd.com|jtwinslow@juno.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,
T_DKIM_INVALID autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Wed, 30 Sep 2015 19:24:47 -0000
Two observations from a Bitcoin investor and non-programmer:
1) I think it's possible that those who are adamantly opposed to a soft
fork may be largely (if not completely) correct on purely technical
terms, but that they also may be underestimating the risk of a
contentious hardfork.
2) The downsides of a softfork are unclear because they seem to be based
primarily on inelegant coding, not that it couldn't be made to work.
As a Bitcoin investor, I am becoming increasingly concerned that the
rancorous and mostly unproductive debates occurring here daily are
slowly closing the window of opportunity for Bitcoin to succeed. If this
were a start-up or public company, the stock would be plunging. Why?
Simple. Uncertainty. While I think (and I'm sure most here would agree)
that these debates are necessary (and due to Bitcoin's decentralized
nature perhaps even necessary to have in a public forum) but when these
debates go on and on indefinitely thereby reducing confidence in
Bitcoin's future something different needs to be done. In a public
company or startup these debates would be happening in private with a an
eye on competition, public/market perception, timing and anticipation of
a shareholder-value-increasing outcome followed by a press release or
marketing campaign. And the clock is always ticking.
My suggestion is the top devs from both sides need to get together
offline and decide what the best compromise would be and then publicly
promote a non-contentious solution that balances the technical with
market concerns that everyone can get behind. Continuing to debate
technical issues ad-infinitum without compromise or waiting until the
Hong Kong conference in December to start making a decision while
Bitcoin dies on the vine should not be an option. If anything, the
conference should be the time at the end of which a confidence-inspiring
technical roadmap is announced.
Further, I would like to add that in my perception what Bitcoin needs to
and can easily become is essentially a public utility/backbone
blockchain (like IP is to the internet) upon which all current and
future blockchain stakeholders should see as their best and cheapest
option for entering the space. For this to happen Bitcoin, from a user's
standpoint needs to be simple and reliable, and from an
investor/developer standpoint cost-effective and scalable. I don't see
why this can't happen.
JTW
On 9/30/2015 8:55 AM, Jorge Timón via bitcoin-dev wrote: On Wed, Sep 30,
2015 at 2:30 PM, Mike Hearn via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>> This will not change the fact that the rollout strategy is bad and nobody
>> has answered my extremely basic question: why is it being done in this way,
>> given the numerous downsides?
> You seem to be the only one who thinks that softforks have "numerous
> downsides" over hardforks.
> So everybody just basically disagrees with the assumption in your
> question and thus nobody can answer it.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
|
