BlockChain 2.0 and Bitcoin XT – 2.0 intelligent contracts

BlockChain 2.0 and Bitcoin XT

gAtO think – 2 of the main core Bitcoin developers Mike and Gavin did the best thing by for Bitcoin by simply making the blockchain bigger so it can support more transaction, contracts and un-developed new apps like 2.0 intelligent contracts that will make the BLockchain more valuable than the coin BTC. Today Blocks only allow 1mb Bitcoins XT makes the blockchain allow 8mb in the same block.

Why is this so important :bitcoin-gollum

Every transaction has to be verified by miners so they become valid in the BLock. Transactions vary in size depending on how many input’s and and how many outputs. Example: I send  a simple .01 BTC to Jane, this is a simple transactions and may have 1 or 2 inputs and and 2 outputs minimum – 1 -Output to Jane and 1 Output as change back to my wallet – maybe 1k in memory size-

Now take a Pool-Miner transaction they just won the block and get’s 25 coins but they have to pay hundreds of thousand of Pool-miners – this transaction may be 50k or larger –

The blockchain protocol only allowed to have a MAX of 1MB of transactions – anything over that goes into the temporary pool and they become the first in line for the NEXT BLOCK – 1MB limits. So if you have a bunch of small private Jane to gAtO individual Transactions you can fit a bunch of those into a 1MB BLOCK- But when you have a bunch of Mining Pools Transactions the 1MB BLOCK get’s filled fast. This delays transactions verified for the NEXT BLOCK.

Bitcoin XT gives the blockchain to 8mb BLOCK size instead of 1MB so a lot more transactions will be process in every BLOCK – This will guarantee less transactions will be delayed and since we have more room we can add Contacts and other stuff in the BLockChain –

This is why it is the best deal around for everyone – except the miners, they will need more memory in their mining rigs to hold a bigger block size of 8MB. Memory is cheap and yes the block size will increased but it will give a NEXT generation of Bitcoin tools available to everyone and that’s COOL BEANS.

The Basic War that’s going on with the new Fork and the 5 major Core Developers-

Let’s not make Bitcoin better and stay stale or let’s take it to the next level Mike Gavin gAtO is %100 behind Bitcoin XT. rOcK tHe KaSbAr

I know the arguments but all technology grows and we have to change and make it better for the new users that want to do Bitcoin 2.0 stuff real easy – I can’t wait to start to re-code my HD-BIP32 Business wallet with 2.0 intelligent contracts – again in this new Bitcoin XT – gATo OuT


Dark Web Escrow Service Explained

Dark Web Escrow Service Explained

gAtO FoUnD – this dark marketplace hidden service website -Nucleus- and they they explains the escrow service policy. gAtO wanted to pass it along so we can all learn how one dark website plays-

Now remember that this is only one dark websites version. Each different marketplaces has different version and flavors os their Bitcoin escrow policy. Bottom line your trussing two unknown people and Bitcoin transactions are final – so think and learn. Another marketplace Evolution closed down with 12-million in Bitcoin in escrow and the admin disappeared  – happily ever after. Beware Will Robinson  – gAtO OuTsegway_bike_Bitcoin

Okay, there seems to be an insane amount of bad finalizing practices on the market – lets lay this out.

Escrow – You give your money to a 3rd party (Nucleus) – This proves to the vendor you have the funds available, they ship product. You receive the item, and when you finalize, Nucleus gives your funds to the vendor. You prove you have money, vendor proves they have product, Nucleus proves the transaction was agreed to and turns the money over making a small profit per transaction and many people and vendors at the same time.

In the event of a dispute where escrow is involved, Nucleus agrees to mediate, acting as an unbiased 3rd party. If the vendor can prove they sent the product through tracking information or some other means, or offers a reshipment which you choose to accept, ect. Nucleus releases the funds to the Vendor. If the Vendor cannot prove they shipped the product, or no remedy is found to the customers dispute, the funds are returned to Customer.
Nucleus also offers a percentage based refund, where the customer can ask for a smaller portion of the price returned. This is useful for situations where for example a customer places an order for 50 units of an item and only 25 units are delivered, ect. – In the example here, the customer would ask for a 50% refund.

