1776 Market: Automated Multi-Signature Escrow

1776 is a marketplace offering a bit more friendly implementation of 3-multisig transactions, we have been chatting with the developer “Tom”, for quite a few months as we worked on this marketplace, ans we are happy to be the first to introduce it now, we have asked the developer to provide us with and overview along with a usage guide of the sites multisig, and here it is exactly as he presents it, so you can be the judge:

What is 1776?

1776 is the answer to the Darknet Markets’ most difficult business problem: theft and fraud.

Many multisig escrow sites have popped up attempting to address this problem. Some require the buyer to get involved in the escrow process. All involve large amounts of fiddly, complicated work for the vendor.
None of them is designed in such a way that they could be a major marketplace in the Silk Road vein. They just expect too much from the vendor and the buyer.

Yours Truly (the author of the 1776 system) was a vendor late in 2013. I lost about $3000 when Sheep Marketplace got hacked/whatever happened.

I headed over to Silk Road’s message board, and posted about a feature that at the time, almost nobody knew about: Multi-Signature Escrow. As recently as last November, almost nobody had ever heard of it.

Within two minutes, my post was deleted. I declined to start using SilkRoad 2, and resolved to write my own system. I probably don’t have totell you that I’m glad I did.

How does it work?

The central design goal for 1776 was to completely secure the escrowed funds from fraud and theft in the most automated, simple-to-use way that could be accomplished. From an interface standpoint, Silk Road is the model.

Buyers never have to understand the escrow, or even know that it exists. When a buyer places an order, they are automatically taken to their orders page, which will show a deposit address unique to that order, and  amount to pay. It also features a QR code to make payment from a smart phone easy.

Within ten seconds of payment being received, the order is marked paid. Buyers need only refresh the page to see that it is awaiting approval from the vendor.

Consider how much more convenient this is than what we’re used to. There is no tedious process of making a deposit, hoping it’s the right amount (due to BTC price fluctuations) two hours from now, waiting however many confirmations the site requires, often made worse by overload-induced lag, then finally placing the order. Making a purchase takes planning ahead to be around your computer for up to several hours. It is a huge hassle. But with 1776, if you know what you want, you can choose the item, enter the quantity and shipping information (which is automatically encrypted for you with the vendor’s public key when you submit it), copy and paste the payment address into your wallet, make the payment, wait ten seconds, refresh the orders page to confirm, and you’re done. There’s not one more thing you have to do until you finalize. If the vendor can’t fulfill the order, your money will be sent to a refund address that you specified in your account settings.

So, unlike other multisig systems, not only is the user experience not more complex than usual, it is actually far more convenient than any other marketplace operating today. The minor amount of added complexity is handled by the vendor. And it is quite minor!

Understanding Multisig

The essence of multisig transactions is pretty simple. An ordinary transaction is conducted by specifying an amount of bitcoins to send to a wallet address, what address to send it to, and then signing the
transaction with the private key of the wallet from which you are sending them. Multisig is simply a wallet which requires 2 or more signatures to do the same thing.

The first question that comes to mind, considering that the signatures are going to come from two different people, is “So where is the escrow wallet then? Is it in the bitcoin network somewhere? If the money isn’t in my wallet and isn’t in yours, where is it?”

The way we create an escrow/multisig wallet is by creating a new wallet address which is in essence the mathematical product of one wallet owned by me, and one wallet owned by you. We give the Bitcoin Core client (which vendors must install) a couple of simple commands to get a “public key.” That public key is put together with the 1776 public key (my key) to create an escrow address. Unlike usual addresses that start with a 1, escrow addresses start with a 3. Here’s an example:

3Cfg5g9f5CVY1MpMigUb6xr322e882NFBN

So, once you’ve got a public key from Bitcoin Core, you enter it on the web site, along with a payout address. When funds are released from escrow, this is where they will be sent. It should not be an address in Bitcoin Core; I strongly recommend creating a blockchain.info wallet (and doing all of the recommended backup procedures!) and sending your bitcoins out from there via the “shared coin” option, which will mix them and make them maximally untraceable.

The back-end engine will see there is a new request for an escrow wallet, and calculate it. This can take up to a minute. Just refresh the page to see the address.

You can also click the “View” button to show you the command you can cut-and-paste into Bitcoin Core to confirm that your public key and my public key do indeed create the specified escrow address.

I mentioned earlier that the buyers send their funds to a unique deposit address for each order. When that deposit receives a single confirmation, the funds are immediately transferred out to the vendor’s escrow wallet. Then (and only then) are you notified that you have received a new order: when the safety of your funds is for all intents and purposes a mathematical certainty. You can verify the existence of the funds by searching on your escrow wallet on blockchain.info.

So, at this point, you accept the orders, decrypt the addresses, ship the product, and await finalization.

I’ll mention here that there are two different methods of creating a multisig address in Bitcoin Core. One is older and simpler, one is newer and more robust. My original development centered around thenewer and more robust command. But in the process of experimenting, I realized that the older implementation was exactly as secure as the new one, did everything I would ever need it to do, and was way simpler to use for everyone concerned. The simple part made the choice a no-brainer.

