> 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

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,


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
Bitcoin-development mailing list

Reply via email to