Peter Vessenes [ARCHIVE] on Nostr: 📅 Original date posted:2012-05-16 📝 Original message:Thanks for this, Amir. My ...

📅 Original date posted:2012-05-16
📝 Original message:Thanks for this, Amir.

My initial reactions:

1) This is cool and useful (but see 3)
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
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.
4) What are the economic motivations to run a stratized server? Other than
cheating people of course.
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.

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:

Likely value and cost to someone of subverting / lying about
1) An n-confirmation transaction, n > 0
2) A 0 confirmation transaction
3) A NODE_STRATIZED transaction chain for a client with m connections to
NODE_STRATIZED servers
4) An address balance request for a client with m connections to
NODE_BALANCE_INFO (I made this name up) servers

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120516/c36915f7/attachment.html>;