Project Description
Tochka Free Market is free open-source marketplace for DarkNet operations. Same-name DarkNet Market (DNM) Tochka is running on it.
Goal of Tochka is to provide reliable software for next-gen darknet operations, while staying transparent, free and secure.
We would like more local players emerge using Tochka as platform of choice.
Technical Overview
Tochka is written on Golang programming language and can be run on wide range of operating systems. Postgres is database of choice and Tor is used to obfuscate server location. Redis is used for caching.
Payaka is a payment gate solution used in conjunction with Tochka.
Payaka supports:
Bitcoin
Ethereum
Tochka Smart Contracts (ICO, Split Payment) based on Ethereum.
Tochka provides script-less HTML interface that can be used in conjunction with Firefox/Tor Browser NoScript as well as a REST API for Tochka Mobile App.
Tochka Mobile App is a free open-source client for Tochka written for Android. It can be downloaded as compiled apk or in form of source-code for manual compilation.
We provide Docker scripts to get Tochka running fast.
Installation from source code
To get Tochka running:
1. Get Tochka source code
torsocks go get -insecure qxklmrhx7qkzais6.onion/Tochka/tochka-free-market
or
mkdir $GOPATH/src/qxklmrhx7qkzais6.onion/Tochka
cd $GOPATH/src/qxklmrhx7qkzais6.onion/Tochka
torify git clone qxklmrhx7qkzais6.onion/Tochka/tochka-free-market.git
2. Build Tochka from source
cd $GOPATH/src/qxklmrhx7qkzais6.onion/Tochka/tochka-free-market
go build
3. Sync DB models and supplementary data.Database user must be postgres.otherwise cant sync.
Let’s start by logging into our frontend server and installing Tor. You will want a very recent version of Tor (version 0.4.3.1 or newer is sufficient, as long as it includes #31684). If you want to use the latest official Tor master, you can do the following:
$ git clone https://git.torproject.org/tor.git
$ cd tor
$ ./autogen.sh && ./configure && make
by the end of this process you should have a Tor binary at ./src/app/tor. If this is not the case, you might be missing various C dependencies like libssl-dev, libevent-dev, etc.
Now setup a minimal torrc with a control port enabled. As an example:
Feel free to tweak your torrc as you feel (also enable logging), but for the purposes of this guide I assume that your control port is at 127.0.0.1:6666.
Now, still on the frontend host we need to setup Onionbalance. If you wish to use the Debian package of onionbalance, you will need version 0.2.0-1 or newer to get v3 support, otherwise you can obtain it via git:
$ git clone https://gitlab.torproject.org/tpo/core/onionbalance.git
$ cd onionbalance
$ sudo python3 setup.py install
# Let's create an onionbalance config file.# -n indicates how many empty backend address slots will be created.# These can be easily modified with a text editor at any time.
$ onionbalance-config --hs-version v3 -n 2
After the final command you should have a ./config/config.yaml file with a basic onionbalance configuration. The onion address of your frontend service can be found in the bottom of your config file. So if it says
the frontend’s onion address is: dpkhemrbs3oiv2fww5sxs6r2uybczwijzfn2ezy2osaj7iox7kl7nhad.onion .
For now, note down the frontend’s onion address and let’s move on to the next step!
Note
If you need to migrate an already existing Tor onion service to Onionbalance, you can use the key directive of the Onionbalance YAML config file to point to the onion service’s private key (hs_ed25519_secret_key). You can then use your existing onion service’s address as your frontend’s address.
So for example if you place your private key in ./config/hs_keys/hs_ed25519_secret_key, your YAML config file might contain a key directive that looks like this:key: hs_keys/hs_ed25519_secret_key
OK now with the frontend onion address noted down, let’s move to setting up your backend instances:
Login to one of your backend instances and let’s setup Tor. Similar to the step above, you will need to use the latest Tor master for Onionbalance to work (because of #32709).
As before:
$ git clone https://gitweb.torproject.org/tor.git
$ cd tor
$ ./autogen.sh && ./configure && make
Now you will need a torrc file for your backend instance. Your torrc file needs to setup an onion service (and in this case a v3 one) and I’m gonna assume you know how to do that. So far so good but here comes the twist:
Inside the HiddenService block of your torrc file, you need to add the following line: HiddenServiceOnionbalanceInstance 1. Note that if you do not have an existing v3 onion service and you are trying to create one from scratch, you must first start Tor once without this torrc line, otherwise it will fail to start. After the onion service was created, add this line to your torrc file.
In your hidden service directory where the hostname and hs_ed25519_public_key files are living (assuming you moved them previously or started Tor as described at previous step to generate them) you need to create a new file with the name ‘ob_config’ that has the following line inside:MasterOnionAddress dpkhemrbs3oiv2fww5sxs6r2uybczwijzfn2ezy2osaj7iox7kl7nhad.onion but substitute the onion address above with your frontend’s onion address.
Start (or restart if currently running) the Tor process to apply the changes.
The points (1) and (2) above are extremely important and if you didn’t do them correctly, nothing is gonna work. If you want to ensure that you did things correctly, start up Tor, and check that your notice log file includes the following line:
If you don’t see that, then something went wrong. Please try again from the beginning of this section till you make it! This is the hardest part of the guide too, so if you can do that you can do anything (fwiw, we are at 75% of the whole procedure right now).
After you get that, also make sure that your instances are directly reachable (e.g. using Tor browser). If they are not reachable, then onionbalance won’t be able to see them either and things are not gonna work.
OK, you are done with this backend instance! Now do the same for the other backend instances and note down the onion addresses of your backend instances because we are gonna need them for the next and final step.
OK now let’s login back to the frontend server! Go to your onionbalance config file and add your instance addresses in the right fields. In the end it should look like this (for a setup with 3 backend instances):
Backend instances can be added, removed or edited at any time simply by following the above format. Onionbalance must be restarted after any change of the config file.
Now let’s fire up onionbalance by running the following command (assuming your ControlPort torrc setting is 6666, substitute if different):
$ onionbalance -v info -c config/config.yaml -p 6666
If everything went right, onionbalance should start running and after about 10 minutes your frontend service should be reachable via the dpkhemrbs3oiv2fww5sxs6r2uybczwijzfn2ezy2osaj7iox7kl7nhad.onion address!
If something did not go right, that’s OK too, don’t get sad because this was quite complicated. Please check all your logs and make sure you did everything right according to this guide. Keep on hammering at it and you are gonna get it. If nothing seems to work, please get in touch with some details and I can try to help you.
Now that you managed to make it work, please monitor your frontend service and make sure that it’s reachable all the time. Check your logs for any errors or bugs and let me know if you see any. If you want you can make onionbalance logging calmer by using the -v warning switch.
You can also setup a Status Socket to monitor Onionbalance.
If you find bugs or do any quick bugfixes, please submit them over Gitlab or Github!
In order for this to work, the user you are trying to run onionbalance from should have permissions to reach Tor’s control port cookie. Othwerise, you will see an error like this:
[ERROR]: Unable to authenticate on the Tor control connection: Authentication failed: unable to read '/run/tor/control.authcookie' ([Errno 13] Permission denied: '/run/tor/control.authcookie')
As always, we do not recommend running anything as root, when you don’t really have to. In Debian, Tor is run by its dedicated user debian-tor, but it’s not the same for other Linux distributions, so you need to check. In Debian you can add the user you are running onionbalance from to the same sudoers group in order to gain permission:
onion eCommerce Marketplace Script V2.2 This is a complete rewrite of my old script: onion eCommerce Marketplace Script. The two share some similarities (functional), but new version is written from scratch, meaning no code is shared between them.
onion eCommerce Marketplace Script v1 is also written in PHP with Laravel framework. It is using the latest standards for encryption (like Sodium library) and security. Its made without the use of JavaScript, so its optimized for TOR, but can also be run normally like any other web app (as you can see on demo).
Requirements
VPS with at least 2GB of RAM
Daemon for each coin that is enabled on marketplace
Server requirements: (what software is needed on VPS)
Elasticsearch (Search interface that will keep track of search records and provide great search performance)
Redis (Optional, but will greatly increase app performance )
Features
Categories Category system is very dynamic. Categories can be nested indefinitely. Creating, deleting and editing of categories is handled in admin panel.
Detailed home page There is placeholder text on the home page at the moment that will represent the most important features of your marketplace. On top of that, all users can see Top Vendors (Vendors with most sales), Latest Orders (Products of orders completed most recently, as well as order value, but no information about buyer or seller), Rising Vendors (Vendors with most sales in specified time frame, defaults to 7 days). Official mirrors are a place where you can specify on what other links your website can be reached.
Password reset Password can be reset with PGP Key added on account (more about PGP below) or with Mnemonic key provided during signup. The mnemonic key is shown only once and should be written down on paper. During signup, it is hashed (bcrypt) instantly and only stored in operating memory for the short time during display after which is cleared from memory manually as an addition to automatic PHP Garbage Collection.
PGP Each user can add their on PGP key which is used for multiple features. Vendors must have PGP and 2FA enabled before they are allowed to upgrade from user to vendor status. If you have active PGP key you can reset your password with it or enable 2FA for your login. Each PGP key must be confirmed before is linked to account, and if you want to add new key you must first sign a message from the old one. Messages can also be encrypted with user’s PGP key if its present (this is not enforced, its user’s choice).
2FA (Two-Factor Authentication)
If user has PGP key linked to their account, they can enable 2FA. If enabled, log in to marketplace will be prevented unless a randomly generated message is signed from the key.
Wishlist
Buyers do not need to save product links for later. On each product there is “Add to wishlist” button that can be used, and they are stored in user’s personal list for later.
Vendors
Normal users cannot post products on Marketplace. In order to post products you must become vendor. Before you can upgrade you must have PGP key and 2FA Enabled in your profile. Vendor price can be set in marketplace config. The vendor can use any of the coins available to purchase vendor status. Out of each vendor sale, a percentage of sale value goes to marketplace addresses.
Vendor profile customization
Vendors are able to customize their profile with pre-defined profile backgrounds and short personal description.
Vendor levels and XP
Each new vendor starts at Level 0 and progresses further based on performance. XP and the Amount of levels is dynamic and configurable. Multipliers determine how much XP is granted to/taken from vendors for each action. XP is granted/taken by formula: USDvalue*multiplier Example: product_delivered multiplier is 20 USD value of product is 100$ When vendor successfully delivers product, he will receive 100*20=2000 XP This is an example from experience config file: Code: 'multipliers' => [ 'product_delivered' => 10, 'product_dispute_lost' =>20, // How much XP per star (given/taken based on feedback type) 'feedback_per_star' => 2, // how much XP per USD value of transaction (given/taken based on feedback type) 'feedback_per_usd' => 5, ] Feedback
After each completed purchase, vendors are able to leave feedback. Feedback types are Positive, Neutral and Negative and they will affect vendor score as well as product score.
Multiple Coins
Probably the most important system is Coin System. Its completely dynamic, which means new coins can be added at any time. Standard version of marketplace comes with Bitcoin and Monero included. For each coin added, in marketplace config there can be set unlimited amount of marketplace addresses (used for receiving fees from purchases), and in case more than one address is present, address for receiving fee will be choosen randomly (for each purchase).
Product types There are two product types. Physical and Digital products. Based on the type, different options are displayed during product creating and purchase. Both Digital and Physical products support offers and custom units of measure (Item, kg, gram, piece …). With offers, vendors can give discounts on a purchase based on quantity. For example: Price for 1 product is 100$ Price for 10 products is 90$ Price for 20+ products is 80$ Each of those is considered an offer and can be added/removed at any time.
Digital products support automatic delivery which is optional. If checked, the autofill system is used. Each line in textarea is treated as a single item and will be the product’s quantity. It will be instantly sent on the user upon purchase.
Physical products have delivery options. Each delivery option consists of: Name, Price, Expected delivery duration, Minimum quantity for delivery, Maximum Quantity for delivery. Physical products can also include/exclude countries from shipping.
Markdown styling Instead of just plain text, product description and rules support markdown styling. Every tag is supported except URL tag.
Purchasing
When user chooses to purchase any product, he is able to pay with any coin supported by market (and vendor, since vendors can choose which coins they want on each product). There is no wallets or anything similar. Users do not need to keep money on marketplace at all times. For each purchase random address is generated, and its used for that purchase only.
Escrow
Escrow is present on every purchase by default. Upon purchase, marketplace address is generated that will hold funds. If purchase is completed if its marked as delivered or dispute is resolved. If buyer is unhappy with purchase he can open dispute and potentially (based on admin’s decision) get his money back. Upon purchase completion, based on result money will be sent from temporary purchase address to buyer/vendor and to one of the marketplace holding addresses.
Cart
If user wants to buy more than one product (maybe from different sellers too), they can add them all in a cart and then checkout only once.
Messages
Most important feature of messages is security. Marketplace uses latest algorithms and standards in Public Key Cryptography (like XChaCha20-Poly1305-IETF) to encrypt messages between users. Upon registration, Public and Private keys are created for each user. Based on user’s password an encryption key is derived, and that key is used to encrypt Private key, while Public Key is exposed. When user A whats to send message to user B, a key exchange happens. User A encrypts message with User B’s public key, and that message is stored in database. Only user B can read that message when he logs in and decrypts his messages with password. This system makes messages secure and unreadable by anyone, including marketplace administrator or basically anyone who can possibly get access to the database.
Messages are organized in conversations. Multiple conversations can be started at the same time.
Notifications
Users will get notifications for most actions that happen on marketplace regarding them. Some of the examples are: New message, Purchase status update (product sent, product delivered etc.), Vendor actions (Feedback) and so on. They can be read in User Account Panel and deleted at any time.
Bitmessage
Marketplace can possibly connect to Bitmessage daemon. If connected, users can chose to add their Bitmessage addresses and get their notifications forwarded there. This means they will still get notifications even if they are not currently logged in, and they don’t need to refresh anything. Before being able to forward notifications, Bitmessage addresses must be confirmed first.
JavaScript Warning
Optional warning can be enabled in marketplace config. If visitor has JavaScript enabled, a message will be displayed notifying them about security issues.
Support
Users can open support tickets regarding any problem they encounter. Administrators/Moderators will see this tickets in admin panel and can reply, or close them.
Admin Panel
Most of the stuff happening on marketplace can be viewed directly on admin panel. Administrators can access every feature on admin panel.
Moderators Modular permission system is currently supported, which means admins can give/take some access to moderators (For example, support staff can only answer tickets and resolve disputes, community manager can only send mass messages etc.). Currently supported features:
Index – Basic information
Categories – Add/Edit/Remove Categories
Mass Messages – Ability to send messages to users by marketplace (Can be filtered to user groups)
Users – View users, search, filter, and edit each user individually.
Products – View, search, filter by user, or edit product
Log – Activity log of all Administrators/Moderators inside Admin Panel Example:
Bitmessage – Status of Bitmessage service (performs test), and view of marketplace bitmessage address
Disputes – View and resolve purchase disputes
Tickets – View and resolve support tickets
Purchases – List of all purchases
Vendor Purchases – List of vendor purchases
Supported coins
Marketplace currently supports these coins:
Bitcoin – Included in standard version
Monero – Included in standard version
Litecoin
DASH
PIVX
Verge
Bitcoin Cash
Installation
Marketplace installation instructions are included. These are not 100% copy paste but they do explain how must of the things work in detail.
Selling terms and conditions:
I’m selling the only script, I will help you install it with extra charges, edit it or whatever you want to do after you purchase it (I can do this for the right price and if I have time, contact me to check)
After purchase, you cannot resell or share this script
Script is tested for bugs but In case you find any, or any error in code it will be fixed with no additional charge
I will not give you files first in any case. I don’t care who you are, if you don’t trust me we will use escrow
In case of escrow I will deal only with bitcointalk trusted escrow (You can find list here)
Price stated below is for one copy of the script, which means I intend to sell it multiple times. In case you want to be the only buyer please contact me
Current price is: 400$ in BTC equivalent (please note that this can be changed at any time) For this price, you get a standard version of the marketplace with two coins (Bitcoin and Monero). If you want additional coins, they are charged separately. Litecoin, DASH, PIVX are 50$ each, Verge is 60$ and Bitcoin Cash is 90$
Multi-Currency Module Default marketplace currency is USD (converted to crypto at the moment of purchase). This module allows user to select local currency in profile (EUR, GBP, JPY…) and every price on marketplace will be converted to that. This module is optional and priced at 100$
There is 100$ discount available for anyone who bought original script onion eCommerce Marketplace Script In order to apply for a discount, you must sign a message from an address that sent coins for purchase.
