Building the Next Generation of Crypto-Currency (developers required)

[bytemaster]

I have a question about the proof-chain.

The proofs are only valid if they are newer than the head of the chain because old proofs say nothing about new blocks.   Therefore, having a history of 'random proofs' for which you no longer have the block header used to generate the proof nor any of the data from that block that serves to confirm the initial condition of the oldest block in the mini-chain is actually worthless.   Any attacker could start building off of the proof chain at any point and ultimately 100% of your security comes from the mini-chain. 

The only 'value' the proof chain could provide is to the extent that it enables new proofs to be performed *after* the most recent mini blockchain node. 

Please let me know what I am missing and why I should care about the old proofs which confirm nothing about the initial state of the mini chain.

[1714810674]

1714810674

[1714810674]

1714810674

[1714810674]

1714810674

[cunicula]

I have a question about the proof-chain.

The proofs are only valid if they are newer than the head of the chain because old proofs say nothing about new blocks.   Therefore, having a history of 'random proofs' for which you no longer have the block header used to generate the proof nor any of the data from that block that serves to confirm the initial condition of the oldest block in the mini-chain is actually worthless.   Any attacker could start building off of the proof chain at any point and ultimately 100% of your security comes from the mini-chain.  

The only 'value' the proof chain could provide is to the extent that it enables new proofs to be performed *after* the most recent mini blockchain node.  

Please let me know what I am missing and why I should care about the old proofs which confirm nothing about the initial state of the mini chain.

This seems like a good point to me. Couldn't the old proof chain be reapplied by anyone? I mean you don't actually have to make a fresh 'old proof chain' to support an attack chain. Instead you build on top of the old proof chain, you make up an arbitrary coin distribution at the beginning of te mini-blockchain, and then you build on it with your own attack blocks. The 'old proof chain' serves no obvious function.

Is the following approach a viable alternative? It is still txn based rather than account based.

1) For the last say 20000 blocks record all txns. This is the miniblockchain. We don't save block-by-block txn data besides this.
2) Every 10000 blocks, net changes in account balances occurring during a 10,000 block period are summarized in a 'superblock'. Say for example that address A starts with 10 coins at time k. Between k and k+ 10,000, address A sends all these coins to various addresses and ends up with 0. All the superblock needs to record is {address A -10}. We don't need to preserve the nitty gritty details of all txns and precisely when they occurred. However, we still preserve a basic historical record of account balance changes.
3）Say it time t=T right now, where t is measured in blocks. At genesis, t=0 and all addresses start with 0. We have periodic snapshots of account balances at times 0, 10000, 20000, 30000, ..., most recent superblock) {I am to tired to write down the timing of the most recent superblock right now}.
4) We also have block-by-block snapshots of account balances for the last 20000 blocks. There is an overlap interval between the miniblockchain and the last superblock to allow for short-reorgnaizations, which might orphan this superblock.
5) You can incorporate PoW based on superblocks and in the old proof chain. Since superblocks behave very similarly to giant merged blocks, so they cannot be altered without redoing all the old PoW. You could build off superblocks to make an attack chain, but you would have to start from an actual historical state of the blockchain. You couldn't make up an arbitrary historical state.

I got on a plane at midnight and arrived at 6 this morning. If this is nonsensical I will try again after I have slept.

[aaaxn]

This problem was already discussed:
https://bitcointalk.org/index.php?topic=195275.msg2035208#msg2035208

In short:
- how many full blocks node stores is configurable (with minimum)
- nodes will not accept competing blockchain unless they have history all the way up to the moment branches diverged.
- if it happened before last available block nodes queries other nodes for missing blocks
- if node cannot find missing history it just refuses to operate and require manual intervention

Too put things into perspective. Mini blockchain should contains something like 1 month of txns minimum. If anyone can do 1 month deep chain reorganization currency would by DEAD no matter if this means overwriting balances or just reverting all transactions.

Anyway whitepaper is little outdated already and update wouldn't hurt.

