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 D4C68BAD for ; Sat, 8 Apr 2017 00:44:52 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com [209.85.217.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1E162B0 for ; Sat, 8 Apr 2017 00:44:52 +0000 (UTC) Received: by mail-ua0-f169.google.com with SMTP id u103so3776705uau.1 for ; Fri, 07 Apr 2017 17:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vaaAyfj1CapGpRhrZmETnXeP+KBJuVJAPqPjxi/ryF8=; b=FZ/rWPgj/RcPdtRh68INOIxtTcCE2EhubLrfn9WJaNq1QaX75E7d3VprG7mVQ8rxrt 4CYOGjceScebZf67LfcVxy3I1U/hchER3EvkK8qUTYXFtpqLVehyzlSxNVa+EpKnfJsz UKLfd3g2xdd/S1ZvbCTuqvrALw2Ujttn64G8kVecaZnBCdS0b9+kc7Y314sMWLrD7/3d bWDrlqqAqkcqk9VmfKKDo2aquH77xaCo0s9+ffN3zeHqTOBId2V9pMflYzafoyUXlk8x bvB6DR4ZeXIblevd2s3vAUkS32VY3+XkHhdcmwoB4fp64mutL+aHV9qS6lbB+ZuyHdSf oSFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vaaAyfj1CapGpRhrZmETnXeP+KBJuVJAPqPjxi/ryF8=; b=mhGV2YRnOVukafB3CFQuRl6e8YMcDVklKnl7cqjG4omgTvYY/VwnkhlV86v5jRAhNC 8mMKMBgU83lCNwoG4/bqkB96sVwPnRLcIjD+IZtexHcNrkcqxPw5wGHJKQleR7gTQPi5 f6KuoADDxSYdKniwEiWLQajUs2zWA7Twk/ZUORJp8ou2iCxSJHcpyHcAg3xVMZ1/UrvA hm6QXbTOi3YGMGFXC/sF1b1RlDJni9auSP+SCHFRv+6estWYzXhv6FhTzSxvvgD4sD8l E7U4rCDpfugxNLebPEnz03LW49m/skpQBD3t1E+CaGGvlj05XtlWrFVxIOGYKSBdm63v Pf9g== X-Gm-Message-State: AFeK/H20Yx711bQkNPWT2hTzj7btYCkHtYhru0aid2FG7JUV9oAWo50gyjPK8023UQKOTu4yohOT4xYeKRXLiQ== X-Received: by 10.176.65.196 with SMTP id 62mr23309898uap.82.1491612291170; Fri, 07 Apr 2017 17:44:51 -0700 (PDT) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.152.203 with HTTP; Fri, 7 Apr 2017 17:44:50 -0700 (PDT) In-Reply-To: <1491599691.1245876.937920664.6EBA20DC@webmail.messagingengine.com> References: <1491516747.3791700.936828232.69F82904@webmail.messagingengine.com> <1491599691.1245876.937920664.6EBA20DC@webmail.messagingengine.com> From: Gregory Maxwell Date: Sat, 8 Apr 2017 00:44:50 +0000 X-Google-Sender-Auth: L0_ktb-rMxysesjnwkkBLhEa6Ek Message-ID: To: Tomas Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, 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 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 00:44:53 -0000 On Fri, Apr 7, 2017 at 9:14 PM, Tomas wrote: > The long term *minimal disk storage* requirement, can obviously not be less > then all the unspent outputs. 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* " As you note that the output costs still bound the resource requirements. Short of radical protocol changes like TXO-proofs the UTXO data remains a driving unavoidable long term resource cost, not an implementation detail. Implementation optimizations like improving locality further or keeping spentness in memory do not change this fact. > The storage that is accessed during peak load (block validation with > pre-synced transactions), is minimized as this only needs the transaction > index (to lookup ptrs from hashes), the tip of the spend-tree and the tip of 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).