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

Didn't know that.  Thanks

The value/share is not included in the email, but the comment for coin transfers. The value/share is shown in /csv/trades though.


Agreed.

I mentioned this to burnside before and he explained that the "pending" disappears automatically after 3 confirmations, but the money isn't credited until a cron job is run.

I've seen that before, but this time the pending deposit notification disappeared after 3 confirmations. 

Click the refresh button next to your balance on the Wallet page. BTCT is sometimes a bit slow to update your balance after the 3 confirms.

Anyone else having deposit issues this morning?  I sent a deposit and it's had 3 confirmations, but isn't showing in my deposits or as a pending deposit on btct.co.

Thanks,
Dave

Is it also for the recipient? I use the same email-address for my dummy-account and I only got one email when I tested it (asset-transfers are reported for both sender and recipient), while I couldn't find an email from the time that I actually received a coin-transfer from someone else.

The workarounds are getting more convoluted by the minute

True, but it's in the email notification.

Another possible workaround could be to abuse the "value/share" (attribute "tsfr_price" for sending, shown in /csv/trades on the receiver side) attribute as challenge token: 1. User initiates transfer by submiting a request with number of shares and involved accounts, 2. Issuer responds with "k, send it with the value 1.123252", 3. User initiates the transfer with exactly this value and amount of shares etc., 4. Issuer matches incoming transfers to open requests and initiates the exchange.

Though I feel like adding the address as optional parameter for transfers is the safest solution right now and probably the easiest one for burnside to implement. It would require a signature verification on receiver side and a signature generation on sender side, but I think this is not such a big deal.

In principle you could automate the entire process this way. I had only thought of the 1 satoshi transfer as a means of proof that the specified account name is valid.

However, I just checked both the BTCT website as well as the API output and it seems that the provided comment isn't shown anywhere. So you can send a comment (so I guess it's stored somewhere), but the recipient can't see it (unless I'm blind). So that spoils that plan for now ^^

Maybe it wasn't clear, but I do transfers at the moment only manual, because I want to be in control, but I see no reason to not automate the above stated solution.


Great idea, I'll keep that as plan B. Thanks for the input by the way! Hm. Not sure where manual labour would be invovled here? Both the transfer of shares as well as the 1 satoshi transfer with a comment can be initiated/fetched via the current API endpoints on both sides (i.e. issuer and user).

I see. But your solution still involves some manual labour, since you do some verification manually.

With my proposed solution of adding your LTCG username to your BTCT account (and vice versa) (using OAuth to authenticate this link), the transfer-process can be automated entirely. My transfer-software already does cross-exchange transfers, but it relies on an external usernames-database, that has to be populated manually, to link two accounts together.

An alternative that is already available (but still involves some manual labour) is for someone to send you their LTCG username as a comment with a 1 satoshi internal coin-transfer on BTCT.

From my end the problem is the following: a user initiates a share transfer by writing a message like "please transfer 250 shares from LTCG account X to BTCT account Y". It doesn't matter, if this is done via PM or a webform. After that he sends the shares to my receiving account. From my point of view I have the following data: the information he submitted and the amount of shares tranferred as well as the sender username from where he sends the shares. If the provided information doesn't match with the incoming transfer (e.g. wrong sender username, not the same amount of shares, timing), the request will be rejected.

I verify this manually to minimize the risk of a villain hijacking the process, but it's not a bullet proof solution. How can I be 100 % sure that the user who sends me a message with a transfer request is the one who transferred shares to the exchange account or what ruleset could I implement to be 100 % sure?

This is where the authentification/verification comes into play. If the address is included I could request a signed message from an user who initiates a share transfer. By verifing this message I get to know his address and thus I can verify that the user is who he claimes to be or be sure that he is the legit owner of that public address. Even if a villain knows how many shares are to be transfered as well as when and from which username or address, he is still unable to generate a valid signature for this address, if he doesn't have the private key to generate the signature.

