Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z3Xwj-0003CD-CY for bitcoin-development@lists.sourceforge.net; Fri, 12 Jun 2015 23:01:09 +0000 X-ACL-Warn: Received: from mail-ig0-f178.google.com ([209.85.213.178]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z3Xwh-0008UU-Sq for bitcoin-development@lists.sourceforge.net; Fri, 12 Jun 2015 23:01:09 +0000 Received: by igbzc4 with SMTP id zc4so20794242igb.0 for ; Fri, 12 Jun 2015 16:01:02 -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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EWE4oq5kU7J93AJPyNRsqtfovAf7rgZ1YH01tyhwRKo=; b=WYTdobbvURrumTkwHQ7lEyLNqtgeu9hw1Hs0Uz5KhpXdSqwDTQuJdtGp8h8yxTsVPo b9NouEzWiTUCX+r1mln5CnVE8tbCW/Is3aAU568xRxoSLqJ/awAFT+wtPSqf+qzcvWSb eLDnPjAQPLRauWCBMaPWj0DBw2st5ZMHTOw0o5jSbQ1cLx0aao5jV3nfSygsdYz9Urn1 045x7eokqanXr90lvt7PIbL7JjIReeX2pH509kD0H/k/mSBj8ysDQR29kSQd1QfrrTW+ wbd9qGNzhxyLG1iM2NK8EgfCXajQgYdoXol580fbYs6QqbP0vym0CSWjR8dK5hUGMtcO 7ocg== X-Gm-Message-State: ALoCoQklTkjHXoqpGoTG/E8mIjK7tI548FKBszuyDODyS9bTrVDVxy/xiQRDHwWjM/IevPVzrAVg MIME-Version: 1.0 X-Received: by 10.107.9.66 with SMTP id j63mr21708297ioi.37.1434150062527; Fri, 12 Jun 2015 16:01:02 -0700 (PDT) Received: by 10.36.122.15 with HTTP; Fri, 12 Jun 2015 16:01:02 -0700 (PDT) X-Originating-IP: [1.152.96.243] Received: by 10.36.122.15 with HTTP; Fri, 12 Jun 2015 16:01:02 -0700 (PDT) In-Reply-To: References: <20150612181153.GB19199@muck> <1466351.XXvDcu7nzO@crushinator> Date: Sat, 13 Jun 2015 09:01:02 +1000 Message-ID: From: Vincent Truong To: Eric Lombrozo Content-Type: multipart/alternative; boundary=001a113f934e082fb805185a15fe X-Spam-Score: 0.9 (/) 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_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: 1Z3Xwh-0008UU-Sq Cc: bitcoin-development 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 23:01:09 -0000 --001a113f934e082fb805185a15fe Content-Type: text/plain; charset=UTF-8 (Sorry for spam, forgot to cc the mailing list) RE: miner economics Miners who have an agenda can forego fees to achieve it and create their own txns if it is completely txn/user driven. It is better to just count miners votes and let the user votes be their backing. Although miners need to include txns that have the same vote as them, or you expect them be able to vote themselves with their own txns, with backing eventually there will be a large pool of unconfirmed txns that vote against them. Which means a juicy choice of fees for an honest or small miner to vote the other way (if there are any). If the votes are required to be near unanimous (almost 100%) rather than majority rule, there will be a small miner out there who will vote honestly and reset the vote on behalf of those users, because there is a fee incentive to do so (a pure honest miner doesn't care about fees. But they're a dying breed). If it is a majority rule type of vote, bigger miners will set the vote direction and small miners have no say no matter how they vote. From a decentralisation perspective, it is better to want the big guns to have a small voice, otherwise it will tend towards centralisation. Troll users (voting against when the direction is very clear) can still be ignored by excluding their txns unless they're paying attractive fees. (So it isn't exactly 100%, but it'll be close). Miners have some power but ultimately they will represent the users if the users votes are clearly divided. If you think 100% is hard, 95-90% could be a compromise but that requires an assumption that at least 5-10% will have their voices unheard. And that might be OK. Personally, 100% is consensus, anything less is just a democracy. RE: vote bits I think letting a vote go up and down in the same vote is a strange one. Personally I think binary votes simplify the process. Would it be better to 'announce' a vote that will contain a certain change. For example, hash of a config file that said change MAX_BLOCK_SIZE -> 8mb. More things can use the same mechanism by including changes in a config (or whatever script/markup) file as needed in the future, for whichever constants you want to expose to votes. Votes can just be 0 and 1 for no/yes and omitted for neutral. My preference is 1 for yes, 0 for no neutral/ignored and omitted for no, so that it is backwards compatible and doesn't skew votes to the agreeing direction, and forces node owners and wallet developers to upgrade and participate. On Jun 13, 2015 6:04 AM, "Eric Lombrozo" wrote: > 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 > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --001a113f934e082fb805185a15fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

(Sorry for spam, forgot to cc the mailing list)

RE: miner economics
Miners who have an agenda can forego fees to achieve it and create their ow= n txns if it is completely txn/user driven. It is better to just count mine= rs votes and let the user votes be their backing.

Although miners need to include txns that have the same vote= as them, or you expect them be able to vote themselves with their own txns= , with backing eventually there will be a large pool of unconfirmed txns th= at vote against them. Which means a juicy choice of fees for an honest or s= mall miner to vote the other way (if there are any).

If the votes are required to be near unanimous (almost 100%)= rather than majority rule, there will be a small miner out there who will = vote honestly and reset the vote on behalf of those users, because there is= a fee incentive to do so (a pure honest miner doesn't care about fees.= But they're a dying breed). If it is a majority rule type of vote, big= ger miners will set the vote direction and small miners have no say no matt= er how they vote. From a decentralisation perspective, it is better to want= the big guns to have a small voice, otherwise it will tend towards central= isation.

Troll users (voting against when the direction is very clear= ) can still be ignored by excluding their txns unless they're paying at= tractive fees. (So it isn't exactly 100%, but it'll be close). Mine= rs have some power but ultimately they will represent the users if the user= s votes are clearly divided.

If you think 100% is hard, 95-90% could be a compromise but = that requires an assumption that at least 5-10% will have their voices unhe= ard. And that might be OK. Personally, 100% is consensus, anything less is = just a democracy.

RE: vote bits
I think letting a vote go up and down in the same vote is a strange one. Pe= rsonally I think binary votes simplify the process.

Would it be better to 'announce' a vote that will co= ntain a certain change. For example, hash of a config file that said change= MAX_BLOCK_SIZE -> 8mb. More things can use the same mechanism by includ= ing changes in a config (or whatever script/markup) file as needed in the f= uture, for whichever constants you want to expose to votes.

Votes can just be 0 and 1 for no/yes and omitted for neutral= . My preference is 1 for yes, 0 for no neutral/ignored and omitted for no, = so that it is backwards compatible and doesn't skew votes to the agreei= ng direction, and forces node owners and wallet developers to upgrade and p= articipate.

On Jun 13, 2015 6:04 AM, "Eric Lombrozo&quo= t; <elombrozo@gmail.com> w= rote:

Miners currently only collect an almost negligible portion of their revenu= e from fees. While I certainly welcome any proposals that move us in the di= rection of defining a smooth metaconsensus process, I think with the curent= economics, miners (and especially those with significant hashing power) ha= ve more of an incentive to block txs/spam their votes than to adapt to tx s= ender preferences...unless people increase their tx fees significantly. But= without wallets that can make decent suggestions in this regard, this feat= ure will be almost inaccessible to most regular users. And the economics st= ill aren't entirely clear.

- Eric Lombrozo

On Jun 12, 2015 12:30 PM, "Jannes Faber&quo= t; <j.faber@elev= ate.nl> wrote:

I'= ;m imagining in Peter's proposal it's not the transaction votes tha= t are counted but only the votes in the blocks? So miners get to vote but t= hey 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 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-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

--001a113f934e082fb805185a15fe--