To prevent vendors waiting an excessively long time for funds if a customer should fail to log on or forget to finalize, Nucleus provides a timer on each order which releases the funds to the vendor when it runs out. The customer should note this timer, or auto-finalize feature, and take measures to file an appropriate dispute before it expires. Often, the mail runs slow, and vendors usually like to be optimistic in their advertising, so occasionally the timer will run out before a product has arrived, despite the vendor having actually sent the product. In these cases, the customer can send an order to reclamations by filing a dispute, which will stop the autofinalize timer until the product arrives. When the product arrives, the customer should select 0% in the refund request field, and the vendor will accept this offer releasing the funds.

FE or Finalize Early – You release the funds directly to the vendor, the vendor ships the product. Nucleus is not holding your money in escrow, therefor, in the case of a dispute, a refund is asked directly from the vendor. Vendors often have legitimate reasons for needing the money before delivery, including but not limited to ;
-Customer wants more of a product than is readily available on hand, but the vendor can easily and reliably obtain that amount of product if provided the funds.
-Vendor has an arranged middle-man product with another vendor. Typically, vendors are able to move product at a faster rate than normal customers, so vendors will work out a mutual agreement amongst each other to provide a discount for driving referral business.
-Order is deemed by vendor to be excessively risky due to international shipments, customs, ect. In this instance, vendors inform the customer of the risks involved and usually agree to keep and share tracking information with the customer.
Often, vendors will offer extra products or discounts for early finalization.

In the event of a dispute where escrow is NOT involved, Nucleus is not liable or required to provide mediation for the dispute, and the customer should address the issue with the vendor directly. HOWEVER. The customer SHOULD report any failure to deliver product to Nucleus staff, because if a pattern of failure to deliver, bad information, ect. begins to appear, Nucleus staff can take appropriate measures to remove the repeat offender from the market.

It is VERY important that customers fully understand their agreement with the vendor and Nucleus, and take appropriate measures to protect their money and not get ripped off. Due to the anonymous nature of the darknet, there is very little culpability or repercussions for scamming innocent people. Scammers are here to mislead and deceive, and will take your money without thinking twice, and if you have released the funds to the vendor, Nucleus will not be able to help you get them back.


Tor Traffic Confirmation Attack

