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 43E2B40C for ; Sat, 10 Dec 2016 21:29:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f180.google.com (mail-qt0-f180.google.com [209.85.216.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B4A2ED3 for ; Sat, 10 Dec 2016 21:29:10 +0000 (UTC) Received: by mail-qt0-f180.google.com with SMTP id p16so46176304qta.0 for ; Sat, 10 Dec 2016 13:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=LbZvU692mPAlUEpAa5MNdrA7Rwux5ktKjDQt+Pt74Ow=; b=tT7VxfbHTO7bsMzC9WXrsrFTAn51iA3Nhanc5VIvX8zM9ntGwSTyO+FPBqq5CUq9Op P2N4yvSNwxbrCpM7NWg+iP+t20GG93CboB/L7AaO9iqQMaW3P13FUi/9jvB9FR6pmZEO oJTukvmrSrZtzESt9kwBLW+U+R061CImAIqbbF3fVXfC2AoU7xFDVT/w5eeTHJORGRyN Xsbvve2I2hF3ax30R7NWLZ60WbfN4sjNmVBPgdDT1PzF4f8uqs3ul3Qbx+7PVYLIEBYq B9xlUJDXvBzKCba8w0T603EmXQ/YQCumUWd7WTZ5eoXL+A0SvOa7BNyXZFkEKzr/8e+B YdgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=LbZvU692mPAlUEpAa5MNdrA7Rwux5ktKjDQt+Pt74Ow=; b=bE8HmmGaeetkpFSW1c9czPlAybaZC4ITDfinpx+bUJKIm3uWMZr0DpJ/N9cHLOxIVj jssab9Odj/WQ212XWKQoKmxhaBqHTLAxusd4OydyFc3xj80e8St+D5CTGzcCsPOFZFMm YvKvUp8uix6qjepEMg+2GwwkXUQzzPjFm3FoV9UYYMKwT2ObWNEvSsK0oryNneA8zbHY T6PmVwAAAzhTVq6THygdpgylyfKcLTbDspRLKdsbu/RIugs5h9XCp0/6dN2m49isVv2M 2EzABAXm+h1Eg26BJbqlH1ocYLS6t2pqZhQkpnT4AKNpUzW4llgHRVeJM9PRNRuF0VNk gAbA== X-Gm-Message-State: AKaTC00GtYSmI03PTFbF6kMcp6zbAAEdBTF1SxlGZPC06+ITpT3NGuVXhQ8IbIbFDVMROKxkyNcKjYNSua0U0w== X-Received: by 10.237.37.60 with SMTP id v57mr86895233qtc.135.1481405349812; Sat, 10 Dec 2016 13:29:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.52.99 with HTTP; Sat, 10 Dec 2016 13:29:09 -0800 (PST) In-Reply-To: References: From: Tier Nolan Date: Sat, 10 Dec 2016 21:29:09 +0000 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a114125e0a4eda00543548f6e X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 Subject: Re: [bitcoin-dev] Forcenet: an experimental network with a new header format 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, 10 Dec 2016 21:29:11 -0000 --001a114125e0a4eda00543548f6e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Dec 4, 2016 at 7:34 PM, Johnson Lau via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Something not yet done: > 1. The new merkle root algorithm described in the MMHF BIP > Any new merkle algorithm should use a sum tree for partial validation and fraud proofs. Is there something special about 216 bits? I guess at most 448 bits total means only one round of SHA256. 16 bits for flags would give 216 for each child. Even better would be to make the protocol extendable. Allow blocks to indicate new trees and legacy nodes would just ignore the extra ones. If Bitcoin supported that then the segregated witness tree could have been added as a easier soft fork. The sum-tree could be added later as an extra tree. > 3. Communication with legacy nodes. This version can=E2=80=99t talk to le= gacy > nodes through the P2P network, but theoretically they could be linked up > with a bridge node > The bridge would only need to transfer the legacy blocks which are coinbase only, so very little data. > 5. Many other interesting hardfork ideas, and softfork ideas that works > better with a header redesign > That is very true. --001a114125e0a4eda00543548f6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Dec 4, 2016 at 7:34 PM, Johnson Lau via bitcoin-de= v <bitcoin-dev@lists.linuxfoundation.org><= /span> wrote:
Something not yet done:
1. The new merkle root algorithm described in the MMHF BIP
=

Any new merkle algorithm should use a sum tree for part= ial validation and fraud proofs.

Is there something speci= al about 216 bits?=C2=A0 I guess at most 448 bits total means only one roun= d of SHA256.=C2=A0 16 bits for flags would give 216 for each child.
Even better would be to make the protocol extendable.=C2=A0 Allow bl= ocks to indicate new trees and legacy nodes would just ignore the extra one= s.=C2=A0 If Bitcoin supported that then the segregated witness tree could h= ave been added as a easier soft fork.

The sum-tree could = be added later as an extra tree.
=C2=A0
3. Communication with legacy nodes. This version can=E2=80=99t talk to lega= cy nodes through the P2P network, but theoretically they could be linked up= with a bridge node

The bridge would on= ly need to transfer the legacy blocks which are coinbase only, so very litt= le data.
=C2=A0
5. Many other interesting hardfork ideas, and softfork ideas that works bet= ter with a header redesign

That is very= true.=C2=A0
--001a114125e0a4eda00543548f6e--