path: root/4a/a70094a7c53094e3a3370d09b04d5f14b762bd

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 <sergiolerner@certimix.com>) id 1YrY6a-000807-Ii
	for bitcoin-development@lists.sourceforge.net;
	Sun, 10 May 2015 20:45:44 +0000
X-ACL-Warn: 
Received: from p3plsmtpa09-04.prod.phx3.secureserver.net ([173.201.193.233])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
	(Exim 4.76) id 1YrY6X-0006Xr-Vi
	for bitcoin-development@lists.sourceforge.net;
	Sun, 10 May 2015 20:45:44 +0000
Received: from [192.168.6.203] ([200.80.130.66])
	by p3plsmtpa09-04.prod.phx3.secureserver.net with 
	id SLlZ1q0051S5ucw01LlaLo; Sun, 10 May 2015 13:45:35 -0700
Message-ID: <554FC36C.80402@certimix.com>
Date: Sun, 10 May 2015 17:45:32 -0300
From: Sergio Lerner <sergiolerner@certimix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative;
	boundary="------------080605070403060205030200"
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [173.201.193.233 listed in list.dnswl.org]
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1YrY6X-0006Xr-Vi
Subject: [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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 10 May 2015 20:45:44 -0000

This is a multi-part message in MIME format.
--------------080605070403060205030200
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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=147124.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=0). 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.




--------------080605070403060205030200
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Two years ago I presented a new way to create a fee market that does
    not depend on the block chain limit.<br>
    <br>
    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).<br>
    <br>
    The original post is here (I was overly optimistic back then):
    <a class="moz-txt-link-freetext" href="https://bitcointalk.org/index.php?topic=147124.msg1561612#msg1561612">https://bitcointalk.org/index.php?topic=147124.msg1561612#msg1561612</a><br>
    <br>
    I'll summarize it here again, with a little editing and a few more
    questions at the end:<br>
    <br>
    The idea is simple, but requires a hardfork, but is has minimum
    impact in the code and in the economics.<br>
    <br>
    Solution: Require that the set of fees collected in a block has a
    dispersion below a threshold. Use, for example, the Coefficient of
    Variation (<a
      href="http://en.wikipedia.org/wiki/Coefficient_of_variation"
      target="_blank">http://en.wikipedia.org/wiki/Coefficient_of_variation</a>).
    If the CoVar is higher than a fixed threshold, the block is
    considered invalid.<br>
    <br>
    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=0). Note that the CoVar function <b>does not
      depend on the scale</b>, so is just what a coin with a floating
    price requires.<br>
    <br>
    This means that if there are many transactions containing high fees
    in a block, then free transactions cannot be included.<br>
    The core devs should tweak the transaction selection algorithm to
    take into account this maximum bound.<br>
    <br>
    <b>Example</b><br>
    <br>
    If the transaction fee set is: 0,0,0,0,5,5,6,7,8,7<br>
    The CoVar is 0.85<br>
    Suppose we limit the CoVar to a maximum of 1.<br>
    <br>
    Suppose the transaction fee set is: 0,0,0,0,0,0,0,0,0,10<br>
    Then the CoVar is 3.0<br>
    <br>
    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.<br>
    <br>
    <b>Why it reduces the Tx spamming Problem?</b><br>
    <br>
    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.<br>
    <br>
    <b>Why it helps solving </b><b>the tragedy-of-the-commons fee
      "problem"?</b><br>
    <br>
    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.<br>
    <br>
    <b>Why it helps solving the block size problem?</b><br>
    <br>
    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.<br>
    <br>
    <b>Can the system by gamed? Can it be attacked?</b><br>
    <br>
    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. <br>
    However, a formal analysis would be required. Miller, Gun Sirer,
    Eyal.. Want to give it a try?<br>
    <b><br>
      Can create a positive feedback to a rise the fees to the top or
      push fess to the bottom?<br>
      <br>
    </b>Again, I don't think so. This depends on the dynamics between
    the each node's fee estimator and the transaction backlog. MIT guys?
    <br>
    <br>
    <b>Doesn't it force miners to run more complex algorithms (such as
      linear programming) to find the optimum tx subset ?<br>
      <br>
    </b>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. <br>
    <br>
    <b><br>
      PLEASE don't confuse the acronym CoVar I used here with
      co-variance.</b><br>
    <br>
    Best regard,<br>
    &nbsp;&nbsp;Sergio.<br>
    <br>
    <br>
    <br>
  </body>
</html>

--------------080605070403060205030200--