Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Vespco

Pages: [1]
Feature Request / Good list of Marketplace features we should have.
« on: December 22, 2017, 06:44:01 PM »
I found this list and think it has provided some rather good suggestions for features of a privacy preserving marketplace. I've copied the feature list that I think apply to developing annularis.

  • You must implement 2-of-3 Multi-Signature.

  • No JavaScript on your market, except for warning users to disable JS if they have it enabled. If the user has enabled JavaScript while visiting your main page, he must be prompted a warning to set the security slider of the Tor browser to high along with a short description of how to do it.

  • Users have to set their public PGP key on their profile before they can make his first order.

  • You must offer all users 2FA with PGP. It has to be enforced for all vendors.

  • The PGP encrypted messages used for 2FA must contain a phrase similar to: 'Only valid for <all valid market addresses>' along with the default random passcode. If 2FA is set, the users should not be able to circumvent it and always be required to enter their password and the decrypted PGP passcode. Furthermore can the encrypted 2FA passcode only be valid for one login.

  • When a vendor wants to change his PGP key, he has to sign it with his old one. You can also display this signature publicly for users so they can check themselves that the vendor signed his new key with his old one.

  • Buyer and seller accounts are different. Buyer accounts cannot become vendor accounts.

  • The order notes, or whatever the message to the vendor is called on your market in which the customer sends his address to the vendor he is buying from, must be PGP encrypted by the user. If it is not, reject the message and tell the user that he has to encrypt his address as well as other sensitive data before sending it and link him to guides on how to properly do it. The checking can easily be done by looking at the beginning of the message and checking if it is the default string of PGP encrypted message (i.e. '-----BEGIN PGP MESSAGE-----').

  • Delete private messages and order details after a certain time period (not longer than 2 months).

  • Use of CSS to prevent reloading pages for small clicks. For example realize some functions like collapsing or expanding a box with CSS instead of reloading the entire page with every click.

  • For country drop-down lists: put the for example 3 most selected ones on top of the list and sort the rest to alphabetically. That way a good chunk of users do not have to scroll down to "United States" for example.

  • make page sizes as small as possible for quick loading.

So, after serhack had updated the older dilapidated bitwasp software into the Annularius Marketplace software and fixed a bunch of issues, we decided that the best approach was to wait until Monero had an RPC API for multisignature addresses and transactions. 

This is because doing a PHP library for monero multisig would be too complicated and have some interesting security risks if it weren't implemented properly.

Well, thanks to the amazing work of MoneroMoo, the RPC API  for multisig now exists so what we'll need to do now is integrate that and we'll have a MVP for Annularis as a monero multisg marketplace! :D

So, the multisig works as described here:

