[Discussion] Contract to create web interface code that one can use to sell/buy Nubits with fiat online

You flag the credit card charge.

How do those platforms deal with that in general?

I mean, anybody could fund the account by credit card, buy a voucher and pay at some place with that voucher.
As soon as the one who’s paid with the voucher redeems the voucher and withdraws the money, the platform has a loss if the credit card payment becomes flagged.

If it were that simple, I could collude with somebody. Each of us would then fund the account by credit card. We transfer vouchers, redeem the funds and afterwards flag the each credit card transactions.
We have created a kind of double spend attack.
It must be more complicated than that.
It’s about time I start to understand how those platforms work as what I’ve written above is 100% hypothetical.

https://www.okpay.com/en/business/digital-wallet
"
Fraud is effectively deterred

We understand the risks online businesses face and take all necessary
steps to protect merchants from chargebacks. We verify the identity of
OKPAY users to make sure you only work with legitimate customers.
"

PerfectMoney: No chargeback policy Every transaction in Perfect Money system is final. Guaranteed.

OKpay: To ensure your safety, the OKPAY risk team works 24/7 to prevent chargebacks before they even occur.
Also “Completely non-reversible.

Payeer: ?

Webmoney: not sure

See also comparison of some 30 payment methods in aspects including chargeback risks

https://en.bitcoin.it/wiki/Payment_methods

1 Like

Hey guys! Sorry, got online late today. I’ll probably be on off-and-on for the next 6-8 hours or so. Anyhow, yes, I would absolutely be interested in working on this on a contract basis! Ideally I’d like to do hourly contracting rather than a project bid, as I believe that aligns incentives better to actually get things done: for instance, when there’s a great idea and requirements change after the fact, as always, instead of having a crazy out-of-scope modifications rate like some large contractors which will go unnamed do, being hourly from the start means we try to get requirements right at the start, then I start working on the core things I know I’ll need, and if we want to do tweaks as we go (like add or remove support for a different payment processor) that should be relatively simple.

It’s also lower risk on both sides in my opinion: I don’t invest all the work up-front to make the software (and get tempted to cut corners to be able to pay the bills by getting to the milestone sooner) and the customer doesn’t risk paying for a “completed” project that doesn’t actually work for them when the actual requirements are different from the initial requirements.

I do think the overall estimate is actually pretty good for getting to a working version. I would expect that working at 20-25 NBT an hour, polishing up the requirements and specifications might be around 100-200 NBT, API / payment processor research will probably be about 200 NBT ultimately, writing and doing some basic testing on an internal wrapper library for these payment processors (research if there’s an existing FOSS library which works first, but I’ve often found making my own simple wrappers can be worthwhile; however, getting them to properly handle errors and such edge cases takes more time) around 200 NBT (just spitballing here), and maybe 200 NBT for the configuration and business logic of trades, oh, and maybe 200 NBT for the nu integration, and we’ll put documentation as 200 NBT. So even with reasonably generous estimates, a decent working version (we’ll just throw another 200 NBT for final integration and testing and ass coverage) should be done by around 1400 NBT. So my very rough estimate matches the initial budget estimate here.

I would perhaps suggest a slight change in description / concept of considering me the “development manager” of the project and directly putting the responsibility for the project on me. I understand the desire for verification, but I would think of it as: since this is intended to be an open source release, then part of what I’m agreeing to for acceptance criteria is sort of a “reasonable hacker” standard of: a reasonably competent sysadmin should be able to install, configure, and operate this system easily, that sort of thing.

I can see the logic of an administrator role which distributes funds as I report hours and which does a basic sanity check that I produce what I’m supposed to by the end. And actually, it would be nice to have a second paid person on the project for a tester role. So I can see putting that in there. I just have an aversion to being able to potentially not get paid, or not get paid until the code is perfect. I’m not worried about whether I can produce acceptable working code but the structure of “here are my initial thoughts; build my idea and report back for the money” has always terrified me because of the experience of requirement change and differing interpretations.

