From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YudN9-0004on-2y for bitcoin-development@lists.sourceforge.net; Tue, 19 May 2015 08:59:35 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.170 as permitted sender) client-ip=209.85.220.170; envelope-from=tier.nolan@gmail.com; helo=mail-qk0-f170.google.com; Received: from mail-qk0-f170.google.com ([209.85.220.170]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YudN7-0002qy-6V for bitcoin-development@lists.sourceforge.net; Tue, 19 May 2015 08:59:35 +0000 Received: by qkgw4 with SMTP id w4so4995735qkg.3 for ; Tue, 19 May 2015 01:59:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.229.185.193 with SMTP id cp1mr36049137qcb.18.1432025967817; Tue, 19 May 2015 01:59:27 -0700 (PDT) Received: by 10.140.85.241 with HTTP; Tue, 19 May 2015 01:59:27 -0700 (PDT) In-Reply-To: <878ucmslu4.fsf@rustcorp.com.au> References: <16096345.A1MpJQQkRW@crushinator> <87a8x5l6bt.fsf@rustcorp.com.au> <878ucmslu4.fsf@rustcorp.com.au> Date: Tue, 19 May 2015 09:59:27 +0100 Message-ID: From: Tier Nolan Cc: Bitcoin Development Content-Type: multipart/alternative; boundary=001a1134b5681ef8be05166b87a1 X-Spam-Score: 3.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.2 MISSING_HEADERS Missing To: header 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 2.7 MALFORMED_FREEMAIL Bad headers on message from free email service X-Headers-End: 1YudN7-0002qy-6V 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: Tue, 19 May 2015 08:59:35 -0000 --001a1134b5681ef8be05166b87a1 Content-Type: text/plain; charset=UTF-8 On Mon, May 18, 2015 at 2:42 AM, Rusty Russell wrote: > OK. Be nice if these were cleaned up, but I guess it's a sunk cost. > Yeah. On the plus side, as people spend their money, old UTXOs would be used up and then they would be included in the cost function. It is only people who are storing their money long term that wouldn't. They are unlikely to have consumed their UTXOs anyway, unless miners started paying for UTXOs. We could make it a range. UTXOs from below 355,000 and above 375,000 are included. That can create incentive problems for the next similar change, I think a future threshold is better. > He said "utxo_created_size" not "utxo_created" so I assumed scriptlen? > Maybe I mis-read. > But you made that number up? The soft cap and hard byte limit are > different beasts, so there's no need for soft cost cap < hard byte > limit. > I was thinking about it being a soft-fork. If it was combined with the 20MB limit change, then it can be anything. I made a suggestion somewhere (her or forums not sure), that transactions should be allowed to store bytes. For example, a new opcode could be added, OP_LOCK_BYTES. This makes the transaction seem larger. However, when spending the UTXO, that transaction counts as smaller, even against the hard-cap. This would be useful for channels. If channels were 100-1000X the blockchain volume and someone caused lots of channels to close, there mightn't be enough space for all the close channel transactions. Some people might be able to get their refund transactions included in the blockchain because the timeout expires. If transactions could store enough space to be spent, then a mass channel close would cause some very large blocks, but then they would have to be followed by lots of tiny blocks. The block limit would be an average not fixed per block. There would be 3 limits Absolute hard limit (max bytes no matter what): 100MB Hard limit (max bytes after stored bytes offset): 30MB Soft limit (max bytes equivalents): 10MB Blocks lager than ~32MB require a new network protocol, which makes the hard fork even "harder". The protocol change could be "messages can now be 150MB max" though, so maybe not so complex. > > > This requires that transactions include scriptPubKey information when > > broadcasting them. > > Brilliant! I completely missed that possibility... > I have written a BIP about it. It is still in the draft stage. I had a look into writing up the code for the protocol change. https://github.com/TierNolan/bips/blob/extended_transactions/bip-etx.mediawiki https://github.com/TierNolan/bips/blob/extended_transactions/bip-etx-fork.mediawiki --001a1134b5681ef8be05166b87a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, May 18, 2015 at 2:42 AM, Rusty Russell <rusty@rustcorp.com.au&= gt; wrote:
OK.= =C2=A0 Be nice if these were cleaned up, but I guess it's a sunk cost.<= br>

Yeah.=C2=A0

On the p= lus side, as people spend their money, old UTXOs would be used up and then = they would be included in the cost function.=C2=A0 It is only people who ar= e storing their money long term that wouldn't.

They a= re unlikely to have consumed their UTXOs anyway, unless miners started payi= ng for UTXOs.

We could make it a range.

UTXOs from below 355,000 and above 375,000 are included.=C2=A0 That can cr= eate incentive problems for the next similar change, I think a future thres= hold is better.
=C2=A0
He said "utxo_created_size" not "utxo_created" s= o I assumed scriptlen?

Maybe I mis-read= .
=C2=A0
But you made that number up?=C2=A0 The soft cap and hard byte limit = are
different beasts, so there's no need for soft cost cap < hard byte limit.

I was thinking about it being a = soft-fork.

If it was combined with the 20MB limit change,= then it can be anything.

I made a suggestion somewhere (= her or forums not sure), that transactions should be allowed to store bytes= .

For example, a new opcode could be added, <byte_coun= t> OP_LOCK_BYTES.

This makes the transaction seem <= byte_count> larger.=C2=A0 However, when spending the UTXO, that transact= ion counts as <byte_count> smaller, even against the hard-cap.
This would be useful for channels.=C2=A0 If channels were 100-1= 000X the blockchain volume and someone caused lots of channels to close, th= ere mightn't be enough space for all the close channel transactions.=C2= =A0 Some people might be able to get their refund transactions included in = the blockchain because the timeout expires.

If transactio= ns could store enough space to be spent, then a mass channel close would ca= use some very large blocks, but then they would have to be followed by lots= of tiny blocks.

The block limit would be an average not = fixed per block.=C2=A0 There would be 3 limits

Absolute h= ard limit (max bytes no matter what): 100MB
Hard limit (max b= ytes after stored bytes offset): 30MB
Soft limit (max bytes e= quivalents): 10MB

Blocks lager than ~32MB requ= ire a new network protocol, which makes the hard fork even "harder&quo= t;.=C2=A0 The protocol change could be "messages can now be 150MB max&= quot; though, so maybe not so complex.
=C2=A0

> This requires that transactions include scriptPubKey information when<= br> > broadcasting them.

Brilliant!=C2=A0 I completely missed that possibility...

I have written a BIP about it.=C2=A0 It is still i= n the draft stage.=C2=A0 I had a look into writing up the code for the prot= ocol change.

https://github.com/Ti= erNolan/bips/blob/extended_transactions/bip-etx.mediawiki
https://github.com/TierNolan/bips/blob/extende= d_transactions/bip-etx-fork.mediawiki
--001a1134b5681ef8be05166b87a1--