From: s7r <s7r@sky-ip.org>
To: "Jorge Timón" <jtimon@jtimon.cc>, NxtChg <nxtchg@hush.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] The need for larger blocks
Date: Sun, 28 Jun 2015 18:28:41 +0300 [thread overview]
Message-ID: <559012A9.3050606@sky-ip.org> (raw)
In-Reply-To: <CABm2gDovynxmZmf_voz-19mmb5k0R4Snxcucx-WObt_stkAL9A@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
+1 for this Jorge.
Agreed the majority should not be able to enforce rules over the
minority. But if the majority will just leave and create an altcoin or
whatever, this will leave the remaining minority with a less value (or
even 0 value) product or service. By enforcing some rules agreed by
the majority or supermajority, the minority will be dragged along and
even so with rules they haven't signed up for, they will still have a
product or service which is worth something.
That is why we have to be very careful into deciding this.
This debate is good, there are lots of valid points from smart people
and I am happy to see there is so much interest in this project, and
regardless if the blocksize hard cap will be changed or not I do hope,
if a hardfork will happen, it will also include a smart change that
will allow future changes (requiring hardforks) simpler, with less
headache and risks involved.
On 6/28/2015 3:13 PM, Jorge Timón wrote:
> On Sat, Jun 27, 2015 at 2:10 PM, NxtChg <nxtchg@hush.com> wrote:
>>
>> On 6/27/2015 at 2:04 PM, "Jorge Timón" <jtimon@jtimon.cc> wrote:
>>
>>> But that option is not unknown...
>>
>> It is, until it actually happens. Before that, anything is a
>> speculation. That's why risk is attached to both "doing nothing"
>> and "raising the limit".
>
> Fortunately we have a lower limit in the standard mining policy to
> see if the skies turn purple when we hit that limit like some
> people predict.
>
>> Various people perceive these risks differently and there is no
>> clear mechanism currently to somehow gauge what the majority
>> wants. So it's tempting to just give up and say: let's do
>> nothing.
>>
>> In this situation, doing a "software fork" seems like the only
>> way to actually see how many people/interests are in favor of
>> bigger blocks.
>
> But this is NOT a way to see the majority of anything. I can run
> 1000 nodes, have you heard of sybil attacks? There's simply no
> decentralized way of voting that works. Otherwise we could vote on
> each block instead of using proof of work. Miners voting on size is
> also ridiculous since big miners have an incentive to completely
> remove the limit and make smaller miners unprofitable.
>
>> (Whether the majority has a moral right to dictate the minority
>> is a tough philosophical question, which should probably be left
>> out of this discussion :)
>
> No, this is very important. The majority has no right to dictate
> on the minority. If the majority of bitcoiners wanted demurrage
> (and we actually had a working method for "measuring majorities"),
> the minority would still say "these are not the rules we signed up
> for, go make freicoin as a separate chain". And that is very
> reasonable. If some people want a more centralized version of
> Bitcoin they can create an altcoin too. Doesn't dogecoin already
> have big blocks? _______________________________________________
> bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJVkBKpAAoJEIN/pSyBJlsR4FMIAITS10rtx4Uw20WjFPkWZRB3
ucRRPncXkKehQlFd9cY6sgPAUk50rM0FSpm69Ra1KnawNLLxkgpzTGZk1iTHbGe8
JlWoTduLOyvInVXCdM8l71TVWoyt8rDZpg1KAsaMmMi9UvstHZPGZp85XScxhYyC
uBHv1Hm7oeszPBkjGsB9B9mF/gH8naCjcNva+XbcgsKNM681xbOeJQ9qW0GOwq+Z
j4ocY77G8AENZkhCy2KKiJrz0ZBVDbnJAos06uKrdxhUPBwliVpyJW96aFsRp/sL
SNqTkpSmvxgSUBHCrRoWiBf/xo06W9QeoEfoROfgFkSTcUlPWqCJHxqwOLk2VrY=
=eUgF
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2015-06-28 15:28 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-26 14:09 [bitcoin-dev] The need for larger blocks Pieter Wuille
2015-06-26 14:38 ` Venzen Khaosan
2015-06-26 15:22 ` Milly Bitcoin
2015-06-26 15:24 ` Pieter Wuille
2015-06-26 18:05 ` Jeff Garzik
2015-06-26 18:32 ` Milly Bitcoin
2015-06-26 15:38 ` Tom Harding
2015-06-26 16:22 ` Venzen Khaosan
2015-06-26 17:04 ` Tom Harding
2015-06-26 17:55 ` Gavin Andresen
2015-06-26 17:57 ` Jeff Garzik
2015-06-26 18:12 ` Pieter Wuille
2015-06-26 18:23 ` Jeff Garzik
2015-06-26 18:31 ` Mark Friedenbach
2015-06-26 19:05 ` Aaron Voisine
2015-06-26 18:34 ` Pieter Wuille
2015-06-26 19:18 ` Ross Nicoll
2015-06-26 19:36 ` Peter Todd
2015-06-27 6:13 ` Filipe Farinha
2015-06-27 7:14 ` Aaron Voisine
2015-06-27 15:13 ` Peter Todd
2015-06-27 19:40 ` Aaron Voisine
2015-06-26 18:47 ` Patrick Strateman
2015-06-26 19:03 ` Tier Nolan
2015-06-26 19:12 ` Mark Friedenbach
2015-06-26 20:44 ` Owen Gunden
2015-06-27 2:18 ` Eric Lombrozo
2015-06-27 2:54 ` Eric Lombrozo
2015-06-27 8:16 ` Venzen Khaosan
2015-06-26 18:29 ` Alex Morcos
2015-06-27 7:43 ` Wladimir J. van der Laan
2015-06-27 9:55 ` NxtChg
2015-06-27 10:04 ` Wladimir J. van der Laan
2015-06-27 10:29 ` NxtChg
2015-06-27 11:04 ` Jorge Timón
2015-06-27 11:18 ` Eric Lombrozo
2015-06-27 11:43 ` Jorge Timón
2015-06-27 12:10 ` NxtChg
2015-06-28 12:13 ` Jorge Timón
2015-06-28 13:51 ` Ivan Brightly
2015-06-28 14:13 ` Eric Lombrozo
2015-06-28 14:16 ` Eric Lombrozo
2015-06-28 14:22 ` Ivan Brightly
2015-06-28 15:05 ` Jorge Timón
2015-06-28 16:01 ` Ivan Brightly
2015-06-28 15:28 ` s7r [this message]
2015-06-28 15:45 ` Jorge Timón
2015-06-27 10:19 ` Venzen Khaosan
2015-06-27 19:55 ` Aaron Voisine
2015-06-28 16:37 ` Venzen Khaosan
2015-06-28 20:56 ` Aaron Voisine
2015-06-27 10:13 ` Jorge Timón
2015-06-27 12:09 ` Wladimir J. van der Laan
2015-06-27 12:15 ` NxtChg
2015-06-27 12:17 ` Greg Sanders
2015-06-27 12:25 ` NxtChg
2015-06-27 12:35 ` Greg Sanders
2015-06-27 12:25 ` Wladimir J. van der Laan
2015-06-27 12:50 ` NxtChg
2015-06-27 13:01 ` Wladimir J. van der Laan
2015-06-28 12:03 ` Jorge Timón
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=559012A9.3050606@sky-ip.org \
--to=s7r@sky-ip.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=jtimon@jtimon.cc \
--cc=nxtchg@hush.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox