[...] > And, on the flip side if the host is persistently behind tor, even > with some watermarkable behaviour, their privacy is protected. So > making sure that hosts can continually use tor (or similar systems) > should be the higher priority. (And, of course, not reimplementing > tor leverages the millions of dollars of investment and dozens of > subject matter experts working on that system). >
Reimplementing Tor would not only mean to lose all the investment that ran into Tor, but also to lose a large user base. We can see this with TorCoin. Still, the fact that Bitcoin is a use case for Tor which measurably shows some limits where it is not fully clear if Tor or Bitcoin is to be blamed does not only mean that both projects may have to evolve in order to properly solve the issue, but also that the means of interfacing between both projects may have to be extended. Ideally, in a way which does not require to run a separate Tor and/or Bitcoin network in order to work, but which will be generic enough to satisfy both sides' need to still work in a standalone manner. But I do see huge merit in exploring better ways of synergy between the projects. For example, Tor's hardcoded circuit length may be considered as a hack which was only necessary due to the lack of a suitable resource compensation mechanism. Which is something that is available with Bitcoin. Best regards, Isidor ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development