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 8F99587A for ; Tue, 21 Jun 2016 22:12:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2042F13A for ; Tue, 21 Jun 2016 22:12:33 +0000 (UTC) Received: by mail-io0-f169.google.com with SMTP id f30so28880548ioj.2 for ; Tue, 21 Jun 2016 15:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adligo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=t1KErJYhfN6zzbX+oN7KbE3OcncKsuAyy31lCGQqcJ0=; b=vgdJAKsuAervrp6K6D144zv8xvNTiyCYdqD7G4WV8H7mdTdYi6o03I/lKPrLnQ4A3Q 3nhcNVIaJ1GOg1St1AwRtgPpclpGGDqU5Np1ZIFY6VhqqH5f88o4Y1h6PKRgYvxFE1Be DxuzVQcg5PwbrpKtwWsU1wEXSItwxexdFNjnPdHe+vKlXXOy6kOzKzhDtj+xQDSgABwc aICMl4YLzUokErvB/QqkjmRiqNcSlGX3o4IFFkYUa9lTD4csl+1rjLei1b2TIP09Gss5 EA19xrQ/C9qwKEzDmThcmvoa8Wul/coXOoJt3qveJgp8k81QUVt7Y/0uatlZacZBfMVo 1xug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=t1KErJYhfN6zzbX+oN7KbE3OcncKsuAyy31lCGQqcJ0=; b=mdwlaPwIDMtu3i913jDQUL8Jt9de4PKzGaAL5CQskXN7WTcDQIkibRa5EJt//2xq1W UAMNn+96Kblpm37B9HM8a7cZa4z815PrsJUEuTaPd8bQhrZPu6+xGmb6QitQLpc9fSx0 sE5wg+NY4+tbjx4rd//47SLx/D+tKWenRciT/ApD6LnV+FJhTxiH+UGJbb1O6aQb1NQV jUiud/CBK8iSnJcnkedzu3tKogw7ZZ52K/gWLmixkcHWIhQSQcwMjWa+WCb2FBXTyIkc 3Q80tPipoS7G+udkpbf+LZQ6LWmHa+44dcTNLl3XsOB+2XoZb6fcSAg+Pv55+kTHo4MA l6Hg== X-Gm-Message-State: ALyK8tKeg5m1K8oZhfFLjfDQOo0XXsYDHijihUe1y+rzLoJmcFiwhGk59+JRqgu5zaLO3qj3qsOp5507msYRBQ== MIME-Version: 1.0 X-Received: by 10.107.47.41 with SMTP id j41mr34128021ioo.168.1466547152380; Tue, 21 Jun 2016 15:12:32 -0700 (PDT) Received: by 10.79.138.1 with HTTP; Tue, 21 Jun 2016 15:12:32 -0700 (PDT) Date: Tue, 21 Jun 2016 17:12:32 -0500 Message-ID: From: Scott Morgan To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a11c1468e107df80535d11e54 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 X-Mailman-Approved-At: Wed, 22 Jun 2016 00:22:22 +0000 Subject: [bitcoin-dev] Merkel Forrest Partitioning 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, 21 Jun 2016 22:12:33 -0000 --001a11c1468e107df80535d11e54 Content-Type: text/plain; charset=UTF-8 Hi Akiva, I have also given a little thought to partitioning, in a totally different way a Merkel Tree Forrest. Generally the idea here would have be to create new Merkel Trees every so often as currency supply was added. It would partition the mining process and therefore improve the distribution of the verification. It would work as follows, and NO I haven't really thought this through it's just an idea! Imagine it was 2009 and there was a small number of 250 BTC in 'Batch 1', once the number of BTC needed to go above 250 BTC two new Batches would be created each one with it's own Merkel Tree until 750 BTC and so on. Eventually there would be a large number of trees, allowing small scale pool miners to dominate a single or small number of the trees and their block chains. This would also create a potential partial payment problem, where you send 3 BTC but only receive 2 BTC since 1 BTC ends up on a bad block and needs to be resent. Since most of the BTC currency supply is already available it's a bit late for BitCoin, but could be used for new crypto currencies. Any thoughts on this idea? Cheers, Scott --001a11c1468e107df80535d11e54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Akiva,

=C2=A0 =C2=A0I have also given a little thought to partitioning, in a totally different way a Merkel Tree Forrest. Generally the idea here would have be to create new Merkel Trees every so often as currency supply was added.=20 It would partition the mining process and therefore improve the distribution of the verification.

It would work as follows, and NO I haven't really thought this through it's just an idea!


Imagine it was 2009 and there was a small number of 250 BTC in 'Batch 1', once the number of BTC needed to go above 250 BTC two new Batches would be created each one with it's own Merkel Tree until 750 BTC and so on. Eventually there would be a large number of trees, allowing small scale pool miners to dominate a single or small number of the trees and their block chains.

This would also create a potential partial payment problem, where you send 3 BTC but only receive 2 BTC since 1 BTC ends up on a bad block and needs to be resent.


Since most of the BTC currency supply is already available it's a bit late for BitCoin, but could be used for new crypto currencies.


Any thoughts on this idea?


Cheers,=

Scott

--001a11c1468e107df80535d11e54--