path: root/72/f0ea64a2bb2f3ff7f17277ee9b20f842a74721

Return-Path: <tshachaf@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6E5985A9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 26 Aug 2017 19:21:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f52.google.com (mail-lf0-f52.google.com
	[209.85.215.52])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 51D5C87
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 26 Aug 2017 19:21:19 +0000 (UTC)
Received: by mail-lf0-f52.google.com with SMTP id c189so589610lfe.4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 26 Aug 2017 12:21:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:from:date:message-id:subject:to;
	bh=8uTes3ht148DKXxGya6ZlXjUIJahZ3Wc2GH4/hh9dHk=;
	b=GcgHBgHyzi9Rwft2JhsdgOF9hYDFqhp9T69Ym6bZR94PT/gxwpin9IjSLpIutJEsSs
	TrG2zjQ9eSr7M23lrVXVTn6qbffTWln+3p4UEoFtREJtiAp/PIlh473SoYNkWsZItlqj
	vzjhOh3lCuoAAda+TC6NwJvFJi3JH0uqzevGZYzoCAMpqD8CZWoR3duUBMZmBA59CdBL
	Bvpm9E+uIl4IF6BIfqLUQRoEoL6Ds154+XW56PmS+U7So5jMBhc54DBJwHsPRd/S0y2z
	wxxvNuJUi/HUPSz4xUO2OquwPjuh6ahtblp2XuxPh2lUmZQQgxwCqj/DtJKbVlgDxuT/
	cY/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
	bh=8uTes3ht148DKXxGya6ZlXjUIJahZ3Wc2GH4/hh9dHk=;
	b=Ns6/0l5/5BotPIpjYjmckxyT2Rx+/iSGhBPB3BvscL49f8NoViktNAb39ymxQ3mkb3
	XL9JM8H3ZVWitk1fd6uspblovKS8ECytWiiszMNhLjxe02+bvIDJBs9vu5zadXYe7tX7
	KZaLtmZWRgfk+rKfbB0w61JP96X+CckYEnhHw+vF4U6hCHTs9elgltKSSPKbaObJDIhf
	AJiNteoYJdzmi7pt5W1F2/MfSQ3Eoi23Vcj1DgTbaebhIlmXnOX7LwJpqJ4bCypCXztW
	FmzCOcf0YBazaqjsbnk0qH8T0ojlnoTEY6w/wisV8fqUqa3bphezxv0RMS7fgatn6yz4
	jISg==
X-Gm-Message-State: AHYfb5gjUjtDem5sB2jmv4hH0Ov/Ch7QrYpgZ2Bs8xYYx95AyO511J/3
	xmal+JeemaaolqniQJMUoGnaNr07I9ch
X-Received: by 10.46.78.17 with SMTP id c17mr834414ljb.106.1503775277173; Sat,
	26 Aug 2017 12:21:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.20.76 with HTTP; Sat, 26 Aug 2017 12:21:16 -0700 (PDT)
From: Adam Tamir Shem-Tov <tshachaf@gmail.com>
Date: Sat, 26 Aug 2017 22:21:16 +0300
Message-ID: <CACQPdjphPmSC7bmicXGytuD3YAXYmsEGOECTTTuLfB_5iqDQGw@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="f403045ecf0637d11c0557acf763"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM 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 19:23:45 +0000
Subject: [bitcoin-dev] Solving the Scalability Problem on Bitcoin
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Aug 2017 19:21:20 -0000

--f403045ecf0637d11c0557acf763
Content-Type: text/plain; charset="UTF-8"

<B> Solving the Scalability issue for bitcoin </B> <BR>

I have this idea to solve the scalability problem I wish to make public.

If I am wrong I hope to be corrected, and if I am right we will all gain by
it. <BR>

Currently each block is being hashed, and in its contents are the hash of
the block preceding it, this goes back to the genesis block.

<BR>

What if we decide, for example, we decide to combine and prune the
blockchain in its entirety every 999 blocks to one block (Genesis block not
included in count).

<BR>

How would this work?: Once block 1000 has been created, the network would
be waiting for a special "pruned block", and until this block was created
and verified, block 1001 would not be accepted by any nodes.

