From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4E64598C for ; Sat, 8 Apr 2017 20:21:16 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 791EC151 for ; Sat, 8 Apr 2017 20:21:15 +0000 (UTC) Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by mx.zohomail.com with SMTPS id 1491682868630839.5423885239028; Sat, 8 Apr 2017 13:21:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Johnson Lau In-Reply-To: <1491681378.2454247.938587616.7199D633@webmail.messagingengine.com> Date: Sun, 9 Apr 2017 04:21:04 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1491516747.3791700.936828232.69F82904@webmail.messagingengine.com> <1491599691.1245876.937920664.6EBA20DC@webmail.messagingengine.com> <1491636528.2474173.938219072.54C44183@webmail.messagingengine.com> <6F1E6FB6-1342-4BD6-BF83-A160C1A7CD34@xbt.hk> <1491681378.2454247.938587616.7199D633@webmail.messagingengine.com> To: Tomas X-Mailer: Apple Mail (2.3259) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev Subject: Re: [bitcoin-dev] Using a storage engine without UTXO-index X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 20:21:16 -0000 > On 9 Apr 2017, at 03:56, Tomas wrote: >=20 >=20 >> I don=E2=80=99t fully understand your storage engine. So the = following deduction >> is just based on common sense. >>=20 >> a) It is possible to make unlimited number of 1-in-100-out txs >>=20 >> b) The maximum number of 100-in-1-out txs is limited by the number of >> previous 1-in-100-out txs >>=20 >> c) Since bitcrust performs not good with 100-in-1-out txs, for = anti-DoS >> purpose you should limit the number of previous 1-in-100-out txs.=20 >>=20 >> d) Limit 1-in-100-out txs =3D=3D Limit UTXO growth >>=20 >> I=E2=80=99m not surprised that you find an model more efficient than = Core. But I >> don=E2=80=99t believe one could find a model that doesn=E2=80=99t = become more efficient >> with UTXO growth limitation. >=20 > My efficiency claims are *only* with regards to order validation. If = we > assume all transactions are already pre-synced and verified, = bitcrust's > order validation is very fast, and (only slightly) negatively effected > by input-counts. pre-synced means already in mempool and verified? Then it sounds like we = just need some mempool optimisation? The tx order in a block is not = important, unless they are dependent >=20 >> One more question: what is the absolute minimum disk and memory usage = in >> bitcrust, compared with the pruning mode in Core? >=20 > As bitcrust doesn't support this yet, I cannot give accurate numbers, > but I've provided some numbers estimates earlier in the thread. >=20 >=20 > Rereading my post and these comments, I may have stepped on some toes > with regards to SegWit's model. I like SegWit (though I may have a > slight preference for BIP140), and I understand the reasons for the > "discount", so this was not my intention. I just think that the = reversal > of costs during peak load order validation is a rather interesting > feature of using spend-tree based validation.=20 >=20 > Tomas Please no conspiracy theory like stepping on someone=E2=80=99s toes. I = believe it=E2=80=99s always nice to challenge the established model. = However, as I=E2=80=99m trying to make some hardfork design, I intend to = have a stricter UTXO growth limit. As you said "protocol addressing the = UTXO growth, might not be worth considering protocol improvements*, it = sounds like UTXO growth limit wouldn=E2=80=99t be very helpful for your = model, which I doubt.=20=