Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UF85p-0006gu-OH for bitcoin-development@lists.sourceforge.net; Mon, 11 Mar 2013 19:09:05 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.83.46 as permitted sender) client-ip=74.125.83.46; envelope-from=tadas.varanavicius@gmail.com; helo=mail-ee0-f46.google.com; Received: from mail-ee0-f46.google.com ([74.125.83.46]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UF85n-0005Ml-MJ for bitcoin-development@lists.sourceforge.net; Mon, 11 Mar 2013 19:09:05 +0000 Received: by mail-ee0-f46.google.com with SMTP id e49so2431535eek.33 for ; Mon, 11 Mar 2013 12:08:57 -0700 (PDT) X-Received: by 10.14.223.69 with SMTP id u45mr28448857eep.23.1363028937268; Mon, 11 Mar 2013 12:08:57 -0700 (PDT) Received: from [192.168.0.100] ([78.63.237.16]) by mx.google.com with ESMTPS id a1sm25289364eep.2.2013.03.11.12.08.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Mar 2013 12:08:56 -0700 (PDT) Message-ID: <513E2BC6.2050102@gmail.com> Date: Mon, 11 Mar 2013 21:08:54 +0200 From: =?UTF-8?B?VGFkYXMgVmFyYW5hdmnEjWl1cw==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <20130310043155.GA20020@savin> <75F78378-7580-4D69-A5EA-E943AF7CEB0C@benlabs.net> In-Reply-To: <75F78378-7580-4D69-A5EA-E943AF7CEB0C@benlabs.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.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 (tadas.varanavicius[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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: 1UF85n-0005Ml-MJ Subject: Re: [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: Mon, 11 Mar 2013 19:09:05 -0000 On 03/11/2013 08:17 PM, Benjamin Lindner wrote: > The problem of UTXO in principal scales with the block size limit. Thus it should be fixed BEFORE you consider increasing the block size limit. Otherwise you just kick the can down the road, making it bigger. Let's assume bitcoin has scaled up to 2000 tx/s. We all want this, right? https://en.bitcoin.it/wiki/Scalability. Block size is 500 MB. CPU, network and archival blockchain storage seem to solvable. Let's say SatoshiDice-like systems are doing informational transactions that produce unspendable outputs, because they can and users are paying for it anyway (proved in real life). 400 unspendable outputs per second would be realistic. This would be bloating UTXO data at a speed of 52 GB/year. That's a very big memory leak. And this is just the unspendable outputs. Bitcoin cannot scale up until such dust output spamming is discouraged at the protocol level.