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!
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:
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.