From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1U5pei-0007bn-5Q for bitcoin-development@lists.sourceforge.net; Thu, 14 Feb 2013 03:38:40 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.181 as permitted sender) client-ip=209.85.217.181; envelope-from=gmaxwell@gmail.com; helo=mail-lb0-f181.google.com; Received: from mail-lb0-f181.google.com ([209.85.217.181]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1U5peg-0007BO-Ia for bitcoin-development@lists.sourceforge.net; Thu, 14 Feb 2013 03:38:39 +0000 Received: by mail-lb0-f181.google.com with SMTP id gm6so1437431lbb.26 for ; Wed, 13 Feb 2013 19:38:32 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.125.239 with SMTP id mt15mr22327075lab.26.1360813111981; Wed, 13 Feb 2013 19:38:31 -0800 (PST) Received: by 10.112.96.164 with HTTP; Wed, 13 Feb 2013 19:38:31 -0800 (PST) In-Reply-To: References: Date: Wed, 13 Feb 2013 19:38:31 -0800 Message-ID: From: Gregory Maxwell To: Stephen Pair Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.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 (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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: 1U5peg-0007BO-Ia Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain 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: Thu, 14 Feb 2013 03:38:40 -0000 On Wed, Feb 13, 2013 at 6:44 PM, Stephen Pair wrote: > One of the beauties of bitcoin is that the miners have a very strong ince= ntive to distribute as widely and as quickly as possible the blocks they fi= nd...they also have a very strong incentive to hear about the blocks that o= thers find. There will not be an issue with blocks being "jealously guarde= d" Then perhaps I totally misunderstood what you were suggesting. I believed you were saying blocksize would be controlled by people having to pay to receive and pay to have blocks forwarded. >(by which I mean the fee or cost associated with the bandwidth and validat= ion that a transaction requires) with some amount of profit. This means th= at the relay node will not fetch and propagate those transactions whose fee= is too small (unless there was some other fee structure outside the miners= fee). The only fee-or-cost they're worrying about is their own marginal costs. This says nothing about the externalized cost of the hundreds of thousands of other nodes which also must validate the block they produce, many of which are not miners=E2=80=94 if we are well distributed= =E2=80=94 and thus don't have any way to monetize fees. And even if they are all miners for some reason, if these fees are paying the ever growing validation/storage costs what expenditure is left for the proof of work that makes Bitcoin resistant to reversal? If the cost is soaked up by validation/forwarding then the capacity to run a validating node ends up being the barrier to entry and difficulty would be very low... which sounds fine until you realize that an attacker doesn't have validation costs, and that selfish ("optimally rational") miners could just eschew validation (who cares if you lose some blocks to invalidity if you're producing them so much cheaper than the honest players?). > It is good to be wary of these potential issues, but I don't see how the = economics are likely to yield the outcome you fear. And, really, there's n= ot a lot that can be done to prevent economics from dictating the ultimate = outcome. In fact, what I write above is not so much about what I think *sh= ould* be built, it's more about what I *predict* will be built. What I want is for economics to dictate a positive outcome. They can do this how the system is currently constructed where the economics of using the system are clearly aligned with securing it.