Hey, thanks for the link. I read a few wikipedia articles, the
BitTorrent things and searched the forum + mailing list, nothing really worth to share though. I heard Mike Hearn recommended
TomP2P and if you are looking for an easy implementation in
Python or
C#, there you go.
Edit:
FreePasteryTutorial might be worth to look at, too.
It's worth searching through the #bitcoin-dev and #bitcoin-wizards irc logs for "DHT" - the Bitcoin development community considers them a joke for anything requiring security against adversaries, or even just good reliability in general:
You know, an interesting question to ask yourself is if it's totally ok to just embed a hash of the actual data in the blockchain, and rely on the data itself being made available by some DHT or something, why can't Bitcoin itself do that to make blocks smaller and improve scalability?
Remember that Bitcoin would work just fine if miners didn't validate transactions if clients implemented client-side validation, as is done in Mastercoin and Counterparty, and to a lesser extent, Colored Coins. What's so special about actually putting those tx's in the block?
Availability of all messages to reconstruct the latest state, right? At least that's the problem I see. To a lesser extend: each client must have at least access to the full chain of all transactions that involves one of his wallets to reconstruct his final balance and this is not necessarily given by a DHT. Altering of messages could be avoided, if OP_RETURN hash == key == H(message).
Despite that, I'm still fascinated by the idea of on overnet, slightly related: if there were a mechanism of easy communication, people could send around CoinJoin transactions, establish channels for micropayments or open a communication line for multisig signing in general.
And not just availability, but guaranteed availability with specific time limits. Basically, in a financial application it's not good enough to just have the message eventually get to the desired recipients - you need it to be guaranteed (with high probability) to either get to them in a certain amount of time
or for the message to be considered invalid. (and detectably so) Blockchains due this because they're a genuine proof that messages were published, side-chains don't.
That said, if you're just trying to, say, make a decentralized mailing list or something with good anti-censorship properties side-chains are probably just fine as you can always have the user's client handle censorship reactively, e.g. by retrying the message. Having a fallback to insert-in-blockchain available as a last resort is good too, and may discourage censors from trying in the first place. But Counterparty, Mastercoin, and Colored Coins are all financial applications and need much better censorship resistance and time guarantees than that.
