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 1U5mxq-0005IY-9V for bitcoin-development@lists.sourceforge.net; Thu, 14 Feb 2013 00:46:14 +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 1U5mxm-00033X-6u for bitcoin-development@lists.sourceforge.net; Thu, 14 Feb 2013 00:46:14 +0000 Received: by 10.37.4.219 with SMTP id mf79.22707.511C1D873 Wed, 13 Feb 2013 17:11:03 -0600 (CST) Received: from mail-la0-f48.google.com (unknown [209.85.215.48]) by mi15 (SG) with ESMTP id 511c1d87.37ce.1a986f5 for ; Wed, 13 Feb 2013 17:11:03 -0600 (CST) Received: by mail-la0-f48.google.com with SMTP id fq13so1704168lab.21 for ; Wed, 13 Feb 2013 15:11:01 -0800 (PST) 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=qcVzQkEHz8m+SxHZWpLdkWnYR4H/2sdpiT8OXeYgV00=; b=d39N24UZM3j80psrBoH1pCQ/N5NHFW1mbH81tVETTCKtFglYWC7l+1Kav2VGJikal0 3n7j4UVC9rjyKq3A+lyME4OFyvvpJwToz/jqvysjziKx3p20tmDyvlfjAt/qD0Nshw77 ujPq9iQLmlOzTYP666rFrHTCDN547YbRfCG+KoPlK8jBCHIzEKlUiPQC/u6CdjOD2jRz jtlwy9neqVm/5QR/b8wPimn8AqzXmsXQZES2BaOLmz/LfwuWr/bw1VSaAmcJg24jh1yq k/lVDmVrEXAsGJ0Gld7+MddFl/zaWkp7HrurqWX5h+V34nhcIIDzqbJC4BIqFGwULcWT DHUQ== X-Received: by 10.112.29.72 with SMTP id i8mr9550509lbh.33.1360797061355; Wed, 13 Feb 2013 15:11:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.1.47 with HTTP; Wed, 13 Feb 2013 15:10:21 -0800 (PST) X-Originating-IP: [71.204.90.78] In-Reply-To: References: From: Stephen Pair Date: Wed, 13 Feb 2013 18:10:21 -0500 Message-ID: To: Gavin Andresen Content-Type: multipart/alternative; boundary=f46d04016997741b9304d5a341bd X-Gm-Message-State: ALoCoQkucNyGDaGakTHxi8VzCHvXT6g7e5TtZYjLjBpKAnvOEDy1qmwFN7aCn989y1wS+6hUJb5E X-Sendgrid-EID: MKV9IjI68is80Jqz/eG9wzL0RPGq34wm6zZKLyf9fV5O8HKFIs9vx7uQQ4ODbOsX7TBKgAJK1fxx+XzyEClnulgedJ97Fy0tAv28lwXLnCtcmCUvV7w4XodiHCPgFePvEDcWV6YUAjmFozq6CCurgQ== 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: 1U5mxm-00033X-6u 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 00:46:14 -0000 --f46d04016997741b9304d5a341bd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Feb 13, 2013 at 4:02 PM, Gavin Andresen wr= ote: > On Wed, Feb 13, 2013 at 10:42 AM, Gregory Maxwell wro= te: > >> Since, in the long run, >> Bitcoin can't meet its security and decenteralization promises without >> blockspace scarcity to drive non-trivial fees and without scaling >> limits to keep it decenteralized=97 it's not a change that could be made >> more lightly than changing the supply of coin. >> > > I disagree with Gregory on this. I believe that Bitcoin CAN meet its > security and decentralization promises without any hard limit on block > size. > > I had a fruitful discussion about this with an economist friend this > weekend, and I'll eventually getting around to writing up why I believe > raising the block size limit will not be a problem. If you've already validated the majority of transactions in a block, isn't validating the block not all that compute intensive? Thus, it's really not blocks that should be used to impose any sort of scarcity, but rather it's the costs associated with the validation and propagation of the transactions themselves...which is the way it should be. When I think about issues like this, I like to remind myself that the mesh network isn't really an essential part of Bitcoin. It is a way to disseminate transactions and blocks, but it's by no means the only possible way and could certainly be improved in various ways. Nodes can at some point start to charge fees to collect and distribute transactions and blocks. Collectives of such nodes could pool together fees to ensure connected nodes can propagate and hear about transactions and blocks. These nodes would charge based on the bandwidth and the work required to validate transactions. They would also charge for the propagation of blocks based on the work required to validate them. Miners would of course have a lot of incentive to pay for such services since they will want to get access to as many fee bearing transactions as possible (and filter out the transactions they don't want to include in blocks). They will also want the blocks to ensure they're always building on the latest valid block. That in turn would give these relay nodes a window into the fees needed to ensure fast inclusion into the block chain (something that wallets could use to automatically set fees on transactions). Note, I think the bitcoin protocol might actually be ideally suited for this type of thing...nodes would broadcast INV messages all day long, but as soon as one of your peers wants the actual transaction or block, well, then you have to pay up. Two relay nodes sending transactions between each other would pay each other when they have to download the transaction body...if they trade roughly equal amounts of transactions, they wouldn't end up owing each other anything...for a given transaction they would pull the data exactly, but would then turn around and provide that transaction to many connected peers, earning a fee for each delivery. P.S. such a fee structure would address the spam issue with economics rather than rules about spammy transactions P.P.S. micropayment channels could be used as the payment method for nodes that validate and relay transactions...this would actually be a very good first use of that technology (people have talked about micropayment channels for renting bandwidth...why not use them to pay for the bandwidth and CPU needed to validate and relay transactions) --f46d04016997741b9304d5a341bd Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 13, 2013 at 4:02 PM= , Gavin Andresen <gavinandresen@gmail.com> wrote:
<= div class=3D"gmail_quote">
On Wed, Feb 13, 2013 at 10= :42 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
=A0Since, in the long run,
Bitcoin can't meet its security and decenteralization promises without<= br> blockspace scarcity to drive non-trivial fees and without scaling
limits to keep it decenteralized=97 it's not a change that could be mad= e
more lightly than changing the supply of coin.

