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 B9B7E41C for ; Sat, 8 Apr 2017 07:28:50 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5D2D8A4 for ; Sat, 8 Apr 2017 07:28:49 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 6D221209F5; Sat, 8 Apr 2017 03:28:48 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute2.internal (MEProxy); Sat, 08 Apr 2017 03:28:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=nEJOU7 b7gOteg0KMGiejUMDV4SQ8CdFJye8MImm32/c=; b=LVOS6pD8HH9daV8cZRFY1C oCiMOCgsz15PkRHIFtEKBwd2oCmcvyWA1oqnwKnMeta8wPWceoJGuQDQmyRPHueJ l/cYnYfVzghj057RFykpOFNgjeO/h+/TcEioD1hvmAWwVYe6ktTFXv0KkOeCWZZy dgOByeih82+ubZ3hDSUWSHqhgAoX1yLJRJipCJSdb8/iHW8jlhndyNVauE7lrtDm 2BXXmYXLNl9mz24y/BxjwAh4XZor90Lj0ht+Dpc7sye+ijl8Cz3jFQkGz89ZCVz/ 0UdBb2nPY8NMcPU+t1I8qTgeQAkZJHFfdEoskq352o0fdvdDCh8n1SfOxdqa6ayQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3F98A9ECBB; Sat, 8 Apr 2017 03:28:48 -0400 (EDT) Message-Id: <1491636528.2474173.938219072.54C44183@webmail.messagingengine.com> From: Tomas To: Gregory Maxwell MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-7c174d5d In-Reply-To: Date: Sat, 08 Apr 2017 09:28:48 +0200 References: <1491516747.3791700.936828232.69F82904@webmail.messagingengine.com> <1491599691.1245876.937920664.6EBA20DC@webmail.messagingengine.com> X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 08 Apr 2017 10:24:29 +0000 Cc: Bitcoin Protocol Discussion 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 07:28:50 -0000 On Sat, Apr 8, 2017, at 02:44, Gregory Maxwell wrote: > As you note that the output costs still bound the resource > requirements. Resource cost is not just a measure of storage requirement; data that needs to be accessed during peak load induce more cost then data only used during base load or only rarely used. > Latency related costs in Bitcoin Core also do not depend on the number > of outputs in transactions in a block. When a transaction is handled > it goes into an in-memory buffer and only gets flushed later if isn't > spent before the buffer fills. A block will take more time to > validate with more inputs, same as you observer, but the aggregate > resource usage for users depends significantly on outputs (so, in fact > there is even further misaligned incentives than just the fact that > small outputs have a outsized long term cost). In Core, when a block comes the inputs are checked against the UTXO set (which grows with outputs) even if pre-synced, to verify order. Am I wrong there? This is not in the case in bitcrust; it is instead checked against the spend-tree (which grows with inputs). How "significant" this is, I neither know nor claim, but it is an interesting difference. > Then I think you may want to retract the claim that "As this solution, > reversing the costs of outputs and inputs, [...] updates to the > protocol addressing the UTXO growth, might not be worth considering > *protocol improvements* " I think you are being a bit harsh here . I am also clearly explaining the difference only applies to peak load, and just making a suggestion. I simply want to stress the importance of protocol / implementation separation as even though you are correct UTXO data is always a resource cost for script validation (as I also state), the ratio of different costs are not necessarily *identical* across implementation. Note that the converse also holds: In bitcrust, if the last few blocks contain many inputs, the peak load verification for this block is slower. This is not the case in Core. Tomas