đ
Original date posted:2013-11-13
đ Original message:-----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-----
John Dillon [ARCHIVE] /
npub15zâŚkn0zr
2023-06-07 15:09:23
in reply to nevent1qâŚg0k0
Author Public Key
npub15z6e9t07ugx267aj3s3c487pln852ydytzlgu0vkkqxfznyvx4jq4kn0zrPublished at
2023-06-07 15:09:23Event JSON
{
"id": "100d8ff71d115a5a7105b63964a0a93a38c5311e832e5a61ce5bc8469b10cc09",
"pubkey": "a0b592adfee20cad7bb28c238a9fc1fccf4511a458be8e3d96b00c914c8c3564",
"created_at": 1686150563,
"kind": 1,
"tags": [
[
"e",
"366591e3422b1dfb01ae68e0b716cfb17ec74ddec49ddd1afaae513acc5fcb82",
"",
"root"
],
[
"e",
"2939c07fcdf6de435bf95701b5fbb6516cbcd927c8234bbe10322908b3f08771",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "đ
Original date posted:2013-11-13\nđ Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\n\u003e Last week I posted a writeup: \"On the optimal block size and why\n\u003e transaction fees are 8 times too low (or transactions 8 times too big)\".\n\u003e\n\u003e Peter Todd made some nice additions to it including different pool sizes\n\u003e into the numbers.\n\nPeter claims on IRC that he is writing a paper of some kind on this topic. I\nsuggest he submit it to that crypto-currency thing the foundation is\nsponsoring. Given the Nov 24th deadline, I also suggest at least making part of\nit public ASAP so some peer review can be done. It would be a shame for a\nsimple math error to cause embarassment later.\n\n\n\u003e However, it occurred to me that things can in fact be calculated even\n\u003e simpler: The measured fork rate will mean out all the different pool\n\u003e sizes and network latencies and will as such provide a simple number we\n\u003e can use to estimate the minimum fee.\n\nAre you sure about that? You are assuming linearity where none may exist.\n\n\n\u003e Luckily the fork frequency and the average block size are easily\n\u003e measurable. blockchain.info keeps historical graphs of number of\n\u003e orphaned blocks pr day\n\nAre those stats accurate? Have any pool operators at least confirmed that the\norphaned blocks that blockchain.info reports match their own records?\n\nMy gut feeling is to relay all orphaned blocks. We know that with a high\ninvestment and sybil attack as blockchain.info has done you can have better\nawareness of orphaned blocks than someone without those resources. If having\nthat awareness is ever a profitable thing we have both created an incentive to\nsybil attack the network and we have linked profitability to high up-front\ncapital investments.\n\nOn those grounds alone I will argue that we should relay all orphans to even\nthe playing field. If there is a circumstance where we do not want the attacker\nto have that knowledge we have failed anyway, as blockchain.info's sybil attack\non the network clearly shows.\n\n\n\u003e Anyway - the all important number is alpha, the network latency which we\n\u003e expect to be dependent of various things such as interconnectivity,\n\u003e bandwidths, software quality etc, where mainly the latter is within our\n\u003e hands to bring down the fee. And you can actually setup the standard\n\u003e client to choose a better fee, as all the parameters in the formula are\n\u003e easily measured!\n\nWith relayed orphans you could even have P2Pool enforce an optimal tx inclusion\npolicy based on a statistical model by including proof of those orphans into\nthe P2Pool share chain. P2Pool needs to take fees into account soon, but simply\nasking for blocks with the highest total fees or even highest fee/kb appears to\nbe incomplete according to what your and Peter's analysis is suggesting.\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.11 (GNU/Linux)\n\niQEcBAEBCAAGBQJSg9pfAAoJEEWCsU4mNhiP5mcH/jKd2Rpl9gEJ7WhTndS5gYJ9\nEp151NyD/iKpAA4E/d9QVYalo8595LCqnrXnV6wuvuiifB6EJD5WBJq3MAMyaJLA\nagl920ygY98slhDmFhnwlU9lkJVim5FoUkZgE7lQ5dr0MIhvoLQiF2Ywky49Izf0\nIqL+nyW83AQweSalvktA+XGkDfGDV/EnJN7SdNqKDNtE7E9NeMl61NNOWNndsYy6\nuT4PF2YB7rh8wGyHXMTC4Z192pfW4S4s60ZAflG/sTtWCcEwWi+5V/RIu0o5Hmog\nRFpEPvc6d6ykdqtPfTRADMGkT2wC1yXsgeos9oFFVVuVSj8EqHb2db0B+psHRBk=\n=76Qs\n-----END PGP SIGNATURE-----",
"sig": "0b93e5e403e0ba837fdeaa7305691b031043064f706e7a8c25b029a1739e253bc9f9a40e11177ba05d15c3a42647ae26c0101049d2eac8506254a8d69b985655"
}