path: root/b6/6ff1c71f5877b8acb4aebffe9f15132a593ea6

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1UEXw6-0004e1-KB
	for bitcoin-development@lists.sourceforge.net;
	Sun, 10 Mar 2013 04:32:38 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.107 as permitted sender)
	client-ip=62.13.148.107; envelope-from=pete@petertodd.org;
	helo=outmail148107.authsmtp.com; 
Received: from outmail148107.authsmtp.com ([62.13.148.107])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1UEXw4-0004Wd-2N for bitcoin-development@lists.sourceforge.net;
	Sun, 10 Mar 2013 04:32:38 +0000
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
	by punt12.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
	r2A4WUaY052439 for <bitcoin-development@lists.sourceforge.net>;
	Sun, 10 Mar 2013 04:32:30 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r2A4WPWq000190
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 10 Mar 2013 04:32:28 GMT
Date: Sat, 9 Mar 2013 23:31:55 -0500
From: Peter Todd <pete@petertodd.org>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20130310043155.GA20020@savin>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 846eadea-893b-11e2-b10b-0025903375e2
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
	P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXgV1
	LRkLXVBSFQZ4ARgL BRwUUBA8cANYeX5u ZEFqQHFbVVt/fUFi
	QwAWFxwCAgcHKWAf UEFRd01VdAJMflFN blYqBSdYMHgPb3ky
	WlZqMmp0N2wHImEN GltQfApJGhlWE2Qq bRQFFjYuG0JNWiM+
	JBsgLVsdF08VengO AXxpUkgVOgMTDQs2 
X-Authentic-SMTP: 61633532353630.1019:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -1.5 (-)
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 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1UEXw4-0004Wd-2N
Subject: [Bitcoin-development] Blocking uneconomical UTXO creation
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 Mar 2013 04:32:38 -0000


--Qxx1br4bt0+wmkIi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

As discussed endlessly data in the UTXO set is more costly, especially
in the long run, than transaction data itself. The fee system is per KB
in a block, and thus doesn't properly capture the long-term costs of
UTXO creation.

It's also been suggested multiple times to make transaction outputs with
a value less than the transaction fee non-standard, either with a fixed
constant or by some sort of measurement.

https://github.com/petertodd/bitcoin/tree/block-uneconomic-utxo-creation

The above patch that implements the latter approach, and thus will not
accept into the mempool any txout whose value is <=3D the fee per KB paid
by the transaction. That fee is then bounded between MIN_TX_FEE and
COIN_DUST, 0.0005BTC and 0.01BTC respectively. The former due to the
fact that the fee can be zero, and the latter so that delibrate high-fee
creation is still allowed. (provably unspendable txouts can of course be
handled specially later)

By basing the calculation on the fee per KB the transaction itself pays
the limit automatically adjustes as the market for blockchain space
changes, and the value of Bitcoins change.

Since scriptSigs greater than 500 bytes are non-standard the marginal
bytes required to spend a txout is always less than 540 bytes. For
standard transactions the marginal cost is usually just a 80+1 byte
signature, and a 33+1 byte pubkey, or 155 bytes. Thus the choice of the
fee for 1000bytes allows a margin to ensure a net positive return, even
if tx fees become more expensive. In particular I think a reasonable
margin is important to deter users from simply deleting wallets filled
with dust-spam, something which gets reported as happening frequently.
It also protects users who do not understand how Bitcoin works from
thinking that repeated small amounts of coins collected from sites
giving away small amounts will add up to an amount that they can
usefully use, and equally protects the long-term health of the network
=66rom those services.

By basing the threshold for what is considered a too-low output value on
ensuring that spending outputs has a net positive return, rather than
trying to come up with some sort of model of UTXO cost, we make the
logic significantly easier to reason about. In particular, it means that
Bitcoin clients can use an unchanging rule based on fees paid, rather
than some constant subject to change as the economics of UTXO costs
change. Note how the total cost of maintaining the UTXO set is
determined by the number of validating nodes, and what that number will
be in the future heavily debated with a possible range spanning many
orders of magnitude.


