Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
I found out that tor nodes have been blocking the old address causing terrible connection issues and I didn't want to wait to apply this fix.
That 's not possible.
"It's not possible for a node to differentiate between proxy and hidden-service traffic for relay purposes."
http://archives.seul.org/or/talk/Aug-2008/msg00377.html
It's not possible for any node to block traffic for a specific hidden service address as no node is aware that it is carrying traffic for a specific hidden service address, or the whole system wouldn't be anonymous.
Your problem is your guard nodes are not set up in a fashion suitable for a hidden service serving at the volume you are. The URL change will help in the very short term, as the new guard nodes will be fresh, but will be adding clients at a rapid clip, and the 'blocking' problem will arise again.
You are throwing the wrong solution at the wrong problem, and executing it poorly as well.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
My signed messages check out, paperchasing is confused (see my pm paperchasing), nothing is different about the database. In regards to variety's solution, it does not work. I thought of that. All of the links on the site are generated by our framework to have absolute paths, including the domain, so multiple domains would not work. In retrospect, I should have announced this change before doing it, but I found out that tor nodes have been blocking the old address causing terrible connection issues and I didn't want to wait to apply this fix. There isn't much more validation that can be done beyond controlling the official Silk Road private key, and the private key corresponding to the old URL, which I have demonstrated. I understand if you want to give it some time to make sure everything is ok, but there is no need to panic. Sorry for all of this trouble.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iQEcBAEBAgAGBQJO1xdWAAoJEAIiQjtnt/ol1M0IAMSh+jcTVqiM6Yq6KULUVCVs
3YWhBDuQJTvQagaioFjzoXv6519xcpBLhymt5xmEEVaU1mvMKj8mflpI7bvcKUGf
8ErjrJlarbnCNfj/zV1QdbUOODLVAU4w1Qv2Ke3LJ4M+ysu4AcIOxbL/3MIPVWfv
zYSiQrBIpvSOm4yS/wlrfvA+vQHYV4FChIgX+dnfzSKRuTxNNS0Wk341Wt+cpWBh
StuSAkA1OMr82ht4RgvnC/JxMYvvJ+uLah74QkGZDbXY3YebJs1FQWW+G8Cp+1m7
+LWz/aaAMaCpWqJ/T9zefCBI4YnClk5202N6l1gDei8OeLzDe7oCYDaiAu2zahQ=
=x34r
-----END PGP SIGNATURE-----
Can't they just block the new address just as well?
ok ya'll something funny here, I just ran out of Mitanox's orange earlier today so if its showing as listed then somethings up
Silk Road: IDENTIFY YOURSELF COMRADE
replacing message on this thread and at ianxz6zefk72ulzz.onion
Why not leave the old addy pointing at the site for a week or two as well so folks get used to it, and put a notice at the top of the page that the new address is now available.
It's trivial to do - 2 lines of code in the torrc file to point another hidden service address at the same http server, you just need a private key file directory for each one.
You can have 64 different .onion addresses pointing to the same server, if you want.
the signature on the post in the forum is the same signature as the post on the original ianxz6zefk72ulzz.onion/ site, but the message is different. that is why the post on the site doesn't verify and the one in the forum does. but a phisher couldn't have created a redirect page with the same .onion address as the actual store without a few decades of brute forcing the private key to get that address. And they can't spoof the address unless they controlled a majority of TOR nodes (which they don't). the link on the redirect page is legit, and if you want to try it with a log in that isn't yours, PM me and I'll give you one to try.
This is way too odd. There's a re-direct on the ianxz6zefk72ulzz.onion adress to silkroadvb5piz3r.onion, and it also differs from the one shown here. Has SR been compromised?
