Re: [bitcoin-dev] Solving the Scalability Problem on Bitcoin

[Matthew Beton via bitcoin-dev]

I think a slight problem with this is that wallets (often ones made by
third party wallet software) do not fully empty. I don't know how often
this happens, but some wallets, even if you tell them to send all funds,
leave a small fraction of bitcoin remaining. If this is the case, it could
be detrimental to the 'pruning idea', as wallets with any coins left cannot
be pruned. For example:

A has 1 BTC
A -> B -> C
If these wallets are not removing all the BTC, and a fraction is left over,
B will not be able to be pruned out of the chain. On the other hand, of the
wallets are completely emptied, the new 'pruned block' will be able to show
A sending 1btc to C.

This could be a problem, and so we need a way to persuade people to get
their wallets to send everything instead of leaving a small fraction left
over. I don't know how problematic this could be, or how frequently this
happens, but I'm just putting it out there.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Solving the Scalability Problem on Bitcoin

[Leandro Coutinho via bitcoin-dev]

>>> 5) The problem with node pruning is that it is not standardized, and
for a new node to enter the network and to verify the data, it needs to
download all data and prune it by itself. This will drastically lower the
information needed by the full nodes by getting rid of the junk.  Currently
we are around 140GB, that number is getting bigger exponentially, by the
number of users and transactions created. It could reach a Terrabyte sooner
than expected, we need to act now.

To have to download all blockchain for then prune is a big drawback.
So I thought about the concept of "trusted" nodes, where you could choose
some nodes to connect and from which block you want to download. Of course
they would do this by their own risk, but there are ways to minimize the
risk, like:
  - check the latest blocks (hashes) if they match what you find in some
sites, like blockchain.info
  - download and compare the utxo from all (some) the nodes you are
connected

Currently utxo size is around 2GB and we cant know how fast it will grow (?)

Em 26/08/2017 19:39, "Adam Tamir Shem-Tov via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> escreveu:

Thank you Thomas for your response.

1) Implement solution is impossible... I have given a solution in part II.
By adding a Genesis Account which will be the new sender.

2)Keeping older blocks: Yes as I said 10 older blocks should be kept, that
should suffice. I am not locked on that number, if you think there is a
reason to keep more than that, it is open to debate.

3) Why 1000? To be honest, that number came off the top of my head. These
are minor details, the concept must first be accepted, then we can work on
the minor details.

4)Finally it's not just the addresses and balance you need to save...  I
think the Idea of the Genesis Account, solves this issue.

5) The problem with node pruning is that it is not standardized, and for a
new node to enter the network and to verify the data, it needs to download
all data and prune it by itself. This will drastically lower the
information needed by the full nodes by getting rid of the junk.  Currently
we are around 140GB, that number is getting bigger exponentially, by the
number of users and transactions created. It could reach a Terrabyte sooner
than expected, we need to act now.

On your second email:
When I say account: I mean private-public key.
The way bitcoin works, as I understand it, is that the funds are verified
by showing that they have an origin, this "origin" needs to provide a
signature, otherwise the transaction won't be accepted.
If I am proposing to remove all intermediate origins, then the funds become
untraceable and hence unverifiable. To fix that, a new transaction needs to
replace old ones. A simplified version: If there was a transaction chain
A->B->C->D, and I wish to show only A->D, only a transaction like that
never actually occurred, it would be impossible to say that it did without
having A's private key, in order to sign this transaction. In order to
create this transaction, I need A's private key. And if I wish this to be
publicly implemented I need this key to be public, so that any node
creating this Exodus Block can sign with it. Hence the Genesis Account. And
yes, it is not really an account.

On 27 August 2017 at 00:31, Thomas Guyot-Sionnest  wrote:

> Pruning is already implemented in the nodes... Once enabled only unspent
> inputs and most recent blocks are kept. IIRC there was also a proposal to
> include UTXO in some blocks for SPV clients to use, but that would be
> additional to the blockchain data.
>
> Implementing your solution is impossible because there is no way to
> determine authenticity of the blockchain mid way. The proof that a block
> hash leads to the genesis block is also a proof of all the work that's been
> spent on it (the years of hashing). At the very least we'd have to keep all
> blocks until a hard-coded checkpoint in the code, which also means that as
> nodes upgrades and prune more blocks older nodes will have difficulty
> syncing the blockchain.
>
> Finally it's not just the addresses and balance you need to save, but also
> each unspent output block number, tx position and script that are required
> for validation on input. That's a lot of data that you're suggesting to
> save every 1000 blocks (and why 1000?), and as said earlier it doesn't even
> guarantee you can drop older blocks. I'm not even going into the details of
> making it work (hard fork, large block sync/verification issues, possible
> attack vectors opened by this...)
>
> What is wrong with the current implementation of node pruning that you are
> trying to solve?
>
> --
> Thomas
>
> On 26/08/17 03:21 PM, Adam Tamir Shem-Tov via bitcoin-dev wrote:
>
>  Solving the Scalability issue for bitcoin  
>
> 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. 
>
> Currently each block 

