From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z3UcP-00088C-82 for bitcoin-development@lists.sourceforge.net; Fri, 12 Jun 2015 19:27:57 +0000 X-ACL-Warn: Received: from mail-la0-f51.google.com ([209.85.215.51]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z3UcN-0005gE-DF for bitcoin-development@lists.sourceforge.net; Fri, 12 Jun 2015 19:27:57 +0000 Received: by lacny3 with SMTP id ny3so6662512lac.3 for ; Fri, 12 Jun 2015 12:27:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=ir0N/2Vepsa4zS68A6NX8m9DbBg6akjgriUnWGY2fqc=; b=N9jM7LPK+5yJsgrviIdIBn39Zco6F5WW5hnCX2qPKykS52ixEqbeTmoEVqtoGrcbAg TVjicFmI8WICJGhjl1x0XyQEmVIPlxEr1XmcbIdkkJQ6Ydx6h7x70PrCCY/BZ3JxpfEA R9U8OMCeaVFx8a7qPMuw4jxNzNxrPReA9ML8wbmtxvZqUS9GUMWJvjY+9PtwtCuhSKVl UnGwW80OoLERP8QZ1aHcx/9zYEhEpxTbiHgx3V5bCC/Iw6krWHvkG74eXIMVPOnX741r 9fQizacUVJ/No1f5CGHSmMvfwGd4IkiHh4h7kyaAr6LHZwVD9SSwWqN00MEOSeZiItXm Jrlg== X-Gm-Message-State: ALoCoQku4V/XlgneBcv6rEh2NBJqtzRb9Y8giFRqB1loMKrutzKYACLhw1Q50r5+nMfmPwNmyZAT X-Received: by 10.112.126.42 with SMTP id mv10mr16827245lbb.58.1434135428155; Fri, 12 Jun 2015 11:57:08 -0700 (PDT) MIME-Version: 1.0 References: <20150612181153.GB19199@muck> <1466351.XXvDcu7nzO@crushinator> In-Reply-To: <1466351.XXvDcu7nzO@crushinator> From: Jannes Faber Date: Fri, 12 Jun 2015 18:56:57 +0000 Message-ID: To: Matt Whitlock , Mark Friedenbach Content-Type: multipart/alternative; boundary=001a11c36bc6c1635d051856ac71 X-Spam-Score: 1.1 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Headers-End: 1Z3UcN-0005gE-DF Cc: bitcoin-development@lists.sourceforge.net 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 19:27:57 -0000 --001a11c36bc6c1635d051856ac71 Content-Type: text/plain; charset=UTF-8 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 > --001a11c36bc6c1635d051856ac71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm imagining in Peter's proposal it's not the t= ransaction votes that are counted but only the votes in the blocks? So mine= rs get to vote but they risk losing money by having to exclude counter voti= ng 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 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
--001a11c36bc6c1635d051856ac71--