Bitcoin Forum

I'm not sure the etiquette about referencing my blog articles on this forum.  Let me know if this is a bad idea.

http://blog.appamatto.com/2010/12/base-less-block-chains.html

I wrote an article about designing a bitcoin-like protocol that allows new clients to determine the proper head-of-chain by receiving only "new" blocks.  In other words, the system would become broadcast-only and there would be no method to request old blocks from peers.

I'm still grappling with the idea, but I think that if timestamps are present in the protocol, attacks on new clients should be at least prohibitively difficult.  If timestamps are not present then there is a "history attack" where an attacker rebroadcasts blocks from the entire history of the chain, forking the chain at the last moment.  The history attack is pretty difficult to pull off since old hands won't rebroadcast nodes that aren't new.

Broadcast-only-ness allows for some interesting properties including lower network and disk usage, but it can be weak against lost blocks.

Naturally this method would require a balance sheet-based implementation of bitcoin.

Bitcoin can already work like this, just not as an absolute.  This is similar to my own 'datacasting' concept.

What is your datacasting concept?

One reason why I think bitcoin can't work like this is that a client who only saw new blocks wouldn't be able to know whether the transactions contained within were valid or not.  This seems to require balance sheets...

Use the search function.  Look for 'datacasting' and 'Dash7'


that is the chicken and egg problem, isn't it?  A client that uses balance sheets cannot independently verify transactions based on blocks prior to it's own initial startup, but a client that uses the full blockchain to verify transaction history doesn't need balance sheets.

If the client has block 5 and its balance sheet he can verify both block 6 and block 4 by fast-forwarding or rewinding the new/old transactions on the balance sheet.  Verification in this case means "if the beginning of the chain is verified then so are all the nodes up until the end."

The client may end up with multiple long chains, which will either be connected in some way or one will be an attacker's chain.  The client should be able to request older blocks until the point where the chains connect or the attacking chain is overpowered.

I think you get too much fragmentation if you only get new blocks, but the idea of "mostly broadcast" may still be a good aim, given that the number of old blocks required to remove all doubt may be quite few.