From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yr58h-0007tU-JH for bitcoin-development@lists.sourceforge.net; Sat, 09 May 2015 13:49:59 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.174 as permitted sender) client-ip=209.85.216.174; envelope-from=tier.nolan@gmail.com; helo=mail-qc0-f174.google.com; Received: from mail-qc0-f174.google.com ([209.85.216.174]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yr58g-0008Ut-QP for bitcoin-development@lists.sourceforge.net; Sat, 09 May 2015 13:49:59 +0000 Received: by qcyk17 with SMTP id k17so49880607qcy.1 for ; Sat, 09 May 2015 06:49:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.33.227 with SMTP id j90mr3426992qgj.6.1431179393376; Sat, 09 May 2015 06:49:53 -0700 (PDT) Received: by 10.140.85.241 with HTTP; Sat, 9 May 2015 06:49:53 -0700 (PDT) In-Reply-To: References: <16096345.A1MpJQQkRW@crushinator> Date: Sat, 9 May 2015 14:49:53 +0100 Message-ID: From: Tier Nolan To: Gavin Andresen Content-Type: multipart/alternative; boundary=001a113a7d025a2af60515a66b16 X-Spam-Score: 0.3 (/) 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 (tier.nolan[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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 0.9 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Yr58g-0008Ut-QP Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step function 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: Sat, 09 May 2015 13:49:59 -0000 --001a113a7d025a2af60515a66b16 Content-Type: text/plain; charset=UTF-8 On Sat, May 9, 2015 at 12:58 PM, Gavin Andresen wrote: > RE: fixing sigop counting, and building in UTXO cost: great idea! One of > the problems with this debate is it is easy for great ideas get lost in all > the noise. > If the UTXO set cost is built in, UTXO database entries suddenly are worth something, in addition to the bitcoin held in that entry. A user's client might display how many they own. When sending money to a merchant, the user might demand the merchant indicate a slot to pay to. The user could send an ANYONE_CAN_PAY partial transaction. The transaction would guarantee that the user has at least as many UTXOs as before. Discussing the possibility of doing this creates an incentive to bloat the UTXO set right now, since UTXOs would be valuable in the future. The objective would be to make them valuable enough to encourage conservation, but not so valuable that the UTXO contains more value than the bitcoins in the output. Gmaxwell's suggested "tx_size = MAX( real_size >> 1, real_size + 4*utxo_created_size - 3*utxo_consumed_size)" for a 250 byte transaction with 1 input and 2 outputs has very little effect. real_size + 4 * (2) - 3 * 1 = 255 That gives a 2% size penalty for adding an extra UTXO. I doubt that is enough to change behavior. The UTXO set growth could be limited directly. A block would be invalid if it increases the number of UTXO entries above the charted path. RE: a hard upper limit, with a dynamic limit under it: > If the block is greater than 32MB, then it means an update to how blocks are broadcast, so that could be a reasonable hard upper limit (or maybe 31MB, or just the 20MB already suggested). --001a113a7d025a2af60515a66b16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, May 9, 2015 at 12:58 PM, Gavin Andresen <gavinandresen@gmail.c= om> wrote:
RE: fixing sigop counting, and building in UTXO cost: g= reat idea! One of the problems with this debate is it is easy for great ide= as get lost in all the noise.

If the = UTXO set cost is built in, UTXO database entries suddenly are worth somethi= ng, in addition to the bitcoin held in that entry.

A user= 's client might display how many they own.=C2=A0 When sending money to = a merchant, the user might demand the merchant indicate a slot to pay to.
The user could send an ANYONE_CAN_PAY partial transaction.= =C2=A0 The transaction would guarantee that the user has at least as many U= TXOs as before.

Discussing the possibility of doing this = creates an incentive to bloat the UTXO set right now, since UTXOs would be = valuable in the future.=C2=A0

The objective would be to = make them valuable enough to encourage conservation, but not so valuable th= at the UTXO contains more value than the bitcoins in the output.

Gmaxwell's suggested "tx_size =3D MAX( real_size >> = 1,=C2=A0 real_size + 4*utxo_created_size - 3*utxo_consumed_size)" for = a 250 byte transaction with 1 input and 2 outputs has very little effect.
real_size + 4 * (2) - 3 * 1 =3D 255

That gives a 2% size penalty for adding an extra UTXO.=C2=A0 I doubt= that is enough to change behavior.

The UTXO set growth c= ould be limited directly.=C2=A0 A block would be invalid if it increases th= e number of UTXO entries above the charted path.

RE: a= hard upper limit, with a dynamic limit under it:
<= div>
If the block is greater than 32MB, then it means an upda= te to how blocks are broadcast, so that could be a reasonable hard upper li= mit (or maybe 31MB, or just the 20MB already suggested).
--001a113a7d025a2af60515a66b16--