Anyhow, I’m still completely new to how things are done around here, just putting out my thoughts on ideal structure. I’d be willing to compromise on a fixed price contract as long as it’s not the open bounty (because of the possible risk of being beat to the punch, and I cannot afford to gamble that much with my income right now), but it would definitely be a hardship for me and would frankly result in a lower quality product without necessarily saving anything. It would however still beat the hell out of going back to killing time flipping burgers, so there’s that. :slightly_smiling:

I do think this is a very interesting project idea. Operating such a site publicly in the United States would constitute a money selling business to the best of my understanding of the law (but I am not a lawyer), but creating the code and releasing it without warranty should be safe I believe. And so long as some people somewhere start using it, then it’s useful.

Also, I just realized I hadn’t been thinking about the advantage of this being NuBits; I’d thought about it so far as a generic cryptocurrency selling/buying site. But the advantage of the NuBits thing is we could make the assumption the exchange rate is always 1:1. xD Personally, I’m enough of a Y2K kid that I think I’d just make the 1 as a constant variable so it could still be modified in a single place if something crazy happened (or for later support of, say, buying NBT with EUR and so forth (with additional modification, but at least already using a constant variable rather than hard-coding the logic of “1 currency unit equals one cryptocurrency unit” everywhere, as amusing as that could be.)).

2 Likes

Thanks for the reply @CoinaDay. There are a lot of similar sites selling bitcoin. We compiled a long list. I think someone who developed those sites should be able to make a Nubits exchange site for 10-20 hours work based on existing code base, including documentation and testing. However although @tomjoad as the outreach manager contacted most of them as I know, we didn’t identify someone who could do the job. So the reason why I put it as a bounty was that we could advrtise and attract offer in a broader community. However the problem with it is that bounty claimers could be someone totally outside the Nu community and is only interested in doing just enough.

It’s very good that you are interested in becoming part of t he community and your cost breakdown is close to my estimate.

@Cybnate set an example of how a manager interfaces deveoper with the community in NuDroid development. I have no problem if you ask for a grant to do the development as long as you keep the community in the loop and installments of payment are tied to measurable milestones.

The Nu shareolders on the other hand would worry about paying and not getting the product. In any case you need to craft a custodial grant proposal yourself and get it approved by the shareholders. As you have no track record in the community you might need a few feedback-iterations to get such request agreed and approved.

It’s great you have thought about it. It’s a tool for a global community.

Nubits pegged to the USD certainly makes such site much easier to make. NuBot and ALP software already get price feeds working so trading NBT with other fiats or even BTC isn’t hugely difficult to code. My main concern is in attacking vectors to such site. An NBT-USD site may be much attack-resistant.

1 Like

Alright, I’ll try it.

There is no possible milestone apart from completion in my opinion, and I will consider support limited and optional after acceptance because otherwise a fixed price development project is suicide. I will be attempting to complete this within two weeks at the very most; ideally within a week. The code should be simple, clean, and easy to review.

I’m not certain yet which language I would use. I usually use PHP for hacking up a site, but for a financial system using its type system seems like a great way to introduce subtle bugs. I’m not a fan of Ruby, or at least its idioms: Rubyists seem to have a fetish for over-complicating things.

This is going to sound really weird, but would you be opposed to the idea of a compiled (or hell, interpreted I guess if a person wanted to get really crazy) C(++) server for it? I’ve never done a web-application in C before, but I’ve done C work and I think strong, explicit typing would be good here. I know web applications can be done in C, and I’ve heard of crazy good performance with it.

The biggest potential problem I think would be it wouldn’t work with some of the more cut-rate hosting, where you just get space for some PHP code or something but can’t run applications or get shell access. Also, the setup I’m imagining wouldn’t work for hosting multiple sites on the same server instance, as it would have the server embedded.

Actually…doing it as a C CGI probably would be pretty clean I think, and reasonably well-supported on hosts.