I disagree with Gregory on this. =A0I believe that Bitcoin CA= N meet its security and decentralization promises without any hard limit on= block size.=A0

I had a fruitful discussion about this with an economi= st friend this weekend, and I'll eventually getting around to writing u= p why I believe raising the block size limit will not be a problem.

If you've already validated the = majority of transactions in a block, isn't validating the block not all= that compute intensive? =A0Thus, it's really not blocks that should be= used to impose any sort of scarcity, but rather it's the costs associa= ted with the validation and propagation of the transactions themselves...wh= ich is the way it should be.

When = I think about issues like this, I like to remind myself that the mesh netwo= rk isn't really an essential part of Bitcoin. =A0It is a way to dissemi= nate transactions and blocks, but it's by no means the only possible wa= y and could certainly be improved in various ways. =A0Nodes can at some poi= nt start to charge fees to collect and distribute transactions and blocks. = =A0Collectives of such nodes could pool together fees to ensure connected n= odes can propagate and hear about transactions and blocks. =A0These nodes w= ould charge based on the bandwidth and the work required to validate transa= ctions. =A0They would also charge for the propagation of blocks based on th= e work required to validate them. =A0Miners would of course have a lot of i= ncentive to pay for such services since they will want to get access to as = many fee bearing transactions as possible (and filter out the transactions = they don't want to include in blocks). =A0They will also want the block= s to ensure they're always building on the latest valid block. =A0That = in turn would give these relay nodes a window into the fees needed to ensur= e fast inclusion into the block chain (something that wallets could use to = automatically set fees on transactions).

Note, I think the bitcoin protocol might actually be ideally suited for th= is type of thing...nodes would broadcast INV messages all day long, but as = soon as one of your peers wants the actual transaction or block, well, then= you have to pay up. =A0Two relay nodes sending transactions between each o= ther would pay each other when they have to download the transaction body..= .if they trade roughly equal amounts of transactions, they wouldn't end= up owing each other anything...for a given transaction they would pull the= data exactly, but would then turn around and provide that transaction to m= any connected peers, earning a fee for each delivery.

P.S. = such a fee structure would address the spam issue with economics rather tha= n rules about spammy transactions

P.P.S. micropayment channels could be used= as the payment method for nodes that validate and relay transactions...thi= s would actually be a very good first use of that technology (people have t= alked about micropayment channels for renting bandwidth...why not use them = to pay for the bandwidth and CPU needed to validate and relay transactions)=

3D"" --f46d04016997741b9304d5a341bd--