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 8BA23AB9 for ; Tue, 11 Apr 2017 09:40:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com [209.85.192.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 16FF815E for ; Tue, 11 Apr 2017 09:40:58 +0000 (UTC) Received: by mail-pf0-f175.google.com with SMTP id s16so46390593pfs.0 for ; Tue, 11 Apr 2017 02:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=us48/ORO90xPCxoBR7qlNNlaAIagQdkm19eR35/vM3Y=; b=EbC5UaaXo3noxk65fuiNedyZD+T4YkpsZ5vHfqUT5noxeGr48GdeBp0/c9HyLoWZCX csl1q0nAi/57tM44gAf9F5DtVNKSVkN4dpbWHeLTDi5LoMytvSeZgjKfOzTIfG0cJOfi RaAMMyUr7QNnO9z0b5SVgit14woLMUX+kNNbJA7677JHYvR71aHC5/DL9R95aKcXBxHk DJOrJOGRXIgYa1Y5gKV1QdKuoUOJxtANkaAuAqTE2/SurU+T1aUSAY17Z8O6EmHjE3YH 0NsGuvTi9IhIVtsvahOcPeFeJUhK1v67GabfOdxazyjqJsP25sCo8XVC5IqQfDxghazw sr4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=us48/ORO90xPCxoBR7qlNNlaAIagQdkm19eR35/vM3Y=; b=WeNn3NhFyPIHyKC0obzDjC17R4rVZGfBqaTxnA1K6EDcxabgnr28gwHHelt8tccrYy ukc2vrqwQaLjv5kpyRd+IUdEZnCHYujerOWuvwPZoAls//pez57/KM6zB1S80RB3GKva M2D8VR6S3ckoQwzcKlivl2f/JOG4GNP9Mdl1GtSz9I9mmzF374g2UihC8RhALCJ9xGm0 18EvunV4HDb+eRZ57Ob5a8RCVS8Tg4S8GHxgDceCmnx6NAhhjVtTRt76W9tHrebq4w8x I42hhdy4WGPJU/pMTNwwaRyOlo+bqwVhB3Zavw6Mu3difHMRgHReT2S7FgjuXo73nYgJ uYTg== X-Gm-Message-State: AFeK/H3juVTgUYVB5vdn7/vNe5C2iYU76XmOeEq90/xGrQP5qOBoVK7ZctvHqrZjiRQTOA== X-Received: by 10.84.208.102 with SMTP id f35mr75680346plh.19.1491903657578; Tue, 11 Apr 2017 02:40:57 -0700 (PDT) Received: from ?IPv6:2601:600:9000:d69e:f5d8:bba:67b2:7d87? ([2601:600:9000:d69e:f5d8:bba:67b2:7d87]) by smtp.gmail.com with ESMTPSA id b70sm29451788pfc.100.2017.04.11.02.40.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 02:40:56 -0700 (PDT) To: Tomas , Bitcoin Protocol Discussion , Libbitcoin Development References: <1491516747.3791700.936828232.69F82904@webmail.messagingengine.com> <1491524267.715789.936916864.1156D8CB@webmail.messagingengine.com> <83618cca-c6a3-301c-af70-ab7807474f30@voskuil.org> <1491695882.3440363.938700256.78C37AC3@webmail.messagingengine.com> <1b6b300d-4b24-2a64-12a3-4e654174c132@voskuil.org> <1491900210.2802950.940953480.4C391C68@webmail.messagingengine.com> From: Eric Voskuil X-Enigmail-Draft-Status: N1110 Message-ID: <83947375-e06b-71dd-1f79-6ca97bea392e@voskuil.org> Date: Tue, 11 Apr 2017 02:41:34 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1491900210.2802950.940953480.4C391C68@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 11 Apr 2017 12:50:19 +0000 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: Tue, 11 Apr 2017 09:40:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/11/2017 01:43 AM, Tomas wrote: > Splitting transactions only happens *on storage* and is just a > minor optimization compared to storing them in full. Ok > Sure, we can still call switching tips a "reorg". And it is indeed > a trade off as orphan blocks are stored, but a block in the spend > tree takes only ~12kb and contains the required state information. > It's not the headers/tx-hashes of the blocks that I'm referring to, it is the confirmation and spend information relative to all txs and all outputs for each branch. This reverse navigation (i.e. utxo information) is essential, must be persistent and is branch-relative. > The blockchain is - by design - only eventually consistent across > nodes. Even if nodes would use the same "tip-selection" rules, you > cannot rely on all blocks being propagated and hence each > transaction having the same number of confirmations across all > nodes. > > As a simpler example, if two miners both mine a block at > approximately the same time and send it to each other, then surely > they would want to continue mining on their own block. Otherwise > they would be throwing away their own reward. That's not your concurrent validation scenario. In the scenario you described, the person chooses the weaker block of two that require validation because it's better somehow, not because it's his own (which does not require validation). > And yes, this can also happen over multiple blocks, but the chances > of consistency are vastly increased with each confirmation. Consistency is reached, despite seeing things at different times, because people use the same rules. If the economy ran on arbitrary block preference consistency would be elusive. > I am not talking about rejecting blocks, I am only talking choosing > on which tip to mine. This line of reasoning has me a bit baffled. Yet as I said, it's not important to the question at hand. It is not likely to be optimal to validate concurrently even if you consider selection of a weaker block advantageous. >> If you intend this to be useful it has to help build the chain, >> not just rely on hardwiring checkpoints once rule changes are >> presumed to be buried deeply enough to do so (as the result of >> other implementations ). >> >> I understand this approach, it was ours at one time. There is a >> significant difference, and your design is to some degree based >> on a failure to fully consider this. I encourage you to not >> assume any consensus-related detail is too small. > > I am not failing to consider this, and I don't consider this too > small . But ensuring contextual transaction validity by "validate > => valid with rules X,Y,Z" and then checking the active rules > (softfork activation) on order validation, will give logically the > same results as "validate with X,Y,Z => valid". This is not > "hardwiring checkpoints" at all. Storing the validation flags with each tx is exactly what libbitcoin does (otherwise pre-validation would be infeasible). But that was not the full point. You said on this in response previously: >>> ...height-based compliance as meta data of validation seems to >>> be adequate and safe. I read this as encoding the height at which a fork historically activated. If you intend to track activation for each branch that will not be "height-based" it will be history based. e -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJY7KTHAAoJEDzYwH8LXOFOI+QH/RzX++1TNLC9DEMWioE7SmMj yKOrP8WEkOnnrZdFKxVmwV9oZBekEvDABMnJmFiW5TMjsmPz7XwKAYzV0Y5L5oGU fZYo3IOPyr0dA9TcpP15gNziR6pFUBq/QTYB6BcbUvvlkJv6xjgIdedgDMEyREWU Hm/JU5g7gQUQd6MIDWbQ9FbYjtPuNSRQi851YfIn5mDivT4HuidaqQYMd9t5yS2Z FuoQBI6L5GTJIqml1bTwJ0wsA7+ZseBEgMn1TT1ehy2v1FFJTojTpzIwG+m3eiXg TxN3U/+fNAj+sKBb8Hq+nb7DvgjvKHyHuyRryBju7yq5d5rsb6meXcoiOtAznP8= =fRXf -----END PGP SIGNATURE-----