Edit: Is there a guide for how to draft proposals? I understand the general concept, but I haven’t seen a point-by-point description of how to do it properly and obviously I’d like to be able to get this through as smoothly as possible. :slight_smile: For text of proposal, I’m basically thinking verbatim what you’ve got here with the modification of assigning it to me as developer.

About the best language to use to develop the site, devs like @desrever @CoinGame @woolly_sammoth @willy @woodstockmerkle @ttutdxh @dysconnect @jooize should know better than I do.

Reading past proposals in https://discuss.nubits.com/c/nushares/custodial-grant-passed will help greately. Basically you create a “[Draft] …” for feed back and iteration.

Then when you think it is ready, if you ask for payment upfront, put in an NBT address and an amount pair in the proposal for voting by changing the title to “[Voting] …”, and updating the hot list post optionally. Once there are 5001 blocks voting for it in a continuous 10000 block chunk, the amount is sent by the blockchain to your address.

However if the payment is not upfront, generally you will first make a motion to pass so that shareholders promise to approve your grant request when agreed conditions are met. You will put up grant requests later. Read Standardised Formatting for Motions to learn how to hash a motion.

I agree with all what @mhps said!
I think doing this by motion instead of grant keeps things easier than with a grant.

A grant would most likely require a “fund manager”, because I imagine NSR holders won’t pay you upfront and that’s what would happen, if you draft a grant with 1,500 NBT - as soon as it passes, the NBT are at the grant address.
As a kind of contract is required to allow you to claim money for your services (the grant would do that as well, but with upfront payment), a motion might be more appropriate.
With a motion that passed, the FLOT or any other entity acting on behalf of Nu could pay you for your services after you delivered what you were contracted for.

…just my 0.02 US-NBT.

It is going to be non-trivial to build a profitable service, where potential security issues aren’t even confined to the scope of strictly technical exploits. I won’t worry about what language to use until one can figure out how to deal with the high-level details. People these days just use Django or Ruby on Rails, both of which seem to be flexible enough and offer sufficient safe-guards for hacking.

Now regarding the pay, if indeed the service could be independently profitable, even with a very small profit margin, the 1500 NBT will only be a cherry on top, something to get people interested. If it’s not profitable then it might not be worth the effort nor the bounty. On the flip side, there are many discussions on this forum that lead to some information (though not comprehensively) on how to manage the risks in running a service like this, so you should look into that first.

Draft proposal, although it’s basically just what you wrote above. I read the thread on hashing motions but @assistant didn’t reply to my test message hash; either I did it wrong or it’s down.

@dysconnect, there is a difference between liquidity services and software development. I have no liquidity to provide. I am able to design and build software.

I am aware there are significant security considerations with this. Many of them are external to this project: for instance, an operator of such a site will need to secure their machine to start with which is non-trivial. I am not signing up for operating a service like this. Nor do I expect that my code will be perfect with regard to security but frankly this isn’t an especially complicated task from a security standpoint, it’s “merely” that it’s important to get right.

Edit: Eh, I don’t like calling it not complicated either…I mean, sure, there are interesting edge cases of various sorts. But it’s not like anything here is original research in the sense of solving some problem from an algorithmic standpoint.

A customer can send more funds than the site has available to convert and that will need to be handled. A customer could attempt a double-spend attack with NBT, and so a configurable option for number of confirmations required makes sense. I’m certainly glad to listen to specific concerns.

Can you give a few examples of possible security issues? The usecases given in the OP seem to expose very small attack surface although I think we should look hard into it.

As for profitablity, it’s not in the scope of this project to guarantee profit for the user. But I see almost no cost of running the site except for opportunity cost of funds put into the system and server cost, which is zero if you already has an VPS or run it on a Ras-pi. If set with 2-3% spread, which is normal in the Internet exchange world, profit (not normalized with hack risks) doesn;t seem hard to achieve.

On the other hand profit might not be the goal for some users at all. Nu could use this system to set up many not-for-profit nubit-fiat liquidity providing mini exchanges, the advantage being -

2 Likes

