Discussion:
Solving the Scalability Problem Part II - Adam Shem-Tov
Add Reply
Adam Tamir Shem-Tov via bitcoin-dev
2017-08-26 21:01:56 UTC
Reply
Permalink
Raw Message
<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 “Genesis Account”, this
account’s 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 “mines” the
coins, and receives the mining bonus. In the 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
Thomas Guyot-Sionnest via bitcoin-dev
2017-08-26 21:41:34 UTC
Reply
Permalink
Raw Message
I don't think you fully understand the way bitcoin works. There are no
"accounts" and no need to know the private key to change transactions in
the chain. What you need is to keep track of all unspent outputs (block
number, index, value and script/witness) so that they can be verified
once a transaction refers to it.

Everything you suggest about moving those funds to a "genesis account"
is nonsense and cannot work.

--
Thomas
Post by Adam Tamir Shem-Tov via bitcoin-dev
<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 “Genesis
Account”, this account’s 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 “mines” the coins, and receives the mining bonus. In the 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
Christian Riley via bitcoin-dev
2017-08-26 21:42:16 UTC
Reply
Permalink
Raw Message
There have been a number of similar (identical?) proposals over the years, some were discussed in these threads:
https://bitcointalk.org/index.php?topic=56226.0
https://bitcointalk.org/index.php?topic=505.0
https://bitcointalk.org/index.php?topic=473.0
https://bitcointalk.org/index.php?topic=52859.0
https://bitcointalk.org/index.php?topic=12376.0
https://bitcointalk.org/index.php?topic=74559.15
Post by Adam Tamir Shem-Tov via bitcoin-dev
<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 “Genesis Account”, this account’s 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 “mines” the coins, and receives the mining bonus. In the 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Adam Tamir Shem-Tov via bitcoin-dev
2017-08-26 22:26:15 UTC
Reply
Permalink
Raw Message
Thank You Christian for your response.

https://bitcointalk.org/index.php?topic=473.0 : I dont see the relevance.
https://bitcointalk.org/index.php?topic=52859.0 : This idea does not seem
to talking about trimming the full node. Trimming the full node is the key,
the full node is what keeps us secure from hackers. If it can be trimmed
without losing security, that would be good, that is what I am proposing.
https://bitcointalk.org/index.php?topic=12376.0 : Same answer as 505.0.
https://bitcointalk.org/index.php?topic=74559.15 : I think his proposal is
similar to mine, unfortunately for us his predictions were way off. He was
trying to fix this problem while believing that in the year 2020 the
blockchain would be 4GB!!! It is not his fault, his prediction was in 2011.
But you can see, by his prediction, which was rational at the time, was way
off. And it stresses my point, we need to fix this now. Too bad, no one
took him seriously back then, when the block chain i was 1GB.
*https://bitcointalk.org/index.php?topic=56226.0
<https://bitcointalk.org/index.php?topic=56226.0>*: Another guy with a
valid point, who was first acknowledged and then apparently ignored.
.
To summarize, this problem was brought up about 6 years ago, when the
blockchain was 1GB in size, Now it is about 140GB in size. I think it is
about time we stop ignoring this problem, and realize something needs to
change, or else the only full-nodes you will have will be with private
multi-million dollar companies, because no private citizen will have the
storage space to keep it. That would make bitcoin the worst decentralized
or uncentralized system in history.
Post by Christian Riley via bitcoin-dev
There have been a number of similar (identical?) proposals over the years,
https://bitcointalk.org/index.php?topic=56226.0
https://bitcointalk.org/index.php?topic=505.0
https://bitcointalk.org/index.php?topic=473.0
https://bitcointalk.org/index.php?topic=52859.0
https://bitcointalk.org/index.php?topic=12376.0
https://bitcointalk.org/index.php?topic=74559.15
On Aug 26, 2017, at 5:01 PM, Adam Tamir Shem-Tov via bitcoin-dev <
<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 “Genesis Account”, this
account’s 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 “mines” the
coins, and receives the mining bonus. In the 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Jorge Timón via bitcoin-dev
2017-08-27 11:33:04 UTC
Reply
Permalink
Raw Message
Regarding storage space, have you heard about pruning? Probably you should.

On 27 Aug 2017 12:27 am, "Adam Tamir Shem-Tov via bitcoin-dev" <
Post by Adam Tamir Shem-Tov via bitcoin-dev
Thank You Christian for your response.
https://bitcointalk.org/index.php?topic=473.0 : I dont see the relevance.
https://bitcointalk.org/index.php?topic=52859.0 : This idea does not seem
to talking about trimming the full node. Trimming the full node is the key,
the full node is what keeps us secure from hackers. If it can be trimmed
without losing security, that would be good, that is what I am proposing.
https://bitcointalk.org/index.php?topic=12376.0 : Same answer as 505.0.
https://bitcointalk.org/index.php?topic=74559.15 : I think his proposal
is similar to mine, unfortunately for us his predictions were way off. He
was trying to fix this problem while believing that in the year 2020 the
blockchain would be 4GB!!! It is not his fault, his prediction was in 2011.
But you can see, by his prediction, which was rational at the time, was way
off. And it stresses my point, we need to fix this now. Too bad, no one
took him seriously back then, when the block chain i was 1GB.
*https://bitcointalk.org/index.php?topic=56226.0
<https://bitcointalk.org/index.php?topic=56226.0>*: Another guy with a
valid point, who was first acknowledged and then apparently ignored.
.
To summarize, this problem was brought up about 6 years ago, when the
blockchain was 1GB in size, Now it is about 140GB in size. I think it is
about time we stop ignoring this problem, and realize something needs to
change, or else the only full-nodes you will have will be with private
multi-million dollar companies, because no private citizen will have the
storage space to keep it. That would make bitcoin the worst decentralized
or uncentralized system in history.
Post by Christian Riley via bitcoin-dev
There have been a number of similar (identical?) proposals over the
https://bitcointalk.org/index.php?topic=56226.0
https://bitcointalk.org/index.php?topic=505.0
https://bitcointalk.org/index.php?topic=473.0
https://bitcointalk.org/index.php?topic=52859.0
https://bitcointalk.org/index.php?topic=12376.0
https://bitcointalk.org/index.php?topic=74559.15
On Aug 26, 2017, at 5:01 PM, Adam Tamir Shem-Tov via bitcoin-dev <
<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 “Genesis Account”, this
account’s 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 “mines”
the coins, and receives the mining bonus. In the 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Loading...