This pruned block would prune everything from block 2 to block 1000,
leaving only the genesis block. Blocks 2 through 1000, would be calculated,
to create a summed up transaction of all transactions which occurred in
these 999 blocks.

<BR>

And its hash pointer would be the Genesis block.

This block would now be verified by the full nodes, which if accepted would
then be willing to accept a new block (block 1001, not including the pruned
block in the count).

<BR>

The new block 1001, would use as its hash pointer the pruned block as its
reference. And the count would begin again to the next 1000. The next
pruned block would be created, its hash pointer will be referenced to the
Genesis Block. And so on..

<BR>

In this way the ledger will always be a maximum of 1000 blocks.

<BR>
<B> A bit more detail: </B>
<BR>
All the outputs needed to verify early transactions will all be in the
pruning block. The only information you lose are of the intermediate
transactions, not the final ones the community has already accepted.

For example:

<BR>

A = 2.3 BTC, B=0, C=1.4. (Block 1)

<BR>

If A sends 2.3 BTC to B. (Block 2)

<BR>

And then B sends 1.5 to C. (Block 3)

<BR>

The pruning block will report:

<BR>

B = 0.8 and C=2.9. <BR>

The rest of the information you lose, is irrelevant. No one needs to know
that A even existed since it is now empty, nor do they need to know how
much B and C had previously, only what they have now.

<BR>
Note: The Transaction Chain would also need to be rewritten, to delete all
intermediate transactions, it will show as though transactions occurred
from the Genesis block directly to the pruned block, as though nothing ever
existed in between.

<BR>

<BR>

You can keep the old blocks on your drive for 10 more blocks or so, just in
case a longer block chain is found, but other than that the information it
holds is useless, since it has all been agreed upon. And the pruning block
holds all up to date account balances, so cheating is impossible.

<BR>

Granted this pruning block can get extremely large in the future, it will
not be the regular size of the other blocks. For example if every account
has only 1 satoshi in it, which is the minimum, then the amount of accounts
will be at its maximum. Considering a transaction is about 256bytes. That
would mean the pruning block would be approximately 500PB, which is 500,000
Terra-bytes. That is a theoretical scenario, which is not likely to occur.
(256bytes*23M BTC*100M (satoshis in 1 BTC))

<BR>

A scenario which could be solved by creating a minimum transaction fee of
100 satoshis, which would insure that even in the most unlikely scenario,
at worst the pruning block would be 5PB in size.

<BR>

Also, this pruning block does not even need to be downloaded, it could be
created by already existing information, each full node by itself, by <BR>

1) combining and pruning all previous blocks <BR>

2) using the genesis block as its hash pointer <BR>

3) using a predefined random number "2", which will be used by all. A
random number which is normally added to a block to ensure the block's
hashrate difficulty, is not needed in this case, since all information can
be verified by each node by itself through pruning. <BR>

4) Any other information which is needed for the SHA256 hash, for example a
timestamp could be copied off the last block in the block chain. <BR>

These steps will ensure each full node, will get the exact hash code as the
others have gotten for this pruning block.

<BR>

And as I previously stated the next block will use this hash code as its
hash reference.

<BR>

By creating a system like this, the pruning block does not have to be
created last minute, but gradually over time, every time a new block comes
in, and only when the last block arrives (block 1000), will it be
finalized, and hashed.

<BR>

And since this block will always be second, it should go by the name
"Exodus Block".
<BR>
Adam Shem-Tov

--f403045ecf0637d11c0557acf763
Content-Type: text/html; charset="UTF-8"

<div dir="ltr">


	
	
	
	


