Proposal: A Second Chain for Scalability - page 3.

BrightAnarchist

donator

Activity: 853

Merit: 1000

Quote from: bfever on May 25, 2012, 02:38:14 PM

Quote from: BrightAnarchist on May 25, 2012, 10:54:04 AM

Here is what I propose:

In this manner, over time old transaction blocks can be forgotten since the most recent balance block plus the most recent transaction blocks are all that are needed to verify transactions. To keep the integrity of the network, of course, more history should be saved, but we probablly don't need more than a few thousand balance blocks while still being very secure.

Do you think this scheme could work? I'm not even remotely an expert on this stuff, so forgive any glaring errors. Thanks!

If you want to be able to verify transactions from "most recent balance block + transactions since this balance block", this "balance block" does not only need to record the balance of each bitcoin address, but in fact (the full details of) each "non-spent" transaction.
Some data around block height 181185: there are 659574 bitcoin addresses with a non-zero balance, and 1591739 "non-spent" transactions. This is at least 391 Mb of data you need to include in the balance block (at least 258 bytes per transaction), if my math is correct. Or at least a 1 hour download on a decent DSL line (not taking into account other nodes will want to get the data too).

So this can reduce storage space requirements (Mbytes instead of GBytes) and transaction lookup times, but network load will be higher (peers need also to relay the second chain).
At the current transaction volume (1100 transactions/h = 400 kb/h or 9.6Mb a day), it is definitely not a good solution: 1 balance block a day = 400 Mb a day (390Mb for that 1 block + 9.6Mb of new transactions), or an increase of 40 times the network load !

Why would the balance chain need to be shared on the network? It can easily be computed using the transaction chain, since each balance block specifically covers "up to" a certain transaction block. Only the nonce values would have to be shared on the network for the balance blocks.

bfever

jr. member

Activity: 39

Merit: 1

Quote from: BrightAnarchist on May 25, 2012, 10:54:04 AM

Here is what I propose:

In this manner, over time old transaction blocks can be forgotten since the most recent balance block plus the most recent transaction blocks are all that are needed to verify transactions. To keep the integrity of the network, of course, more history should be saved, but we probablly don't need more than a few thousand balance blocks while still being very secure.

Do you think this scheme could work? I'm not even remotely an expert on this stuff, so forgive any glaring errors. Thanks!

If you want to be able to verify transactions from "most recent balance block + transactions since this balance block", this "balance block" does not only need to record the balance of each bitcoin address, but in fact (the full details of) each "non-spent" transaction.
Some data around block height 181185: there are 659574 bitcoin addresses with a non-zero balance, and 1591739 "non-spent" transactions. This is at least 391 Mb of data you need to include in the balance block (at least 258 bytes per transaction), if my math is correct. Or at least a 1 hour download on a decent DSL line (not taking into account other nodes will want to get the data too).

So this can reduce storage space requirements (Mbytes instead of GBytes) and transaction lookup times, but network load will be higher (peers need also to relay the second chain).
At the current transaction volume (1100 transactions/h = 400 kb/h or 9.6Mb a day), it is definitely not a good solution: 1 balance block a day = 400 Mb a day (390Mb for that 1 block + 9.6Mb of new transactions), or an increase of 40 times the network load !

Andrew Bitcoiner

sr. member

Activity: 396

Merit: 250

Send correspondance to GPG key A372E7C6

That's pretty interesting. One thing that I see is that you would have to have people mining all the chains though and each one would still be vulnerable to the 51% attack unless say they confirm a merkle hash of each block in each chain.

BrightAnarchist

donator

Activity: 853

Merit: 1000

Here is what I propose:

Every block in the block chain only pays out ~~90%~~ 99.9% of its block reward. The other ~~10%~~ 0.1% is kept on reserve in the block.
A second "balance" chain is created, which consists of transaction chain blocks hashed in a tree along with the usual nonce and a hash of the previous balance chain block.
Each balance chain block holds the balance of every non-empty bitcoin address up to the point of the last transaction block included.
The balance chain difficulty is ~~100X~~ 1000X the transaction chain difficulty.
The node that solves a balance chain block recieves all of the reserved block rewards from the included transaction blocks.
In this manner, over time old transaction blocks can be forgotten since the most recent balance block plus the most recent transaction blocks are all that are needed to verify transactions. To keep the integrity of the network, of course, more history should be saved, but we probablly don't need more than a few thousand balance blocks while still being very secure.
In this manner, the only data required for each full node would be: (1) block headers for all balance blocks (2) the most recent balance block (3) transaction blocks that occurred after the most recent balance block.

Do you think this scheme could work? I'm not even remotely an expert on this stuff, so forgive any glaring errors. Thanks!

Topic: Proposal: A Second Chain for Scalability - page 3. (Read 3976 times)