Topic: Building the Next Generation of Crypto-Currency (developers required) - page 5. (Read 23562 times)

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.

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

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.

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.

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?

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:


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

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.

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

This problem was already discussed:
https://bitcointalksearch.org/topic/m.2035208

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.

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.

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.

Ok after some discussion with other members, the name has been decided and a github repo has been created.

The name we are going with is Peercash and the repo can be found here (it's still empty right now):
https://github.com/peercash/peercash

Currency code: XPC

The name probably isn't as awesome as it could have been but it was hard to come up with something unique and with the domain name still available. Still I think it's a pretty good name and describes what the project is about so I'm not unhappy with the decision.

The concept is still being fully developed in the project wiki and aaaxn probably wont be around for a little while, so the real development still hasn't started yet. However if anyone wants to start contributing to the project repository that is fine.

I understand, but your statement is somewhat of a non-sequitur. The naming convention "****coin" is not at all incompatible with an ISO currency code starting with X. The USD could be called "DollarCoin" and the ISO code would still be USD. So this currency could be called "FailCoin" and the code would still be XFL or XFC or something like that.
However, it was suggested to stay away from the _____Coin convention, and I think that's probably a good idea provided we can think of a non-stupid name - but I just wanted to point out that this convention is not inherently incompatible with an ISO convention. It is just the Bitcoin community's resistance that prevents XBT from being adopted; not that the name "bitcoin" itself prevents this code from being used.

You could do it with simple hash tree. You include root hash of merge mined blockchains headers and every single chain can prove its inclusion with 2 * logN hashes. I think its affordable and does not need inclusion of new untested and potentially complicated algorithms.

You mean 32-branches at every level of tree or just joining accounts in 32 blocks and construct binary tree over such blocks?
If you mean former then to prove membership you need to include all siblings on your path to leaf which means 32 * log32(accounts number) * (size of hash)
If you mean latter you get 2 * log2(accounts / 32) * (size of hash)

If I was mining for Namecoin and Bitcoin I would create an accumulator that included the hash of the block-header for both.  The block-header for each chain would contain the previous node in that chain.

Then when I found the work, I could submit  accumulator + namecoin header hash + key  as the proof of work for the namecoin chain and accumulator + bitcoin header hash + bckey to the bitcoin network.  Thus I solved 2 blocks at once, but each block still has a unique previous hash.

Of couse if the two chains have different difficulties it may only work for namecoin and not for bitcoin unless the resulting hash was good enough for both.

But accumulator can only check if it contains an element but not how they are linked, right? I mean for "proof chain" you need to have a linked list and accumulator cannot reproduce it.

One problem I see with instant pruning is when receiver account is emptied while there is pending tx which sends funds to it. I think we should add tx validity rule. Tx has block number under which they were created. I think we could just drop transaction which has this block earlier than last slot pruning. Introducing delay is still good idea and it should be done too.

THis would be for the proof chain and would allow people to search for proof of work on multiple chains at once without requiring any chain to be overly bloated. 

I have contacted the ZeroCoin author attempting to get his implementation for ZeroCoin and creating such a library.   Even without a full implementation, this chain could be designed to potentially work with merged mining by moving the nonce but just use a simple non-merged-mining hash for initial versions.