Tor Traffic Confirmation Attack -Roger Dingledine Report
  On July 4 2014 we found a group of relays that we assume were trying
  to deanonymize users. They appear to have been targeting people who
  operate or access Tor hidden services. The attack involved modifying
  Tor protocol headers to do traffic confirmation attacks.gato_signal_02

  The attacking relays joined the network on January 30 2014, and we
  removed them from the network on July 4. While we don't know when they
  started doing the attack, users who operated or accessed hidden services
  from early February through July 4 should assume they were affected.

  Unfortunately, it's still unclear what "affected" includes. We know
  the attack looked for users who fetched hidden service descriptors,
  but the attackers likely were not able to see any application-level
  traffic (e.g. what pages were loaded or even whether users visited
  the hidden service they looked up). The attack probably also tried to
  learn who published hidden service descriptors, which would allow the
  attackers to learn the location of that hidden service. In theory the
  attack could also be used to link users to their destinations on normal
  Tor circuits too, but we found no evidence that the attackers operated
  any exit relays, making this attack less likely. And finally, we don't
  know how much data the attackers kept, and due to the way the attack
  was deployed (more details below), their protocol header modifications
  might have aided other attackers in deanonymizing users too.

  Relays should upgrade to a recent Tor release ( or, to close the particular protocol vulnerability the
  attackers used -- but remember that preventing traffic confirmation in
  general remains an open research problem. Clients that upgrade (once
  new Tor Browser releases are ready) will take another step towards
  limiting the number of entry guards that are in a position to see
  their traffic, thus reducing the damage from future attacks like this
  one. Hidden service operators should consider changing the location of
  their hidden service.

  We believe they used a combination of two classes of attacks: a traffic
  confirmation attack and a Sybil attack.

  A traffic confirmation attack is possible when the attacker controls
  or observes the relays on both ends of a Tor circuit and then compares
  traffic timing, volume, or other characteristics to conclude that the
  two relays are indeed on the same circuit. If the first relay in the
  circuit (called the "entry guard") knows the IP address of the user,
  and the last relay in the circuit knows the resource or destination
  she is accessing, then together they can deanonymize her. You can read
  more about traffic confirmation attacks, including pointers to many
  research papers, at this blog post from 2009:

  The particular confirmation attack they used was an active attack where
  the relay on one end injects a signal into the Tor protocol headers,
  and then the relay on the other end reads the signal. These attacking
  relays were stable enough to get the HSDir ("suitable for hidden
  service directory") and Guard ("suitable for being an entry guard")
  consensus flags:
  Then they injected the signal whenever they were used as a hidden
  service directory, and looked for an injected signal whenever they
  were used as an entry guard.

  The way they injected the signal was by sending sequences of "relay"
  vs "relay early" commands down the circuit, to encode the message they
  want to send. For background, Tor has two types of cells: link cells,
  which are intended for the adjacent relay in the circuit, and relay
  cells, which are passed to the other end of the circuit.
  In 2008 we added a new kind of relay cell, called a "relay early"
  cell, which is used to prevent people from building very long paths
  in the Tor network (very long paths can be used to induce congestion
  and aid in breaking anonymity):
  But the fix for infinite-length paths introduced a problem with
  accessing hidden services:
  and one of the side effects of our fix for bug 1038 was that while
  we limit the number of outbound (away from the client) "relay early"
  cells on a circuit, we don't limit the number of inbound (towards the
  client) relay early cells:

  So in summary, when Tor clients contacted an attacking
  relay in its role as a Hidden Service Directory to publish
  or retrieve a hidden service descriptor (steps 2 and 3 on
  https://www.torproject.org/docs/hidden-services), that relay would
  send the hidden service name (encoded as a pattern of relay and
  relay-early cells) back down the circuit. Other attacking relays,
  when they get chosen for the first hop of a circuit, would look for
  inbound relay-early cells (since nobody else sends them) and would
  thus learn which clients requested information about a hidden service.

  There are three important points about this attack:

  A) The attacker encoded the name of the hidden service in the injected
  signal (as opposed to, say, sending a random number and keeping a local
  list mapping random number to hidden service name). The encoded signal
  is encrypted as it is sent over the TLS channel between relays. However,
  this signal would be easy to read and interpret by anybody who runs
  a relay and receives the encoded traffic. And we might also worry
  about a global adversary (e.g. a large intelligence agency) that
  records Internet traffic at the entry guards and then tries to break
  Tor's link encryption. The way this attack was performed weakens Tor's
  anonymity against these other potential attackers too -- either while
  it was happening or after the fact if they have traffic logs. So if
  the attack was a research project (i.e. not intentionally malicious),
  it was deployed in an irresponsible way because it puts users at risk
  indefinitely into the future.

  (This concern is in addition to the general issue that it's probably
  unwise from a legal perspective for researchers to attack real users
  by modifying their traffic on one end and wiretapping it on the
  other. Tools like Shadow are great for testing Tor research ideas out
  in the lab: http://shadow.github.io/ )

  B) This protocol header signal injection attack is actually pretty neat
  from a research perspective, in that it's a bit different from previous
  tagging attacks which targeted the application-level payload. Previous
  tagging attacks modified the payload at the entry guard, and then
  looked for a modified payload at the exit relay (which can see the
  decrypted payload). Those attacks don't work in the other direction
  (from the exit relay back towards the client), because the payload
  is still encrypted at the entry guard. But because this new approach
  modifies ("tags") the cell headers rather than the payload, every
  relay in the path can see the tag.

  C) We should remind readers that while this particular variant of
  the traffic confirmation attack allows high-confidence and efficient
  correlation, the general class of passive (statistical) traffic
  confirmation attacks remains unsolved and would likely have worked
  just fine here. So the good news is traffic confirmation attacks
  aren't new or surprising, but the bad news is that they still work. See
  https://blog.torproject.org/blog/one-cell-enough for more discussion.

  Then the second class of attack they used, in conjunction with their
  traffic confirmation attack, was a standard Sybil attack -- they
  signed up around 115 fast non-exit relays, all running on
  or Together these relays summed to about 6.4% of the
  Guard capacity in the network. Then, in part because of our current
  guard rotation parameters:
  these relays became entry guards for a significant chunk of users over
  their five months of operation.

  We actually noticed these relays when they joined the network, since
  the DocTor scanner reported them:
  We considered the set of new relays at the time, and made a decision
  that it wasn't that large a fraction of the network. It's clear there's
  room for improvement in terms of how to let the Tor network grow while
  also ensuring we maintain social connections with the operators of all
  large groups of relays. (In general having a widely diverse set of relay
  locations and relay operators, yet not allowing any bad relays in,
  seems like a hard problem; on the other hand our detection scripts did
  notice them in this case, so there's hope for a better solution here.)

  In response, we've taken the following short-term steps:

  1) Removed the attacking relays from the network.
  2) Put out a software update for relays to prevent "relay early" cells
     from being used this way.
  3) Put out a software update that will (once enough clients have
     upgraded) let us tell clients to move to using one entry guard
     rather than three, to reduce exposure to relays over time.
  4) Clients can tell whether they've received a relay or relay-cell.
     For expert users, the new Tor version warns you in your logs if
     a relay on your path injects any relay-early cells: look for the
     phrase "Received an inbound RELAY_EARLY cell".

  The following longer-term research areas remain:

  5) Further growing the Tor network and diversity of relay operators,
     which will reduce the impact from an adversary of a given size.
  6) Exploring better mechanisms, e.g. social connections, to limit the
     impact from a malicious set of relays. We've also formed a group to
     pay more attention to suspicious relays in the network:
  7) Further reducing exposure to guards over time, perhaps by extending
     the guard rotation lifetime:
  8) Better understanding statistical traffic correlation attacks and
     whether padding or other approaches can mitigate them.
  9) Improving the hidden service design, including making it harder
     for relays serving as hidden service directory points to learn what
     hidden service address they're handling:

  Q1) Was this the Black Hat 2014 talk that got canceled recently?
  Q2) Did we find all the malicious relays?
  Q3) Did the malicious relays inject the signal at any points besides
      the HSDir position?
  Q4) What data did the attackers keep, and are they going to destroy it?
      How have they protected the data (if any) while storing it?

  Great questions. We spent several months trying to extract information
  from the researchers who were going to give the Black Hat talk, and
  eventually we did get some hints from them about how "relay early"
  cells could be used for traffic confirmation attacks, which is how
  we started looking for the attacks in the wild. They haven't answered
  our emails lately, so we don't know for sure, but it seems likely that
  the answer to Q1 is "yes". In fact, we hope they *were* the ones doing
  the attacks, since otherwise it means somebody else was. We don't yet
  know the answers to Q2, Q3, or Q4.

