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 6691894F for ; Sat, 8 Apr 2017 22:12:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com [209.85.213.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BA9BC169 for ; Sat, 8 Apr 2017 22:12:10 +0000 (UTC) Received: by mail-vk0-f53.google.com with SMTP id r69so94590290vke.2 for ; Sat, 08 Apr 2017 15:12:10 -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=C7vIl4WYD0FnEUKhj6OigmyIxqpbLb1asQIF6CKOd0Q=; b=Bj9cE0lZ8UoJhRxyOxgoiXbWmwBNMF7S6OSeyblhGRF+bKzsQikj3wKwS0yVEjYxa/ o2uFT4R5WdxdUDfoUbw/cDsjArAWI9q3YX1eSijxXGNd6VD3zYdSKK4S4gJpWwCHH9+w jmZ+WPfMJhNrXFrFaJfHa6UxcApduxvVTSMlFcu3nZEK/MXH3h3MFoUp8/mXrHczgcgR vtRzYfEe+4Rs7saw0rkkU6NIbk6tBv0SLAQlEHE5M2XlsteNMqKOF7ltArMDI/HU837Z 823HLtGaN3HnFHL8QvslniZfGuuWXLkTB3nccdQhNzLRkpuEnpO/mbO6BcCRaP50iGs0 GHlw== 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=C7vIl4WYD0FnEUKhj6OigmyIxqpbLb1asQIF6CKOd0Q=; b=sS+q2uYcVQqx4N5qgWyou4YxeGrJ8fWozxKMUcquO87aRBmkFxrJdeiwGK3OM1fv9S 47PVeBdGIoTS8mAo1mzvLRqMDjdBE9WE/d0I0UB9EwotaF9BRlAWiIx99aaRo7FuOi3/ 3Pr4wT+twjXBux/VZ9LVDsOVICZ0m020Kl0VPdRyqvd3cuz7rVkFuJ/sEUQs//l5nAWG llvxqiN4s8HCWMENfMYwtQ7Vfvu9FAyqz6/0CCBOHfcXy6HQ1fXgtpWKYjxXIuLY5pki hn40/1HVQcuuH+9iJ4dJnMO8zY+4OwFZG6ROgt4QgRCh4wUleFlSaIH8s72JqBbaQGv8 9/jw== X-Gm-Message-State: AN3rC/7QxoBaHbIsQsbUlMmj8XaMYF5X4YR34x5VBYzd5Uro6NijV8H2m9MDu/xJfofVZ713RatXsm6EnS+mdQ== X-Received: by 10.31.57.71 with SMTP id g68mr3989484vka.43.1491689529870; Sat, 08 Apr 2017 15:12:09 -0700 (PDT) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.152.203 with HTTP; Sat, 8 Apr 2017 15:12:09 -0700 (PDT) In-Reply-To: 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> From: Gregory Maxwell Date: Sat, 8 Apr 2017 22:12:09 +0000 X-Google-Sender-Auth: NWXoIcdZ21LyM3VMxMh7RowiTtk Message-ID: To: Johnson Lau 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-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 22:12:11 -0000 On Sat, Apr 8, 2017 at 8:21 PM, Johnson Lau wrote: > 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 In Bitcoin Core the software _explicitly_ and intentionally does not exploit mempool pre-validation because doing that very easily leads to hard to detect consensus faults and makes all mempool code consensus critical when it otherwise is not. There have been bugs in the past which would have split the network if this optimization had been used. (in particular, I believe I recall one related to correctly removing coinbase spends from the mempool during reorganization that made them immature; and with the optimization and without the CNB post-test would have resulted in nodes that saw the reorg creating and accepting an invalid block, while nodes that didn't rejecting it; but because of prudent design it was largely harmless). Because signature validation is cached, and takes the majority of the block validation time the speed up from the risky optimization isn't that considerable, and there are other lower hanging fruity with bigger payouts like Pieter's change to the per-txout management model and the new non-atomic flushing logic.... and these things don't make more of the system consensus critical.