[bytemaster]

In other words the proof chain is worthless and the mini-block chain must have at least 1 month of history.

[bytemaster]

I have a question about the proof-chain.

The proofs are only valid if they are newer than the head of the chain because old proofs say nothing about new blocks.   Therefore, having a history of 'random proofs' for which you no longer have the block header used to generate the proof nor any of the data from that block that serves to confirm the initial condition of the oldest block in the mini-chain is actually worthless.   Any attacker could start building off of the proof chain at any point and ultimately 100% of your security comes from the mini-chain.  

The only 'value' the proof chain could provide is to the extent that it enables new proofs to be performed *after* the most recent mini blockchain node.  

Please let me know what I am missing and why I should care about the old proofs which confirm nothing about the initial state of the mini chain.

This seems like a good point to me. Couldn't the old proof chain be reapplied by anyone? I mean you don't actually have to make a fresh 'old proof chain' to support an attack chain. Instead you build on top of the old proof chain, you make up an arbitrary coin distribution at the beginning of te mini-blockchain, and then you build on it with your own attack blocks. The 'old proof chain' serves no obvious function.

Is the following approach a viable alternative? It is still txn based rather than account based.

1) For the last say 20000 blocks record all txns. This is the miniblockchain. We don't save block-by-block txn data besides this.
2) Every 10000 blocks, net changes in account balances occurring during a 10,000 block period are summarized in a 'superblock'. Say for example that address A starts with 10 coins at time k. Between k and k+ 10,000, address A sends all these coins to various addresses and ends up with 0. All the superblock needs to record is {address A -10}. We don't need to preserve the nitty gritty details of all txns and precisely when they occurred. However, we still preserve a basic historical record of account balance changes.
3）Say it time t=T right now, where t is measured in blocks. At genesis, t=0 and all addresses start with 0. We have periodic snapshots of account balances at times 0, 10000, 20000, 30000, ..., most recent superblock) {I am to tired to write down the timing of the most recent superblock right now}.
4) We also have block-by-block snapshots of account balances for the last 20000 blocks. There is an overlap interval between the miniblockchain and the last superblock to allow for short-reorgnaizations, which might orphan this superblock.
5) You can incorporate PoW based on superblocks and in the old proof chain. Since superblocks behave very similarly to giant merged blocks, so they cannot be altered without redoing all the old PoW. You could build off superblocks to make an attack chain, but you would have to start from an actual historical state of the blockchain. You couldn't make up an arbitrary historical state.

I got on a plane at midnight and arrived at 6 this morning. If this is nonsensical I will try again after I have slept.

This would work, however, maintaining even the diffs of the entire account history would require GB of data for any large number of accounts.    I think the right solution is to not require anything more than 1 year.

[aaaxn]

In other words the proof chain is worthless and the mini-block chain must have at least 1 month of history.

Proof chain with block headers is needed to prove that historical block you hold is valid (for example you hold block with certain txn which you want to keep record forever). Proof chain on its own is absolutely useless imo.

[bitfreak!]

In other words the proof chain is worthless and the mini-block chain must have at least 1 month of history.

The proof chain is simply a container of expended energy, all it needs to do is prove that some sort of work was done. aaaxn already gave a link to where we discussed the issue you brought up. It's really a minor issue because chances are it would never happen and if it does happen we have a good failsafe plan mentioned by aaaxn:

I think new nodes in this situation (it should be extremely rare or never) should just query nodes for blockchain all the way to block in which competing chains diverged and if no one around has this long history node should just refuse to operate and wait until thing settle. Or it can be advised to download updated client which should in this situation contain hardcoded checkpoint provided by community pointing to right chain.

It's really only new nodes which would be at risk so dealing with it in that way is acceptable.

[cunicula]

This would work, however, maintaining even the diffs of the entire account history would require GB of data for any large number of accounts.    I think the right solution is to not require anything more than 1 year.

The balance sheet is the diff of the entire account history from genesis. This is always needed.

