Topic: We need smart contract based exchange (Read 2838 times)

With a distributed record of ownership, a lot of things become possible.  TOR-hidden exchanges, brokerages, and dealers, for example.  And person to person transactions, which I'm almost positive are totally legal.

I'm personally going to be very careful about dealing with securities.  The SEC could get (easily) involved and that would get messy fast.

Huh, I didn't even know what he was talking about (maninthemiddle?) until you answered.

This week I'll get some changes at my work and university and I will know if I'm time capable to start project as it is said in topic.

http://www.lmgtfy.com/?q=cloudflare

-MarkM-

If you're about to say that for HTTPS, the certificate issuer acts as "man in the middle" then no -- that is blatantly wrong.

With HTTPS, you get a secure encrypted connection to some "entity" running a server. But you don't have any idea or guarantees about who is your communication partner. Now, to help with that, a known and "trusted" other entity certifies that this "entity" actually is what it claims to be. This certificate issuer certifies this by signing the "entitie's" server certificate. In practice, certificate issuer companies are selling that serive for money. It is a well known unofficial fact that many, if not most certificate issuer copanies don't go into mouch trouble for actually verifying the identity of their customers. It is said that oftern there is just a cursory check about the domain registration. Well, this is inofficial knowledge, because, officially, by the terms of law, the certificate issuer guarantees that the identity of your communication partner is "verified".

But this does in no way mean that the certificate issuer is able to intercept a HTTPS communication.

There is another thing. Today, many more elaborate corporate firewalls perform a dedicated man-in-the-middle attack on any HTTPS connection from the general internet to a client within the company. They intercept the connection, decrypt the content, and forward it with another HTTPS connection, signed with the certificate of the firewall proxy. Of course, this triggers a huuuuge alarm in any sensible internet browser. Now, unfortunately, since this practice has become so common, a lot of people routinely click away any "breach of security" alert given by their browser indicating a mismatch on the HTTPS certificate.

No, it is not possible to fake a Certificate, without again triggering an alarm in the client's browser. But, see above, thanks to improved corporate security measures, we have now trained a lot of people to ignore any such alarm.

Apparently GLBSE did not even actually have proper encrypted https, it had pretend/fake man in the middle system with a commercial professional man in the middle corporation that pretends to browsers that they have a secure connection but in fact is a deliberate man in the middle that Nefario actually deliberately conspired to set up as man in the middle intercepting all communications between browsers and GLBSE?

Is that correct?

-MarkM-

Site could just generate a bitcoin link which is accepted now as I know already by main client.
And it's all no add-ons or anything needed, and there could be competing websites for link generation.

For security encryption is of course recommended.

I have to install IRC client to start chat ing posting is to slow.

MPEX uses signatures and encryption, not just signatures.  And encryption provides half of the authentication, and all of the privacy in the PGP/GPG model.  Bitcoin keys can't be used for encryption, only signing.  If you've created a key recently (last 5 years? 10?) you may have noticed that the default is to create two sets of keys, one for encryption, and one for signing.

Sounds resonable. Maybe the bitcoin client should also include encrypt/decrypt then otherwise everyone along the route you send your messages can see what you are up to, except I guess maybe in the special case of using an https connection though actually I hear that is itself pretty much a built in man in the middle in the person of the certificate issuer plus maybe also people can fake the certificates too.

-MarkM-

Yes, this sign-message capability is available via the GUI interface or RPC API.

ECDSA signatures and keys also tend to be smaller than PGP-used forms.  That was one reason why Satoshi chose ECDSA.

And, double plug, distributed bonds and smart property use bitcoin signatures already.

The reason I'm not a fan of PGP is because you need to install separate software, create separate keys, upload them to key servers, and keep backups of your keys. These are all things you already have to do with Bitcoin, anyway (or your BTC wallet service does for you). Blockchain.info and the Satoshi clients provide very simple signing already as part of your wallet. It's not as prominent, but I am hoping that will change, with big SIGN and VERIFY buttons clearly visible. At that point, since you'll be buying and selling shares from your wallet, anyway, which already includes copy/pasting long address strings, copy/pasting signature strings will not be too big of a step from it. If people can learn how to copy/paste email addresses, and now how to copy/paste BTC addresses, I expect they can learn to copy/pasting a text string and click a SIGN button.
Worst case, Bitcoin gets popular enough that btcsign: becomes as popular as mailto:, and clicking on it launches your default Bitcoin wallet, with a verification string ready to be copy/pasted into a field in the browser.
The other major benefit of BTC signing over PGP is that you can't pay, or receive payments from, PGP keys. Thus you need a system that stores a whole set of account related info, like payment address, PGP keys, and likely user names and passwords. With this setup, all that is needed is your BTC address.

