path: root/cb/0262659bcad51795eac2bce31aceed59dd0003

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
	<bounces+404635-86d7-bitcoin-development=lists.sourceforge.net@email.bitpay.com>)
	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 <bitcoin-development@lists.sourceforge.net>;
	Wed, 13 Feb 2013 23:36:51 -0600 (CST)
Received: by mail-la0-f53.google.com with SMTP id fr10so1921870lab.40
	for <bitcoin-development@lists.sourceforge.net>;
	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: <CAAS2fgTNQZkUo3k4Uke7sLrZd1=o2TO1BLtdA6_Q7hUegHRQHQ@mail.gmail.com>
References: <CAN1xFdrX61HsRxsXxXW+i0FzjQkoNVRaDG-2yJNOfYUi5FnsPA@mail.gmail.com>
	<CAAS2fgTwjXCGFS-N8a8Ro80ahxXT01dCfqWYOqmwCkdRramaMg@mail.gmail.com>
	<CAN1xFdrGiWmn_EaBNMXXZAV38oeqP14YiMzMZQrkA+WL9QEMfA@mail.gmail.com>
	<CAAS2fgR5=nLTBQUBzjZQs91AVw5XSTiqe-KB_T9R9wKfBrOq6Q@mail.gmail.com>
	<CABsx9T2RWamFxebVJExo_4NT4WPPE=Fd4deG1AFmT=GqjD=vwQ@mail.gmail.com>
	<CADb9v0L9RgfK8=FaM-tZm7AcYMhP6+OAyWu4x+3pLrrQ8yoeLw@mail.gmail.com>
	<CAAS2fgQRineAXRs9uaLRv-YaXMfjd+ietzd1aRmYV98N0y=OuQ@mail.gmail.com>
	<CADb9v0Kf1TfzWnUb3J8YNsLUxsbkeFX2nZXRnW5JJnmfDV9psQ@mail.gmail.com>
	<CAAS2fgTNQZkUo3k4Uke7sLrZd1=o2TO1BLtdA6_Q7hUegHRQHQ@mail.gmail.com>
From: Stephen Pair <stephen@bitpay.com>
Date: Thu, 14 Feb 2013 00:36:09 -0500
Message-ID: <CADb9v0JAhJG_KBcuDC2Vr-01wgaQzH5+gXD+LCKr+QqSaKdjPg@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <gmaxwell@gmail.com>wrote:

> On Wed, Feb 13, 2013 at 6:44 PM, Stephen Pair <stephen@bitpay.com> 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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Feb 13, 2013 at 10:38 PM, Gregory Maxwell <span dir=3D"ltr">&lt;<a href=
=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>&gt;=
</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Wed, Feb 13, 2013 at 6:=
44 PM, Stephen Pair &lt;<a href=3D"mailto:stephen@bitpay.com">stephen@bitpa=
y.com</a>&gt; wrote:<br>

</div><div class=3D"im">
&gt;(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).<br>


<br>
</div>The only fee-or-cost they&#39;re worrying about is their own marginal=
<br>
costs. =A0This says nothing about the externalized cost of the hundreds<br>
of thousands of other nodes which also must validate the block they<br>
produce, many of which are not miners=97 if we are well distributed=97 and<=
br>
thus don&#39;t have any way to monetize fees. =A0</blockquote><div><br></di=
v><div style>But this is exactly the point I&#39;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).</div>

<div style><br></div><div style>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).</di=
v>

<div style><br></div><div style>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&#39;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&#39;s pr=
ofitable for them...and relaying and validating nodes will ignore transacti=
ons with fees that are too low to be profitable.</div>

<div style><br></div><div style>It will be a few years before we see the ki=
nds of volumes that will force this infrastructure to evolve...I don&#39;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</div>

<div style><br></div><div style>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).</div>

</div>
</div></div>
<img src=3D"http://email.bitpay.com/wf/open?upn=3DFPVR34OW0iTCykNVpPzODvIQt=
2S-2BzCNFBszsV6r9gX31pUdL7Qn-2Be1uVJ4jTNxzgC-2FJyxOucBo7cvYzTabGzofjGrwehwN=
ngCTZS6mgMUNEBpGp0ymgWZwp1aDDpXDzi7c-2B-2BEfPKFrFSyJym65DsANoC9PLcrr8e2snlr=
qUeckChA6fDmdz7WI7FELcxplz-2BuZQ0-2B5b8jpL1uiP7kCJ3cw-3D-3D" alt=3D"" width=
=3D"1" height=3D"1" border=3D"0" style=3D"height:1px !important;width:1px !=
important;border-width:0 !important;margin-top:0 !important;margin-bottom:0=
 !important;margin-right:0 !important;margin-left:0 !important;padding-top:=
0 !important;padding-bottom:0 !important;padding-right:0 !important;padding=
-left:0 !important;"/>

--f46d0401f78d379eca04d5a8a5d2--