[BTC-TC] Virtual Community Exchange [CLOSED]

[🏰 TradeFortress 🏰]

You should add a trollbox to your site! You can use CoinChat - simply iframe it with the "j:yourroom" part so they'll automatically be in your room. If you create it, you have full moderation powers like kicking people.

Some third party clients for coinchat:

http://chromaticcreative.net/bitcoin/moobot/flatapp.php#

http://whiskers75.github.io/whiskchat/index.html

They're all responsive and can fit into any size.

[ThickAsThieves]

You should add a trollbox to your site! You can use CoinChat - simply iframe it with the "j:yourroom" part so they'll automatically be in your room. If you create it, you have full moderation powers like kicking people.

Some third party clients for coinchat:

http://chromaticcreative.net/bitcoin/moobot/flatapp.php#

http://whiskers75.github.io/whiskchat/index.html

They're all responsive and can fit into any size.

Please don't add chat.

[Garr255]

Please don't add chat.

^

[Newscastix]

Please don't add chat.

^

+1

Especially not by embedding/iframing 3rd party sites you have no control of like proposed above.

[🏰 TradeFortress 🏰]

There shouldn't be any problem security side (all modern browsers isolate iframed stuff on external domains), but I guess people don't like chat / trollboxes on stock exchanges

[btharper]

No, the asset issuers get lists sent to them every 12 hours, so if you're in the list, you're good to go.  This does suck somewhat if you made a trade in the meantime so I have been exploring other options for users to be able to prove trades using the emails that get sent out.  Basically will require the site to gpg sign trade emails I suspect.

What I haven't figured out yet is how to give you a gpg signed copy of your trade that the issuer could use as a diff against their copy of the asset holders.  For them to be able to use it, the copy of your trade would need to have both your account and the other user's account in the trade data.  I can't really send out info about the other user, so that's kind of where I'm stuck right now.

Cheers.

Ah. Thanks for the clarification. What would be the problem with sending an updated list to an asset holder after every trade involving his or her asset?

That'd be a lot of emails.    Way too many on most assets.

Why not send the following data: (add or subtract to your liking)