Tor Wacky Times and the NSA

gAtO rEaD – that Tor (The Deep Dark Web) is now all messed up by the NSA, FBI and LEO so all you bad guys using the Tor network better watch out, or should they???fed_links_01

Aug 5 the FBI snakes in Freedom Hosting and put a number of websites out of business in the Dark Web. They let the flames go out that they caught a bunch of Pedophile sites with that bust, but it does not seem so.

The Attack on the Dark Net Took Down a Lot More Than Child Porn – http://gawker.com/the-attack-on-the-dark-net-took-down-a-lot-more-than-ch-1081274609 – gAtO contribute to this article–

fed_usCitizenship_01Aug 19 – Millions of Tor Clients start to go up in numbers. What’s this all about, we get a bunch of Tor clients just hanging around doing nothing in Tor. Some say it’s a Bot-net or something like that. Then it growns 4, 5  million Tor users and the last week or so it starts to go down again. So what is all this about all these Tor Clients and the Tor- Botnet?fed_rent_a_hacker01

Oct 3– Silk Road get’s taken down, Oh the FBI had a copy of the Silk Road servers back in June just before the AUG 5 take down of FH by the FBI. So the Feds had Silk Road all this time and this is all they can do, can’t even get a few Bitcoin wallets- what a cluster fˆ%k—//fed_cc-paypal_01

Now you got NSA saying that Tor is cracked and the bad guys cannot use it. They claim that they can hack Tor anytime and anywhere with documents that a summer student left on how to hack the Tor network back in 2006. By the Way – most of these hacks do not work in Tor, maybe on a regular network but not on the Tor network.fed_hit_man_01

So now gAtO goes in search of Tor sites and a lot of sites went down by hook or crook —BUT someone has started to replace these Tor Hidden Websites in the Tor Network – But something is FuNnY – all these sites us the same web templates –

So now you can take a walk down memory lane and see all the older Tor-Websites have gone away and new ones have magicly re-appear.

fed_apple4bitcoin_01Now if this was the only place were this has happens OK sure, but at other Tor- Wiki Tor Link sites you will see the same thing – Commercial sites are all FuNnY and all the non-commercial Tor-websites are Tango Down.

So now Tor goes round and round but nobody knows what the heck is going on- In the Tor network – The Deep Dark Web run by Criminals or the FBI – you can answer these questions yourself by visiting the site –trust but Verify– ((not me))– gAtO oUt

fed_counterfiet_euro_50 fed_counterfiet_usd_01 fed_links_01 fed_mobile_steal_store_01 fed_uk_guns_01














Silk Road down – Tor still OK

