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:
#bitcoin-dev/13/03/13-03-10.log:20:00 < Scrat> DHT makes your hair fall
#bitcoin-dev/13/03/13-03-10.log:20:02 < sipa> < gmaxwell> Someday I'm going to get myself invited to some conference with the president, and while he's talking about some middle east conflict thing— I'm going to ask if they've considered using a DHT.
#bitcoin-dev/13/05/13-05-07.log:15:51 < cjd> DHTs are annoying, they are just so pitifully attackable that in general one should avoid using them if at all possible
#bitcoin-dev/13/05/13-05-07.log:15:57 < sipa> gmaxwell: next time some suggests a DHT, tell them this is outdated technology... all the fancy kids on the block now use DH Rainbow Tables
#bitcoin-dev/13/05/13-05-07.log:15:58 <@gmaxwell> cjd: I think people mostly know that "TheCloud" is a ... at least a big vague. But basically every discussion about Bitcoin communications challenges has someone wade in and say "I KNOW GUIS! LETS US A DHT!"
#bitcoin-dev/13/06/13-06-12.log:13:14 <@jgarzik> I need to get on Cafe Press or somewhere that has an online t-shirt shop. Need shirts and coffee mugs with taglines like "DHT will fix it" or "have DHT, will travel"
#bitcoin-dev/13/10/13-10-07.log:17:05 < phantomcircuit> a naive DHT is not even remotely censorship resistant
#bitcoin-dev/13/10/13-10-07.log:17:05 < phantomcircuit> im actually fairly surprised the RIAA/MPAA haven't hired someone to fill the bittorrent DHT with nonsense yet
#
#bitcoin-wizards/13/03/13-03-06.log:23:41 < nanotube> jgarzik: if you want to troll gmaxwell, you have to mention DHTs, at least.
#bitcoin-wizards/13/03/13-03-06.log:23:42 < amiller> did someone mention dhts
#bitcoin-wizards/13/11/13-11-27.log:05:26 < gmaxwell> nah not you.. sorry, like, I've developed a pratice of reflexively ignoring anyone who says DHT. It's usually invoked by people who encounter a problem they don't understand and it really means "magical distributed thingy". Like early physicists invoking god when they encountered something they couldn't explain.
#bitcoin-wizards/13/11/13-11-27.log:05:33 < adam3us> dht's usuall have extremely poor even non-hostile user characteristics, dht in a byzantine threat environment with real money on the line
#bitcoin-wizards/13/11/13-11-27.log:05:35 < gmaxwell> yea, dht's basically appear to be unworkable in an adversarial enviroment.
#bitcoin-wizards/13/11/13-11-27.log:05:42 < gmaxwell> mappum: bittorrent dht is mostly fail, it works .. kinda.. for very large swarms that can also do peer exchange, but mostly it just ends up helping people find other trackers. For small swarms it'll often spin finding nothing even when its not getting attacked.
#bitcoin-wizards/13/11/13-11-27.log:05:43 < midnightmagic> you're never getting away from dhts are you
#bitcoin-wizards/13/11/13-11-27.log:05:45 < gmaxwell> But there was a period of time when we couldn't go days without someone joing #bitcoin-dev and responding to the very first thing they heard with USE A DHT.
#bitcoin-wizards/13/11/13-11-27.log:05:45 < midnightmagic> mappum: the endless, endless stream of users who come in to #bitcoin and insist we adopt dht rather than dns/irc for initial peer discovery is really astounding. it's jsut a running joke is all. no worries man.
#bitcoin-wizards/13/11/13-11-27.log:05:46 < petertodd> mappum: pro-tip: suggest fidelity bonds instead, like a fidelity-bonded DHT
#bitcoin-wizards/13/11/13-11-27.log:05:46 < gmaxwell> or instead of *, you name a technical challenge we've had in the bitcoin ecosystem and someone has suggested a DHT to solve it.
#bitcoin-wizards/13/11/13-11-27.log:05:46 < gmaxwell> Signature validation slow? Use a DHT. etc.
#bitcoin-wizards/13/12/13-12-19.log:22:43 <@gmaxwell> I would certantly be happy if DHTs were the magical tools people often assume they are. The more systems that get built which fail obviously when the DHT doesn't work the more likely people will work out the issues.
#bitcoin-wizards/14/02/14-02-23.log:21:57 < gmaxwell> DHT has suffered waves of amazing hype, but generally been an actual engineering failure because of poor performance when not contructed out of spherical cows.
By itself this isn't so bad, but because of the use of it in torrent (even where it actually doesn't work much of the time when you'd need it) it's often invoked by people who can't even understand explinations about why it wouldn't apply or wouldn't work for whatever ...
#bitcoin-wizards/14/02/14-02-23.log:21:58 < andytoshi> gmaxwell: i actually had a person on PM -today- asking why an alt couldn't just use a DHT to use consensus
#bitcoin-wizards/14/03/14-03-11.log:14:46 < gmaxwell> maybe there is indeed a way to use an anonymous consensus to undo some of the traditional DHT failsauce unreliability... but so far I've not seen any serious work. I think perhaps until we have some better language for abstractions about this stuff it will be too complicated to reason about.
#bitcoin-wizards/14/03/14-03-11.log:14:46 < Luke-Jr> much DHT
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.
