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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1Ysgkm-00061w-PS
for bitcoin-development@lists.sourceforge.net;
Thu, 14 May 2015 00:11:56 +0000
Received: from mail-wi0-f170.google.com ([209.85.212.170])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Ysgkk-0000kS-64
for bitcoin-development@lists.sourceforge.net;
Thu, 14 May 2015 00:11:56 +0000
Received: by widdi4 with SMTP id di4so219803809wid.0
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 May 2015 17:11:48 -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:date
:message-id:subject:from:to:cc:content-type;
bh=iqe9HrvsYPzGW/9IAfRxUpArpsJhVRQfvXqzOvouwyc=;
b=FCkaAASgL9N8TCQ7fAic/qYqEBkRofyg3ntfeWc6RrOTJs8yV508Wy1QhV/dyA9Zc8
5iSVBpJUt9KbqVoP9nmmmwJtT3QZVagRu2vkAmfaFQKp/C3RRRw12+9idF8iv776zOla
0+4bEqfrdpdW1BXIm4sEF8BUR8kRp63EwXsYH5tPPBSNfMuxtEH1/vBMAeQ9AEn0g+J+
2a1dd9nU9Os4U7sFtB5BXqBgB7Ky65bvlHACYyU4mvhpI2tgteQ2VCnlIZEdZg3mAxLR
h5ghMPkYU8etQ1fVsNuHd4eDi35yw/f9WdAiyUyaWl5gC48Fq4aQdZrToMD0mSEfAIcV
Q3nQ==
X-Gm-Message-State: ALoCoQmRAL2kDLJw05zXTSOaq9UxwGATXtfOjskJtNRHH4q61WKCJLqCWecFCIYo6UCcBjBskpLr
MIME-Version: 1.0
X-Received: by 10.194.60.164 with SMTP id i4mr2497613wjr.133.1431562308048;
Wed, 13 May 2015 17:11:48 -0700 (PDT)
Received: by 10.194.127.97 with HTTP; Wed, 13 May 2015 17:11:47 -0700 (PDT)
In-Reply-To: <CABsx9T1VgxEJWxrYTs+2hXGnGrSLGJ6mVcAexjXLvK7Vu+e3EA@mail.gmail.com>
References: <5550D8BE.6070207@electrum.org>
<ce3d34c92efd1cf57326e4679550944e@national.shitposting.agency>
<CABsx9T1VgxEJWxrYTs+2hXGnGrSLGJ6mVcAexjXLvK7Vu+e3EA@mail.gmail.com>
Date: Thu, 14 May 2015 02:11:47 +0200
Message-ID: <CABm2gDoQ-atjWKB0c6AC1ZQ9fy22ceFtHHwpLmnX8DLW4DAgYA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1Ysgkk-0000kS-64
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Long-term mining incentives
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, 14 May 2015 00:11:56 -0000
On Mon, May 11, 2015 at 7:29 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> I think long-term the chain will not be secured purely by proof-of-work. I
> think when the Bitcoin network was tiny running solely on people's home
> computers proof-of-work was the right way to secure the chain, and the only
> fair way to both secure the chain and distribute the coins.
>
> See https://gist.github.com/gavinandresen/630d4a6c24ac6144482a for some
> half-baked thoughts along those lines. I don't think proof-of-work is the
> last word in distributed consensus (I also don't think any alternatives are
> anywhere near ready to deploy, but they might be in ten years).
Or never, nobody knows at this point.
> I also think it is premature to worry about what will happen in twenty or
> thirty years when the block subsidy is insignificant. A lot will happen in
> the next twenty years. I could spin a vision of what will secure the chain
> in twenty years, but I'd put a low probability on that vision actually
> turning out to be correct.
I think is very healthy to worry about that since we know it's
something that will happen.
The system should work without subsidies.
> That is why I keep saying Bitcoin is an experiment. But I also believe that
> the incentives are correct, and there are a lot of very motivated, smart,
> hard-working people who will make it work. When you're talking about trying
> to predict what will happen decades from now, I think that is the best you
> can (honestly) do.
Lightning payment channels may be a new idea, but payment channels are
not, and nobody is using them.
They are the best solution to scalability we have right now,
increasing the block size is simply not a solution, it's just kicking
the can down the road (while reducing the incentives to deploy real
solutions like payment channels).
Not worrying about 10 years in the future but asking people to trust
estimates and speculations about how everything will burn in 2 years
if we don't act right now seems pretty arbitrary to me.
One could just as well argue that there's smart hard-working people
that will solve those problems before they hit us.
It is true that the more distant the future you're trying to predict
is, the more difficult it is to predict it, but any threshold that
separates "relevant worries" from "too far in the future to worry
about it" will always be arbitrary.
Fortunately we don't need to all share the same time horizon for what
is worrying and what is not.
What we need is a clear criterion for what is acceptable for a
hardfork and a general plan to deploy them:
-Do all the hardfork changes need to be uncontroversial? How do we
define uncontroversial?
-Should we maintain and test implementation of hardfork whises that
seem too small to justify a hardfork on their own (ie time travel fix,
allowing to sign inputs values...) to also deploy them at the same
time that other more necessary hardforks?
I agree that hardforks shouldn't be impossible and in that sense I'm
glad that you started the hardfork debate, but I believe we should be
focusing on that debate rather than the block size one.
Once we have a clear criteria, hopefully the block size debate should
become less noisy and more productive.
|