<p style="margin-bottom:0in;line-height:100%">&lt;B&gt; Solving
the Scalability issue for bitcoin &lt;/B&gt; &lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">I have this idea to
solve the scalability problem I wish to make public.</p>
<p style="margin-bottom:0in;line-height:100%">If I am wrong I hope
to be corrected, and if I am right we will all gain by it. &lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">Currently each block
is being hashed, and in its contents are the hash of the block
preceding it, this goes back to the genesis block.</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">What if we decide,
for example, we decide to combine and prune the blockchain in its
entirety every 999 blocks to one block (Genesis block not included in
count).</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">How would this
work?: Once block 1000 has been created, the network would be waiting
for a special &quot;pruned block&quot;, and until this block was
created and verified, block 1001 would not be accepted by any nodes.</p>
<p style="margin-bottom:0in;line-height:100%">This pruned block
would prune everything from block 2 to block 1000, leaving only the
genesis block. Blocks 2 through 1000, would be calculated, to create
a summed up transaction of all transactions which occurred in these
999 blocks.</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">And its hash pointer
would be the Genesis block.</p>
<p style="margin-bottom:0in;line-height:100%">This block would now
be verified by the full nodes, which if accepted would then be
willing to accept a new block (block 1001, not including the pruned
block in the count).</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">The new block 1001,
would use as its hash pointer the pruned block as its reference. And
the count would begin again to the next 1000. The next pruned block
would be created, its hash pointer will be referenced to the Genesis
Block. And so on..</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">In this way the
ledger will always be a maximum of 1000 blocks.</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;<br>
&lt;B&gt;
A bit more detail: &lt;/B&gt;<br>
&lt;BR&gt;<br>
All the outputs
needed to verify early transactions will all be in the pruning block.
The only information you lose are of the intermediate transactions,
not the final ones the community has already accepted.</p>
<p style="margin-bottom:0in;line-height:100%">For example:</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">A = 2.3 BTC, B=0,
C=1.4. (Block 1)</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">If A sends 2.3 BTC
to B.  (Block 2)</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">And then B sends 1.5
to C. (Block 3)</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">The pruning block
will report:</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">B = 0.8 and C=2.9.
&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">The rest of the
information you lose, is irrelevant. No one needs to know that A even
existed since it is now empty, nor do they need to know how much B
and C had previously, only what they have now.</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;<br>
Note:
 The Transaction Chain would also need to be rewritten, to delete all
intermediate transactions, it will show as though transactions
occurred from the Genesis block directly to the pruned block, as
though nothing ever existed in between.</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">You can keep the old
blocks on your drive for 10 more blocks or so, just in case a longer
block chain is found, but other than that the information it holds is
useless, since it has all been agreed upon. And the pruning block
holds all up to date account balances, so cheating is impossible.</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">Granted this pruning
block can get extremely large in the future, it will not be the
regular size of the other blocks. For example if every account has
only 1 satoshi in it, which is the minimum, then the amount of
accounts will be at its maximum. Considering a transaction is about
256bytes. That would mean the pruning block would be approximately
500PB, which is 500,000 Terra-bytes. That is a theoretical scenario,
which is not likely to occur. (256bytes*23M BTC*100M (satoshis in 1
BTC))</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">A scenario which
could be solved by creating a minimum transaction fee of 100
satoshis, which would insure that even in the most unlikely scenario,
at worst the pruning block would be 5PB in size.</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">Also, this pruning
block does not even need to be downloaded, it could be created by
already existing information, each full node by itself, by &lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">1) combining and
pruning all previous blocks &lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">2) using the genesis
block as its hash pointer &lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">3) using a
predefined random number &quot;2&quot;, which will be used by all. A
random number which is normally added to a block to ensure the
block&#39;s hashrate difficulty, is not needed in this case, since all
information can be verified by each node by itself through pruning.
&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">4) Any other
information which is needed for the SHA256 hash, for example a
timestamp could be copied off the last block in the block chain. &lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">These steps will
ensure each full node, will get the exact hash code as the others
have gotten for this pruning block.</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">And as I previously
stated the next block will use this hash code as its hash reference.</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">By creating a system
like this, the pruning block does not have to be created last minute,
but gradually over time, every time a new block comes in, and only
when the last block arrives (block 1000), will it be finalized, and
hashed.</p>
<p style="margin-bottom:0in;line-height:100%">&lt;BR&gt;</p>
<p style="margin-bottom:0in;line-height:100%">And since this block
will always be second, it should go by the name &quot;Exodus
Block&quot;.<br>
&lt;BR&gt;<br>
Adam Shem-Tov</p>

</div>

--f403045ecf0637d11c0557acf763--