From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UFran-0007ed-Hz for bitcoin-development@lists.sourceforge.net; Wed, 13 Mar 2013 19:44:05 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of email.bitpay.com designates 198.37.155.136 as permitted sender) client-ip=198.37.155.136; envelope-from=bounces+404635-86d7-bitcoin-development=lists.sourceforge.net@email.bitpay.com; helo=o19837155136.outbound-mail.sendgrid.net; Received: from [198.37.155.136] (helo=o19837155136.outbound-mail.sendgrid.net) by sog-mx-2.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1UFral-0007OF-Ag for bitcoin-development@lists.sourceforge.net; Wed, 13 Mar 2013 19:44:05 +0000 Received: by 10.42.80.130 with SMTP id filter-064.24699.5140D6FD3 Wed, 13 Mar 2013 19:43:57 +0000 (UTC) Received: from mail-la0-f48.google.com (unknown [209.85.215.48]) by mi17 (SG) with ESMTP id 5140d6fc.6108.10961f0 for ; Wed, 13 Mar 2013 14:43:56 -0500 (CST) Received: by mail-la0-f48.google.com with SMTP id fq13so1563721lab.7 for ; Wed, 13 Mar 2013 12:43:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=UABPN6KtW8zfCwGgz3Y0wzyTJQAvESCpmHhE56Bn2t4=; b=X98iRUOJSovQR7z9R+/r1+LFTHeeN+MJaKNWJTTopdjiyeedydiqVdoWiWD/IYOgvt V56oqUxUy+I0FbgTPMVN6Tn0KcvPBwNChRFsy2NyQ+rybfcQ2L24rjkN+neYcGZ5DNFu U3wvYOzX+YFi6pPG+N7EJfDRXYxm8uQ3I9dnrGngW2yupt28BDEHzAkQMTOhQ070FgPp k9EgFGxUImeaJcpMQsg+ycLXnRNoO4+8omne/Mi4aNk6U3EVoiM8XVdDTnCQTJ9F61Gp BbQyQy9BOkC0pYbHfpW7HiTxFrA324KlawyAgA9GFYhk7kuxE5IGKGop0/ibUwcNq0FO S5tA== X-Received: by 10.112.88.10 with SMTP id bc10mr42729lbb.70.1363203835111; Wed, 13 Mar 2013 12:43:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.82.132 with HTTP; Wed, 13 Mar 2013 12:43:15 -0700 (PDT) X-Originating-IP: [66.194.102.6] In-Reply-To: <20130313182805.GA7921@vps7135.xlshosting.net> References: <20130313174838.GA22621@savin> <2FCCE0F7-66B0-4EBE-8448-C5F0F92A75FF@ceptacle.com> <20130313182805.GA7921@vps7135.xlshosting.net> From: Stephen Pair Date: Wed, 13 Mar 2013 15:43:15 -0400 Message-ID: To: Pieter Wuille Content-Type: multipart/alternative; boundary=f46d040169755958ed04d7d3a0b1 X-Gm-Message-State: ALoCoQknIJPlcblgyunK3D4YWNo5d9ch9z/ica2eZTa1sYa1azkTSreNlMvdZxWU8RRC7yddTqUB X-SG-EID: MKV9IjI68is80Jqz/eG9wzL0RPGq34wm6zZKLyf9fV5O8HKFIs9vx7uQQ4ODbOsXepzcyWTd64mtNHqsdI51Kv5A4cNRB5wN8sTVu7YKMKFj7bSthHkRGu+hd03IN0B1dOpUVcdOqIbFcXAjDmeTxAkZGXI7VGci9DunbmG47Ig= X-Spam-Score: 0.5 (/) 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 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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.0 RDNS_NONE Delivered to internal network by a host with no rDNS X-Headers-End: 1UFral-0007OF-Ag Cc: Bitcoin Dev , Michael Gronager Subject: Re: [Bitcoin-development] Blocksize and off-chain transactions X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:44:05 -0000 --f46d040169755958ed04d7d3a0b1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 13, 2013 at 2:28 PM, Pieter Wuille wrote: > But we cannot just drop support for old nodes. It is completely > unreasonable to put the > _majority_ of the network on a fork, without even as much as a discussion > about it. > "Oh, you didn't get the memo? The rules implemented in your client are > outdated." - that > is not how Bitcoin works: the network defines the rules. > ... > Finally, we'll have to schedule a hard fork to drop the 0.8.1 limit. This > is something > that requires widespread community consensus - far more than just miners > and developers The way I've started thinking about it is that there is a market for securing a payment network. In that market you have consumers (users of bitcoin) and providers (miners). It's not clear to me that if the overwhelming majority of miners stayed on 0.8 that the 0.7 fork wouldn't have still won out in the long run because effectively what you would have had is a situation where the providers abandon a large portion of their customers (0.7 users) and start providing a service that is in much less demand. Would everyone have upgraded to 0.8? Maybe, but maybe not. Maybe many people would have made the rational decision to stay on earlier versions and the small minority of miners that choose to service the 0.7 fork could have earned more Bitcoin on that fork...and maybe in the long run, the majority of miners on 0.8 would realize this situation and start to trickle back over to the 0.7 fork. The flip side of the equation is that the users have a pretty compelling reasons to use the services of the most secure network (less risk of double spends). So, the users very well could have made the rational decision to consume the services of the most powerful network and made the switch to 0.8. What happened in reality is that the majority of the mining community made the rational decision to service the largest pool of customers (0.8 as well as 0.7 and earlier users). It was rational because the risk of servicing only the 0.8 users would have been much greater. Because of this dynamic, I doubt there would ever be multiple forks of any consequence in permanent coexistence. I would even go so far as to say that at this point, a successful competitor to Bitcoin would have to arise as a fork of the UTXOs in the block chain (even if the competitor didn't even use a block chain). That competitor might even have to begin life in lock step co-existence with Bitcoin, recognizing all Bitcoin transactions for some period of time while it attempts to gain market share. --f46d040169755958ed04d7d3a0b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 13, 2013 at 2:28 PM= , Pieter Wuille <pieter.wuille@gmail.com> wrote:
But we cannot just drop support for old nodes. It is completely unreasonabl= e to put the
_majority_ of the network on a fork, without even as much as a discussion a= bout it.
"Oh, you didn't get the memo? The rules implemented in your client= are outdated." - that
is not how Bitcoin works: the network defines the rules.
...
Finally, we'll have to schedule a hard fork to drop the 0.8.1 limit. Th= is is something
that requires widespread community consensus - far more than just miners an= d developers

The way I've started= thinking about it is that there is a market for securing a payment network= . =A0In that market you have consumers (users of bitcoin) and providers (mi= ners). =A0It's not clear to me that if the overwhelming majority of min= ers stayed on 0.8 that the 0.7 fork wouldn't have still won out in the = long run because effectively what you would have had is a situation where t= he providers abandon a large portion of their customers (0.7 users) and sta= rt providing a service that is in much less demand. =A0Would everyone have = upgraded to 0.8? =A0Maybe, but maybe not. =A0Maybe many people would have m= ade the rational decision to stay on earlier versions and the small minorit= y of miners that choose to service the 0.7 fork could have earned more Bitc= oin on that fork...and maybe in the long run, the majority of miners on 0.8= would realize this situation and start to trickle back over to the 0.7 for= k. =A0The flip side of the equation is that the users have a pretty compell= ing reasons to use the services of the most secure network (less risk of do= uble spends). =A0So, the users very well could have made the rational decis= ion to consume the services of the most powerful network and made the switc= h to 0.8. =A0

What happened in reality is that the majori= ty of the mining community made the rational decision to service the larges= t pool of customers (0.8 as well as 0.7 and earlier users). =A0It was ratio= nal because the risk of servicing only the 0.8 users would have been much g= reater.

Because of this dynamic, I doubt there woul= d ever be multiple forks of any consequence in permanent coexistence. =A0I = would even go so far as to say that at this point, a successful competitor = to Bitcoin would have to arise as a fork of the UTXOs in the block chain (e= ven if the competitor didn't even use a block chain). =A0That competito= r might even have to begin life in lock step co-existence with Bitcoin, rec= ognizing all Bitcoin transactions for some period of time while it attempts= to gain market share.
3D""= --f46d040169755958ed04d7d3a0b1--