You could aggregate 'superblocks' in a telescoping fashion. The past snapshots would become progressively macroscopic; e.g.  

1,2,4,8,16,32,64,128,256,512,1024,2048,4096,8132,16384,32678, 65536, 131072, 262144, ...,

That is 18 sets of differences for 5 years worth of blockchain. 19 snapshots for 10 years and so on.

The overlapping miniblockchain could be quite short, say a day.

1,2,3,...,142,143,144 (the end)

I don't think that would necessarily be larger in size than a month long mini-blockchain and a balance sheet.

I'm still wrapping my head around the idea. Intuitively ignoring the past seems correct, but then you begin to wonder why keep a month of information in the blockchain, why not just a day? Is there a good answer for this? What problems arise as you decrease the time interval?

[bytemaster]

Well, Bitcoin seems to think that 1 day is sufficient to handle chain-reorgs.

There *is* one benefit for the long-tail proof of work is that it establishes the initial difficulty condition.  Which would then force all attackers to have 51% power with the ability to overcome 1 month of transactions.

[cunicula]

Well, Bitcoin seems to think that 1 day is sufficient to handle chain-reorgs.

There *is* one benefit for the long-tail proof of work is that it establishes the initial difficulty condition.  Which would then force all attackers to have 51% power with the ability to overcome 1 month of transactions.

Yes, I guess if you can rent PoW, then renting a month is much more expensive than renting a day. It then follows that renting 10 years is much more expensive then renting a month.

If you can't rent PoW and must own the capital, then 1 day = 1 month = 1 year. more or less.

[aaaxn]

You could build off superblocks to make an attack chain, but you would have to start from an actual historical state of the blockchain. You couldn't make up an arbitrary historical state.

You just pushed problem one step back. All you have to do is start from known superblock  and proceed to next one which can be arbitrary and then wait util txn between this blocks are forgotten. It is impossible to overcome this "problem", but it isn't any problem in real world, because very deep reorgs are not expected to happen and if they do community wil react anyway. Imagine bitcoin was attacked today with chain making 10000 blocks reorg and cancelling all txns. What would happen? Of course coummunity will apply patch with checkpoint cancelling this emerged fork.

There *is* one benefit for the long-tail proof of work is that it establishes the initial difficulty condition.  Which would then force all attackers to have 51% power with the ability to overcome 1 month of transactions.

