Significant slimming of Blockchain

[Frodek]

Trouble of blockchain size is often belittled, but I personally mind. Imagine 100 millions of people using bitcoin. Every day.
My proposal involves big changes in blockchain and I don't know how to impacts to security.
Namely.
In https://en.bitcoin.it/wiki/Introduction is Bitcoin idea:

   

Suppose Alice wants to send a Bitcoin to Bob.
    1) Bob sends his address (from which the public key can be derived) to Alice.
    2) Alice adds Bob’s public key and the amount of bitcoins to transfer to a message: a 'transaction' message.
    3) Alice signs the transaction with her private key.
    4) Alice broadcasts the transaction on the Bitcoin network for all to see.

Step 4) causes big net traffic and disk usage.
How avoid it?
If we avoid it - Alice can send coin, but how prevent double-spending?
Bob can send money to Charlie because Charlie can know about transaction A->B from B.
Alice can send the same money to Charlie?
In Bitcoin net - No, because Charlie know transaction A->B
My idea is : Charlie and thousands users not know about A->B transaction while not need it
If Charlie need it, can ask B, how will he know that B?
- it is can be maybe like DHT system in BitTorrent and Kademlia (I know a not enough the details)
[correction!] What if Bob will not be logged? Alice (or maybe better Bob?) broadcast the transaction
to only a few users, the larger the network, the smaller the percentage of users.
if even Bob is not logged, the probability that is at least one user who know about transaction is near 1.
Even if probability is only 90%, Alice not risk double-spending because danger of ban (or even loss of coins? preferably no..)

Users will have smaller disk occupied, problem is bigger wallet - if anyone have one account and thousands of
donation, in Bitcoins secure wallet has only key to this account, here must be private transaction history,
but [correction!] if anyone else know this transactions, is possible to download it like download blocks,
at least theoretically.

[Eri]

the as of now, not yet implemented blockchain 'pruning' should take care of the large amount of data issue.

[auzaar]

problem with this is that you are replacing size of block-chain by sparsely distributing it which means
to do a transaction could be slow as I may have to wait for confirmation that coin X belongs to A, and I may not ever found that, if that node(s) are somehow unavailable.

[Rales]

This is very big change and I don't know how it will work with blocks and if at all. I am planning make new client of cryptocurrence "trustcoin" working on test net to test this feature.
In schema above is for instance no word about block creating, this matter one need to think about.

problem with this is that you are replacing size of block-chain by sparsely distributing it which means
to do a transaction could be slow as I may have to wait for confirmation that coin X belongs to A, and I may not ever found that, if that node(s) are somehow unavailable.

It is really problem, because in minimal version, everyone holds only a story of its influence and we believe that is not profitable to cheat. (even if cheats, it simply means withdrawal operation - it is no profitable)
We have hanging transaction, but how group it in blocks?
Maybe - someone who win a block, gets info about all hanging transaction, make block and not broadcast them (except small broadcasting to several nodes to make redundancy if it will be offline)

[deepceleron]

Trouble of blockchain size is often belittled, but I personally mind. Imagine 100 millions of people using bitcoin. Every day.
My proposal involves big changes in blockchain and I don't know how to impacts to security.
Namely.
In https://en.bitcoin.it/wiki/Introduction is Bitcoin idea:

   

Suppose Alice wants to send a Bitcoin to Bob.
    1) Bob sends his address (from which the public key can be derived) to Alice.
    2) Alice adds Bob’s public key and the amount of bitcoins to transfer to a message: a 'transaction' message.
    3) Alice signs the transaction with her private key.
    4) Alice broadcasts the transaction on the Bitcoin network for all to see.

Step 4) causes big net traffic and disk usage.
How avoid it?
If we avoid it - Alice can send coin, but how prevent double-spending?
Bob can send money to Charlie because Charlie can know about transaction A->B from B.
Alice can send the same money to Charlie?
In Bitcoin net - No, because Charlie know transaction A->B
My idea is : Charlie and thousands users not know about A->B transaction while not need it
If Charlie need it, can ask B, how will he know that B?
- it is can be maybe like DHT system in BitTorrent and Kademlia (I know a not enough the details)
[correction!] What if Bob will not be logged? Alice (or maybe better Bob?) broadcast the transaction
to only a few users, the larger the network, the smaller the percentage of users.
if even Bob is not logged, the probability that is at least one user who know about transaction is near 1.
Even if probability is only 90%, Alice not risk double-spending because danger of ban (or even loss of coins? preferably no..)

Users will have smaller disk occupied, problem is bigger wallet - if anyone have one account and thousands of
donation, in Bitcoins secure wallet has only key to this account, here must be private transaction history,
but [correction!] if anyone else know this transactions, is possible to download it like download blocks,
at least theoretically.

Your idea is not new, the concept of thin clients is older than Bitcoin, except previous publications have been written from an informed perspective understanding how the blockchain and mining works to prevent double-spends.

Your last paragraph is to clever to be understood.

[the founder]

Ancillary evidence that this problem is growing,  as this happened to me last week.

"Dad you should look at these bitcoins" - Me
"I read about them,  how do I do it" - Dad (age 65)
"You need to download the client"  - Me
"Dad,  ok show me how" -