Silkroad Seized Coins Addresses are identifiers which you use to send bitcoins to another person.

– https://blockchain.info/address/1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX

I found what I was after – this is all the Bitcoin Wallet Address from Silk Road that the FBI has –

caveat – check your wallet number if it’s not listed then your wallet is still cool and the funds available  –MaYbE!!!

UPDATE: notice that SILK ROAD account is still paying out all this money to France, Germany all over the UE – 500 BTC – 100 -BTC at a time WoW – Someone is making off with all the money from the SR account-

Unspent Outputs 1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX – https://blockchain.info/unspent?active=1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX&format=html 

 gAtO sEe- the fact is that as always GREED is what got SilkRoad Tango Down. I been getting lot’s of slack about Tor and all that but sorry, it’s as safe as you make it. Tor gives you an edge and if you really need the privacy and do your research on Tor, you too can communicate anonymous FACT not fiction -// 

Now the Bitcoin aspect of this take down is what is really cool. This take down now makes BTC more legit since they can’t say yeah it all criminals using Bitcoins, na, na, na, – I saw the first few 1 million dollars BTC transaction the other day – but still “Bitcoin Buying and Selling is a pain the A$$” my new Bitcoin book coming out in a next months just in time for the holiday seasons – gAtO oUt


On 10/04/2013 02:21 AM, Roger Dingledine wrote:

 OK, I just read the Maryland complaint. It’s obvious what happened.

 An FBI undercover agent contacted him, wanting to sell large quantities

of cocaine. He found a buyer, and delegated the details to his employee.

Said employee had full admin access to his servers.

His employee then provided his ACTUAL PHYSICAL ADDRESS to the undercover

FBI agent. The FBI mailed 1 Kg (very highly cut) cocaine to said

employee, and arrested him on receipt. Said employee soon told the FBI

all that he knew.

So now the FBI had access to the servers. There’s no reason to suspect

that they needed to compromise Tor to gain access, or for anything else.

There’s more drama about the murder for hire stuff, but it’s irrelevant.



Tor Usage goes UP PirateBay, Iran-Syria and Google-play Orbot

USCyberLabs Stats of the Tor Network Aug-27

USCyberLabs Stats of the Tor Network


Sudden rise in direct Tor users

On Tuesday 27th, Roger Dingledine drew attention to the huge increase of Tor clients running [14]. It seems that their number has doubled since August 19th according to the count of directly connecting users [15]. According to Roger this is not just a fluke in the metrics data. The extra load on the directory authorities is clearly visible [16], but it does not look that the overall network performance are affected so far [17]. The cause is still unknown, but there are already speculations about the Pirate Browser [18] or the new “anti-piracy” law in Russia which is in force since August, 1st [19]. As Roger pointed out, ?some good solid facts would sure be useful.?

[14] https://lists.torproject.org/pipermail/tor-talk/2013-August/029582.html

[15] https://metrics.torproject.org/users.html?graph=direct-users&start=2013-05-29&end=2013-08-27&country=all&events=off#direct-users

[16] https://metrics.torproject.org/network.html#dirbytes

[17] https://metrics.torproject.org/performance.html

[18] https://lists.torproject.org/pipermail/tor-talk/2013-August/029584.html

[19] https://lists.torproject.org/pipermail/tor-talk/2013-August/029583.html

Ever since the the NSA Prism program came out something else is going on in Tor. People want privacy and they will use anything they can to get it. Tor is one solution that a lot of people know about but there are other factors about the increase.

Piratebay.sx and it’s users are doing a lot more stuff with the new browser – There has not been a sustained increase in search traffic for the Pirate Browser on Google. Tor and “Tor browser” haven’t shown a spike in search, either. Could it be from users in Syria?  Also note that the Google Play Store has been unblocked in Iran, allowing distribution of Orbot/Orweb in that country to phones with the Play Store app installed (partial bootstrapping problem).

Syria had a spike from 1000 to 4000 but that’s a tiny fraction of the recent increase. Iran doubled from 4000 to 8000 which is also only a part of the increase. Is there a page listing each graph by country or overlapping them all?

The Tor Project also pushed out Orbot v12 to Google Play in the last few weeks – 2 separate updates. That would not account for all of the increase, but it could have prodded enough existing users who had not used Orbot in awhile to start the app up again. We have also seen about 75,000 new installs over the last 3 months.

So we have a lot of factors as the Tor network grows larger everyday– gATo oUt



