From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Vggd4-0000p2-Uh for bitcoin-development@lists.sourceforge.net; Wed, 13 Nov 2013 20:01:34 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of googlemail.com designates 209.85.215.171 as permitted sender) client-ip=209.85.215.171; envelope-from=john.dillon892@googlemail.com; helo=mail-ea0-f171.google.com; Received: from mail-ea0-f171.google.com ([209.85.215.171]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Vggd3-00021m-U7 for bitcoin-development@lists.sourceforge.net; Wed, 13 Nov 2013 20:01:34 +0000 Received: by mail-ea0-f171.google.com with SMTP id h10so420227eak.16 for ; Wed, 13 Nov 2013 12:01:27 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.14.127.4 with SMTP id c4mr308545eei.144.1384372887583; Wed, 13 Nov 2013 12:01:27 -0800 (PST) Received: by 10.223.135.132 with HTTP; Wed, 13 Nov 2013 12:01:27 -0800 (PST) In-Reply-To: <528367F5.9080303@ceptacle.com> References: <528367F5.9080303@ceptacle.com> Date: Wed, 13 Nov 2013 20:01:27 +0000 Message-ID: From: John Dillon To: Michael Gronager Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.3 (-) 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: googlemail.com] -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 (john.dillon892[at]googlemail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (john.dillon892[at]googlemail.com) -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: 1Vggd3-00021m-U7 Cc: Bitcoin Dev 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:01:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > Last week I posted a writeup: "On the optimal block size and why > transaction fees are 8 times too low (or transactions 8 times too big)". > > Peter Todd made some nice additions to it including different pool sizes > into the numbers. Peter claims on IRC that he is writing a paper of some kind on this topic. I suggest he submit it to that crypto-currency thing the foundation is sponsoring. Given the Nov 24th deadline, I also suggest at least making part of it public ASAP so some peer review can be done. It would be a shame for a simple math error to cause embarassment later. > 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. > Luckily the fork frequency and the average block size are easily > measurable. blockchain.info keeps historical graphs of number of > orphaned blocks pr day Are those stats accurate? Have any pool operators at least confirmed that the orphaned blocks that blockchain.info reports match their own records? 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. On those grounds alone I will argue that we should relay all orphans to even the playing field. If there is a circumstance where we do not want the attacker to have that knowledge we have failed anyway, as blockchain.info's sybil attack on the network clearly shows. > Anyway - the all important number is alpha, the network latency which we > expect to be dependent of various things such as interconnectivity, > bandwidths, software quality etc, where mainly the latter is within our > hands to bring down the fee. And you can actually setup the standard > client to choose a better fee, as all the parameters in the formula are > easily measured! 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJSg9pfAAoJEEWCsU4mNhiP5mcH/jKd2Rpl9gEJ7WhTndS5gYJ9 Ep151NyD/iKpAA4E/d9QVYalo8595LCqnrXnV6wuvuiifB6EJD5WBJq3MAMyaJLA agl920ygY98slhDmFhnwlU9lkJVim5FoUkZgE7lQ5dr0MIhvoLQiF2Ywky49Izf0 IqL+nyW83AQweSalvktA+XGkDfGDV/EnJN7SdNqKDNtE7E9NeMl61NNOWNndsYy6 uT4PF2YB7rh8wGyHXMTC4Z192pfW4S4s60ZAflG/sTtWCcEwWi+5V/RIu0o5Hmog RFpEPvc6d6ykdqtPfTRADMGkT2wC1yXsgeos9oFFVVuVSj8EqHb2db0B+psHRBk= =76Qs -----END PGP SIGNATURE-----