Re: [bitcoin-dev] Solving the Scalability Problem on Bitcoin

[Btc Ideas via bitcoin-dev]

I also like only keeping the last "n" blocks. Every "n" minus all the previous 
balances are kept, but the transactions are deleted. There's good enough record 
keeping, and there's excessive. Part of scaling is being able to get the 
blockchain and sync quickly.

Jason

 Original Message 
On Aug 27, 2017, 05:31, Thomas Guyot-Sionnest via bitcoin-dev wrote:

> Pruning is already implemented in the nodes... Once enabled only unspent 
> inputs and most recent blocks are kept. IIRC there was also a proposal to 
> include UTXO in some blocks for SPV clients to use, but that would be 
> additional to the blockchain data.
>
> Implementing your solution is impossible because there is no way to determine 
> authenticity of the blockchain mid way. The proof that a block hash leads to 
> the genesis block is also a proof of all the work that's been spent on it 
> (the years of hashing). At the very least we'd have to keep all blocks until 
> a hard-coded checkpoint in the code, which also means that as nodes upgrades 
> and prune more blocks older nodes will have difficulty syncing the blockchain.
>
> Finally it's not just the addresses and balance you need to save, but also 
> each unspent output block number, tx position and script that are required 
> for validation on input. That's a lot of data that you're suggesting to save 
> every 1000 blocks (and why 1000?), and as said earlier it doesn't even 
> guarantee you can drop older blocks. I'm not even going into the details of 
> making it work (hard fork, large block sync/verification issues, possible 
> attack vectors opened by this...)
>
> What is wrong with the current implementation of node pruning that you are 
> trying to solve?
>
> --
> Thomas
>
> On 26/08/17 03:21 PM, Adam Tamir Shem-Tov via bitcoin-dev wrote:
>
>>  Solving the Scalability issue for bitcoin  
>>
>> 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. 
>>
>> 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.
>>
>> 
>>
>> 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).
>>
>> 
>>
>> 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.
>>
>> 
>>
>> 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).
>>
>> 
>>
>> 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..
>>
>> 
>>
>> In this way the ledger will always be a maximum of 1000 blocks.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Revised - Solving the Scalability Problem on Bitcoin

[Adam Tamir Shem-Tov via bitcoin-dev]

This is a link to the most updated version of the problem and my proposed
solution, granted it still needs work, but this problem needs to be
resolved quickly. So I hope it will receive the attention it deserves, even
if the solution comes from somebody else.
https://bitcointalk.org/index.php?topic=2126152.new#new

The latest version of the day:

*Solving the Scalability issue for Bitcoin  *

*What am I trying to solve?* Currently Bitcoin’s blockchain is around 140GB.
In 2011 it took 1GB, and it was predicted back then that in 2020 that size
would be 4GB.
As you can see it is not yet 2020, and we are way over that predicted size.
At our current time, prune nodes which make the block smaller, but they can
not be validated without the full node. And this full node is getting
exponentially bigger, we need to stop that. Because if we don’t no private
citizen will have the capability of storing the full node in his computer,
and all full nodes will be at private multi-million dollar companies. That
would literally be the end of decentralization (or non-centralization).
What I am proposing also makes sure the blockchain has a maximum finite
size, because today the blockchain can grow to any size without limit while
it approaches an infinite size!
Today our blockchain is growing at speed which is much faster than Moore’s
law! This proposal will help set storage growth at a reasonable number.