Attacker just adopts existing proofchain (it doesn't prove anything without txns after all) into his attack so it gives us nothing.

[cunicula]

You could build off superblocks to make an attack chain, but you would have to start from an actual historical state of the blockchain. You couldn't make up an arbitrary historical state.

You just pushed problem one step back. All you have to do is start from known superblock  and proceed to next one which can be arbitrary and then wait util txn between this blocks are forgotten. It is impossible to overcome this "problem", but it isn't any problem in real world, because very deep reorgs are not expected to happen and if they do community wil react anyway. Imagine bitcoin was attacked today with chain making 10000 blocks reorg and cancelling all txns. What would happen? Of course coummunity will apply patch with checkpoint cancelling this emerged fork.

There *is* one benefit for the long-tail proof of work is that it establishes the initial difficulty condition.  Which would then force all attackers to have 51% power with the ability to overcome 1 month of transactions.

Attacker just adopts existing proofchain (it doesn't prove anything without txns after all) into his attack so it gives us nothing.

I think it is possible to overcome this "problem". You need to introduce POW that depends on historical superblocks, but not recent history. I am not going to specify the details because I don't have a clear enough understanding of the problem yet. You should be more hesitant to declare things impossible.

Useless to solve perhaps, but impossible, no, I strongly suspect you are wrong.

[aaaxn]

I think it is possible to overcome this "problem". You need to introduce POW that depends on historical superblocks, but not recent history. I am not going to specify the details because I don't have a clear enough understanding of the problem yet. You should be more hesitant to declare things impossible.

Useless to solve perhaps, but impossible, no, I strongly suspect you are wrong.

You are trying to replace real txn data which have account owner signatures with some summary data, which is smaller, but cannot be verified. You secure such smaller set with PoW. Txn data is irreversibly lost so you cannot distinguish 'real' summary from made up one and you must rely on PoW honesty. There is no way around it.

[klee]

blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.

This! Though if we can have smaller blockchain would be a plus!
I like very much this idea and the quality talk here.
When I can I will add a small amount in the bounty - wish I could give more...

And I am here for any help needed, not so much interested in programming but whatever else I can help!

[klee]

Instead of another "******Coin", it's better to take a good ISO currency code from the beginning, like Ripple did with XRP. It must start with X then. Something like XCC, i.e. CC for Crypto Currency.

Yeah I agree we should make the currency code begin with an X. And I would prefer to leave "coin" out of the name unless someone thinks of something extremely clever which hasn't been used already.

Supercoin

EDIT: PeerCash is great!

[bytemaster]

blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.

This! Though if we can have smaller blockchain would be a plus!
I like very much this idea and the quality talk here.
When I can I will add a small amount in the bounty - wish I could give more...

And I am here for any help needed, not so much interested in programming but whatever else I can help!

The bloat may not be a problem for you, but I am building a blockchain with built in exchange which means having as much data as possible in Ram to match bids / orders.  It also means an order of magnitude more transactions.  If you end up paging things out to disk that will be a problem.   I will also have clients that want to be on multiple parallel chains at the same time and thus what isn't a problem for one chain can become a problem when you start multiplying the problem.

[klee]

blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.

This! Though if we can have smaller blockchain would be a plus!
I like very much this idea and the quality talk here.
When I can I will add a small amount in the bounty - wish I could give more...

And I am here for any help needed, not so much interested in programming but whatever else I can help!

The bloat may not be a problem for you, but I am building a blockchain with built in exchange which means having as much data as possible in Ram to match bids / orders.  It also means an order of magnitude more transactions.  If you end up paging things out to disk that will be a problem.   I will also have clients that want to be on multiple parallel chains at the same time and thus what isn't a problem for one chain can become a problem when you start multiplying the problem.

So you work with bitfreak for this? Or you follow your own designs (seen them in other threads).
Just to add something, I think that in the long term any coin should adopt P2P exchange infrastructures and be like Ripple (coin+platform).

In time...

[bytemaster]

I am attempting to pull the best ideas from across the web/forum into BitShares.  If the result is something bitfreak and I can both use, so much the better.  I will be developing in c++ though.

[cunicula]

You are trying to replace real txn data which have account owner signatures with some summary data, which is smaller, but cannot be verified. You secure such smaller set with PoW. Txn data is irreversibly lost so you cannot distinguish 'real' summary from made up one and you must rely on PoW honesty. There is no way around it.

It probably makes no sense to use txns at all. Instead users should sign current balances (not differences in balances, actual current balances).

User signs his own balance A using private key and another balance B.

Validity rules for inclusion of balance sheet update in block (these replace txns):

New balance A < Old Balance A
New Balance A - Old Balance A + balance B = 0

Due to this modification, every single deduction in the balance sheet would be signed by the balance's private key owner.

Similar to bitcoin and unlike the miniblockchain, txns could not be forged only deleted.
Similar to the miniblockchain and unlike bitcoin, you would not need to preserve records of all history. Instead you could preserve snapshots.

I'm not sure if the snapshots can be telescoping or not yet (I can't figure out how they could be, but feel like someone else probably could).

I'm also still puzzling over the details of attaching PoW to snapshots and interweaving this with PoW attached to current balance sheet updates.

[I can do this later. I have been on two economy night flights within a 48 hours span. I feel like one of those hangovers where you wake up drunk.]

[cunicula]

I am attempting to pull the best ideas from across the web/forum into BitShares.  If the result is something bitfreak and I can both use, so much the better.  I will be developing in c++ though.

I think this is a great attitude. It is sad to see stuff degenerate into separate competing teams.