From: Gavin Andresen <gavinandresen@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f > bounty*fork_rate/average_blocksize
Date: Thu, 14 Nov 2013 09:52:41 +1000 [thread overview]
Message-ID: <CABsx9T0ZchCDReG5W6_7r+BU=zH7aZ=JzV0G4LUs3BpW926d2w@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 3310 bytes --]
next reply other threads:[~2013-11-13 23:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-13 23:52 Gavin Andresen [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-11-13 11:52 Michael Gronager
2013-11-13 12:34 ` Michael Gronager
2013-11-15 10:46 ` Peter Todd
2013-11-13 20:01 ` John Dillon
2013-11-13 20:32 ` Michael Gronager
2013-11-15 9:54 ` Peter Todd
2013-11-15 9:59 ` Gregory Maxwell
2013-11-15 10:47 ` Michael Gronager
2013-11-15 11:12 ` Peter Todd
2013-11-15 11:58 ` Michael Gronager
2013-11-15 19:09 ` Peter Todd
2013-11-15 10:32 ` Peter Todd
2013-11-15 11:47 ` Michael Gronager
2013-11-15 19:19 ` Peter Todd
2013-11-20 10:01 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABsx9T0ZchCDReG5W6_7r+BU=zH7aZ=JzV0G4LUs3BpW926d2w@mail.gmail.com' \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox