Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z3VBn-0001Wf-R0 for bitcoin-development@lists.sourceforge.net; Fri, 12 Jun 2015 20:04:31 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.175 as permitted sender) client-ip=209.85.217.175; envelope-from=elombrozo@gmail.com; helo=mail-lb0-f175.google.com; Received: from mail-lb0-f175.google.com ([209.85.217.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z3VBm-0002MG-AX for bitcoin-development@lists.sourceforge.net; Fri, 12 Jun 2015 20:04:31 +0000 Received: by lbbtu8 with SMTP id tu8so25152477lbb.2 for ; Fri, 12 Jun 2015 13:04:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.5.65 with SMTP id q1mr16712689laq.110.1434139463966; Fri, 12 Jun 2015 13:04:23 -0700 (PDT) Received: by 10.112.53.5 with HTTP; Fri, 12 Jun 2015 13:04:23 -0700 (PDT) Received: by 10.112.53.5 with HTTP; Fri, 12 Jun 2015 13:04:23 -0700 (PDT) In-Reply-To: References: <20150612181153.GB19199@muck> <1466351.XXvDcu7nzO@crushinator> Date: Fri, 12 Jun 2015 13:04:23 -0700 Message-ID: From: Eric Lombrozo To: Jannes Faber Content-Type: multipart/alternative; boundary=089e013d17544ee52f0518579d53 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (elombrozo[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Z3VBm-0002MG-AX Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] User vote in blocksize through fees X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 20:04:31 -0000 --089e013d17544ee52f0518579d53 Content-Type: text/plain; charset=UTF-8 Miners currently only collect an almost negligible portion of their revenue from fees. While I certainly welcome any proposals that move us in the direction of defining a smooth metaconsensus process, I think with the curent economics, miners (and especially those with significant hashing power) have more of an incentive to block txs/spam their votes than to adapt to tx sender preferences...unless people increase their tx fees significantly. But without wallets that can make decent suggestions in this regard, this feature will be almost inaccessible to most regular users. And the economics still aren't entirely clear. - Eric Lombrozo On Jun 12, 2015 12:30 PM, "Jannes Faber" wrote: I'm imagining in Peter's proposal it's not the transaction votes that are counted but only the votes in the blocks? So miners get to vote but they risk losing money by having to exclude counter voting transactions. But garbage transactions are no problem at all. Note that users that want to cast a vote "pay" for that by increased confirmation time (on average, hopefully slightly depending on the trend). On Fri, Jun 12, 2015, 20:27 Matt Whitlock wrote: > On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote: > > Peter it's not clear to me that your described protocol is free of miner > > influence over the vote, by artificially generating transactions which > they > > claim in their own blocks > > Miners could fill their blocks with garbage transactions that agree with > their vote, but this wouldn't bring them any real income, as they'd be > paying their own money as fees to themselves. To get real income, miners > would have to vote in accordance with real users. > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development --089e013d17544ee52f0518579d53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Miners currently only collect an almost negligible portion o= f their revenue from fees. While I certainly welcome any proposals that mov= e us in the direction of defining a smooth metaconsensus process, I think w= ith the curent economics, miners (and especially those with significant has= hing power) have more of an incentive to block txs/spam their votes than to= adapt to tx sender preferences...unless people increase their tx fees sign= ificantly. But without wallets that can make decent suggestions in this reg= ard, this feature will be almost inaccessible to most regular users. And th= e economics still aren't entirely clear.

- Eric Lombrozo

On Jun 12, 2015 12:30 PM, "Jannes Faber&quo= t; <j.faber@elevate.nl> wro= te:

I'm= imagining in Peter's proposal it's not the transaction votes that = are counted but only the votes in the blocks? So miners get to vote but the= y risk losing money by having to exclude counter voting transactions. But g= arbage transactions are no problem at all.

Note that users that want to cast a vote "pay" for= that by increased confirmation time (on average, hopefully slightly depend= ing on the trend).


On Fri, Jun 12, 2015, 20:27= =C2=A0Matt Whitlock <bip@mattwhitlock.name> wrote:
On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
> Peter it's not clear to me that your described protocol is free of= miner
> influence over the vote, by artificially generating transactions which= they
> claim in their own blocks

Miners could fill their blocks with garbage transactions that agree with th= eir vote, but this wouldn't bring them any real income, as they'd b= e paying their own money as fees to themselves. To get real income, miners = would have to vote in accordance with real users.

---------------------------------------------------------------------------= ---
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/= listinfo/bitcoin-development

-----------------------------------------------------------------= -------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/= listinfo/bitcoin-development

--089e013d17544ee52f0518579d53--