summaryrefslogtreecommitdiff
path: root/7a/d2b7f9728e27b8c2859f7c6f12ecba53d8e95f
blob: 984c6e85bb0a27504a1d04005e931de21c517682 (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
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
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 <etotheipi@gmail.com>) id 1Um5qF-0004Vv-Aw
	for bitcoin-development@lists.sourceforge.net;
	Mon, 10 Jun 2013 17:25:15 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.172 as permitted sender)
	client-ip=209.85.216.172; envelope-from=etotheipi@gmail.com;
	helo=mail-qc0-f172.google.com; 
Received: from mail-qc0-f172.google.com ([209.85.216.172])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Um5qD-0006ND-MT
	for bitcoin-development@lists.sourceforge.net;
	Mon, 10 Jun 2013 17:25:15 +0000
Received: by mail-qc0-f172.google.com with SMTP id j10so3859074qcx.3
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 10 Jun 2013 10:25:08 -0700 (PDT)
X-Received: by 10.49.0.244 with SMTP id 20mr12022393qeh.50.1370885108162;
	Mon, 10 Jun 2013 10:25:08 -0700 (PDT)
Received: from [192.168.1.52] (c-76-111-96-126.hsd1.md.comcast.net.
	[76.111.96.126]) by mx.google.com with ESMTPSA id
	c10sm14999392qao.10.2013.06.10.10.25.07
	for <bitcoin-development@lists.sourceforge.net>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 10 Jun 2013 10:25:07 -0700 (PDT)
Message-ID: <51B60BF1.3020701@gmail.com>
Date: Mon, 10 Jun 2013 13:25:05 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CAPaL=UWcKmnChw0zYGVduzHHdQ-AgG7uqbCLvjjuW6Q67zmS0g@mail.gmail.com>
	<51B602D8.5030706@monetize.io>
