Following our recent interview with the founder and developer of the Bitwasp software, we were just told that the new version is now released and is offering built in multisig transactions, this is pretty good news as we know this software is being used from time to time for marketplaces and had some history of getting hacked with all the bitcoins stolen – so with this new multisig feature we could at least not worry about this part, this is a repost of the announcement from the bitwasp forum + the guide for using multisig transactions, you can find the original thread here: http://bit-wasp.org/index.php/topic,215.0.html
(The Guide is after the announcement )
Folks, it’s time at last. Announcing Bitwasp, the marketplace that stores no user funds.
I’ve spent a lot of my recent time working on this code in the background, not posting to Github. There wasn’t much I could say, since rebuilding the project was a huge undertaking, it didn’t justify posting incremental, broken commits to Github. It needed to be fairly well tested, and I’ve had to work on things like OP_CHECKSIG functionality, rewriting the system so it used a scraper rather than relying in incoming wallet transactions, and refactoring the order system.
Since most of you are familiar with the live-wallet version, I’ll describe what’s new:
- No more ‘Bitcoin’ link on the navigation panel.
- Instead of giving funds a regular address to pay to, which enables all sorts of scams, and can lead to theft, multisignature transactions are now standard, for up-front payment or escrow.(***)
- Administrators must enter an electrum master public key(*) to derive addresses for registration fee payment’s, and keys for multisig addresses. Let me just say now that this is what attackers will be trying to change. Secure your admin account with 2FA.
- Vendors can enter a list of public keys(**) in advance of accepting orders, or will be prompted to enter keys if they have none available when creating an order.
- Buyers must enter public keys on a per-order basis(**).
- The order process in the old version pretty much just moved around magic numbers (user balances) in a database to grant entitlement to coins on the wallet. Now, once funds leave a multisig address, they pay directly to the users key that was used to create the address.
- Users need to sign multisignature transactions. I’ll explain in detail below…
* It isn’t my intention to force people to use a particular client, however electrum is the only deterministic key derivation algorithm that sees mainstream use. (**)
** – Forcing users to enter a list of keys, or individually, or solely from an MPK, sucks. However, this is an acceptable solution until clients adopt BIP32, which will be the case for the next version of electrum, and eventually all the others as well.
*** – Since vendors/buyers can go missing during an order, 2 of 3 multisignature addresses are used for escrow and up-front payments, so funds are recoverable.
I will post the code onto github shortly once I finish a few small bits, and get it presentable.
Pushing code to github does NOT mean it is a tested, vetted, and definitely working version – the software really needs to be reevaluated now, since I’ve recoded a vast amount of it.
So, whats multisig?
Multisignature addresses are addresses controlled by more than one person. They are created with a set of requirements, that dictate how the funds in the address can be moved.
2-of-3 signature addresses are jointly controlled by 3 people, say the site operator, the buyer, and the seller, but funds can only be moved if two people authorize and sign a transaction.
Users will be expected to sign transactions for themselves. While client’s leave much to be desired regarding support for multisignature transactions, I believe the best way to increase their adoption is to bring them into day-to-day life, and watch the situation improve from there.
Currently, the only unmodified client which supports signing multisignature transactions is Bitcoin Core. Otherwise, users can use an offline copy of https://coinb.in/multisig to sign in their browser.
It sucks that Bitcoin Core is the only client that lets us do this. I’m very much looking forward to a light client that supports it out of the box.
Training users to use multisig
Multisig can seem complicated, but I’ve done what I can to make the process as smooth as practicality and security allows me to.
I have decided against allowing buyers to click to sign with the Administrators key. The reason for this, is that it undermines the assurances that come with multisig. Buyers will be expected to sign
Completing an order doesn’t require many complicated steps at once, but rather it is a gradual process where users are guided doing the transaction. If users have any experience with an electrum offline wallet, the process is very similar – Take unsigned transaction, sign, broadcast. I will create a document later which outlines the process using Bitcoin Core.
Step 0: Buyer choses their items, as normal. When they’re ready, they enter a public key, and their address, and confirm their order.
Step 1: Vendor has a new order, must decide if it’s escrow, or up-front, based on ratings. The vendor has probably entered public keys in advance, but will be prompted to do so if not.
Step 2: Awaiting Payment: Once the order is accepted by the vendor, and the terms are selected (up-front or escrow), the multisig address will be created, and available to all users. A redeemScript is given, allowing users to verify that the address is one they have control over (contains their public key). The buyer needs to pay to the address to continue.
Once Bitwasp has seen enough incoming transactions to this address to cover the order, it will progress the order to the next step, which is signing. First, both users need to import the address to their wallet. A copy/paste command is shown to help them with that.
Step 3: Up-front order’s only – await buyer signature. If the order is up-front, then the buyer signs the unsigned transaction. They paste the partially signed transaction onto the order page and submit, where it will be verified, and the order progressed to step 4.
If the order is escrow, then the process skips this step, and the vendor signs/dispatches first.
Step 4: Waiting for Vendor to deliver goods. The vendor signs to indicate they have dispatched.
If the order is up-front, then the vendor will now sign, and broadcast the transaction. Once Bitwasp see’s this transaction in the blockchain, then the order is moved to step 5.
If the order is escrow, the vendor will add the first signature to the transaction, and paste the partially signed transaction onto the order page.
Step 5: Order has been dispatched. Await buyer to sign & broadcast (Escrow), or click Received (Up-front).
If it’s up-front, the buyer simply clicks the ‘Received’ button, and the order is completed (step 7). Otherwise, the buyer can raise a dispute.
If it’s escrow, when the goods arrive the buyer signs & broadcasts the transaction paying the vendor, the order is marked as completed (step 7). Otherwise, the buyer or vendor can raise a dispute.
Step 6: Disputed Order
If a dispute is raised, and the order was escrow, the administrator will be able to craft a new raw transaction, which pays the buyer/vendor an appropriate amount at their discretion. Ideally, both users should be satisfied with the outcome, but the admin can sign, and wait for the second signature, and the transaction to be broadcast, before the dispute is automatically closed, and the order marked complete (step 7)
If the transaction was up-front, all the admin can do is close the dispute, and mark the order as complete.
Step 7: Completed Order
At this point, the buyer and seller will be asked to leave feedback for the other party.
A buyer will leave feedback for the vendor, and then the items.
A vendor will leave feedback for the buyer.
If the order was disputed, this will mark each review on the page as Disputed, allowing users to read what happened.
Vendors can rate buyers on qualities like Cooperation and Communication, from 1-5. I want feedback on the community on this, and what people should be rating!
Buyers can rate vendors on qualities like Shipping, and Communication, from 1-5. They also rate the items on an order, on qualities: Item Quality, and if it Matches Description. Again, I need feedback here.
When buyers leave feedback for an order with more than one item, they can choose to rate all the items with the same score, and comments, or else fill in ratings/comments individually.
All users can leave comments about the vendor/buyer/item. These can be from a list of prepared statements (to mask people’s writing styles), or else a bespoke comment can be written. Also, feedback takes on average 12 hours to show up – All feedback will have a timestamp of 12pm the following day, so they appear in a batch.
I need to write up an article describing the commands to actually import, sign, and broadcast the transaction.
Transactions are created by the bitwasp software, so mostly its a case of pasting the unsigned/partially signed transaction into the bitcoin console, taking the output, and pasting to the site/broadcasting it.
I need to work out the best solution for admins. Keys are generated using an electrum mpk, but electrum can’t sign transactions it produces.. I think admins will likely need to run Bitcoin Core on their own computer, dump the private key from electrum, import to Bitcoin Core, and then sign. Otherwise, they can use coinb.in.
Once this gets adequate testing, things will be looking good. The code will start to become mature, and I can mop up the outstanding issues posted on the forum.
I want to try and remove Bitwasps dependency on BitcoinD. There’s nothing I can do about the clients users use to sign, however I hope to find a way that allow it to run off an API, if that’s what people want.
What I really need now is for developers to set up a copy, test it on the testnet, and work with me to finish the software, and take it to the next level. You all know it’s just me working on the code, but this project will only reach it’s true potential with help from the community. It’s got to be more give and take, so I’d ask if you’re considering to use Bitwasp, that you actively participate in it’s development, or donate to us here: 19EkDTAaGWySZv1QsWxyWwYMZpo7jpvPYe. The project isn’t ready for mainstream use yet, and we want help to accelerate things.
This is a guide to completing an order using Bitcoin Core, via the Help->Debug->Console window, or bitcoind using the command line. The commands entered at the bitcoin core console can be run just the same by doing: bitcoind <command> <arguments>
As a buyer confirms their order, they are asked to enter a new public key, and their order address.
To generate a new public key using Bitcoin Core, run the following two commands
> validateaddress 1HpCq3FVZf4UDvPjFSCz1V4aLMijdfKjfK
"isvalid" : true,
"address" : "1HpCq3FVZf4UDvPjFSCz1V4aLMijdfKjfK",
"ismine" : true,
"isscript" : false,
"pubkey" : "03ff0d9f8332ca6261739901fac22b520921ca370d98a354467a2ea6d2c93520cc",
"iscompressed" : true,
"account" : ""
Vendors are able to upload several public keys at a time, by running the above commands several times.
If no keys are available in the vendors list, they will be prompted to enter some before they can accept an order. At this time they choose if the order should be escrow or up-front.
Once the order is accepted, the multisignature address is generated out of the buyer, vendor, and administrators public key. The administrators public key is generated from a master public key.
The buyer must pay to the order in order to progress to the next step.
Once the order is paid in full, a raw transaction paying the vendor/admin is created.
(If the order is up-front, the buyer will be asked to sign the transaction first)
If it’s escrow, the vendor will sign. Once the vendor signs, they are indicating that they have dispatched the order.
In order to sign the transaction, you need to add the multisig address to your wallet. This is done by copy/pasting the command shown on the order page into the Bitcoin Core console:
addmultisigaddress 2 '["02eec4737ddb62092d8b4834022ae41cf9af4faee9cc25b9b5c553eaa07d98a3dd","026d017c249eae64b039f3cb33c913a6f8762198d998cf03f440b66622bdb2c75c","04eadc08c551774e82a9869dc6279d96d66920a0ccdcd6ac94ebaa11aa33827c21096e2ec974d21411c653d8d60cca06936523fa2774f237a2c347ffdb3b1147aa"]'
In order to sign the transaction, an extra JSON field is supplied as well as the raw transaction. This is required, but is automatically generated. Whenever a user is asked to sign a transaction, they can copy/paste the transaction into the console, and prefixed by the command ‘signrawtransaction’.
Once the transaction is partially signed, it needs to be passed to the other user to add the final signature. Just paste the raw transaction hex back onto the site and submit.
Once the buyer receives the goods, they can sign and broadcast the transaction.
The entire process guides users towards this final end result: the transaction leaving the multisig address:
If there is ever a dispute along the way, the admin will be notified, and the users will have a chat thread to discuss the situation. If the order was escrow, the admin can create a new transaction. If the order was up-front, there is little the buyer can do unless the seller cooperates.