From: "Zooko Wilcox-O'Hearn" <zooko@zooko•com>
To: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Punishing empty blocks?
Date: Fri, 25 May 2012 23:03:15 -0600 [thread overview]
Message-ID: <CANdZDc7+_xBH0DhujnXbh7gVB603qMQdQ7yOO5qq3HEfsJ2Lpw@mail.gmail.com> (raw)
In-Reply-To: <CA+8xBpdBe4yR6xkCODL6JQ41Gyx9eWcGGGvcQVt7DCmaEnAhbg@mail.gmail.com>
For what it is worth, I question whether this is a problem. Or, I
guess I question whether the best solution to it isn't for people to
start including more transaction fees. In fact, I'm not entirely sure
that this problem doesn't actually *encourage* people to that
solution, which would be very good if true.
I would be more comfortable if the reward for mining were more
commensurate with the value it provides. Ultimately, of course, that
means that each transaction fee would have to be more of a proportion
of the value *to the spender* of that transaction being included in
the blockchain.
(Aside: in order to convey to outsiders that miners are providing a
useful service rather than gaining undeserved reward for wasting
electricity, I refer to them as "distributed transaction verification
servers" rather than "miners" whenever possible.)
I'm pretty sure that — assuming there isn't some Bitcoin-killing
disaster — transaction fees will eventually rise, but sooner might be
better, especially with the first coinbase-halving looming.
Perhaps people will be motivated to include transaction fees if they
know that some miners don't bother to validate their transactions and
others do. They may feel motivated to reward the miners that are
serving them and punish the ones that are not. (Note: this wouldn't be
a valid strategy on their part from a strictly game-theoretic
perspective, but if they act on those motivations, then I don't care
if it was rational or not.)
Also, they may decide that they want to counteract the added delay
which those no-transactions miners are adding to *all* transactions
(with or without fee), by putting a fee on their transactions in order
to make them take less long when they are processed by a miner which
does process (some) transactions.
Already this visualization, which I typically glance at a few times a
day, usually shows a good separation with fee-included transactions
sometimes doing much better than (some) free transactions:
http://bitcoinstats.org/
However, this graph shows that the aggregate reward to the miners for
processing transaction is minimal:
http://blockchain.info/charts/transaction-fees?timespan=60days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=
You can see from the first visualization (assuming it is showing the
typical pattern that I've seen) how you risk greater delay by sending
your transaction without fees. The no-transactions miners push *all*
transactions, fee or no-fee to the right. This may incentivize more
people to change their transactions from red diamonds into blue
circles, in order to move their transactions further to the left, even
though the no-transactions miners are not currently discriminating
among the two types.
Therefore, the presence of those miners may help push the aggregate
fees in that latter graph up, which is something I would very much
like to see.
Regards,
Zooko
next prev parent reply other threads:[~2012-05-26 5:18 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-24 16:33 Jeff Garzik
2012-05-24 17:05 ` Arthur Britto
2012-05-24 17:13 ` Joel Joonatan Kaartinen
2012-05-24 17:23 ` Jeff Garzik
2012-05-24 17:27 ` Robert McKay
2012-05-24 18:16 ` Jeff Garzik
2012-05-24 20:31 ` Luke-Jr
2012-05-24 21:00 ` Jeff Garzik
2012-05-25 0:45 ` Luke-Jr
2012-05-25 0:51 ` Jeff Garzik
2012-05-25 0:57 ` Luke-Jr
2012-05-25 1:17 ` Jeff Garzik
2012-05-25 7:47 ` Christian Decker
2012-05-25 13:44 ` Alan Reiner
2012-05-25 14:00 ` Peter Vessenes
2012-05-25 1:00 ` Gregory Maxwell
2012-05-26 5:03 ` Zooko Wilcox-O'Hearn [this message]
2012-05-26 11:52 ` Stefan Thomas
2012-05-28 14:54 ` Peter Vessenes
[not found] ` <1338222334.48856.YahooMailNeo@web121001.mail.ne1.yahoo.com>
2012-05-28 16:25 ` [Bitcoin-development] Fw: " Amir Taaki
2012-05-29 8:52 ` [Bitcoin-development] " Michael Grønager
2012-05-29 14:47 ` Luke-Jr
2012-05-29 15:05 ` Peter Vessenes
2012-05-29 15:18 ` Luke-Jr
2012-05-29 15:28 ` Peter Vessenes
2012-05-29 15:34 ` Luke-Jr
2012-05-29 15:36 ` Peter Vessenes
2012-05-29 15:39 ` Luke-Jr
2012-05-29 15:45 ` Peter Vessenes
2012-05-29 16:30 ` Rebroad (sourceforge)
2012-05-29 15:33 ` Gregory Maxwell
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=CANdZDc7+_xBH0DhujnXbh7gVB603qMQdQ7yOO5qq3HEfsJ2Lpw@mail.gmail.com \
--to=zooko@zooko$(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