In-Reply-To: <51B602D8.5030706@monetize.io>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/alternative;
	boundary="------------030609060502040605000400"
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
	(etotheipi[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: 1Um5qD-0006ND-MT
Subject: Re: [Bitcoin-development] Proposal: Vote on the blocksize limit
 with proof-of-stake voting
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: Mon, 10 Jun 2013 17:25:15 -0000

This is a multi-part message in MIME format.
--------------030609060502040605000400
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

One major problem I see with this, no matter how well-thought-out it is,
it's unlikely that those with money will participate.  Those with the
most stake, likely have their private keys behind super-secure
accessibility barriers, and are not likely to go through the effort just
to sign votes.  Not only that, but it would require them to reveal their
public key, which while isn't technically so terrible, large amounts of
money intended to be kept in storage for 10+ years will prefer to avoid
any exposure at all, in the oft-chance that QCs come around a lot
earlier than we expected.  Sure, the actual risk should be pretty much
non-existent, but some of the most paranoid folks are probably the same
ones who have a lot of funds and want 100.00% of the security that is
possible.   They will see this as wildly inconvenient.

I think this a great thought experiment, and I'd like to see where this
idea goes, in terms of designing ways for a decentralized community to
find consensus for important decisions, but I don't think that any idea
that requires users to dig up their private keys is going to be feasible
(or possibly reconstruct them from pieces and/or get multiple
signatures).  Especially if the system requires some kind of persistent
voting.

-Alan


On 06/10/2013 12:46 PM, Mark Friedenbach wrote:
>
> John,
>
> What you are recommending is a drastic change that the conservative
> bitcoin developers probably wouldn't get behind (but let's see).
> However proof-of-stake voting on protocol soft-forks has vast
> implications even beyond the block size limit. Within Freicoin, we
> have looked at is as a possibility for determining how to distribute
> the demurrage, a proposal we are calling 'Republicoin' due to the fact
> that with proxy voting we expect a system to emerge similar to the
> government budgeting in parliamentary republics. Distributed,
> non-coersive government by protocol, if you will.
>
> So anyway, even if you get shot down, please continue to pursue this
> proposal. It very likely has uses that you haven't thought of yet.
>
> Cheers,
> Mark
>
> On 6/9/13 9:09 PM, John Dillon wrote:
> > It has been suggested that we leave the decision of what the
> blocksize to be
> > entirely up to miners. However this leaves a parameter that affects
> every
> > Bitcoin participant in the control of a small minority. Of course we
> can not
> > force miners to increase the blocksize if they choose to decrease
> it, because
> > the contents of the blocks they make are their decision and their
> decision
> > only. However proposals to leave the maximum size unlimited to allow
> miners to
> > force us to accept arbitrarily large blocks even if the will of the
> majority of
> > Bitcoin participants is that they wish to remain able to validate the
> > blockchain.
>
> > What we need is a way to balance this asymetrical power relationship.
>
> > Proof-of-stake voting gives us a way of achieving that balance.
> Essentially for
> > a miner to prove that the majority will of the poeple is to accept a
> larger
> > blocksize they must prove that the majority has in fact voted for that
> > increase. The upper limit on the blocksize is then determined by the
> median of
> > all votes, where each txout in the UTXO set is one vote, weighted by
> txout
> > value. A txout without a corresponding vote is considered to be a
> vote for the
> > status quo. To allow the voting process to continue even if coins
> are "lost"
> > votes, including default votes, are weighted inversely according to
> their age
> > in years after 1 year. IE a vote with weight 1BTC that is 1.5 years
> old will be
> > recorded the same as a <1 year old vote weighted as 0.67BTC, and a 1
> day old
> > and 6 months old UTXO are treated equivalently. The 1 year minimum
> is simply to
> > make voting required no more than once per year. (of course, a real
> > implementation should do all of these figures by block height, IE
> after 52,560
> > blocks instead of after 1 year)
>
> > A vote will consist of a txout with a scriptPubKey of the following
> form:
>
> >     OP_RETURN magic vote_id txid vout vote scriptSig
>
> > Where scriptSig is a valid signature for a transaction with nLockTime
> > 500,000,000-1 spending txid:vout to scriptPubKey:
>
> >     OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL
>
> > vote_id is the ID of the specific vote being made, and magic is
> included to
> > allow UTXO proof implementations a as yet unspecified way of
> identifying votes
> > and including the weighted median as part of the UTXO tree sums. (it
> also
> > allows SPV clients to verify the vote if the UTXO set is a Patricia
> tree of
> > scriptPubKeys) vote is just the numerical vote itself. The vote must
> compute
> > the median, rather than the mean, so as to not allow someone to skew
> the vote
> > by simply setting their value extremely high. Someone who still
> remembers their
> > statistics classes should chime in on the right way to compute a
> median in a
> > merkle-sum-tree.
>
> > The slightly unusual construction of votes makes implementation by
> wallet
> > software as simple as possible within existing code-paths. Votes
> could still be
> > constructed even in wallets lacking specific voting capability
> provided the
> > wallet software does have the ability to set nLockTime.
>
> > Of course in the future the voting mechanism can be used for
> additional votes
> > with an additional vote_id. For instance the Bitcoin community could
> vote to
> > increase the inflation subsidy, another example of a situation where
> the wishes
> > of miners may conflict with the wishes of the broader community.
>
> > Users may of course actually create these specially encoded txouts
> themselves
> > and get them into the blockchain.  However doing so is not needed as
> a given
> > vote is only required to actually be in the chain by a miner wishing to
> > increase the blocksize. Thus we should extend the P2P protocol with
> a mechanism
> > by which votes can be broadcast independently of transactions. To
> prevent DoS
> > attacks only votes with known vote_id's will be accepted, and only for
> > txid:vout's already in the blockchain, and a record of txouts for
> whom votes
> > have already broadcast will be kept. (this record need not be
> authoritative as
> > its purpose is only to prevent DoS attacks) Miners wishing to
> increase the
> > blocksize can record these votes and include them in the blocks they
> mine as
> > required. To reduce the cost of including votes in blocks 5% of
> every block
> > should be assigned to voting only. (this can be implemented by a
> soft-fork)
>
> > For any given block actual limit in effect is then the rolling
> median of the
> > blocks in the last year. At the beginning of every year the value
> considered to
> > be the status quo resets to the mean of the limit at the beginning
> and end of
> > the interval.  (again, by "year" we really mean 52,560 blocks) The
> rolling
> > median and periodic reset process ensures that the limit changes
> gradually and
> > is not influenced by temporary events such as hacks to large
> exchanges or
> > malicious wallet software.  The rolling median also ensures that for
> a miner
> > the act of including a vote is never wasted due to the txout later
> being spent.
>
> > Implementing the voting system can happen prior to an actual
> hard-fork allowing
> > for an increase and can be an important part of determining if the
> hard-fork is
> > required at all.
>
> > Coercion and vote buying is of course possible in this system. A
> miner could
> > say that they will only accept transactions accompanied by a vote
> for a given
> > limit. However in a decentralized system completely preventing vote
> buying is
> > of course impossble, and the design of Bitcoin itself has a fundemental
> > assumption that a majority of miners will behave in a specific kind
> of "honest"
> > way.
>
> > A voting process ensures that any increase to the blocksize genuinely
> > represents the desires of the Bitcoin community, and the process
> described
> > above ensures that any changes happen at a rate that gives all
> participants
> > time to react. The process also gives a mechanism for the community
> to vote to
> > decrease the limit if it turns out that the new one was in fact too
> high. (note
> > how the way the status quo is set ensures the default action is for
> the limit
> > to gradually decrease even if everyone stops voting)
>
> > As many of you know I have been quite vocal that the 1MB limit
> should stay. But
> > I would be happy to support the outcome of a vote done properly,
> whatever that
> > outcome may be.
>
> >
> ------------------------------------------------------------------------------
> > How ServiceNow helps IT people transform IT departments:
> > 1. A cloud service to automate IT design, transition and operations
> > 2. Dashboards that offer high-level views of enterprise services
> > 3. A single system of record for all IT processes
> > http://p.sf.net/sfu/servicenow-d2d-j
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > .
>
>
>
>
>
>
------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--------------030609060502040605000400
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    One major problem I see with this, no matter how well-thought-out it
    is, it's unlikely that those with money will participate.&nbsp; Those
    with the most stake, likely have their private keys behind
    super-secure accessibility barriers, and are not likely to go
    through the effort just to sign votes.&nbsp; Not only that, but it would
    require them to reveal their public key, which while isn't
    technically so terrible, large amounts of money intended to be kept
    in storage for 10+ years will prefer to avoid any exposure at all,
    in the oft-chance that QCs come around a lot earlier than we
    expected.&nbsp; Sure, the actual risk should be pretty much non-existent,
    but some of the most paranoid folks are probably the same ones who
    have a lot of funds and want 100.00% of the security that is
    possible. &nbsp; They will see this as wildly inconvenient.<br>
    <br>
    I think this a great thought experiment, and I'd like to see where
    this idea goes, in terms of designing ways for a decentralized
    community to find consensus for important decisions, but I don't
    think that any idea that requires users to dig up their private keys
    is going to be feasible (or possibly reconstruct them from pieces
    and/or get multiple signatures).&nbsp; Especially if the system requires
    some kind of persistent voting.<br>
    <br>
    -Alan<br>
    <br>
    <br>
    On 06/10/2013 12:46 PM, Mark Friedenbach wrote:<br>
    <span style="white-space: pre;">&gt;</span><br>
    <blockquote type="cite">John,<br>
      <br>
      What you are recommending is a drastic change that the
      conservative bitcoin developers probably wouldn't get behind (but
      let's see). However proof-of-stake voting on protocol soft-forks
      has vast implications even beyond the block size limit. Within
      Freicoin, we have looked at is as a possibility for determining
      how to distribute the demurrage, a proposal we are calling
      'Republicoin' due to the fact that with proxy voting we expect a
      system to emerge similar to the government budgeting in
      parliamentary republics. Distributed, non-coersive government by
      protocol, if you will.<br>
      <br>
      So anyway, even if you get shot down, please continue to pursue
      this proposal. It very likely has uses that you haven't thought of
      yet.<br>
      <br>
      Cheers,<br>
      Mark<br>
      <br>
      On 6/9/13 9:09 PM, John Dillon wrote:<br>
      &gt; It has been suggested that we leave the decision of what the
      blocksize to be<br>
      &gt; entirely up to miners. However this leaves a parameter that
      affects every<br>
      &gt; Bitcoin participant in the control of a small minority. Of
      course we can not<br>
      &gt; force miners to increase the blocksize if they choose to
      decrease it, because<br>
      &gt; the contents of the blocks they make are their decision and
      their decision<br>
      &gt; only. However proposals to leave the maximum size unlimited
      to allow miners to<br>
      &gt; force us to accept arbitrarily large blocks even if the will
      of the majority of<br>
      &gt; Bitcoin participants is that they wish to remain able to
      validate the<br>
      &gt; blockchain.<br>
      <br>
      &gt; What we need is a way to balance this asymetrical power
      relationship.<br>
      <br>
      &gt; Proof-of-stake voting gives us a way of achieving that
      balance. Essentially for<br>
      &gt; a miner to prove that the majority will of the poeple is to
      accept a larger<br>
      &gt; blocksize they must prove that the majority has in fact voted
      for that<br>
      &gt; increase. The upper limit on the blocksize is then determined
      by the median of<br>
      &gt; all votes, where each txout in the UTXO set is one vote,
      weighted by txout<br>
      &gt; value. A txout without a corresponding vote is considered to
      be a vote for the<br>
      &gt; status quo. To allow the voting process to continue even if
      coins are "lost"<br>
      &gt; votes, including default votes, are weighted inversely
      according to their age<br>
      &gt; in years after 1 year. IE a vote with weight 1BTC that is 1.5
      years old will be<br>
      &gt; recorded the same as a &lt;1 year old vote weighted as
      0.67BTC, and a 1 day old<br>
      &gt; and 6 months old UTXO are treated equivalently. The 1 year
      minimum is simply to<br>
      &gt; make voting required no more than once per year. (of course,
      a real<br>
      &gt; implementation should do all of these figures by block
      height, IE after 52,560<br>
      &gt; blocks instead of after 1 year)<br>
      <br>
      &gt; A vote will consist of a txout with a scriptPubKey of the
      following form:<br>
      <br>
      &gt;&nbsp;&nbsp;&nbsp;&nbsp; OP_RETURN magic vote_id txid vout vote scriptSig<br>
      <br>
      &gt; Where scriptSig is a valid signature for a transaction with
      nLockTime<br>
      &gt; 500,000,000-1 spending txid:vout to scriptPubKey:<br>
      <br>
      &gt;&nbsp;&nbsp;&nbsp;&nbsp; OP_HASH160 H(OP_RETURN magic vote_id txid vout vote)
      OP_EQUAL<br>
      <br>
      &gt; vote_id is the ID of the specific vote being made, and magic
      is included to<br>
      &gt; allow UTXO proof implementations a as yet unspecified way of
      identifying votes<br>
      &gt; and including the weighted median as part of the UTXO tree
      sums. (it also<br>
      &gt; allows SPV clients to verify the vote if the UTXO set is a
      Patricia tree of<br>
      &gt; scriptPubKeys) vote is just the numerical vote itself. The
      vote must compute<br>
      &gt; the median, rather than the mean, so as to not allow someone
      to skew the vote<br>
      &gt; by simply setting their value extremely high. Someone who
      still remembers their<br>
      &gt; statistics classes should chime in on the right way to
      compute a median in a<br>
      &gt; merkle-sum-tree.<br>
      <br>
      &gt; The slightly unusual construction of votes makes
      implementation by wallet<br>
      &gt; software as simple as possible within existing code-paths.
      Votes could still be<br>
      &gt; constructed even in wallets lacking specific voting
      capability provided the<br>
      &gt; wallet software does have the ability to set nLockTime.<br>
      <br>
      &gt; Of course in the future the voting mechanism can be used for
      additional votes<br>
      &gt; with an additional vote_id. For instance the Bitcoin
      community could vote to<br>
      &gt; increase the inflation subsidy, another example of a
      situation where the wishes<br>
      &gt; of miners may conflict with the wishes of the broader
      community.<br>
      <br>
      &gt; Users may of course actually create these specially encoded
      txouts themselves<br>
      &gt; and get them into the blockchain.&nbsp; However doing so is not
      needed as a given<br>
      &gt; vote is only required to actually be in the chain by a miner
      wishing to<br>
      &gt; increase the blocksize. Thus we should extend the P2P
      protocol with a mechanism<br>
      &gt; by which votes can be broadcast independently of
      transactions. To prevent DoS<br>
      &gt; attacks only votes with known vote_id's will be accepted, and
      only for<br>
      &gt; txid:vout's already in the blockchain, and a record of txouts
      for whom votes<br>
      &gt; have already broadcast will be kept. (this record need not be
      authoritative as<br>
      &gt; its purpose is only to prevent DoS attacks) Miners wishing to
      increase the<br>
      &gt; blocksize can record these votes and include them in the
      blocks they mine as<br>
      &gt; required. To reduce the cost of including votes in blocks 5%
      of every block<br>
      &gt; should be assigned to voting only. (this can be implemented
      by a soft-fork)<br>
      <br>
      &gt; For any given block actual limit in effect is then the
      rolling median of the<br>
      &gt; blocks in the last year. At the beginning of every year the
      value considered to<br>
      &gt; be the status quo resets to the mean of the limit at the
      beginning and end of<br>
      &gt; the interval.&nbsp; (again, by "year" we really mean 52,560
      blocks) The rolling<br>
      &gt; median and periodic reset process ensures that the limit
      changes gradually and<br>
      &gt; is not influenced by temporary events such as hacks to large
      exchanges or<br>
      &gt; malicious wallet software.&nbsp; The rolling median also ensures
      that for a miner<br>
      &gt; the act of including a vote is never wasted due to the txout
      later being spent.<br>
      <br>
      &gt; Implementing the voting system can happen prior to an actual
      hard-fork allowing<br>
      &gt; for an increase and can be an important part of determining
      if the hard-fork is<br>
      &gt; required at all.<br>
      <br>
      &gt; Coercion and vote buying is of course possible in this
      system. A miner could<br>
      &gt; say that they will only accept transactions accompanied by a
      vote for a given<br>
      &gt; limit. However in a decentralized system completely
      preventing vote buying is<br>
      &gt; of course impossble, and the design of Bitcoin itself has a
      fundemental<br>
      &gt; assumption that a majority of miners will behave in a
      specific kind of "honest"<br>
      &gt; way.<br>
      <br>
      &gt; A voting process ensures that any increase to the blocksize
      genuinely<br>
      &gt; represents the desires of the Bitcoin community, and the
      process described<br>
      &gt; above ensures that any changes happen at a rate that gives
      all participants<br>
      &gt; time to react. The process also gives a mechanism for the
      community to vote to<br>
      &gt; decrease the limit if it turns out that the new one was in
      fact too high. (note<br>
      &gt; how the way the status quo is set ensures the default action
      is for the limit<br>
      &gt; to gradually decrease even if everyone stops voting)<br>
      <br>
      &gt; As many of you know I have been quite vocal that the 1MB
      limit should stay. But<br>
      &gt; I would be happy to support the outcome of a vote done
      properly, whatever that<br>
      &gt; outcome may be.<br>
      <br>
      &gt;
------------------------------------------------------------------------------<br>
      &gt; How ServiceNow helps IT people transform IT departments:<br>
      &gt; 1. A cloud service to automate IT design, transition and
      operations<br>
      &gt; 2. Dashboards that offer high-level views of enterprise
      services<br>
      &gt; 3. A single system of record for all IT processes<br>
      &gt; <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/servicenow-d2d-j">http://p.sf.net/sfu/servicenow-d2d-j</a><br>
      &gt; _______________________________________________<br>
      &gt; Bitcoin-development mailing list<br>
      &gt; <a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
      &gt;
      <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
      &gt; .<br>
      <br>
      <br>
    </blockquote>
    <span style="white-space: pre;">&gt;<br>
      &gt;<br>
      &gt;<br>
      &gt;
------------------------------------------------------------------------------<br>
      &gt; This SF.net email is sponsored by Windows:<br>
      &gt;<br>
      &gt; Build for Windows Store.<br>
      &gt;<br>
      &gt; <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/windows-dev2dev">http://p.sf.net/sfu/windows-dev2dev</a><br>
      &gt;<br>
      &gt;<br>
      &gt; _______________________________________________<br>
      &gt; Bitcoin-development mailing list<br>
      &gt; <a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
      &gt;
      <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a></span><br>
    <br>
    <br>
  </body>
</html>

--------------030609060502040605000400--