Short-term
----------

SatoshiDice will have to change their betting system to have their
"failed bet" messages return enough coins to be economically spendable.
It's notable that Satoshidice seems to have already changed their system
to return what appear to be randomly chosen amounts, likely to get
around the users who have applied custom patches to consider 1 satoshi
output values non-standard. Because this patch does not block
SatoshiDice, nor do I expect it to result in less SatoshiDice traffic, I
expect pool operators to be open to applying it.

Other services such as CoinAd will also have to make changes to either
collect multiple payments together, or use off-chain transactions. I've
spoken with a person who runs one of these sites, CoinAd IIRC, and he
was open to opening an instawallet or easywallet account and using it to
do direct off-chain transactions for users who wanted to be paid
immediately.

Part of the patch includes code that sends change to fees if creating a
change output would produce an uneconomic txout. This will likely
occasionally generate confusion from users, especially as it will only
happen if they try to send almost all of their wallet.


Security
--------

For a non-upgraded client, accepting zero-confirmation transactions
becomes more risky as the change represents yet another way of creating
a transaction that won't be mined. Fortnately the nLockTime problem has
served to warn people yet again about those dangers.


Long-term
---------

If fees required on transactions go up in numerical value, the patch
adapts the minimum output size as required.

If fees go down numerically, the minimum output size is also adjusted as
required. If they go down sufficiently that MIN_TX_FEE requires
changing, only one constant needs to change. In particular, the
MIN_RELAY_TX_FEE blocks relaying small output values with small fees
anyway, and it's set to one fifth of MIN_TX_FEE. Additionally most
miners follow the MIN_TX_FEE default, so using that value ensures that
the logic holds true for the more likely case that fees numerically stay
stable or rise. In any case, Bitcoin will never be a good
microtransaction system.


Ouputs representing other assets; "colored coins" and "smartcoins"
------------------------------------------------------------------

The colored coin ideas being passed around on the forums often used
fixed representations of assets, that is 1 bond unit =3D=3D 1 satoshi or
similar. Since proving the state of a colored coin to an SPV client
requires providing the full transaction history changing these protocols
to allow a floating numerical ratio Bitcoins to assets is always
possible by allowing for ordinary, non-marked, transaction inputs and
outputs to add or remove coins as required. This has the additional
advantage of making divisibility easy.

If the asset itself is worth less than a tx fee, moving it will still
incur a net loss. Equally if the asset is worth more than a tx fee, the
quickly the burden of requiring an additional tx fee to be locked up by
the asset becomes minor.



Testing Required
----------------

To be written after more consensus. Essentially a UI testing script, and
unittests in wallet_tests.cpp need to be written.

--=20
'peter'[:-1]@petertodd.org

--Qxx1br4bt0+wmkIi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJRPAy6AAoJEH+rEUJn5PoEAeoH+QEaoT4FCMYDbyN1JUvi1Ec9
UXduVE//o0MMWQv2xTBP99vU2aNcTHV3cL33vGjRy8YCQ4N96721pWDS0BWoGhBe
rqiVUh7NvWefHBpNd7+fNczeuPoUDaCXj6WPHWYQdt715DpkBOfXmi3epxg+1MU3
9MEBptoDBA42BZkM1z5rQGjZa8Pj5PSLx2SZM+u8mQflF9G7tRJOaPpKJce9u5Xr
oJYktDQyMNf151BzSy3D+UhabrZsyiL7IQzz7tr+kR+CyJul3lEFQj8BbTuItdD3
hx1d2Es6f+tbPwf7yr+/qBpSGzVNWR+PpRLZU7rFr2dyW7WZeMg9aO4/I6xpKlc=
=ultN
-----END PGP SIGNATURE-----

--Qxx1br4bt0+wmkIi--