P. S. It was thanks to MPEX that I started thinking about this setup, and am hoping someone can code something like this. With this available, there won't be any need for MPEX.

Seems unlikely. MPEx has you sign with PGP or GPG instead of bitcoin but that is just as "inconvenient", requiring doing a copy and paste then the signing then copy and paste the result. Copy nad paste is way too complicated for "normal" folk apparently.

You need the signing app to pop up automatically like your email client does for mailto: URLs, and automatically submit the result back into the form or something like that and still people aren't going to like it, thus the browser plugin. Then they'll complain they don't want to install the plugin.

-MarkM-

Nope. Don't like MPEX at all. I think being able to sign text using Bitcoin clients is very easy, and will likely become as simple and prominent as signing checks is now. But that is assuming the "normal" people you are referring to are Bitcoin users.

Ah, maybe you are a MPEx user?

Apparently "normal" people don't find that "useable", or even, maybe, understandable...

-MarkM-

Not sure why you would need a browser plugin. The software can just give you a message to sign as plain text, then once you use your own Bitcoin client to sign it, can verify it using it's own signature verification service (own Bitcoin, or third party)

A major component of this is distributed bonds.

One implementation, pybond, should have basic distributed bonds working within a week or two.

With distributed bonds, you don't have to worry about your exchange going under, and taking all the bonds with you.

Anyone with software that reads the distributed bond format may set up an exchange.

That is a form of decentralisation; each asset is handled by its issuer, who you already have to trust anyway.

To do it as a web thing though you still need some kind of browser plugin that will talk to your bitcoin daemon to sign messages and to validate messages it receives from the server.

If you look at the tabs in the Open Transactions GUI, you will see that it has a tab for bitcoin, in which it does talk to your bitcoind daemon.

If people really insist on using bitcoin address signing instead of their 'nym maybe that functionality can be added into Open Transactions too.

-MarkM-

If you are suggesting replacing GLBSE, technically we don't need anything decentralized. The company issuing the stock can be in charge of selling and managing it, too.

My idea was to create open source software that runs on the company's server, and sells/tracks shares there. Since we can sign messages using out BTC addresses, the whole implementation can be very easy:

Shares listed on the site, using trading software.
You purchase shares using a Bitcoin address. That address is now registered by the software as the owner of those shares.
Dividends get automatically paid out to that address.
Selling the shares back to the company involves selecting the option, and sending a confirmation signed by the BTC address, which upon confirmation receives the money.
Selling/transferring the shares to someone else involves setting up a transfer and signing a confirmation using the BTC address, at which point the new address is registered as the owner.

No need for centralized exchanges, or even tracking names and registrations. Just a private, company-owned ledger that keeps track of which shares belong to which addresses.

I do wonder exactly what smart contracts you are thinking of specifically.

Once you have Open Transactions working at your end maybe you can look through the sample smart-contracts and be more explicit as to the exact contract it is that you are looking for?

-MarkM-

Open Transactions has smart contracts, but web browsers do not natively handle their users' private keys or certificates, they only seem to care about identifying the website, not proving to the website that the user is who the user claims to be.

This is why a bounty is being offered for making an Open Transactions client "that grandma can use".

Right now the only GUI client is the "test client" which was originally developed as reference code showing how each function can be done. It needs a lot of polishing up to make it something that "grandma can use".

If you want to make a web interface, you will need to create a way for the user's browser to do all the decrypting of messages from the server and encrypting of messages to the server, or you will have to just be another "mybitcoin" by having everyone just trust you with their private keys, making you, not them, the owner of their accounts.

If you use Windows, try out the new Windows build of the GUI. Supposedly it "just works" now:

https://bitcointalksearch.org/topic/m.1216747

Browsers are ridiculously over-featured for this kind of thing. But nonetheless the plan is to make the user's main Open Transactions install be a system service or system tray icon type of thing that is always running then have plugins for browsers, skype, IM clients etc etc etc none of which need the guts of OT in them as they will all call that resident daemon to do the hard parts.

Try out that Windows GUI, see how it all works, then think about how you could get people using web browsers to interface to it via a website. I figured most likely anyone who "needs" a website method for it would be better served by a real live broker they can videochat with via skype who will insulate them from the nitty gritty of it all - a "full service" broker.

-MarkM-