Topic: [BTC-TC] Virtual Community Exchange [CLOSED] - page 137. (Read 316534 times)

It works well like that for my real-life trading account for years. I see however how the very shallow market depth on BTC exchanges would be a problem. Ah, hopefully one day...

Terrible idea unfortunately.

Only way to implement it is to automatically buy from Asks (it can't be from issuer - as then it's just a dumb way to replace reinvestment instead of dividends in the contract).  Anyone who knows the time dividends will pay out (including the asset issuer) can then buy up all reasdonably priced asks, relist sky-high and get them auto-sold to those receiving dividends.  Leads to market manipulation and the total inability to make any sense of trading data.

If you want reinvestment you need to either do it manually or invest in assets that reinvest rather than pay dividends as part of their plan.

There's maybe some half-way measure which would work - implementing unplaced orders which will be placed if your balance rises sufficient to cover the order.  That would allow you to predefine what you want to buy (and at what price) when funds become available.  I don't think it's all that useful myself - but can see how some would like it.

What I propose MAY sound just like reinvestment - but it's not.  Placing an order is not the same as reinvestment as there's no guarantee it'll ever get filled.  At best it's an attempt to reinvest at a predefined price.

How about automatic dividend re-investment? I can see it'd be tricky for partial shares, but maybe for full shares?

Sounds good. And the shareholder should only get data he needs to know who owns what shares. no passwords or similar. maybe even no emails so that the shareholder can be identified by the btc address he owns.

at least it sounds like you want to address the problems glbse had. A good sign. lets see what it will be at the end.

I think the current emails every 12 hours of the shareholder lists accomplish most of what we need to protect the issuers and the shareholders.  It's gravy that the asset issuers can get their lists more frequently from the API.  Asset holders also can get their portfolio from the API at regular intervals if they wish. 

The remaining piece of data to protect is the code and data necessary to operate the exchange, which is needed for the shareholders of BTC Trading Corp to protect their investment.  This I suspect we'll end up with once we get a shareholder with significant stake in the company.  (greater than 25% is about where my comfort level is depending on the person.)

Cheers.

That's kind of what I was thinking.  I do replication in MySQL as part of my day job.  It's easy enough to implement.  Still have to find someone trustworthy on the other side. 

I guess the usermoney cant be protected against a scam happening. So the best probably would be to let as less money lie there as you have to. As a user and issuer.

Regarding the asset infos. I read in asicminerthread that issuer can get a full list of shareholders every 5 minutes. That would be a good protection because the issuer than wont have the problem they had with glbse after closing.

Another solution for the asset info could be that a daily, hourly or whatever backup including the asset- and bitcoin-related tables. No passwords and so on. They only would get a zipped file containing sql-statements that can create the tables and fill them with the data. So all shareholders would have the data about the issuer, shareholders, user money and so on. Then in any case it could be reestablished who owned what.

Maybe only shareholders with shares more than 10% should get such backup to protect the users against spammailattacks or similar. But data privacy is another thing to think about. Spreading the emails of all users is a risk in itself.

I think if you dont let much btc lay there and you know that your shares are known more than one person that you trust the risk would be relatively low. (Of course, when an exchange is created only to scam there would be ways to scam. For example sell shares that arent official, sell shares from users and show them they still have them or something. This way one could create more btc than the userbtc stored at the server so that scamming makes more sense. But it looks this can only be prevented when you trust the shareholders of the exchange, especially the boss.)

Thanks!
Sebastian

Unless.....

You can use database replication to a different server also running mysql so there are multiple live up to date copies of the database. This also keeps a binary log of the transactions which make the database current and provide a backup which can be used to restore should there ever be an 'accidental' mass deletion, malevolent hack, etc.

If different people are in charge of different servers then this would solve the potential issue of one person preventing acess to the data so long as the replication is kept running.

If all the data was deleted deliberately then it would also be deleted from the replicated server but it can be rebuilt using backups and the binary logs with mysqlbinlog.