Multisig for RingCT on Monero

    2 of 2

    User A (coordinator):
    Spendkey b,B
    Viewkey a,A (shared)

    User B:
    Spendkey c,C
    Viewkey a,A (shared)

    Public Address: C+B, A

    Both have their own watch only wallet via C+B, a

    A will coordinate spending process (though B could easily as well, coordinator is more needed for more participants)

    A and B watch for incoming outputs

    B creates "half" key images for discovered output D:
    I2_D = (Hs(aR)+c) * Hp(D)

    B also creates 1.5 random keypairs (one scalar and 2 pubkeys; one on base G and one on base Hp(D)) for each output, storing the scalar(k) (linked to D),
    and sending the pubkeys with I2_D.

    A also creates "half" key images:
    I1_D = (Hs(aR)+b) * Hp(D)

    Then I_D = I1_D + I2_D

    Having I_D allows A to check spent status of course, but more importantly allows A to actually build a transaction prefix (and thus transaction).

    A builds the transaction until most of the way through MLSAG_Gen, adding the 2 pubkeys (per input) provided with I2_D
    to his own generated ones where they are needed (secret row L, R).

    At this point, A has a mostly completed transaction (but with an invalid/incomplete signature). A sends over the tx and includes r,
    which allows B (with the recipient's address) to verify the destination and amount (by reconstructing the stealth address and decoding ecdhInfo).

    B then finishes the signature by computing ss[secret_index][0] = ss[secret_index][0] + k - cc[secret_index]*c (secret indices need to be passed as well).

    B can then broadcast the tx, or send it back to A for broadcasting. Once B has completed the signing (and verified the tx to be valid), he can add the full I_D
    to his cache, allowing him to verify spent status as well.

    A and B *must* present key A and B to each other with a valid signature proving they know a and b respectively.
    Otherwise, trickery like the following becomes possible:
    A creates viewkey a,A, spendkey b,B, and sends a,A,B to B.
    B creates a fake key C = zG - B. B sends C back to A.
    The combined spendkey C+B then equals zG, allowing B to spend funds at any time!
    The signature fixes this, because B does not know a c corresponding to C (and thus can't produce a signature).

The seller will join, and create a spendkey (c,C) on their own. They'll give C to the annularis marketplace implementation.
The buyer will join, and create a spendkey (b,B) on their own. They'll give B to the annularis marketplace implementation as well.
The marketplace will combine them to form the multisig address: C+B, A.
The buyer will recieve this multisig address and pay to it.
The seller will then sign this transaction to recieve the funds
The buyer will only sign it if they have recieved the products and are happy with it: otherwise, they'll have to work it out or no one will get any money.

I'm going to talk to serhack, he's probably pretty busy with all that he does for monero and the monero integrations, but hopefully this project will begin moving forward again soon. :)

Coding is probably the best way to help. If you can code or do design, get in touch and we'll discuss everything with you.

Another way is to interview us. If you write for magazines, journals, podcasts. vlogs, etc. I am very happy to be on audio/video interviews or answer any text questions you might have.

You can donate to us here:

Monero Public Address:

Monero View Key:


If you have other coins you can donate via -- We will receive the payment in the form of Monero.

We will generally convert the Bitcoin to monero or use bitcoin first for costs such as hosting, development, and so on. I think the value of monero is likely to increase more than bitcoins so it is preferable for us to hold.

I will also setup the ability to donate via credit card using Stripe. If you want to do that now, contact me.

We're not really asking for any financial donations yet, just posting this so I can link to it on the forum. 

There is a good chance we're going to do a Monero FFS -- so you may want to donate that way. I believe it has mile marker payouts and so it will have more accountability.  Keep an eye on this post and we will update this with the FFS link when we move forward with that.

General Annularis Discussion / Annularis Mission
« on: July 07, 2017, 05:47:20 PM » has the explicit goal of creating & maintaining free and open source marketplace software that above all else preserves the privacy, security, and anonymity of all users.

Preserving privacy, security, and anonymity is the primary goal. The secondary goal is to focus on ease of use for all parties. This includes making it easy to setup an instance of the Annularis Marketplace Software, easy to join, and easy to buy and sell items.

If ease of use features conflicts with preserving privacy, security or anonymity they will either not be implemented or be implemented in such a way that the users can disable them without losing functionality.

Privacy is addressed by use of GPG encryption of messages, shipping addresses, and two-factor authentication. Additionally, it will use 2 of 2 multisig by default as that further preserves information between buyer and seller without providing additional data to the marketplace administration or other escrow agents.

Security is addressed by using 2 of 2 multisig "escrow" between buyer and seller. This prevents collusion which is possible with 2 of 3 multisig. We are also exploring implementing an M.A.D, NashX styled transaction system to ensure that the winning/dominant strategy is to cooperate and not attempt to scam.

Anonymity is addressed by using Monero, encryption of shipping addresses and ensuring that the default installation of Annularis is compatible with Tor and other anonymity networks. "Compatibility" in this instance means that it does not depend on Javascript, or have data-intensive graphics since anonymity networks are often slow.

To further preserve anonymity, security, and privacy, Ring signatures will be researched as an option for the rating system: ring signatures will allow for a rating system that has verified users but without revealing which buyer or seller left the rating. This will reduce opportunities for sellers, site administration, or buyers from attempting to blackmail one another due to having potentially sensitive information such as their order history and shipping address.

Pages: [1]