<div>Thanks for this, Amir.
</div><div><br></div><div>My initial reactions:</div><div><br></div><div>1) This is cool and useful (but see 3)</div><div>2) This is significantly less secure than validating an entire blockchain; it's certainly worth working out some use cases here in more detail than just a sample conversation. More on this below</div>
<div>3) What about discovery? Will a client now have the chance to look for NODE_STRATIZED clients on IRC? How do you envision a stratized server decides which transactions to relay/store? Or is it just a caching layer in front of a high quality blockchain service? If it is just a caching service, the question of cache hits / misses is an interesting one as well. </div>
<div>4) What are the economic motivations to run a stratized server? Other than cheating people of course.</div><div>5) Seems like a 'send me everything for this source address' is going to save a lot of roundtrip conversations for what I imagine the most common request will be.</div>
<div><br></div><div>Inre: majority agreement on transactions, and even balances, it would be nice to work out some theoretical security / cost / value calculations for the following scenarios:</div><div><br></div><div>Likely value and cost to someone of subverting / lying about</div>
<div>1) An n-confirmation transaction, n > 0</div><div>2) A 0 confirmation transaction</div><div>3) A NODE_STRATIZED transaction chain for a client with m connections to NODE_STRATIZED servers</div><div>4) An address balance request for a client with m connections to NODE_BALANCE_INFO (I made this name up) servers</div>
<div><br></div><div>Peter</div>