From: "Rebroad (sourceforge)" <rebroad+sourceforge.net@gmail•com>
Cc: "bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Punishing empty blocks?
Date: Tue, 29 May 2012 17:30:52 +0100 [thread overview]
Message-ID: <CAFBxzADDbBZ94ckDHEBccNbPQzfW7NWYfC4AibJZYk654bQ87A@mail.gmail.com> (raw)
In-Reply-To: <4FC0C401.1040600@justmoon.de>
[-- Attachment #1: Type: text/plain, Size: 1075 bytes --]
I'd like to garner consensus on whether anyone else thinks it desirable to
have a flag option for bitcoin to punish blocks for not including
transactions. I notice there are already pro-miner options, such as the
restricting the relaying of free transactions, and so including an option
to restrict relaying of blocks from "stingy" miners to balance against the
current bias, so that the default bitcoin client can be run as much
pro-miner as pro-non-miner.
On Monday, May 28, 2012, rebroad@gmail•com wrote:
> What i think this thread reveals is whether a bitcoin client is pro-miner
> or pro-non-miner. What i think is needed is a fork where one benefits
> miners (e.g. Limits relaying of free transactions, as has been added to the
> current default client), and one that benefits non-miners (e.g. Limits
> relaying of blocks not including free transactions). Then people can vote
> based on the client they use.
>
> It seems to me that the current main client is a pro-miner one, and
> possibly not what most people would vote for if they were given an easier
> choice.
[-- Attachment #2: Type: text/html, Size: 1306 bytes --]
next prev parent reply other threads:[~2012-05-29 16:30 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
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) [this message]
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=CAFBxzADDbBZ94ckDHEBccNbPQzfW7NWYfC4AibJZYk654bQ87A@mail.gmail.com \
--to=rebroad+sourceforge.net@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