diff options
| author | Rusty Russell <rusty@rustcorp.com.au> | 2015-05-18 11:12:11 +0930 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-05-18 06:22:01 +0000 |
| commit | 0de2161032e5264566c7926392af70f12452e6c8 (patch) | |
| tree | 53e578693637d59c1e12a30180b6cfd2eda476cf | |
| parent | f676f9b1161bca0cb75aee43a1246ddf9ec9d586 (diff) | |
| download | pi-bitcoindev-0de2161032e5264566c7926392af70f12452e6c8.tar.gz pi-bitcoindev-0de2161032e5264566c7926392af70f12452e6c8.zip | |
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
| -rw-r--r-- | 59/15e0bd951df9b7585ffcab2bc215d767671927 | 133 |
1 files changed, 133 insertions, 0 deletions
diff --git a/59/15e0bd951df9b7585ffcab2bc215d767671927 b/59/15e0bd951df9b7585ffcab2bc215d767671927 new file mode 100644 index 000000000..8bf6144fe --- /dev/null +++ b/59/15e0bd951df9b7585ffcab2bc215d767671927 @@ -0,0 +1,133 @@ +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 <rusty@ozlabs.org>) id 1YuER7-0008Hb-IB + for bitcoin-development@lists.sourceforge.net; + Mon, 18 May 2015 06:22:01 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of ozlabs.org + designates 103.22.144.67 as permitted sender) + client-ip=103.22.144.67; envelope-from=rusty@ozlabs.org; + helo=ozlabs.org; +Received: from ozlabs.org ([103.22.144.67]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) + (Exim 4.76) id 1YuER6-00025l-B2 + for bitcoin-development@lists.sourceforge.net; + Mon, 18 May 2015 06:22:01 +0000 +Received: by ozlabs.org (Postfix, from userid 1011) + id 6A126140D18; Mon, 18 May 2015 16:21:52 +1000 (AEST) +From: Rusty Russell <rusty@rustcorp.com.au> +To: Tier Nolan <tier.nolan@gmail.com> +In-Reply-To: <CAE-z3OXue5E0TzRhx6y8eTOTy=EARsrGwJ1qv8Kv1nbCsjVE_g@mail.gmail.com> +References: <16096345.A1MpJQQkRW@crushinator> + <CAOG=w-szbLgc1jLpkE_uMa3bkFTi-RiBEaQ6Y-u5aKLBC2HvUg@mail.gmail.com> + <CAAS2fgQRS7w7RRNXVK_+=4CQ7=AWxWQQ7+Tf4tNUPTTZOf7rEQ@mail.gmail.com> + <CAE-z3OUzYZDvsOYEDT229vnvNBa9ntW+86O3uA-K5-KaneMF_g@mail.gmail.com> + <87a8x5l6bt.fsf@rustcorp.com.au> + <CAE-z3OXue5E0TzRhx6y8eTOTy=EARsrGwJ1qv8Kv1nbCsjVE_g@mail.gmail.com> +User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1 + (x86_64-pc-linux-gnu) +Date: Mon, 18 May 2015 11:12:11 +0930 +Message-ID: <878ucmslu4.fsf@rustcorp.com.au> +MIME-Version: 1.0 +Content-Type: text/plain +X-Spam-Score: -0.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 SPF_HELO_PASS SPF: HELO matches SPF record + -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay + domain + -0.0 SPF_PASS SPF: sender matches SPF record + 1.1 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date + -0.2 AWL AWL: Adjusted score from AWL reputation of From: address +X-Headers-End: 1YuER6-00025l-B2 +Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net> +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: <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: Mon, 18 May 2015 06:22:01 -0000 + +Tier Nolan <tier.nolan@gmail.com> writes: +> On Sat, May 16, 2015 at 1:22 AM, Rusty Russell <rusty@rustcorp.com.au> +> wrote: +>> 3) ... or maybe not, if any consumed UTXO was generated before the soft +>> fork (reducing Tier's perverse incentive). +> +> The incentive problem can be fixed by excluding UTXOs from blocks before a +> certain count. +> +> UTXOs in blocks before 375000 don't count. + +OK. Be nice if these were cleaned up, but I guess it's a sunk cost. + +>> 4) How do we measure UTXO size? There are some constant-ish things in +>> there (eg. txid as key, height, outnum, amount). Maybe just add 32 +>> to scriptlen? +>> +> +> They can be stored as a fixed digest. That can be any size, depending on +> security requirements. +> +> Gmaxwell's cost proposal is 3-4 bytes per UTXO change. It isn't +> 4*UXTO.size - 3*UTXO.size + +He said "utxo_created_size" not "utxo_created" so I assumed scriptlen? + +> It is only a small nudge. With only 10% of the block space to play with it +> can't be massive. + +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. + +> This requires that transactions include scriptPubKey information when +> broadcasting them. + +Brilliant! I completely missed that possibility... + +>> 5) Add a CHECKSIG cost. Naively, since we allow 20,000 CHECKSIGs and +>> 1MB blocks, that implies a cost of 50 bytes per CHECKSIG (but counted +>> correctly, unlike now). +>> +>> This last one implies that the initial cost limit would be 2M, but in +>> practice probably somewhere in the middle. +>> +>> tx_cost = 50*num-CHECKSIG +>> + tx_bytes +>> + 4*utxo_created_size +>> - 3*utxo_consumed_size +>> +>> > A 250 byte transaction with 2 inputs and 2 outputs would have an adjusted +>> > size of 252 bytes. +>> +>> Now cost == 352. +> +> That is to large a cost for a 10% block change. It could be included in +> the block size hard fork though. + +I don't think so. Again, you're mixing units. + +> I think have one combined "cost" for +> transactions is good. It means much fewer spread out transaction checks. +> The code for the cost formula would be in one place. + +Agreed! Unfortunately there'll always be 2, because we really do want a +hard byte limit: it's total tx bytes which brings most concerns about +centralization. But ideally it'll be so rarely hit that it can be ~ +ignored (and certainly not optimized for). + +Cheers, +Rusty. + + |