GPG(Btct.co key)-Sign({trade:{time:<timestamp>, asset:<Asset name>, qty:<+-number traded based on buy/sell>, bal:<new balance>}
,info:{GPG(issuers key)-encrypt({nonce:<incremented value>, user:<userid in 12h emails>, from:{0:{user:<user id of other side of the txn>, qty:<number>},<n>{user:.., qty:..}} ) }

No new emails are required (but some extra processing and data per email, and extra work for issuers, but that's true in any system). This transmits (securely) everything the buyer needs to to prove they have new shares (asset name, how many, how many they have now). The issuer (but not the buyer or seller) can decrypt the portion containing everything about what user(s) sold their shares and how many. Userids are linked to the email that's normally sent out. The nonce assures correct ordering of separate transactions (even if the timestamp is identical), and allows the issuer to know at least how many transactions are missing based on holes from the highest nonce (but not later transactions with higher nonce's). The nonce should also be included in the emails so the issuer knows where the next one starts (generating the email should increment and get it's own unique nonce to create a clear before and after, no >=/<= confusion). Additionally if you wanted to the encrypted portion could also contain data for n previous transactions (not including ones before the email if one was sent just before the emailed txn) to help fill in the pieces faster for issuers, but increasing overhead and complexity of server side code.

Only issue that's glaring at me is if the key is compromised then there's no way to verify anything, but that's a larger problem anyway.

[btharper]

There shouldn't be any problem security side (all modern browsers isolate iframed stuff on external domains), but I guess people don't like chat / trollboxes on stock exchanges

Between security concerns (founded in truth, founded in paranoia, or unfounded) and potential to be seen as a spambox I'm not sure everyone would enjoy it at all. It could be possible to make a browser plugin to add boxes to sites that could use this as an initial offering. Taking the far end of an opt-in system.

[Newscastix]

There shouldn't be any problem security side (all modern browsers isolate iframed stuff on external domains), but I guess people don't like chat / trollboxes on stock exchanges

Even if the iframed stuff is isolated, it is still embedded and the html/flash/java within the iframe is executed.

I just need to hack the chat provider and i can have any content displayed in within the iframe. Great for malicious code/java/etc.

And everything of that is beyond the control of the owner/admin of btctc.

[burnside]

There shouldn't be any problem security side (all modern browsers isolate iframed stuff on external domains), but I guess people don't like chat / trollboxes on stock exchanges

There's always #bitcoin-assets on Freenode. 

[burnside]

No, the asset issuers get lists sent to them every 12 hours, so if you're in the list, you're good to go.  This does suck somewhat if you made a trade in the meantime so I have been exploring other options for users to be able to prove trades using the emails that get sent out.  Basically will require the site to gpg sign trade emails I suspect.

What I haven't figured out yet is how to give you a gpg signed copy of your trade that the issuer could use as a diff against their copy of the asset holders.  For them to be able to use it, the copy of your trade would need to have both your account and the other user's account in the trade data.  I can't really send out info about the other user, so that's kind of where I'm stuck right now.

Cheers.

Ah. Thanks for the clarification. What would be the problem with sending an updated list to an asset holder after every trade involving his or her asset?

That'd be a lot of emails.    Way too many on most assets.

Why not send the following data: (add or subtract to your liking)

GPG(Btct.co key)-Sign({trade:{time:<timestamp>, asset:<Asset name>, qty:<+-number traded based on buy/sell>, bal:<new balance>}
,info:{GPG(issuers key)-encrypt({nonce:<incremented value>, user:<userid in 12h emails>, from:{0:{user:<user id of other side of the txn>, qty:<number>},<n>{user:.., qty:..}} ) }

No new emails are required (but some extra processing and data per email, and extra work for issuers, but that's true in any system). This transmits (securely) everything the buyer needs to to prove they have new shares (asset name, how many, how many they have now). The issuer (but not the buyer or seller) can decrypt the portion containing everything about what user(s) sold their shares and how many. Userids are linked to the email that's normally sent out. The nonce assures correct ordering of separate transactions (even if the timestamp is identical), and allows the issuer to know at least how many transactions are missing based on holes from the highest nonce (but not later transactions with higher nonce's). The nonce should also be included in the emails so the issuer knows where the next one starts (generating the email should increment and get it's own unique nonce to create a clear before and after, no >=/<= confusion). Additionally if you wanted to the encrypted portion could also contain data for n previous transactions (not including ones before the email if one was sent just before the emailed txn) to help fill in the pieces faster for issuers, but increasing overhead and complexity of server side code.

Only issue that's glaring at me is if the key is compromised then there's no way to verify anything, but that's a larger problem anyway.

That's a great idea, issuing a key per issuer.  No real flaws as far as I can tell.

I've thought about the compromised key issue a bit.  Things always get ugly if the box gets rooted.

Thank you for that!

[furuknap]

Burnside, did you change anything with the CSS just now? In IE I now get this:

http://imgur.com/kgQK8SS

Looks good in FF, though.

.b

[btharper]

No, the asset issuers get lists sent to them every 12 hours, so if you're in the list, you're good to go.  This does suck somewhat if you made a trade in the meantime so I have been exploring other options for users to be able to prove trades using the emails that get sent out.  Basically will require the site to gpg sign trade emails I suspect.

What I haven't figured out yet is how to give you a gpg signed copy of your trade that the issuer could use as a diff against their copy of the asset holders.  For them to be able to use it, the copy of your trade would need to have both your account and the other user's account in the trade data.  I can't really send out info about the other user, so that's kind of where I'm stuck right now.

Cheers.

Ah. Thanks for the clarification. What would be the problem with sending an updated list to an asset holder after every trade involving his or her asset?

That'd be a lot of emails.    Way too many on most assets.

Why not send the following data: (add or subtract to your liking)

GPG(Btct.co key)-Sign({trade:{time:<timestamp>, asset:<Asset name>, qty:<+-number traded based on buy/sell>, bal:<new balance>}
,info:{GPG(issuers key)-encrypt({nonce:<incremented value>, user:<userid in 12h emails>, from:{0:{user:<user id of other side of the txn>, qty:<number>},<n>{user:.., qty:..}} ) }

No new emails are required (but some extra processing and data per email, and extra work for issuers, but that's true in any system). This transmits (securely) everything the buyer needs to to prove they have new shares (asset name, how many, how many they have now). The issuer (but not the buyer or seller) can decrypt the portion containing everything about what user(s) sold their shares and how many. Userids are linked to the email that's normally sent out. The nonce assures correct ordering of separate transactions (even if the timestamp is identical), and allows the issuer to know at least how many transactions are missing based on holes from the highest nonce (but not later transactions with higher nonce's). The nonce should also be included in the emails so the issuer knows where the next one starts (generating the email should increment and get it's own unique nonce to create a clear before and after, no >=/<= confusion). Additionally if you wanted to the encrypted portion could also contain data for n previous transactions (not including ones before the email if one was sent just before the emailed txn) to help fill in the pieces faster for issuers, but increasing overhead and complexity of server side code.

Only issue that's glaring at me is if the key is compromised then there's no way to verify anything, but that's a larger problem anyway.

That's a great idea, issuing a key per issuer.  No real flaws as far as I can tell.

I've thought about the compromised key issue a bit.  Things always get ugly if the box gets rooted.

Thank you for that!

You could use btc-otc for people already active there, or just insist that all issuers be active there and use those keys. Either way you don't have to worry about creating and distributing the keys yourself.

As far as the compromised key issue, all I can think of is getting another server to sign a timestamp + btct.co data at the cost of another extra step. Depending on how the mail system is setup now (I'm assuming one for trading activity that tells a mail server to send things), and assuming rooting one wouldn't mean definitely or possibly owning both servers you could have the trade machine sign transaction data and the mail server sign data+timestamp. Then as long as both servers aren't rooted you can't forge a timestamp that supersedes the correct data.

[burnside]

Burnside, did you change anything with the CSS just now? In IE I now get this:

http://imgur.com/kgQK8SS

Looks good in FF, though.

.b

What's wrong with that?  Looks great to me!   

Problem seems to be that all of a sudden IE wants to render it in compatibility mode.  (compatible with what?  IE 3?)

I added some code in the header and it seems better now.

Code:

<meta http-equiv="X-UA-Compatible" content="IE=9; IE=8; IE=7; IE=EDGE" />

Cheers.

[burnside]

You could use btc-otc for people already active there, or just insist that all issuers be active there and use those keys. Either way you don't have to worry about creating and distributing the keys yourself.

As far as the compromised key issue, all I can think of is getting another server to sign a timestamp + btct.co data at the cost of another extra step. Depending on how the mail system is setup now (I'm assuming one for trading activity that tells a mail server to send things), and assuming rooting one wouldn't mean definitely or possibly owning both servers you could have the trade machine sign transaction data and the mail server sign data+timestamp. Then as long as both servers aren't rooted you can't forge a timestamp that supersedes the correct data.

I'm thinking I'll create a key pair for all issuers when the security is created, then let them override it if they want.  That way the users with existing keys should be good to go.

The mail setup would have to be altered significantly to do the staged signing, but it's a great idea.  I'll have to think about it a bit.

Cheers.

[btharper]

You could use btc-otc for people already active there, or just insist that all issuers be active there and use those keys. Either way you don't have to worry about creating and distributing the keys yourself.

As far as the compromised key issue, all I can think of is getting another server to sign a timestamp + btct.co data at the cost of another extra step. Depending on how the mail system is setup now (I'm assuming one for trading activity that tells a mail server to send things), and assuming rooting one wouldn't mean definitely or possibly owning both servers you could have the trade machine sign transaction data and the mail server sign data+timestamp. Then as long as both servers aren't rooted you can't forge a timestamp that supersedes the correct data.

I'm thinking I'll create a key pair for all issuers when the security is created, then let them override it if they want.  That way the users with existing keys should be good to go.

The mail setup would have to be altered significantly to do the staged signing, but it's a great idea.  I'll have to think about it a bit.

Cheers.

All told, that should work well too, although the difference between per security and per user might matter (complicated by issuers using multiple accounts across multiple assets and personal trading).

Glad I could help you with a fun, challenging weekend project.

[Skrapps]

I have a suggestion: Can there be a way to add some optional requirements/settings for the 'Withdraw to- Address Lock' and/or 'Internal Transfers'? Maybe options such as email confirmations, or some other verification (besides the PIN)?

My situation: I locked my withdraw address to an offline, paper address, thinking that I would probably reinvest most of my dividends and wouldn't need to withdraw anything for awhile. However I changed my mind, some other investments on other sites caught my eye, and I wanted to make a few purchases with earned dividends - though I didn't want to load and use the offline wallet yet.

Instead, I created another account and internally transferred my spare BTC to the new account. Within some odd minutes I had my coin off of btct.co.

I know there is already quite a bit of security in place, and that if an attacker had my PIN and 2FA then my email probably is compromised as well, though I still feel irksome that I was able to contradict an earlier decision of mine. Not that I'm asking you to save me from myself, not your job to watchdog the users and safeguard against self-sabotage. Though I can't see much downside if there were a few more options a user could place on his account, if implementation was easy and it didn't increase things too much on your end.

Could one have a time-specific withdraw lock (maybe a week or month, etc), delays or confirmations for internal transfers (or maybe securities only transfers), etc?

Regardless, love the site and the work you put into it is admirable. Thanks!

[blurden]

as the clients grow more available on bitcoinx - would you have any interest into converting ASICMINER-PT to a colored bitcoin system? I've only scratched the surface on the concept myself - but it seems to be a pretty exciting idea...

[burnside]

as the clients grow more available on bitcoinx - would you have any interest into converting ASICMINER-PT to a colored bitcoin system? I've only scratched the surface on the concept myself - but it seems to be a pretty exciting idea...

I probably would 't run the PT outside btct.co.

I think in this thread the question would be whether or not the entire site would support the colored coin system somehow.  It is pretty exciting, but I'm not really sure how they could be integrated exactly.

[burnside]

I have a suggestion: Can there be a way to add some optional requirements/settings for the 'Withdraw to- Address Lock' and/or 'Internal Transfers'? Maybe options such as email confirmations, or some other verification (besides the PIN)?

My situation: I locked my withdraw address to an offline, paper address, thinking that I would probably reinvest most of my dividends and wouldn't need to withdraw anything for awhile. However I changed my mind, some other investments on other sites caught my eye, and I wanted to make a few purchases with earned dividends - though I didn't want to load and use the offline wallet yet.

Instead, I created another account and internally transferred my spare BTC to the new account. Within some odd minutes I had my coin off of btct.co.

I know there is already quite a bit of security in place, and that if an attacker had my PIN and 2FA then my email probably is compromised as well, though I still feel irksome that I was able to contradict an earlier decision of mine. Not that I'm asking you to save me from myself, not your job to watchdog the users and safeguard against self-sabotage. Though I can't see much downside if there were a few more options a user could place on his account, if implementation was easy and it didn't increase things too much on your end.

Could one have a time-specific withdraw lock (maybe a week or month, etc), delays or confirmations for internal transfers (or maybe securities only transfers), etc?

Regardless, love the site and the work you put into it is admirable. Thanks!

Definitely an interesting issue.  Seems like we have a few options:

- apply the same limits to internal transfers as we do to withdrawals.
- allow outgoing internal transfers (shares and coins) to be permanently locked as well
- make all withdrawals manual

I'm leaning toward that second option.

[FloatesMcgoates]

Any idea if TAT.VIRTUALMINE will be approved for trade? I might want to buy in at IPO prices and would rather do it here than at bitfunder