--- instructions on going to bitcoin.org, etc ---

--- several hours  later ---

"I feel like I am on the first computer I got you, the Commodore 64... this is going to take forever...  can we just do this another day" - Dad

--------------------------------

What happened is he was downloading the blockchain ... and his internet access, though decent though comcast still took a very long time...    He got frustrated and gave up.

For the record,  my dad would be considered an old school Bitcoin guy.. if he grew up today he would be buying bitcoins like mad... but he grew up years ago and his "bitcoins" were gold and silver coins and bars....   in other words he IS our target market.

[CasinoBit]

Ancillary evidence that this problem is growing,  as this happened to me last week.

"Dad you should look at these bitcoins" - Me
"I read about them,  how do I do it" - Dad (age 65)
"You need to download the client"  - Me
"Dad,  ok show me how" -

--- instructions on going to bitcoin.org, etc ---

--- several hours  later ---

"I feel like I am on the first computer I got you, the Commodore 64... this is going to take forever...  can we just do this another day" - Dad

--------------------------------

What happened is he was downloading the blockchain ... and his internet access, though decent though comcast still took a very long time...    He got frustrated and gave up.

For the record,  my dad would be considered an old school Bitcoin guy.. if he grew up today he would be buying bitcoins like mad... but he grew up years ago and his "bitcoins" were gold and silver coins and bars....   in other words he IS our target market.

The blockchain wasn't meant to be downloaded by the individual bitcoin user right from the start, Satoshi has predicted that only servers would download the blockchain. If you wanted to introduce your father to bitcoins you should have used blockchain.info or any other similar third party.

As for reducing the size of the chain wouldn't it be possible to eliminate any spent transactions which are older than a month for example? This would not only decrease the size of the chain but would cap it effectively eventually.

[TierNolan]

What happened is he was downloading the blockchain ... and his internet access, though decent though comcast still took a very long time...    He got frustrated and gave up.

They need to do the simplified system, where they download the headers first and then work backwards.

You can use bitcoins without knowing the entire chain back to the genesis block as long as you have verified all blocks since any coins that were sent to you last changed hands.

If all the fiat to bitcoin exchanges moved their "live" wallets every 2000 blocks, then all you need to do is verify the last 2k blocks and you can verify the bitcoins they sent you were valid.  You can verify the block the transaction comes from is valid and wasn't spent in the last 2k blocks.

This would allow limiting the client to say 10% CPU and let it do the full verification over a week or so.

There could be a warning on the transaction that simplified verification is being used until full verification is complete.

Also, they should add a way to get a checkpoint from someone else.  In the OP's case, he could have send his father a checkpoint of some block within the last 2k.  This could be a QR code, so just a 64 character hex value that he emails.

[Frodek]

Alice has 50 coins, send 30 to Bob. Bob can be offline. Alice send to Victor signed transaction.
Alice try send to Charlie. Charlie ask Alice for income, ask Victor for Alice outcome.
Problems:
- how work with blocks? One block today has about 400 transactions, in future can be 50*600=30'000 transactions per block.
- how add money to system?
- what if Victor will be offline?
- in Bitcoin all have the same data except wallet, here each has different data and must not delete it.
System might reward Victor for stay online and store Alice data.

[Frodek]

How work with blocks? Maybe divide block to parallel blocks?
Each kind of block has only transactions with FROM or TO in range.
We have 10 nodes, 10 addresses: 0-9
We have 4 group of address:
0,1,2
3,4
5,6,7
8,9
and random 10 transactions:

Code:

1 send to 8 30 coins //BEFORE: 1 has 50,       8 has 50; AFTER: 1 has 20, 8 has 80
2 send to 0 20 coins //BEFORE: 2 has 50,       0 has 50; AFTER: 2 has 30, 0 has 70
0 send to 7 40 coins //BEFORE: 0 has 50 or 70, 7 has 50; AFTER: 0 has 30, 7 has 90
5 send to 9 10 coins //BEFORE: 5 has 50,       9 has 50, AFTER: 5 has 40, 9 has 60
9 send to 8 20 coins //BEFORE: 9 has 50 or 60, 8 has 80 or 50; AFTER: 9 has 40, 8 has 100
2 send to 7 10 coins //BEFORE: 2 has 50 or 30, 7 has 50 or 90; AFTER: 2 has 20, 7 has 100
3 send to 1 20 coins //BEFORE: 3 has 50,       1 has 50 or 20; AFTER: 3 has 40, 1 has 40
1 send to 7 10 coins //BEFORE: 1 has 40 or 50, 7 has 50 or 100; AFTER: 1 has 30, 7 has 110
0 send to 4 30 coins //BEFORE: 0 has 50 or 30, 4 has 50; AFTER: 0 has 0, 40 has 80
3 send to 7 20 coins //BEFORE: 3 has 50 or 40, 7 has 50 or 110 AFTER: 3 has 20, 7 has 130

 We have 2*4 blocks with 10+(10-common 2) transactions:

Code:

parblock FROM or TO = 0,1,2
1 send to 8 30 coins //before 1 has 50, 8, AFTER 50, AFTER 1 has 20, 8 has 80
 Tout(1)={-30} Tin(8)={???}  -OK
2 send to 0 20 coins//before 2 has 50, 0 has 50 AFTER 2 has 30, 0 has 70
 Tout(2)={-20} 0,Tin(0)={+20} -OK
0 send to 7 40 coins//before 0 has 70 or jeszcze 50, 7 has 50; AFTER 0 has 30, 7 has 90
 Tout(0)={-40} 7,Tin(7)={???} -OK
2 wysłal 7 10 coins//before 2 has 50 lub 30,7 has 50 lub 90 PO 2 has 20, 7 has 100
 Tout(2)={-20,-10} 7,Tin(7)={???} -OK
1 wysłal 7 10 coins//before 1 has 40 lub 50, 7 has 50 lub 100 PO 1 has 30, 7 has 110
 Tout(1)={-30,-10} 7,Tin(7)={???} - OK
0 wysłal 4 30 coins//before 0 has 50 lub 30, 4 has 50, PO 0 has 0, 40 has 80
 Tout(0)={-40,-30} Tin(4)={???} - OK

parblock not FROM but TO = 0,1,2
3 wysłal 1 20 coins//before 3 has 50,1 has 50 lub 20, PO 3 has 40, 1 has 40
 Tout(3)={???} Tin(1)={+20} - not confirmed


parblock FROM or TO = 3,4
3 wysłal 1 20 coins//before 3 has 50,1 has 50 lub 20, PO 3 has 40, 1 has 40
  Tout(3)={-20} Tin(1)={???} - OK
3 wysłal 7 20 coins//before 3 has 50 lub 40, 7 has 50 lub 110 PO 3 has 20, 7 has 130
  Tout(3)={-20} Tin(7))={???} - OK

parblock not FROM but TO = 3,4
0 wysłal 4 30 coins//before 0 has 50 lub 30, 4 has 50, PO 0 has 0, 40 has 80
  Tout(0)={???} Tin(4)={+40} - not confirmed


parblock FROM or TO = 5,6,7
5 send to 9 10 coins//before 5 has 50,9 has 50, AFTER 5 has 40, 9 has 60
  Tout(5)={-10},Tin(9)={???} - OK

parblock not FROM but TO = 5,6,7
0 send to 7 40 coins//before 0 has 70 or jeszcze 50, 7 has 50; AFTER 0 has 30, 7 has 90
  Tout(0)={???} 7,Tin(7)={+40} - not confirmed
2 wysłal 7 10 coins//before 2 has 50 lub 30,7 has 50 lub 90 PO 2 has 20, 7 has 100
  Tout(2)={???} 7,Tin(7)={+40,+10} - not confirmed
1 wysłal 7 10 coins//before 1 has 40 lub 50, 7 has 50 lub 100 PO 1 has 30, 7 has 110
 Tout(1)={???} 7,Tin(7)={???} - not confirmed
3 wysłal 7 20 coins//before 3 has 50 lub 40, 7 has 50 lub 110 PO 3 has 20, 7 has 130
  Tout(3)={???} Tin(7))={+40,+10,+10,+20} - not confirmed


parblock FROM or TO = 8.9
9 wysłal 8 20 coins//before 9 has 50 lub 60, 8 has 80 lub 50, AFTER 9 has 40, 8 has 100 -
  Tout(9)= {-20}, Tin(8)={+3-,+20} - OK

parblock not FROM but TO = 8.9
1 send to 8 30 coins //before 1 has 50, 8, AFTER 50, AFTER 1 has 20, 8 has 80
  Tout(1)={???} Tin(8)={+30} - not confirmed
5 send to 9 10 coins//before 5 has 50,9 has 50, AFTER 5 has 40, 9 has 60
  Tout(5)={???},Tin(9)={+10} - not confirmed

This verbose example show decomposition list of transactions to parallel blocks. We have 4 groups and 18 instead 40 summary transactions in all blocks

[Frodek]

Proposal of block synchronization: peer who finds blocks get half of reward, rest of reward is divided to (for example) 256 nodes which checked transactions parallel.

[doobadoo]

How hard would it be to add another parameter to the block header that would also get hashed.  No seriously.  Couldn't we map out the protocol change today and specify that the protocol change would occure 1 year from now, and that every one needs to upgrade by then or else they won't be able to sync with the chain, or mine new coins?

[MysteryMiner]

First implement pruning in Satoshi client and then continue this discussion.

And there always will be needed full nodes with complete blockchain available for new full nodes to download and verify. So pruning and node specialization will take care. Large data is not problem for specialized storage hardware. Many data centers have more data than Bitcoin blockchain might possibly generate in next 20 years.

[TierNolan]

First implement pruning in Satoshi client and then continue this discussion.

The transaction compression (in the other thread at least) is actually a slightly different problem.

It is for the simplified node.  It allows proving that transactions have not been spent already.

And there always will be needed full nodes with complete blockchain available for new full nodes to download and verify.

That could potentially be distributed.  However, that risks the loss of some of the history.  If 1 million nodes had 0.1% of the blockchain each, then the odds of a record being lost would be essentially zero.