Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VgkEq-0003qg-Vs for bitcoin-development@lists.sourceforge.net; Wed, 13 Nov 2013 23:52:49 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.179 as permitted sender) client-ip=209.85.212.179; envelope-from=gavinandresen@gmail.com; helo=mail-wi0-f179.google.com; Received: from mail-wi0-f179.google.com ([209.85.212.179]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VgkEp-00031E-PZ for bitcoin-development@lists.sourceforge.net; Wed, 13 Nov 2013 23:52:48 +0000 Received: by mail-wi0-f179.google.com with SMTP id fb10so1622039wid.12 for ; Wed, 13 Nov 2013 15:52:41 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.11.166 with SMTP id r6mr22737717wib.9.1384386761565; Wed, 13 Nov 2013 15:52:41 -0800 (PST) Received: by 10.194.156.163 with HTTP; Wed, 13 Nov 2013 15:52:41 -0800 (PST) Date: Thu, 14 Nov 2013 09:52:41 +1000 Message-ID: From: Gavin Andresen To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11c248f027af3804eb17a99f X-Spam-Score: -0.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 (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: blockchain.info] 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1VgkEp-00031E-PZ Subject: Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize 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 Nov 2013 23:52:49 -0000 --001a11c248f027af3804eb17a99f Content-Type: text/plain; charset=ISO-8859-1 Couple of thoughts: RE: the marvelous coincidence that the average fee these days is very close to the modeled minimum orphan cost: Engineers tend to underestimate the power of markets, even inefficient markets, to arrive at the 'correct' price. It would not surprise me at all if the messy, chaotic inefficient market with tens of thousands of individual decisions ("which mining pool should I join" and "how high should my dice site set fees" and "how large should the minimum payout be" and "should I make my blocks bigger or smaller") might arrive at the 'correct' price, even if NOBODY involved has any clue how or why it happened. Or it might just be a coincidence. RE: orphan rate: The network-wide orphan rate has been very steady apart from the March blockchain fork. Kudos to Ben Reeves for keeping track of the data and giving us a nice chart: http://blockchain.info/charts/n-orphaned-blocks RE: new block latency: We should be able to reduce the size of new block announcements by about a factor of ten with very little additional effort (transmit/relay as "merkleblock" with full bloom filters-- the factor of 10 is because a transaction id hash is 32 bytes, average transaction size is a few hundred bytes). Mining revenue is a fixed-size pie, so if EVERYBODY agreed to accept (somewhat) higher orphan rates for more transaction volume then, in the long run, there is no difference. Well, except that more transaction volume means more utility for Bitcoin as a whole, so everybody should benefit from a higher bitcoin price. That's a classic free-rider problem, though-- a miner could defect to try to get a lower orphan rate. This is one of the reasons why I think relaying all blocks in a race is probably the right thing to do; if a miner is mildly punished (by losing the occasional block race) for creating blocks that don't include "enough" already-relayed transactions, that is a strong incentive to go along with whatever consensus has been established. The same argument applies for a miner producing too-large blocks, or blocks with lots of transactions that were never relayed across the network. -- -- Gavin Andresen --001a11c248f027af3804eb17a99f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Couple of thoughts:

RE= : the marvelous coincidence that the average fee these days is very close t= o the modeled minimum orphan cost:

Engineers t= end to underestimate the power of markets, even inefficient markets, to arr= ive at the 'correct' price. It would not surprise me at all if the = messy, chaotic inefficient market with tens of thousands of individual deci= sions ("which mining pool should I join" and "how high shoul= d my dice site set fees" and "how large should the minimum payout= be" and "should I make my blocks bigger or smaller") might = arrive at the 'correct' price, even if NOBODY involved has any clue= how or why it happened.

Or it might= just be a coincidence.

RE: orphan rate:

The network-wide orphan rate has been very steady apart from the March bloc= kchain fork. Kudos to Ben Reeves for keeping track of the data and giving u= s a nice chart:
=A0=A0http://blockchain.= info/charts/n-orphaned-blocks

RE: new blo= ck latency:

We should be able to reduce the size of new block announcements by ab= out a factor of ten with very little additional effort (transmit/relay as &= quot;merkleblock" with full bloom filters-- the factor of 10 is becaus= e a transaction id hash is 32 bytes, average transaction size is a few hund= red bytes).

Mining reve= nue is a fixed-size pie, so if EVERYBODY agreed to accept (somewhat) higher= orphan rates for more transaction volume then, in the long run, there is n= o difference. =A0Well, except that more transaction volume means more utili= ty for Bitcoin as a whole, so everybody should benefit from a higher bitcoi= n price.

That's = a classic free-rider problem, though-- a miner could defect to try to get a= lower orphan rate.

This is one of the reasons why I think relaying all blocks in a race is pro= bably the right thing to do; if a miner is mildly punished (by losing the o= ccasional block race) for creating blocks that don't include "enou= gh" already-relayed transactions, that is a strong incentive to go alo= ng with whatever consensus has been established.

The same ar= gument applies for a miner producing too-large blocks, or blocks with lots = of transactions that were never relayed across the network.

--
--
Gavin Andresen

--001a11c248f027af3804eb17a99f--