-----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----- ------------------------------------------------------------------------------ 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