Tor Network Consensus Document

gAtO lOOkInG – at the Tor-network intelligence, how does it do what it does. Tor takes volunteers Onion-relays and organizes them into different categories they are called “flags” –

—  known-flags Authority BadExit Exit Fast Guard HSDir Named Running Stable Unnamed V2Dir Valid  —

Of course there are only now 10 authority flags-servers own and controlled by some of the top people in the Tor-project community. These 10 Authority-relays control all the intelligence that Tor need to run and keep everything working automatic. Every few hours these relays gather the OR-relays and depending on how long they have been turned on, how much bandwidth they have what version of Tor-software and OS they have and put this together into one document then it does a calculation and assigns flags to the 3,500 or so volunteer OR-relays throughout the world. After it’s all said and done they produce a “Consensus Document and sends this information to every HSDir -OR-relay so that clients can find hidden service websites in Tor. The HSDIR relays have all the DNS information to find Tor-hidden service -websites…//

consensus document – May-2013


network-status-version 3

vote-status consensus

consensus-method 17

valid-after 2013-05-17 12:00:00

fresh-until 2013-05-17 13:00:00

valid-until 2013-05-17 15:00:00

voting-delay 300 300



known-flags Authority BadExit Exit Fast Guard HSDir Named Running Stable Unnamed V2Dir Valid

params CircuitPriorityHalflifeMsec=30000 UseOptimisticData=1 bwauthpid=1 pb_disablepct=0


dir-source tor26 14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4 80 443

contact Peter Palfrader

vote-digest C9B36D4CE1E4E25D313DBCB9CAB01BD6402136BB

dir-source turtles 27B6B5996C426270A5C95488AA5BCEB6BCC86956 9030 9090

contact Mike Perry <mikeperryTAfsckedTODorg>

vote-digest 2974C1E86CE7D44B2A1B304DDED4D6965C519F6C

dir-source maatuska 49015F787433103580E3B66A1707A00E60F2D15B 443 80

contact 4096R/23291265 Linus Nordberg <linus@nordberg.se>

vote-digest 4C9F8F31152829E776531350A3D0A3AB4F601FBF

dir-source dannenberg 585769C78764D58426B8B52B6651A5A71137189A dannenberg.ccc.de 80 443

contact Andreas Lehner <anonymizer@ccc.de>

vote-digest E326C020E9462BA105EC190DFBE4EA8FADA3A138

dir-source urras 80550987E1D626E3EBA5E5E75A458DE0626D088C 443 80

contact 4096R/4193A197 Jacob Appelbaum <jacob@appelbaum.net>

vote-digest 9D6CB9D0890C4BF18D12BBB4F26F5BC762B081C3

dir-source moria1 D586D18309DED4CD6D57C18FDB97EFA96D330566 9131 9101

contact 1024D/28988BF5 arma mit edu

vote-digest 21FCEA71FE6597E39E586721F7DA65C3A74A4EA1

dir-source dizum E8A9C45EDE6D711294FADF8E7951F4DE6CA56B58 80 443

contact 1024R/8D56913D Alex de Joode <adejoode@sabotage.org>

vote-digest 0787DE217B45ED8895701D679F02E755A257AF4F

dir-source gabelmoo ED03BB616EB2F60BEC80151114BB25CEF515B226 80 443

contact 4096R/C5AA446D Sebastian Hahn <tor@sebastianhahn.net>

vote-digest EEECD55223C97CACF7655D897782B61B64C1CF03

dir-source Faravahar EFCBE720AB3A82B99F9E953CD5BF50F7EEFC7B97 80 443

contact 0x0B47D56D SiNA Rabbani (inf0) <sina redteam io>

vote-digest EE92CA0F3820E3BAFC22C41DFD107D4F4B34E542

r ididnteditheconfig6 AB+dZViiymIEpTtbx+9cX5Y32i0 sjraCwjE8lzInizQ0UPqTI1AHkE 2013-05-17 10:29:13 9001 9030

s Exit Fast Running V2Dir Valid

v Tor

w Bandwidth=14

p accept 20-23,43,53,79-81,88,110,143,194,220,389,443,464,531,543-544,554,563,636,706,749,873,902-904,981,989-995,1194,1220,1293,1500,1533,1677,1723,1755,1863,2082-2083,2086-2087,2095-2096,2102-2104,3128,3389,3690,4321,4643,5050,5190,5222-5223,5228,5900,6660-6669,6679,6697,8000,8008,8074,8080,8087-8088,8332-8333,8443,8888,9418,9999-10000,11371,19294,19638

