Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YrgJC-00024W-JA for bitcoin-development@lists.sourceforge.net; Mon, 11 May 2015 05:31:18 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.182 as permitted sender) client-ip=209.85.216.182; envelope-from=stephencalebmorse@gmail.com; helo=mail-qc0-f182.google.com; Received: from mail-qc0-f182.google.com ([209.85.216.182]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YrgJA-0002ip-Ta for bitcoin-development@lists.sourceforge.net; Mon, 11 May 2015 05:31:18 +0000 Received: by qcyk17 with SMTP id k17so64073688qcy.1 for ; Sun, 10 May 2015 22:31:11 -0700 (PDT) X-Received: by 10.140.43.100 with SMTP id d91mr11401294qga.77.1431322271478; Sun, 10 May 2015 22:31:11 -0700 (PDT) Received: from [10.0.0.7] (c-24-218-184-40.hsd1.nh.comcast.net. [24.218.184.40]) by mx.google.com with ESMTPSA id w67sm9868488qgw.41.2015.05.10.22.31.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 May 2015 22:31:11 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-2CC38370-3669-4500-B390-C55CC1163D67 Mime-Version: 1.0 (1.0) From: Stephen X-Mailer: iPhone Mail (12F70) In-Reply-To: <554FC36C.80402@certimix.com> Date: Mon, 11 May 2015 01:31:09 -0400 Content-Transfer-Encoding: 7bit Message-Id: <82E6CC14-1B3B-4B45-91F2-F19CE89E34A0@gmail.com> References: <554FC36C.80402@certimix.com> To: Sergio Lerner 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 (stephencalebmorse[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars -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: 1YrgJA-0002ip-Ta Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] A way to create a fee market even without a block size limit (2013) 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: Mon, 11 May 2015 05:31:18 -0000 --Apple-Mail-2CC38370-3669-4500-B390-C55CC1163D67 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Why do so many tie the block size debate to creating "a fee market", as if o= ne didn't already exist? Yes, today we frequently see many low priority tran= sactions included into the next block, but that does not mean there is not a= marketplace for block space. It just means miners are not being sufficientl= y tough to create a *competitive* marketplace.=20 But who are we to say that the marketplace should be more competitive, and t= o go further and try to force it by altering consensus rules like the block s= ize limit? If miners want to see more competitive fees, then they need only t= o alter their block creation protocol.=20 There are many arguments for and against changing the consensus limit on blo= ck size. I'm simply saying that "to force a marketplace for fees/block space= " should not be one of them. Let the market develop on it's own.=20 - Stephen > On May 10, 2015, at 4:45 PM, Sergio Lerner wro= te: >=20 > Two years ago I presented a new way to create a fee market that does not d= epend on the block chain limit. >=20 > This proposal has not been formally analyzed in any paper since then, but I= think it holds a good promise to untangle the current problem regarding inc= reasing the tps and creating the fee market. BTW, think the maximum tps shou= ld be increased, but not by increasing the block size, but by increasing the= block rate (I'll expose why in my next e-mail). >=20 > The original post is here (I was overly optimistic back then): https://bit= cointalk.org/index.php?topic=3D147124.msg1561612#msg1561612 >=20 > I'll summarize it here again, with a little editing and a few more questio= ns at the end: >=20 > The idea is simple, but requires a hardfork, but is has minimum impact in t= he code and in the economics. >=20 > Solution: Require that the set of fees collected in a block has a dispersi= on below a threshold. Use, for example, the Coefficient of Variation (http:/= /en.wikipedia.org/wiki/Coefficient_of_variation). If the CoVar is higher tha= n a fixed threshold, the block is considered invalid. >=20 > The Coefficient of variation is computed as the standard deviation over th= e mean value, so it's very easy to compute. (if the mean is zero, we assume C= oVar=3D0). Note that the CoVar function does not depend on the scale, so is j= ust what a coin with a floating price requires. >=20 > This means that if there are many transactions containing high fees in a b= lock, then free transactions cannot be included. > The core devs should tweak the transaction selection algorithm to take int= o account this maximum bound. >=20 > Example >=20 > If the transaction fee set is: 0,0,0,0,5,5,6,7,8,7 > The CoVar is 0.85 > Suppose we limit the CoVar to a maximum of 1. >=20 > Suppose the transaction fee set is: 0,0,0,0,0,0,0,0,0,10 > Then the CoVar is 3.0 >=20 > In this case the miner should have to either drop the "10" from the fee se= t or drop the zeros. Obviously the miner will drop some zeros, and choose th= e set: 0,10, that has a CoVar of 1. >=20 > Why it reduces the Tx spamming Problem? >=20 > Using this little modification, spamming users would require to use higher= fees, only if the remaining users in the community rises their fees. And mi= ners won't be able to include an enormous amounts of spamming txs. >=20 > Why it helps solving the tragedy-of-the-commons fee "problem"? >=20 > As miners are forced to keep the CoVar below the threshold, if people rise= s the fees to confirm faster than spamming txs, automatically smamming txs b= ecome less likely to appear in blocks, and fee-estimators will automatically= increase future fees, creating a the desired feedback loop. >=20 > Why it helps solving the block size problem? >=20 > Because if we increase the block size, miners that do not care about the f= ee market won't be able to fill the block with spamming txs and destroy the m= arket that is being created. This is not a solution against an attacker-mine= r, which can always fill the block with transactions. >=20 > Can the system by gamed? Can it be attacked? >=20 > I don't think so. An attacker would need to spend a high amount in fees to= prevent transactions with low fees to be included in a block.=20 > However, a formal analysis would be required. Miller, Gun Sirer, Eyal.. Wa= nt to give it a try? >=20 > Can create a positive feedback to a rise the fees to the top or push fess t= o the bottom? >=20 > Again, I don't think so. This depends on the dynamics between the each nod= e's fee estimator and the transaction backlog. MIT guys?=20 >=20 > Doesn't it force miners to run more complex algorithms (such as linear pro= gramming) to find the optimum tx subset ? >=20 > Yes, but I don't see it as a drawback, but as a positive stimulus for rese= archers to develop better tx selection algorithms. Anyway, the greedy algori= thm of picking the transactions with highest fees fees would be good enough.= =20 >=20 >=20 > PLEASE don't confuse the acronym CoVar I used here with co-variance. >=20 > Best regard, > Sergio. >=20 >=20 >=20 > --------------------------------------------------------------------------= ---- > One dashboard for servers and applications across Physical-Virtual-Cloud=20= > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --Apple-Mail-2CC38370-3669-4500-B390-C55CC1163D67 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Why do so many tie the block size deba= te to creating "a fee market", as if one didn't already exist? Yes, today we= frequently <= /span>see many low priority transactions included into the next block, but t= hat does not mean there is not a marketplace for block space. It just means m= iners are not being sufficiently tough to create a *competitive* marketplace= . 

But who are we to say that the marketplace s= hould be more competitive, and to go further and try to force it by altering= consensus rules like the block size limit? If miners want to see more competitive fees, then t= hey need only to alter their block creation protocol. 

There are many arguments for and against changing the consen= sus limit on block size. I'm simply saying that "to force a marketplace for f= ees/block space" should not be one of them. Let the market develop on it's o= wn. 

- Stephen


On May 10, 2015, at 4:45 PM, Sergio Lerner <sergiolerner@certimix.com> wrote:

=20 =20 =20 Two years ago I presented a new way to create a fee market that does not depend on the block chain limit.

This proposal has not been formally analyzed in any paper since then, but I think it holds a good promise to untangle the current problem regarding increasing the tps and creating the fee market. BTW, think the maximum tps should be increased, but not by increasing the block size, but by increasing the block rate (I'll expose why in my next e-mail).

The original post is here (I was overly optimistic back then): https://bitcointalk.org/index.php= ?topic=3D147124.msg1561612#msg1561612

I'll summarize it here again, with a little editing and a few more questions at the end:

The idea is simple, but requires a hardfork, but is has minimum impact in the code and in the economics.

Solution: Require that the set of fees collected in a block has a dispersion below a threshold. Use, for example, the Coefficient of Variation (http://en.wikipedia.org/wiki/Coefficient_of_variation= ). If the CoVar is higher than a fixed threshold, the block is considered invalid.

The Coefficient of variation is computed as the standard deviation over the mean value, so it's very easy to compute. (if the mean is zero, we assume CoVar=3D0). Note that the CoVar function does not depend on the scale, so is just what a coin with a floating price requires.

This means that if there are many transactions containing high fees in a block, then free transactions cannot be included.
The core devs should tweak the transaction selection algorithm to take into account this maximum bound.

Example

If the transaction fee set is: 0,0,0,0,5,5,6,7,8,7
The CoVar is 0.85
Suppose we limit the CoVar to a maximum of 1.

Suppose the transaction fee set is: 0,0,0,0,0,0,0,0,0,10
Then the CoVar is 3.0

In this case the miner should have to either drop the "10" from the fee set or drop the zeros. Obviously the miner will drop some zeros, and choose the set: 0,10, that has a CoVar of 1.

Why it reduces the Tx spamming Problem?

Using this little modification, spamming users would require to use higher fees, only if the remaining users in the community rises their fees. And miners won't be able to include an enormous amounts of spamming txs.

Why it helps solving the tragedy-of-the-commons fee "problem"?

As miners are forced to keep the CoVar below the threshold, if people rises the fees to confirm faster than spamming txs, automatically smamming txs become less likely to appear in blocks, and fee-estimators will automatically increase future fees, creating a the desired feedback loop.

Why it helps solving the block size problem?

Because if we increase the block size, miners that do not care about the fee market won't be able to fill the block with spamming txs and destroy the market that is being created. This is not a solution against an attacker-miner, which can always fill the block with transactions.

Can the system by gamed? Can it be attacked?

I don't think so. An attacker would need to spend a high amount in fees to prevent transactions with low fees to be included in a block.
However, a formal analysis would be required. Miller, Gun Sirer, Eyal.. Want to give it a try?

Can create a positive feedback to a rise the fees to the top or push fess to the bottom?

Again, I don't think so. This depends on the dynamics between the each node's fee estimator and the transaction backlog. MIT guys?

Doesn't it force miners to run more complex algorithms (such as linear programming) to find the optimum tx subset ?

Yes, but I don't see it as a drawback, but as a positive stimulus for researchers to develop better tx selection algorithms. Anyway, the greedy algorithm of picking the transactions with highest fees fees would be good enough.


PLEASE don't confuse the acronym CoVar I used here with co-variance.

Best regard,
  Sergio.



=20
--------------------= ----------------------------------------------------------
O= ne dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications<= /span>
Performance metrics, stats and reports that give you Actiona= ble Insights
Deep dive visibility with transaction tracing u= sing APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567= 292;y
____= ___________________________________________
Bitcoin-developm= ent mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
= --Apple-Mail-2CC38370-3669-4500-B390-C55CC1163D67--