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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Vgh7d-0002R5-42 for bitcoin-development@lists.sourceforge.net; Wed, 13 Nov 2013 20:33:09 +0000 X-ACL-Warn: Received: from 2508ds5-oebr.1.fullrate.dk ([90.184.5.129] helo=mail.ceptacle.com) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Vgh7a-0003sB-VO for bitcoin-development@lists.sourceforge.net; Wed, 13 Nov 2013 20:33:09 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.ceptacle.com (Postfix) with ESMTP id 5208F36E8DDE for ; Wed, 13 Nov 2013 21:33:01 +0100 (CET) X-Virus-Scanned: amavisd-new at ceptacle.com Received: from mail.ceptacle.com ([127.0.0.1]) by localhost (server.ceptacle.private [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geUV5yrYX+Ea for ; Wed, 13 Nov 2013 21:32:59 +0100 (CET) Received: from MacGronager.local (2508ds5-oebr.1.fullrate.dk [90.184.5.129]) by mail.ceptacle.com (Postfix) with ESMTPSA id B4FF636E8DC5 for ; Wed, 13 Nov 2013 21:32:59 +0100 (CET) Message-ID: <5283E1FB.40509@ceptacle.com> Date: Wed, 13 Nov 2013 21:32:59 +0100 From: Michael Gronager User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <528367F5.9080303@ceptacle.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 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] X-Headers-End: 1Vgh7a-0003sB-VO 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 20:33:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi John, Thanks for the feedback - comments below: >> However, it occurred to me that things can in fact be calculated even >> simpler: The measured fork rate will mean out all the different pool >> sizes and network latencies and will as such provide a simple number we >> can use to estimate the minimum fee. > > Are you sure about that? You are assuming linearity where none may exist. Well, my work from last week and now is a model. A model enabling you to easily calculate the minimum fee and as a miner which transaction to include to not shoot yourselves in the foot risking to create an orphaned block. The assumption that there is a linearity between block size and latency is shown pretty well in the paper by Decker et. al (see last weeks post). What I add this week is mainly more up to date numbers and a formula dependent only of data that is easy to measure. (fork rate and block size). > > Are those stats accurate? Have any pool operators at least confirmed that the > orphaned blocks that blockchain.info reports match their own records? Probably not - but the are at least a minimum - in case they are higher, the fee should go up further. > > My gut feeling is to relay all orphaned blocks. We know that with a high > investment and sybil attack as blockchain.info has done you can have better > awareness of orphaned blocks than someone without those resources. If having > that awareness is ever a profitable thing we have both created an incentive to > sybil attack the network and we have linked profitability to high up-front > capital investments. Another way to measure latency is to setup a node that only listens but do not relay data. By measuring the propagation of blocks of different size as well as transactions, you can get a propagation distribution and from that an average. However, the relevant propagation time is the one between the pools/(single miners). Which you cannot assess using this scheme - however, it would be nice to compare it to the orphan block scheme. > > With relayed orphans you could even have P2Pool enforce an optimal tx inclusion > policy based on a statistical model by including proof of those orphans into > the P2Pool share chain. P2Pool needs to take fees into account soon, but simply > asking for blocks with the highest total fees or even highest fee/kb appears to > be incomplete according to what your and Peter's analysis is suggesting. Indeed, and nice... But note that it is never of benefit for the miner to include a transaction with a fee of less than ~0.0004BTC - unless it is linked to another transaction that pay an extra fee. There have been a lot of assumptions on the fee size and generally it has been linked to the bitcoin exchange rate. This analysis shows that this is wrong. Also it shows that the scalability of bitcoin is directly linked to the network and node latency (with the current latency it will never beneficial for miners to include more than ~30k transactions in a block or ~70 pr second resulting in ~10MB blocks). However, halving the latency will double the capacity, down to the minimum which is governed by the speed of light. > > > ------------------------------------------------------------------------------ > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access > Free app hosting. Or install the open source package on any LAMP server. > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! > http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSg+H7AAoJEKpww0VFxdGRn+gIAIgju90DED5r//USqKvkQsYI JDj0tLBLMg9BPXOOt3eJ+NX4YE4lW+QkwqDd/swuJxLmj0l9BQKgt1lTb/f0P/cY GdE14gh5EYlvNzY1h0TGKcMe8NTWXU0/tC+Clpy4sqBHPXW/eF/77sLQUnFRrLKi sT48aHOOFUdBLdlyylUzzevh/FFVLidkKqV031tv52+BFHcTFd4kRPwZXgBSs9YH U66MkJ4ytAqeOfJue9n7Qn4kJF9kNIhRpqTrtapqu8jglLfuYlJ3s5fwaw9FxQdR +On4IWeXzURQ6tcVRCovCq/2lxRKIbYGlW7HGVASjRmm68/+8YUAfFsYFl6DIgA= =9tbL -----END PGP SIGNATURE-----