r MukiMukiAmaguri ADwuo9jHaHhVHIjp8/rSBaoXkj8 qZ48RT3ftleevrpO/kNy1qeBAS0 2013-05-16 18:16:19 9001 9030

s Fast HSDir Running Stable Unnamed V2Dir Valid

v Tor

w Bandwidth=38

p reject 1-65535


r= Version of Tor- -OS -timestamp -IP address

s= Flags of the Onion-relay

w= bandwidth that the relays has

p= Exit relay information

The 10 servers on top of the documents are the Tor- Authority the servers that have all the real power in Tor controlled by – SiNA Rabbani (inf0) <sina redteam io> – Sebastian Hahn <tor@sebastianhahn.net> – Alex de Joode <adejoode@sabotage.org> – arma mit edu – Andreas Lehner <anonymizer@ccc.de> – Linus Nordberg <linus@nordberg.se> –  Mike Perry <mikeperryTAfsckedTODorg> – Jacob Appelbaum – Peter Palfrader <jacob@appelbaum.net> –

These are the real master of the Tor network nah… just joking it’s in the code– gAtO oUt


There is a small set (say, around 5-10) of semi-trusted directory authorities.  A default list of authorities is shipped with the Tor software.  Users can change this list, but are encouraged not to do so, in order to avoid partitioning attacks.

Every authority has a very-secret, long-term “Authority Identity Key”. This is stored encrypted and/or offline, and is used to sign “key certificate” documents.  Every key certificate contains a medium-term (3-12 months) “authority signing key”, that is used by the authority to sign other directory information.  (Note that the authority identity key is distinct from the router identity key that the authority uses in its role as an ordinary router.)

Routers periodically upload signed “routers descriptors” to the directory authorities describing their keys, capabilities, and other information.  Routers may also upload signed “extra info documents” containing information that is not required for the Tor protocol. Directory authorities serve router descriptors indexed by router identity, or by hash of the descriptor.

Routers may act as directory caches to reduce load on the directory authorities.  They announce this in their descriptors.

Periodically, each directory authority generates a view of the current descriptors and status for known routers.  They send a signed summary of this view (a “status vote”) to the other authorities.  The authorities compute the result of this vote, and sign a “consensus status” document containing the result of the vote.

Directory caches download, cache, and re-serve consensus documents.

Clients, directory caches, and directory authorities all use consensus

documents to find out when their list of routers is out-of-date.

(Directory authorities also use vote statuses.) If it is, they download

any missing router descriptors.  Clients download missing descriptors

from caches; caches and authorities download from authorities.

Descriptors are downloaded by the hash of the descriptor, not by the

relay’s identity key: this prevents directory servers from attacking

clients by giving them descriptors nobody else uses.


All directory information is uploaded and downloaded with HTTP.

[Authorities also generate and caches also cache documents produced and

used by earlier versions of this protocol; see dir-spec-v1.txt and

dir-spec-v2.txt for notes on those versions.]


Finding the Bad Guy’s in Tor -triangulated irregular network

gAtO ThInKiNg – a car GPS works very simple, It takes the delay time from one geo-positioned satellite and compares is to another geo-positional satellite and estimates the position of the GPS in my CAR – I think they call it satellite triangulation or something cool, it’s been done with radios to guide pilots navigate ever since they developed radios. We do it with satellite and we can use networks too.

triangulated irregular network  -So now apply this to the Tor bad guy’s websites- a hidden service!math_clouadTag

With a simple command you can get the time it takes to crawl a website, so you have one server in the U.S one is South America, one in Europe and one in Asia and we run the same command getting the delays from each location. I bet with a little math and some basic network tools we could figure out the geo-location of any given website in Tor. One of my good mentors told me that in my crawls I was capturing timing information, we all see timing information with a simple ping command in the clear web but in Tor – UDP is unsupported so it does not work -//- we must take into account the Tor network thru-put and utilization bit that’s easy to get from a number of Tor tools.

Reverse triangulation of a network server should be easy to find with a little math, just take a good sample and the longer you wait the more data you collect and the better the chance you can find a geo-location of a website. We do this in the clear web all the time we can see bad areas of the world that are bad spammers, and other like mail from Africa Prince Scams offering you millions if you send them some money to cover the transfer, or Russian and Chinese phishing attacks. So we know geo-location and some IP are more prime to bad actors and we can draw a profile, a geo-location of a place and/or  country or an ISP so not having the IP of a Tor server may not be neededto find them we could use network triangulation. “triangulated irregular network  ” So the same thing can be done with networks and timing delays of data back and forth from a // client <–> Tor OR <–>server.