I can then very safely assume that a "transfer to username/public address" wasn't hijacked which would give me the confidence to implement an automated share transfer service.

An altnerative approach to the username/address linking would be to allow users to link two accounts on both exchanges. Right now there is already some sort of linkage possible for LTC-Global moderators with a BTCT account. But I imagine extending this to provide an OAuth authentication path, where you go to BTCT, click some "link LTC-Global account" button somewhere, it then requires you to authenticate with LTC-Global via OAuth, after which the BTCT callback can use the "get_portfolio" OAuth API call to obtain the username on LTC-Global. This can then be stored in the users profile and the "get_portfolio" call can be extended to also include a field for the LTC-Global username.

I don't know how closely interwoven the databases for the two exchanges are, but I can imagine that such mechanism could be easier and directer than the OAuth path I proposed.

Anyway, as I think about this, it dawns on me that the BTCT public address is a BTC address while the LTC-Global public address will be a LTC address. So they can't be the same and can't be used to programatically link two accounts without major additional effort. Usernames alone are not sufficient for this purpose, since they're not protected.

Very good point. I just assumed the address would be unique. You could use both address and username as input. This way the user can be identified/authenticated by the address outside of BTCT, but the username is used to determine the destination. The address parameter could be optional and would be used as additional layer of security. If an address is provided and does not match with the given username, the transfer will be rejeceted.

Another approach could be to implement an additional endpoint that solely answers the question: "Is this username linked to that address?"


Should we fear about our balance on BTCT now?

Thanks.

On #1, I have updated the warning and posted clarification to the LABCOIN thread.  In general I have not been following it except where people have sent me links to specific posts.  The post volume is just too fast for me to keep up.

On #2, that's a great idea.  Only real trick I see is that it's possible for a user to have multiple accounts and to use the same address on one or more of them.  If there's more than one account with the same address, how do we decide where to put the inbound shares?


We've been trying to work out some fairly serious issues.  I really hope to be able to post more soon.


It's not.  I think you might not have set your public withdrawal address yet?  If you have the warning up on your screen, then trading is locked just for you.  Set an address you are willing to share with issuers on the Account page here: https://btct.co/account?tab=tab2

Cheers.

   Why has COG.F2 trading been frozen?

bump

To make it clear, "legal issues" does not mean "illegal" or "morally incorrect". It means that LC is raising a new challenge for btct. How to handle a security that is not following the rules?

If your vision of bitcoin is short term, then yes, you can answer "this is the BTC world, and that's how it works here".

Maybe it's time to see further and be proactive regarding questions about regulation of these markets.

I wish people would say "this is morally incorrect" instead of "this is illegal". But that's a meta discussion and the Labcoin stuff doesn't belong here either, in my opinion.

1. Burnside, a question re this topic:

There are two scenarios now. They improve and work things out, in this case it would be great if you not only remove the warning, but I think it would be great, if you issue a statement. Not sure, if you are following the Labcoin thread, but the consens was "warnung is fine, a vague reason not". The other outcome would be no improvement. I'd like to know: how would you handle this case, if it comes true? Is the timer ticking now? T -6 days?

2. Share transfers and public Bitcoin/Litecoin address

Is it possible to implement an API endpoint on which I could transfer shares to the public address of an user instead of to the username? I'd like to implement an automatic share exchange service, but right now there is no 100 % way to identify an user outside of BTCT/LTCG. An address/signature based identification could solve this easily.


Edit:

I have one BTCT account that I'm not using right now. If anyone is seriously interested, send me a PM with an offer.

I'm not interested in scam alert neither posting crap around here.

I see it as a legal issue and if you feel that it doesn't worth one post then you should just close your eyes and listen to some music. And yes, I know how the BTC world works, thanks for your useless advice. Labcoin is not interesting, but this case scenario is. It could be a motivation to change (or think) how a security market can be regulated.