From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 ; Sun, 10 Mar 2013 04:32:28 GMT Date: Sat, 9 Mar 2013 23:31:55 -0500 From: Peter Todd 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--