*A short list of what I am about to explain:   Steps that need to be taken:*
-
(The details are not described in this order)
1) Create a pair of keys, called the Genesis Pair, or Genesis Account, a
private and public key which will be publicly known to all and yet it’s use
will be restricted and monitored by all. The key will be the source of all
funds (Point A).
2) Preserve the Genesis Block, its hash code is needed. And personally I
think its of historical value.
3) Combine all Blocks up to the most recent (not including the Genesis
Block), and cut out all intermediary transactions, by removing All
transactions, and replacing them with new transactions sent from A to every
public key which has funds in the most recent block, in the amount they
have. And sign these transactions with A’s private-key. And create a new
block with this information.
4) This Combined/Pruned Block should point to the Genesis Block hash, and
the next block created should point to the Pruned Blocks hash. The random
number used for this pruned block will be predefined, this random number
normally used to meet the hash difficulty requirement in this case is not
needed, since no difficulty setting is necessary for this block, and by
predefining it, this block can be easily identified.
5) Download the pruned block from another node or create it yourself, the
hash code will be identical for everyone, since the block will be created
exactly the same everywhere.
6) Preserve a certain amount of the most recent blocks, just in case a
longer blockchain is discovered, and then the Pruned Block should be
recalculated.

-
*Now for a more detailed description: *
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.
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.

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).

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.

And its hash pointer would be the Genesis block.
This block would now be verified by the full nodes (or created by them),
which if accepted would then be willing to accept a new block (block 1001,
not including the pruned block in the count).

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..
In this way the ledger will always be a maximum of 1000 blocks.

 A bit more detail:

All the relevant outputs needed to verify early transactions will all be
preserved in the pruning block. The only information you lose are of the
intermediate transactions, not the final ones the community has already
accepted. 

Re: [bitcoin-dev] Solving the Scalability Problem on Bitcoin

[Thomas Guyot-Sionnest via bitcoin-dev]

How do you trust your <1000 block blockchain if you don't
download/validate the whole thing? (I know it should be easy to spot
that by looking at the blocks/tx or comparing to other nodes, but from a
programmatic point of view this is much harder). You can of course
include a checkpoint in the code to tell which recent block is valid
(which is already done afaik), but you still need all blocks from that
checkpoint to validate the chain (not 10!). If you rely on such
checkpoint, why not just include the UTXO's as well so you can start
mid-way based on code trust?

Indeed pruning doesn't allow you to start mid-way yet but there are much
easier solutions to that than what you propose.

--
Thomas

On 26/08/17 06:32 PM, Adam Tamir Shem-Tov wrote:
> Thank you Thomas for your response.
>
> 1) Implement solution is impossible... I have given a solution in part
> II. By adding a Genesis Account which will be the new sender.
>
> 2)Keeping older blocks: Yes as I said 10 older blocks should be kept,
> that should suffice. I am not locked on that number, if you think
> there is a reason to keep more than that, it is open to debate.
>
> 3) Why 1000? To be honest, that number came off the top of my head.
> These are minor details, the concept must first be accepted, then we
> can work on the minor details.
>
> 4)Finally it's not just the addresses and balance you need to save... 
> I think the Idea of the Genesis Account, solves this issue.
>
> 5) The problem with node pruning is that it is not standardized, and
> for a new node to enter the network and to verify the data, it needs
> to download all data and prune it by itself. This will drastically
> lower the information needed by the full nodes by getting rid of the
> junk.  Currently we are around 140GB, that number is getting bigger
> exponentially, by the number of users and transactions created. It
> could reach a Terrabyte sooner than expected, we need to act now.
>
> On your second email:
> When I say account: I mean private-public key.
> The way bitcoin works, as I understand it, is that the funds are
> verified by showing that they have an origin, this "origin" needs to
> provide a signature, otherwise the transaction won't be accepted.
> If I am proposing to remove all intermediate origins, then the funds
> become untraceable and hence unverifiable. To fix that, a new
> transaction needs to replace old ones. A simplified version: If there
> was a transaction chain A->B->C->D, and I wish to show only A->D, only
> a transaction like that never actually occurred, it would be
> impossible to say that it did without having A's private key, in order
> to sign this transaction. In order to create this transaction, I need
> A's private key. And if I wish this to be publicly implemented I need
> this key to be public, so that any node creating this Exodus Block can
> sign with it. Hence the Genesis Account. And yes, it is not really an
> account.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Solving the Scalability Problem Part II - Adam Shem-Tov

[Jorge Timón via bitcoin-dev]

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" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
> *: 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.
>
>
> On 27 August 2017 at 00:42, Christian Riley  wrote:
>
>> 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
>>
>>
>> On Aug 26, 2017, at 5:01 PM, Adam Tamir Shem-Tov via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Solving the Scalability Problem Part II
>> 
>> 
>> 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.
>> Here is how that would work:
>> The Genesis Account:
>> -
>> 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.
>> 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.
>> 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.
>> 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).
>> 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.
>>
>> 
>> 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