The other multisig systems require you to modify commands that you’ll paste into Bitcoin Core, or similar. You have to pull your private key out and paste it in to the transaction. Given the state of the art in client software, the newer method is just too darned complicated.

With 1776, all you need to do is this: Your Bitcoin Core software (unlike with the newer multisig) has to actually know the escrow wallet exists. It needs to do the math itself and “realize” that it has one of the keys for this wallet, so it knows what to do when you go to sign the transaction.

The addmultisigaddress command only has to be done once per escrow wallet. Bitcoin Core will remember it after that.

Here we see a finalized transaction ready to be redeemed. It takes the exact transaction that was forwarded to your escrow, and sends 95% of it to you, and 5% to me. Note that I only EVER get paid when you do. Figure I’m honest?

(You can verify what the transaction does by typing “decoderawtransaction ” followed by the hexidecimal string in the box. It will show you where the outputs of the transaction go).

You highlight and copy the contents of the box, then you paste it into the Bitcoin Core console window. It will return another long hexidecimal string. That is the signed transaction.

The quickest way to grab that is to double-click it; it highlights exactly the right text. Hit Control-C or right-click and copy, then type “sendrawtransaction ” with a space and paste the signed transaction in.

Boom – if you have your payout wallet software open you’ll see the funds hit immediately, not when some batch process happens on the server as with other systems but *right now.*

When there is a refund the site creates a signed transaction giving the refund and the vendor signs it and sends it.  Each user has a refund address they must specify in order to be able to place an order, so it is all set up automatically.

Once you are in practice, it should be easy to redeem one transaction every ten seconds or so. Seems a small price to pay for perfect assurance of the security of your funds to me. How about you?

Vendors who can establish that they are established vendors on an existing site will be able to get a free vendor account for one week from launch. During that week, vendors who are not established sellers will be able to purchase an account for $200USD. (All prices on the site are given in dollars and converted to bitcoins at a market price not more than ten minutes old, via Coinbase).

After that week, vendor accounts will probably go up, possibly quite a bit.

I figure I’ll either see you guys this week, or after the next time someone steals all your bitcoins.

Resolution / Support

For now, the buyers don’t have a signature on the escrow accounts.  I’m going to add that functionality soon.  For now, what happens is they send a message to support/dispute resolution, and whatever the resolution is, the vendor and I will sign a transaction that reflects the decision.  Buyers who want to be on the escrow in the future will be able to purchase an account that has that functionality, which will be much less expensive than a vendor account.

XMPP Address

You will notice that there is an XMPP address for your account at the top of the main page. Click the address for instructions on how to use it with Tor. It is a tor-only XMPP system with no connection to the Internet, so it is inherently secure. Users may create any number of rooms for discussion. I offered this because I think it is superior to a message board and because I think the Darknet needs it. I don’t know of another.

The Future

In the near future, I intend to introduce multisigs that include buyers, but they will be special buyer accounts. They won’t be free, but they won’t be nearly as expensive as vendor accounts. I anticipate these being used by people buying very large amounts of product from abroad, for example.

How would you like to be able to export all your orders to a .csv file you could import into any shipping label software you liked? Automatically decrypt all the addresses and get your labels done in five minutes, even if there’s a hundred of them. How big could you grow your operation then? How much less would shipping suck? The capability is already there. I’ll be announcing how to take advantage of it soon.

SECURITY

I’ll give the final word to the security question. First and foremost: there’s nothing to steal. The amount of money in the system is exactly what has come in since the last confirmation. Once any funds coming in get that one confirmation, they immediately go out to escrow wallets. The only sensitive information in the system that is theoretically stealable is the site’s private key. All that would do is allow you to get your funds out of escrow without my help. And by the way, if the site gets taken down, that’s exactly what I’ll do: give you the private key so you can get your money out yourself. That’s dead simple too. Then I’ll set the system back up somewhere else, in some other country, with no real names attached to it, and never connecting to it via any method but Tor. With 1776 credibility intact, we just get back on track as fast as we can, and probably from a very recent database backup. My interests are aligned with yours: I set it up that way deliberately.

The front-end application connects to a back end API. It is the API that talks to the database. There is no SQL code in the front-end so there is no chance of SQL injection attacks. All sensitive operations
are carried out by a completely separate process that doesn’t even know the front-end exists.

All mailing addresses are encrypted automatically when sent to the vendor, all messages sent to vendors are also encrypted automatically. The only messages not encrypted automatically are the ones from vendors to users. If the user specifies a PGP key, it is used. If they have not, it goes in the database as cleartext, for now. In the near-term, I expect to require encryption for users to receive a message even from vendors.

The server has never touched an IP address associated with me, it has been procured anonymously and is not within the jurisdiction of the US government. It contains precisely fuck-all with which a DEA agent could conceivably advance his career, or catch a single dealer. It has no money, no useful data, no connection to any real person. There just isn’t anything to hack– by design.

Hope to see you soon! – Tom

——

Marketplace url is also added to our hidden marketplace list

And this post is added to the Multisig Guides page.

You might also like:

Share and Enjoy