summaryrefslogtreecommitdiff
path: root/83/88bac93912704f6b2b00593b50ec9b963292d6
blob: e71f0f99c45c28c8691c2eafdcb7d372fe2e8014 (plain)
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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <jeremie.dl@gmail.com>) id 1YqRiZ-0003un-Si
	for bitcoin-development@lists.sourceforge.net;
	Thu, 07 May 2015 19:44:23 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.218.52 as permitted sender)
	client-ip=209.85.218.52; envelope-from=jeremie.dl@gmail.com;
	helo=mail-oi0-f52.google.com; 
Received: from mail-oi0-f52.google.com ([209.85.218.52])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YqRiV-0005Im-9M
	for bitcoin-development@lists.sourceforge.net;
	Thu, 07 May 2015 19:44:23 +0000
Received: by oift201 with SMTP id t201so42222612oif.3
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 07 May 2015 12:44:13 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.65.164 with SMTP id y4mr189047obs.57.1431027853913; Thu,
	07 May 2015 12:44:13 -0700 (PDT)
Received: by 10.202.210.88 with HTTP; Thu, 7 May 2015 12:44:13 -0700 (PDT)
In-Reply-To: <CANEZrP0TKWESj3-h4k=Shd0R5SXAyGe31C3tQRq7UwK=y4+JTg@mail.gmail.com>
References: <554A91BE.6060105@bluematt.me>
	<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
	<CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
	<CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com>
	<CABm2gDqd6iHRUDKZWWTudcC1QkYa+rCuHjz7pMC2K1Db8wpgfA@mail.gmail.com>
	<CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com>
	<CABsx9T2Nxvr4fqREMw3_LXftzsxrUAR1+9sVMa8_EpTnH1nN1Q@mail.gmail.com>
	<CAPWm=eUFe7dKJCLeNACZ4n9vw0Xj9rHVM_RRLSczGXNU-ShR2w@mail.gmail.com>
	<CANEZrP1tCda9EbYgYu5QHN8ZgBCtGP7zRiDaXnq-rWU0ZHR9NQ@mail.gmail.com>
	<CAJHLa0Nrp4QEQqrBu6Tb+dohxX2VhWKMnO40xscZF1OJdfPF-A@mail.gmail.com>
	<CANEZrP0bmh5braGO5OKTNJU9VC_9=_1RDqHMx=aJBxT1w-q8oA@mail.gmail.com>
	<CABm2gDozyxovazcNEjWsRK0KzNJotWTg9X4m3aOfx7Gr_KprxQ@mail.gmail.com>
	<CANEZrP0TKWESj3-h4k=Shd0R5SXAyGe31C3tQRq7UwK=y4+JTg@mail.gmail.com>
Date: Thu, 7 May 2015 21:44:13 +0200
Message-ID: <CAJqsvLB4WkevHPTGbV_cxoDAU3CZ3=2FvHXtu_3vO9LXRVF2Ow@mail.gmail.com>
From: =?UTF-8?B?SsOpcsOpbWllIER1Ym9pcy1MYWNvc3Rl?= <jeremie.dl@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.2 (+)
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
	(jeremie.dl[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.2 MISSING_HEADERS        Missing To: header
	-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
	1.6 MALFORMED_FREEMAIL Bad headers on message from free email service
X-Headers-End: 1YqRiV-0005Im-9M
Subject: Re: [Bitcoin-development] Block Size Increase
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, 07 May 2015 19:44:23 -0000

Any proposal to switch to a new hardcorded value so we have time to
*really* figure out later what's next and all implications, is a road
to a gigantic issue later when we want to switch to that "next".

Sure we would have more time to think about, research all
implications, simulate, discuss, etc. But the ability then to agree
enough on a change to roll it out successfully will be much smaller,
because of the economy being built on top of Bitcoin being much larger
and the technical specifications of Bitcoin being closer to a complete
freeze.

What I'm trying to say is that we should look at long term lasting
solutions even if it takes more effort and time right now and puts the
network into some "troubles" for a while, because they're short term
"troubles". (You define "troubles", depending on which side you stand
at the moment...).

I personally believe in adaptive block size mechanisms, because:

(i) common sense tells me harcoding is never a solution for a system
    whose usage is for many aspects unpredictable
(ii) we can't rely on human consensus to adapt it (seeing the mess
     it is already this time).

It would have the advantage to place this block size issue entirely as
part of the algorithmic contract you agree on when you use Bitcoin,
similar to the difficulty adapation or the block reward.


J=C3=A9r=C3=A9mie


2015-05-07 21:37 GMT+02:00 Mike Hearn <mike@plan99.net>:
>
>> These statements may even be true, but they're no logical conclusions
>> even if they seem obvious to you.
>> I don't think those claims are strictly true, specially because they
>> involve predictions about what people will do.
>> But if they're true they require some proof or at least some explanation=
.
>
>
> Thank you for your patience, Jorge.
>
> I have written up an explanation of what I think will happen if we run ou=
t
> of capacity:
>
>    https://medium.com/@octskyward/crash-landing-f5cc19908e32
>
> Now I'm going to go eat some dinner :)
>
> -------------------------------------------------------------------------=
-----
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>