Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1U5rVK-0006Kl-NU for bitcoin-development@lists.sourceforge.net; Thu, 14 Feb 2013 05:37:07 +0000 Received-SPF: pass (sog-mx-3.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-3.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1U5rVE-00014W-2F for bitcoin-development@lists.sourceforge.net; Thu, 14 Feb 2013 05:37:06 +0000 Received: by 10.8.49.92 with SMTP id mf40.29112.511C77F56 Wed, 13 Feb 2013 23:36:53 -0600 (CST) Received: from mail-la0-f53.google.com (unknown [209.85.215.53]) by mi4 (SG) with ESMTP id 511c77f3.1702.dc5fcb for ; Wed, 13 Feb 2013 23:36:51 -0600 (CST) Received: by mail-la0-f53.google.com with SMTP id fr10so1921870lab.40 for ; Wed, 13 Feb 2013 21:36:50 -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=Y4UPqd1kfbqmR2Dd/kNbyZNH2M7nk/t1BPb4Ay+aHp4=; b=hmv390HHRDhg6V6FwC4S3Tjxm5c4jpOKB6UsSHrV8pl4OhijaI6FUpgc+4fJDhxEt7 h7e49zNzD/PVkDU78Bz07dZV7VPGO1vSeZIdclwxne4B9W5AfOmZEUFifjaAgWvHUDqL NltEEMXFCxyNAjoEByNZpHk1LwR7+tiXjFZTS80NjOYRO6j15JIsf1Jlsg86nzWhRr9T F+U5PHo24CFppfj4vMwC3PDgFDluP9mTfDtXmZ8/RoycOPVSwSxYXwFs5yagM609HEk9 9UnW6co6Sgu7jhgE+qAUOmEM0vh/V9j7nFAceK8WlV/KuGuKE20+A+mSAj87LcrWM+gG i0Ag== X-Received: by 10.112.100.199 with SMTP id fa7mr86903lbb.28.1360820209950; Wed, 13 Feb 2013 21:36:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.1.47 with HTTP; Wed, 13 Feb 2013 21:36:09 -0800 (PST) X-Originating-IP: [71.204.90.78] In-Reply-To: References: From: Stephen Pair Date: Thu, 14 Feb 2013 00:36:09 -0500 Message-ID: To: Gregory Maxwell Content-Type: multipart/alternative; boundary=f46d0401f78d379eca04d5a8a5d2 X-Gm-Message-State: ALoCoQlYHT+NlNuYPR9he8mM1njXxneB7OmYfq1ecrDUVZzAYAvhB3FdgY7wD5JeRakdV+qRty0M X-Sendgrid-EID: MKV9IjI68is80Jqz/eG9wzL0RPGq34wm6zZKLyf9fV5O8HKFIs9vx7uQQ4ODbOsX5L1jYGkq8tW1ZMhSJ5GNbw8ddtMuOvtKKqZFv+1UJfDdjsMrkupJbyuPwNUlXazhOtvLLRNurYZfwF2C/8FYGQ== 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: 1U5rVE-00014W-2F 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 05:37:07 -0000 --f46d0401f78d379eca04d5a8a5d2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Feb 13, 2013 at 10:38 PM, Gregory Maxwell wrote: > On Wed, Feb 13, 2013 at 6:44 PM, Stephen Pair wrote: > >(by which I mean the fee or cost associated with the bandwidth and > validation that a transaction requires) with some amount of profit. This > means that 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=97 if we are well distributed=97 and > thus don't have any way to monetize fees. But this is exactly the point I'm making...the thousands of other nodes do have a way to monetize the work they do in relaying and validating transactions. Miners will pay them for the prompt delivery of profitable transactions. So, in effect, the block reward and transactions fees will be paying not only for the mining work, but also the validation and relaying work. Such nodes would get paid in micro transactions from the miners for that service. This would be one way that full nodes could operate profitably (there may be many other indirect ways). I think decentralization is pretty much guaranteed because anyone with profitable transactions would only deliver them to miners or other peers that are willing to pay for them. This is in effect a rebate of a portion of the transaction fee to the network for delivering the transaction to the miner. Wallet software might cut out the middle men and submit directly to miners...other nodes with access to a large amounts of transactions and good infrastructure might be able to reduce the infrastructure a miner has to maintain and deliver a larger volume of fee bearing transactions. And everyone would have a very good sense of the market price for transaction fees for a given level of service (speed of block inclusion). The other side of it is that wallets will need to receive valid, wallet relevant transactions. They may also need to connect with multiple nodes for independent verification of the validity of their transactions. But I think that cost would be more than covered with fees they include in any transactions they originate (but if they rarely originate fee bearing transactions, they might need to pay something to keep receiving an incoming transaction feed...it could be as simple as an artificial transaction they pay to themselves, but that includes a fee). A while back everyone was worried that a tragedy of the commons situation would develop whereby all transactions that carried any fee at all would get included by miners, thus destroying the mining business as the block reward diminished...but I think the cost involved in relaying and validating transactions ensures that situation won't develop...mining nodes will have to only connect to relaying and validating nodes such that they can filter down the volume to something that's profitable for them...and relaying and validating nodes will ignore transactions with fees that are too low to be profitable. It will be a few years before we see the kinds of volumes that will force this infrastructure to evolve...I don't think there is an issue with lifting or even eliminating the block size limit...there may be a point at which the volume is sufficient enough that full nodes start dropping offline...and the nodes that do remain will have to increasingly find ways to cover their costs...which will be a forcing function for solutions similar to these. There is no doubt that Bitcoin will be a lot more valuable if it can handle very large volumes of transactions. Also, Mike Hearn has done some analysis that suggests that even at Visa scales, the hardware requirements to do full validation and relay may not all that substantial (enabling lots of small, but profitable, node operators and low transactions fees...the key to profitability would be access to a sufficient number of original transactions bearing fees). --f46d0401f78d379eca04d5a8a5d2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 13, 2013 at 10:38 PM, Gregory Maxwell <gmaxwell@gmail.com>= wrote:
On Wed, Feb 13, 2013 at 6:= 44 PM, Stephen Pair <stephen@bitpa= y.com> wrote:
>(by which I mean the fee or cost associated with the bandwidth and vali= dation that a transaction requires) with some amount of profit. =A0This mea= ns that the relay node will not fetch and propagate those transactions whos= e fee is too small (unless there was some other fee structure outside the m= iners fee).

The only fee-or-cost they're worrying about is their own marginal=
costs. =A0This 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=97 if we are well distributed=97 and<= br> thus don't have any way to monetize fees. =A0

But this is exactly the point I'm making...the thousands o= f other nodes do have a way to monetize the work they do in relaying and va= lidating transactions. =A0Miners will pay them for the prompt delivery of p= rofitable transactions. =A0So, in effect, the block reward and transactions= fees will be paying not only for the mining work, but also the validation = and relaying work. =A0Such nodes would get paid in micro transactions from = the miners for that service. =A0This would be one way that full nodes could= operate profitably (there may be many other indirect ways). =A0I think dec= entralization is pretty much guaranteed because anyone with profitable tran= sactions would only deliver them to miners or other peers that are willing = to pay for them. =A0This is in effect a rebate of a portion of the transact= ion fee to the network for delivering the transaction to the miner. =A0Wall= et software might cut out the middle men and submit directly to miners...ot= her nodes with access to a large amounts of transactions and good infrastru= cture might be able to reduce the infrastructure a miner has to maintain an= d deliver a larger volume of fee bearing transactions. =A0And everyone woul= d have a very good sense of the market price for transaction fees for a giv= en level of service (speed of block inclusion).

The other side of it is that wallets will n= eed to receive valid, wallet relevant transactions. =A0They may also need t= o connect with multiple nodes for independent verification of the validity = of their transactions. =A0But I think that cost would be more than covered = with fees they include in any transactions they originate (but if they rare= ly originate fee bearing transactions, they might need to pay something to = keep receiving an incoming transaction feed...it could be as simple as an a= rtificial transaction they pay to themselves, but that includes a fee).

A while back everyone was worried that a tr= agedy of the commons situation would develop whereby all transactions that = carried any fee at all would get included by miners, thus destroying the mi= ning business as the block reward diminished...but I think the cost involve= d in relaying and validating transactions ensures that situation won't = develop...mining nodes will have to only connect to relaying and validating= nodes such that they can filter down the volume to something that's pr= ofitable for them...and relaying and validating nodes will ignore transacti= ons with fees that are too low to be profitable.

It will be a few years before we see the ki= nds of volumes that will force this infrastructure to evolve...I don't = think there is an issue with lifting or even eliminating the block size lim= it...there may be a point at which the volume is sufficient enough that ful= l nodes start dropping offline...and the nodes that do remain will have to = increasingly find ways to cover their costs...which will be a forcing funct= ion for solutions similar to these. =A0There is no doubt that Bitcoin will = be a lot more valuable if it can handle very large volumes of transactions.= =A0

Also, Mike Hearn has done some analysis tha= t suggests that even at Visa scales, the hardware requirements to do full v= alidation and relay may not all that substantial (enabling lots of small, b= ut profitable, node operators and low transactions fees...the key to profit= ability would be access to a sufficient number of original transactions bea= ring fees).
3D"" --f46d0401f78d379eca04d5a8a5d2--