Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DF546491 for ; Sat, 26 Aug 2017 21:42:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f193.google.com (mail-ua0-f193.google.com [209.85.217.193]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 21DBED4 for ; Sat, 26 Aug 2017 21:42:19 +0000 (UTC) Received: by mail-ua0-f193.google.com with SMTP id x18so1279282uah.5 for ; Sat, 26 Aug 2017 14:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=LViGGtsal08wFIBRQirTyEUGHpvcd+lKRInBEdWFNSI=; b=vHw9f2k09R/4kR5k5mtXDhmj1TIWvDkgmAAI3y+CDZxD6mt/1hBm3RLlLn5uajcdJe j0XF5QRbR5NpkSotmEugDaY/IGmmLD2M2uHVEdK1JycSZCYHHlxfyzFWzFMX1fcO4Ind Rrn0iM0aoNtTSlq6N9i818e159zDmSaNbhOogm8szDl1piwnOvB4Qkg82H0cXJ/znbXa XUil3oJsMehpBjqbyvjbr2U9tvt0lHZlwHVMyUyP5qXCy7IZMQmCksswviXGM2D0hg6Q ehGdTJCoIOBOfPyFYwhCwkC9K8rZcluyGZzEdOk+ZTLMXw7cWHmZqwmlE/rc3Cc4LLBW aGEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to; bh=LViGGtsal08wFIBRQirTyEUGHpvcd+lKRInBEdWFNSI=; b=bKRAzI34sBwTkTbB4W5AY1rxB9yaD9d8Y0eUk+5IhHZvOLUf8ye2T1OEMyjB6Lca7W z6u90VFWFiTLmkAr9ge+POmSMVC6YxA17Q1bpuLGYyVbdSFom+a9VmioiwcO/yYE/ycs ynzCL73e43NoKdB2Q/Y47xoGmPD48MtgTLt7ZoBXg1OIZpblgpDnbNk7qasB9MMF6abj Nkrz3Ykad5M9QFRnoQWTDMT44iBpWhZPrsT2kWbsFUlcPTJYdSnv6arOV2aw9xJ8oIVa Yxerl8UcQAy9Dc+TvWd7/9XBdnxjsiYGLFC/GCSK2oXRjj50bIl1EXIBKF20zPUshkRz NzeA== X-Gm-Message-State: AHYfb5isE9DuB4qurcqTd3UPO1JKs22QPzUglWz9Nf42JUqc1ss7Da5e 3xqVr7VJgEJFBw== X-Received: by 10.176.23.77 with SMTP id k13mr1548622uaf.128.1503783738237; Sat, 26 Aug 2017 14:42:18 -0700 (PDT) Received: from [192.168.1.18] (c-73-53-249-28.hsd1.fl.comcast.net. [73.53.249.28]) by smtp.gmail.com with ESMTPSA id f123sm2110957vke.32.2017.08.26.14.42.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Aug 2017 14:42:17 -0700 (PDT) From: Christian Riley Content-Type: multipart/alternative; boundary=Apple-Mail-98ECC027-4FD5-488A-B789-24D5E0DB2BB7 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Sat, 26 Aug 2017 17:42:16 -0400 Message-Id: References: In-Reply-To: To: Adam Tamir Shem-Tov , Bitcoin Protocol Discussion X-Mailer: iPad Mail (14G60) X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, TVD_PH_BODY_ACCOUNTS_PRE autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 26 Aug 2017 21:44:18 +0000 Subject: Re: [bitcoin-dev] Solving the Scalability Problem Part II - Adam Shem-Tov 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, 26 Aug 2017 21:42:20 -0000 --Apple-Mail-98ECC027-4FD5-488A-B789-24D5E0DB2BB7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There have been a number of similar (identical?) proposals over the years, s= ome were discussed in these threads: https://bitcointalk.org/index.php?topic=3D56226.0 https://bitcointalk.org/index.php?topic=3D505.0 https://bitcointalk.org/index.php?topic=3D473.0 https://bitcointalk.org/index.php?topic=3D52859.0 https://bitcointalk.org/index.php?topic=3D12376.0 https://bitcointalk.org/index.php?topic=3D74559.15 > On Aug 26, 2017, at 5:01 PM, Adam Tamir Shem-Tov via bitcoin-dev wrote: >=20 > Solving the Scalability Problem Part II > -------------------------------------------------------------------- >
> In the previous post I showed a way to minimize the blocks on the block ch= ain, to lower the amount of space it takes on the hard drive, without losing= any relevant information. > I added a note, saying that the transaction chain needs to be rewritten, b= ut I did not give much detail to it.
> Here is how that would work:
> The Genesis Account: > -----------------------------------------
> The problem with changing the transaction and block chain, is that it cann= ot be done without knowing the private key of the sender of the of the funds= for each account. There is however a way to circumvent that problem. That i= s to create a special account called the =E2=80=9CGenesis Account=E2=80=9D, t= his account=E2=80=99s Private Key and Public Key will be available to everyo= ne.
> But this account will not be able to send or receive any funds in a normal= block, it will be blocked--blacklisted. So no one can intentionally use it.= The only time this account will be used is in the pruning block, a.k.a Exod= us Block.
> When creating the new pruned block chain and transaction chain, all the fu= nds that are now in accounts must be legitimate, and it would be difficult t= o legitimize them unless they were sent from a legitimate account, with a pu= blic key, and a private key which can be verified. That is where the Genesis= account comes in. All funds in the Exodus Block will show as though they or= iginated and were sent from the Genesis Account using its privatekey to gene= rate each transaction.
> The funds which are sent, must match exactly the funds existing in the mos= t updated ledger in block 1000 (the last block as stated in my previous post= ).
> In this way the Exodus Block can be verified, and the Genesis Account cann= ot give free money to anyway, because if someone tried to, it would fail ver= ification.
>
> Now the next problem is that the number of Bitcoins keeps expanding and so= the funds in the Genesis Account need to expand as well. That can be done b= y showing as though this account is the account which is mining the coins, a= nd it will be the only account in the Exodus Block which =E2=80=9Cmines=E2=80= =9D the coins, and receives the mining bonus. In the Exodus Block all coins m= ined by the real miners will show as though they were mined by Genesis and s= ent to the miners through a regular transaction. >
> Adam Shem-Tov >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-98ECC027-4FD5-488A-B789-24D5E0DB2BB7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
There have been a number of similar (identical?) pro= posals over the years, some were discussed in these threads:
https://bitc= ointalk.org/index.php?topic=3D56226.0

<= div>
On Aug 26, 2017, at 5:01 PM, Adam Tamir Shem-Tov via bitcoin-dev <= ;bitcoin-dev@lists.= linuxfoundation.org> wrote:

=09 =09 =09 =09

<B>Solving the Scalability Problem Part II</B>
--------------------------------------------------------------------
<BR>
In the previous post I showed a way to minimize the blocks on the block chain, to lower the amount of space it takes on the hard drive, without losing any relevant information.
I added a note, saying that the transaction chain needs to be rewritten, but I did not give much detail to it.<BR>
Here is how that would work:<BR>
<B>The Genesis Account:</B>
-----------------------------------------<BR>
The problem with changing the transaction and block chain, is that it cannot be done without knowing the private key of the sender of the of the funds for each account. There is however a way to circumvent that problem. That is to create a special account called the =E2=80=9CGenesi= s Account=E2=80=9D, this account=E2=80=99s Private Key and Public Key will be available to everyone.<BR>
But this account will not be able to send or receive any funds in a normal block, it will be blocked--blacklisted. So no one can intentionally use it. The only time this account will be used is in the pruning block, a.k.a Exodus Block.<BR>
When creating the new pruned block chain and transaction chain, all the funds that are now in accounts must be legitimate, and it would be difficult to legitimize them unless they were sent from a legitimate account, with a public key, and a private key which can be verified. That is where the Genesis account comes in. All funds in the Exodus Block will show as though they originated and were sent from the Genesis Account using its privatekey to generate each transaction.<BR>
The funds which are sent, must match exactly the funds existing in the most updated ledger in block 1000 (the last block as stated in my previous post).<BR>
In this way the Exodus Block can be verified, and the Genesis Account cannot give free money to anyway, because if someone tried to, it would fail verification.<BR>

<BR>
Now the next problem is that the number of Bitcoins keeps expanding and so the funds in the Genesis Account need to expand as well. That can be done by showing as though this account is the account which is mining the coins, and it will be the only account in the Exodus Block which =E2=80=9Cmines=E2=80=9D the coins, and receives the mining bonus. In t= he Exodus Block all coins mined by the real miners will show as though they were mined by Genesis and sent to the miners through a regular transaction.

<BR>

Adam Shem-Tov


____________________= ___________________________
bitcoin-dev mailing list<= br>bitcoin-de= v@lists.linuxfoundation.org
https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-98ECC027-4FD5-488A-B789-24D5E0DB2BB7--