I got a crazy Idea that may or may-not work, but it sounds good—//  so— Now if I can only find a government grant and a good math major to help out and we have a big business model to find the bad guy’s geo-location even in Tor – gAtO oUt…


Tor Website 36% are Criminals Sites

gAtO iS CrAwLliNg websites-We just completed our new crawl of Tor URL that we found. We started with 2,000 URL’s and we got about 550 positives from this first run. This will change since some sites go up and down for no rhyme or reason. I went back to verify one site that my crawl picked up with all kinds of good information but later when I went back it would not come up. So this is an ongoing thing in order to map out all of Tor’s hidden service websites. From the preliminary data Pedo sites are about 18% of the sites we discovered another 4-6% guns and assassins and another 14-16% of different criminal type’s of sites or scams. So that is over 36% of the sites we found were criminal type, that is not good for anyone.

Crawling Tor Hidden Service - websites

Crawling Tor Hidden Service – websites

Tor is an excellent software for being private and having some level of safety but this new light is not good for the people that want to use Tor and the Dark Web to do good things and positive things. Now we see that the bad guys are all over Tor-Dark Web we hope this list will help it become better.

This list is only available to Law enforcement, governments and selected security companies, you must be verified first before you can get a hold of this list of Onion websites in Tor. This is not a free list (we have to recover our cost of r&d) and this is only the first steps we have gained over 12,000 new URL in Tor from this crawl and will be doing more crawls and adding more information to the list.

What really freaked us out was the undocumented website that are not in any hidden wiki in Tor and the number of them being put out by criminals. Now some of the other information that we collected see list below will give us a baseline like — Last-Modified: — will give us an indication of how active they are. The —Server: & Web Application:— will give us the web app they use and from the looks of things some are vulnerable to all kinds of hacking attacks. Tor websites are the same as any site and if you don’t update your website, well your vulnerable to hacking from anyone and in Tor you don’t have a clue because they are protected just like the site.

This will be an ongoing crawl for the next year or so, so expect the list to grow and as new data is collected more will be revealed about the how, and the use of Tor and who uses Tor will become not just theories but facts that we can verify – gAtO OuT 

Internal URL’s – 













    [size_upload] => 0

    [size_download] => 124

    [speed_download] => 7












Crawl Date:










Web Application:



Mapping Tor Websites

gATo and fRiEnDs- are am now working on the Tor-Directory Project crawling about 2000 Tor-url and getting some new information about Tor and the sites that reside in the Dark Web. Example I got a good crawl from a site and I went to double check it and now it was down, so are the sites going up and down and online just for a period of time? Are the site not available because of the browser I am using -vs- my crawler. These are some of the answers I will find out.

I expected due to the slowness of Tor to spend a lot of time running these crawls. I have now a script that I can run in about 20hr or less and scrape about 2000 sites. I thought that the slowness of Tor-Dark Web would make this a real time eater but I am wrong. Another thing is the secret Tor sites I found, I now have a fingerprint on them and these sites that hide in secret on top of being in Tor are a real interest to me and others.

The main issue is Tor is not socks-http friendly so setting up the infrastructure was a real learning curve and now I can replicate the installation so as I get more servers online this will become a little easier. Right now I am mapping the sites so I can crawl every page, the good part and bad is I am finding more and more URL that I never thought existed, so the discovery of new URL is a good thing but once again the collection becomes a real bear.

I am putting this into a db to make the search of the collected data a little easier but finding that db programing on the web is well not very user friendly but I have a good partner that is fixing all my mistakes. We will house this new Tor-only website search engine in the clear web so we can keep the speed up and well people are scared to go into Tor, so why not keep everything in the clearWeb for now.

I expect the crawls to get much longer since I now have the urls to crawl every site a little better but the information and mapping out Tor will be and invaluable tool for us. You say how about the hidden wiki, and all those sites that have Tor directory wiki sites. Well they are OK for basic stuff but I am finding new sites I never heard of and the pedophiles are all over Tor so you best beware I am putting a light on your websites and the next part will be to stop you from using Tor as a play ground for your sick crap. Tor is meant for real needs of privacy and protection and I hope my work in this will get these sick bastards to run somewhere else — gATO is watching you in Tor so beware!!!