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

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.

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 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!

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.

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.

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.


Cheers.

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, 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

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!

There's always #bitcoin-assets on Freenode. 

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.

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.

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

GPG(Btct.co key)-Sign({trade:{time:, asset:, qty:<+-number traded based on buy/sell>, bal:}
,info:{GPG(issuers key)-encrypt({nonce:, user:, from:{0:{user:, qty:},{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.

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

+1

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

^

Please don't add chat.

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.

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

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?