Haven’t had time to read all of the above but I’ve been longing for a direct way to buy Nubit - Fiat and sell Nubit - Fiat without the need of an exchange ever since I’ve heard about Nubits! This would help us out so much and have the additional benefit of us being able to remove the costly support of numerous exchanges in favor of B&C Exchange when it arrives. Customers could use Fiat to buy Nubits directly and then use those Nubits to fund their trading account at B&C Exchange!

5 Likes

This is what makes me hesitate to set this up, although the idea is definitely interesting. Many of these rules apply also in other countries like New Zealand.

Have you looked into Cryptopia at all? I know they operate out of New Zealand (they’re the only exchange for NYAN currently, which is part of my interest in projects like B&C Exchange).

It’s frustrating, because this would be a really cool type of operation to be able to run. I’ve wanted to do “buyabit” concepts and stuff like that before but the legal concerns make it untenable for me.

I should be safe writing and testing it though. And it would be fun to see what experiences people have operating it. I would expect the spread to be relatively small like NuBits typically has, so presumably it would be people with a lot of liquidity for the operation and a lot of volume going through who would do well with it.

A “LocalBitcoins” version for Nubits would be something interesting.

But I dunno what the required changes are…

We’ve got a different situation here…

Although @CoinaDay is gone, it’s still a valid point that contracting a community member to do the development has advantages. So I think I will just ask @desrever @CoinGame @woolly_sammoth @willy @woodstockmerkle @ttutdxh @dysconnect @jooize @Ben and any other developers I missed (and I can only mention 10 users in a post) – if any of you are interested in developing the web-based Nubit-fiat exchange software?

This software is not only a convenience utility to the Nubits seller/buyers. It is potentially as important as the Automated Liquidity Pool (ALP) software that enables individuals to provide liquidity to pegs. The difference is that ALP works for Nubits/crypto pairs on centralized exchanges; this software is for Nubit/fiat pairs on a single web page, taking advantage that there is no exchange rate to track for NBT/USD and no order book is required. The software is decentralized and free from exchange risks. It’s a missing piece of Nu liquidity provision system.

I welcome comments and suggestions on aspects of the proposal – scope, price, should it be a bounty or a fixed price contract offer?

2 Likes

Paging @glv @mably @JetJet13 @peerchemist @sandakersmann @erasmospunk @SigmundAlpha @pennybreaker please read the post above. I can only mention 10 users in a post.

1 Like

thanks @mhps to bump this up . I will add this in the backlog, unfortunately at the moment I won’t be unable to allocate resources to it. I forwarded this post to a friend who might be interested

Personally I think the networks money is better spent throwing it at developing the NuBer LocalNuBits concept I wrote about.

Developing a gateway connected to payment processors puts the people in charge of that service in significant risk. Those processors could choose to shutdown the service, the service has to earn some money for the people running it (harsh truth… it won’t earn them anything. The demand for NuBits isn’t there yet). There’s probably other downsides.

Why does updating NuDroid to assist in becoming a LocalNuBits platform make more sense? Local NuBits traders can trade literally anything for NuBits. It doesn’t just have to be USD… It can be Euro, Yuan, Bitcoins, Ethereum, a car, cookies, cat food… anything. The platform would simply streamline the process of getting someone who wants NuBits in touch with someone willing to trade for them. Any web service connected to the platform wouldn’t actually be involved in any trading, and because of that it’s much less likely to be shut down. Any connected web service would be for metadata or statistics of the LocalNuBits platform. Trading would happen directly between buyers and sellers locally. It would put the legal obligations on the shoulders of the people making the actual trades as well. This would also encourage moving NuBits where we want them. Off exchanges and into peoples pockets where they will most likely use them. Like cash in their pocket instead of sitting on some exchange account (assuming they’ll meet somewhere in public and trade via mobile apps). Even if the mobile app gets banned the apk can still be distributed and installed.

I think there’s a lot more benefit in trying to encourage individuals to transfer NuBits among each other (even personally for goods and services).

4 Likes