Recent Posts

Pages: [1] 2 3 ... 5
1
Looks like this will have amazing functionality. Any updates about this project, Vespco?
2
News / Re: Development update: 3 months
« Last post by Vespco on January 15, 2018, 03:49:13 AM »
Yes definitely. I am working on getting it setup on taiga.getmonero.org to help get more attention to the project and to have more input.
I need to define how the multisig is going to be implemented. I'm still not sure the best/easiest way to do it. Seems like a nice multisig feature for bitcoin was ever worked out.
3
News / Re: Development update: 3 months
« Last post by danfossi on January 12, 2018, 10:50:17 AM »
In the last few weeks I have been a bit busy with the work and I have not been able to publish new updates but I constantly follow the development phase.

Unfortunately the implementation of new features in the back-end proceeds a bit slow .. I have to study a lot before each commit.

At the moment @serhack is busy with Mastering Monero and all the contacts I have received in the last months are almost all end-users or testers but no developer ..

Your words, however, encourage a lot knowing that the hard work done in recent months has encouraged some real developer to give us his contribution.

It's just an opinion but I think that:
* Having a well-defined official roadmap could simplify the work
* Some news (maybe via social) about the progress of the development could intrigue some developer / tester more. From that point of view at the moment the project seems a bit 'in a state of neglect, even if in reality it is exactly the opposite ..
4
News / Re: Development update: 3 months
« Last post by Vespco on January 09, 2018, 11:42:46 PM »
Wonderful! Checking it out now.
Going to get more involved. Been crazy busy with life but I am more then happy to help test bugs and everything else I can do.

Also I'm in contact with humancell and they're going to add massive support to this project soon. It is very exciting times!
Thank you for the update and demo. Really appreciate all the effort that has been put forth for this!
5
News / Re: Development update: 3 months
« Last post by danfossi on January 07, 2018, 02:30:36 PM »
Hi all,
in the last months together with serhack we worked behind the scenes,
unfortunately still a lot of work is needed before you can release a working beta,
especially if the market wants to respect the features and security standards proposed by Vespco in the last post (see here: https://annularis.org/forum/index.php?topic=73.msg96;topicseen#msg96).

For those interested, I set up a demo with the latest changes:

URL: http://51.15.6.88
----------------------
User: Admin
Pass: masterpass
Role: Administrator
----------------------
User: Vendor1
Pass: vendor1
Role: Vendor
----------------------
User: Buyer1
Pass: buyer1
Role: Buyer
----------------------

Note:
* The addresses of the wallets are Bitcoin and NOT Monero (even if XMR is written!),
In the last commits (before the new TODO by Vespco) we were removing the bitcoins from the front-end.
* Any bugs must be reported on the github
6
Feature Request / Good list of Marketplace features we should have.
« Last post by Vespco 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.

https://www.reddit.com/r/DNMSuperlist/wiki/superlist/market-listing-criteria

  • 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.
7
News / Development update: 3 months
« Last post by serhack on December 16, 2017, 07:46:38 PM »
Hello guys,

I was busy with my others projects: Monero integrations and Mastering Monero ebook.

Enjoy the new UI

8
Member Introductions / Re: Interested in helping out
« Last post by Vespco on October 08, 2017, 08:35:09 AM »
"We could have solutions in place so that the software takes a percentage of commissions to donate to charities by default. "
Not really possible..it is free and open source code, anyone can change it so the funds are allocated to just seller and marketplace.
I would rather have this just be a tool for people to use, and then they can opt into whatever they like, such as if they want to donate. The goal of this is privacy, security, etc -- forcing a percent to be donated, or even encouraging that potentially jeaprodizes such goals.

What are your motivations for building crypto marketplace software?
My honest answer is I'd like to lower the barrier to entry for people who want to start darknet marketplaces, and for it to act as a nucleating point for various libraries related to cryptocurrency and other privacy-preserving tools. Hopefully, we can create some Monero PHP libraries that get used in other software.

There is maybe a more moderate answer about helping grow the cryptocurrency economy, but for me it's not about that, it's about providing a tool that gives people power.


Is this a political statement to you? Or is this more of a technological statement?
Both, but ultimately the tech interests me because of political views. I am not sure how you mean technologically - as tech isn't interesting without considering it's implications/utility.


How have you stayed motivated for so long?

Idealism and positive reinforcement.
However, it is important to note that I have lost interest in this one fewer times than I have been interested in it:

Bitwasp idea originally came about in 2012, flopped because no one had any real interest in it. Then when silkroad got shut down - everyone had a huge interest in it which revived it - which we made another attempt at it again, got pretty far and then it just flopped again thanks to loss of interest due to the OpenBazaar hype.
Additionally, I had become a bit disillusioned with bitcoin since it was so public and had so many issues. Monero inspired me again, and so I figured: hey, let's revive this yet again because I really do want an open source, free marketplace software available. It seems like this project teeters on people being just enough interested to help, but that it really struggles to get good traction. I have way more experience with fundraising, developing software and networking with reporters, ec than ever before, and we're closer than ever before - so this time it should be a home run. Hopefully then we'll see it get more traction and others actually using it, developing addons/apps for it and so forth.



Is this something that is still in progress? Or am I just replying on a dead forum?
Still very much in progress, we're doing some stuff behind the scenes with Monero's RPC and figuring out how to do multisig -- it's a bit of a hold up because the multisig RPC isn't merged - we're developing with what exists currently in a branch, but

What are your goals for this project? What do you want from it?
A very secure, actively developed free and open source privacy oriented monero marketplace software that anyone can setup and use, and that helps to build various libraries for Monero, and other privacy-preserving tools.

That's both the goal of the project and what I want from it; I like to be involved with such a thing.

How concerned should we be about security around here? While we're not technically doing anything illegal, it's definitely something that's looked down upon. What are you opinions on best practices while browsing this forum?

Depends on who you are: if you're a software developer, it likely is fine to be public: I believe the previous coder, afk11, basically got a pretty good job out of it since his coding/efforts were noticed. 

The flip side to that has I had a very involved death threat come to all of my emails/fb/etc after posting about this project on the SR1 forums the first time.
Law enforcement is probably lazily watching it, or will be able to look at stuff retroactively via google cache, etc

Ultimately, you have to decide for what you are doing with it, who you are, your intentions, etc. I have obviously opted to attach my real name to it.
9
Feature Request / Re: Let's ditch the 2-2. 2-3 represented instead.
« Last post by Vespco on October 08, 2017, 07:49:28 AM »
Both will be available. It is open source and an on going project but 2/2 multisig for monero is further along and easier to implement.

In a 2/3 the marketplace would be the third signer.
10
General Annularis Discussion / Great news! RPC API for Monero's Multisig exists.
« Last post by Vespco on September 27, 2017, 11:02:27 PM »
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:

Quote
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.

    NOTE:
    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).
- https://github.com/moneromooo-monero/bitmonero/commit/b99bd7eecf86738d08bceb40cc6b29c9db335a2f

So:
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. :)
Pages: [1] 2 3 ... 5