This is not entirely straightforward but it can be done by someone with some mysql DBA experience.

Moving this over from the ASICMINER thread: https://bitcointalk.org/index.php?topic=99497.960


Good points for sure.  I don't want to go into too much detail, but it's definitely different for me than it was for Nef.  I already have a full time job that I love and will not be giving up.

This exchange started as an LTC exchange with no intention of going into BTC.  That alone should speak to my motivation, as it was just a fun project, a labor of love, and most certainly was not going to make anyone much money. 

I tried to sell the code to run the BTC side of the site a month or so ago when GLBSE failed.  I didn't really want to be the figurehead of a BTC project.  I just wanted to be the part-time programmer.    The fact though is that GLBSE's failure presents a great opportunity and if someone wants to invest and buy a chunk of the exchange, I'm all for it, and if that person is a well respected member of the community, all the better.  And if that person wants to do the AML and register their shares, then I'm definitely on board with giving up some control.  I believe the exchange needs ~3-5 such individuals to last long term.

On the server side of things, the comment about the database password... I'm not sure how you protect against that.  Anyone with root on a box has the ability to lock out everyone else.

Cheers.

Ok i will give more time to devellop the contract...When I will have the time

Let it active then but I wont issue any shares until vote NO is at 0... Not willing to give bad image to my company for that. Let users shareholders decide then if Esecurity have to be traded in btct or not... Just a bit surprised the other security have 4 vote when i got 10...also 6 NO... Its just showing most shareholder never vote yes, but vote only no...Anyway I didnt expected so much bad vote and Im little bit angry to be honnest... I will give some effort but dont expect so much from me then as we each know its mainly useless to change contract...No vote will stay and I will not trade the bond, actually I see it like a waste of time, so I wil edit it when I will have some time to waste myself...

GLBSE asset issuer transition plan is up at: https://bitcointalksearch.org/topic/glbse-to-btc-tc-transition-import-strategy-for-asset-issuers-127215

Ok, got the google auth setup fixed so it displays on the first load.

The issue was that on the first load it was updating db settings, but not updating a couple of required variables that are used later on to display the QR code.

The next load the required variables would come out of the db no problem. 

Cheers.

Thanks for the bug report.  There's definitely something wrong with it.  It should be displaying the QR code on the first load.  Looking into it...

Thanks a lot, that solved the issue

Refresh the page and scroll down again and it shows. Make sure you test it in another browser first before anything.

If you want to use multiple 2fa accounts you need to enter the code manually not scan it.

I tried enabling Google2FA, well actually, I enabled it.

I checked the box, entered my pin, had my phone qr scanner ready, was redirected to my account page with the following message on top:

Google Authenticator enabled. MAKE SURE YOU HAVE SCANNED YOUR CODE BELOW!

So I scrolled down to the bottom of the page where it says:

Display Google Authenticator Codes

But there is nothing below it and you can't click on it either

I guess I could/should have scanned the code before although I am not sure how I could have missed a big QR code on the screen.

I don't want to register a new user... any ideas ?

P.S. This is on Windows XP with Chrome

 

Well handled, sir, well handled.

The users get prompted to vote again on the portfolio page when the contract is changed.

I don't really want to get involved with the voting process but you don't have to swing a lot of votes.  Swing one NO and get another YES and you're in good shape.

If you still want to pull the asset, I will, but it may be worth giving it a little more time & energy.

Im surprised you got so many downvotes. Perhaps people will reverse their vote since you fixed the contract.
I hold a few esecurity bonds so if people want exposure/proxy to it they can buy bitcoinrs. 

Could you delete the security ( Esecuritysabtc) I created and being in waiting approval. Got 6 bad vote ( my fault as some mistake in contract) anyway it will cause more bad image than good to my company. Better I leave Btctc for the btc bond and will focuse only on cryptostocks as already started there.

You can also keep the 5BTC fees, its my mistake and I not complaining, just acting for the good of my company.

Regards, Neotrix