Open-Transactions announcement: new GUI mock-ups / Monetas

[fellowtraveler]

Once again it is I, Fellow Traveler, your faithful and loyal friend.


First off, the newest versions of OT and Moneychanger have been
released. In addition to automake, this new OT is now able to start up
without a data folder, and AUTO-GENERATE any files/folders that are
necessary. (Meaning there is no longer any dependency on sample data in
order to run...)

Make sure you download both OT and Moneychanger (or neither), since both
were changed (to accommodate an API change.)

https://github.com/FellowTraveler/Open-Transactions/
https://github.com/FellowTraveler/Moneychanger

http://open-transactions-tv.github.com/



===> Also, I am pleased to announce that I am starting up a new company,
~ Monetas ~, to pursue building high-end applications using the OT
technology. (OT is only a foundation--there is more we must accomplish.)


QUESTION: What does this mean? Is some corporation going to gain control
over OT?

ANSWER: Absolutely not. I want to address any concerns about this right
away: Open-Transactions is free software and it will always belong to
the open-source community where it was developed, just like Linux or
GPG. It's NOT being signed over to some corporation. We believe this is
actually the best move, from a business perspective.

David Wheeler's comments are instructive:

"The GPL has enforced a consortia-like arrangement on any
major commercial companies that want to use it. Red Hat, Novell, IBM,
and many others are all contributing as a result, and they feel safe in
doing so because the others are legally required to do the same. Just
look at the domain names on the Linux kernel mailing list – big
companies, actively paying for people to contribute. In July 2004,
Andrew Morton addressed a forum held by U.S. Senators, and reported that
most Linux kernel code was generated by corporate programmers (37,000 of
the last 38,000 changes were contributed by those paid by companies to
do so.)"

... We believe that Open-Transactions can function the same way. There
are already multiple contributors. We envision a future where many
competing companies feel safe spending money on improving the OT code
base, just as they do today with Linux.

===> The focus of Monetas, rather, will be on NEW, high-end applications
and integrations, built using OT technology. We will also develop the
premier server platform for all kinds of smart contracts and other
financial instruments. Our roadmap includes innovations that solve
fundamental problems and that will greatly benefit the Bitcoin ecosystem.

We believe we stand at the beginning of a new epoch, a time of
unprecedented opportunities for innovations that will change the course
of history.

My business partner is Johann Gevers (mailto:johann@monetas.net). He is leading
the business side of the company as CEO, and I am leading the technical
side of the company as CTO.

We have very exciting plans for Monetas. Stay tuned.


-Fellow Traveler



P.S. ...and one more thing. I thought you guys might like to see some
new GUI mock-ups...


Standard mode:
https://www.fluidui.com/editor/live/preview/p_8ZN0r9Pbp2XzPC7yL3lDFw5lW2L7vEye.1343824445082

Advanced mode:
https://www.fluidui.com/editor/live/preview/p_XcN9TmQ5FItuPr5QctxES2XfAhinsVPp.1343659566990


Mock-ups currently only available in Chrome or Safari, sorry.
(I promise my own web apps will be compliant with web standards :-)

[paulie_w]

does this use native widgets?

[Meatpile]

Very exciting, this will absolutely work if it becomes easy to use.

Can you explain to me how you think real world cash will make its way into this system?

For instance to replace current bitcoin exchanges, there needs to be some kind of "bank" entity that accepts cash and gives out a "CompanyABC USD cash value" that can be bought and sold from this company, and then into any other currency on the open transaction market?  Or do you think it is more likely that people will deal cash in person and then transfer a digital assets?

Also is there any way to integrate credit cards into such a system? Maybe some kind of "potentially revocable" asset? It would get traded around, but everyone knows there is a potential for it to be clawed back someday?


And one more question I have regarding open transactions that I don't understand how it could work: Stock ownership. How can an issuer of a stock asset, know exactly how much of that asset a single person has? So you know how much voting power he has compared to other stock holders. I know that an issuer can see total stock in the wild, but how to verify how much a single Nym is in control of?

[markm]

I doubt that an issuer of an asset will know how many shares any particular nym has. It is not necessary, as far as I can see.

The server itself can read all account balances thus can know with information, and thus can add up votes on motions and divvy up dividends; and an issuer can know how many of an asset they issued on a specific server so can know how much of their total dividend any particular server they issued their asset on needs.

Any kind of payment that can be clawed back is a problem. In the past I had thought about creating an asset representing funds that came from a reversible source, and tracking how much of it is over 180 days old thus no longer subject to being reversed. So startign six months after the first paypal bucks (for example) enter the system, some of them start to actually be useful, the rest simply sitting around similar to bitcoins that are waiting for confirmations. It'd be six months instead of six blocks.

In practice though it seems more likely there will be people who will take the risk for a percentage, so they will sell you digibucks on some server in return for some larger amount in reversible funds. I don't know how they deal with the fact they will be scammers' favourite places for fencing stolen funds, but I have seen at least one thread in soem section or other where someone selling bitcoins for paypal discussed some of how they did it.

-MarkM-

[Meatpile]

...
The server itself can read all account balances thus can know with information, and thus can add up votes on motions and divvy up dividends; and an issuer can know how many of an asset they issued on a specific server so can know how much of their total dividend any particular server they issued their asset on needs.
...

Oh I see, so it would be a smart contract, and there is some kind of function that knows a Nyms total balance on that server only?

[markm]

The account balances are not encrypted on disk, merely "armoured ascii text", so basically any scripts etc running as a username that can access the files can do any kind of adding up comparing etcetera the server operator wishes to do.

This stuff is not actually in place yet though so the exact details await an actual implementation.

-MarkM-

[marcus_of_augustus]

Good work, watching to see where this all leads to.

[fellowtraveler]

does this use native widgets?

Of course you are looking at a mock-up, so it can use whatever widgets you prefer to imagine.

Very exciting, this will absolutely work if it becomes easy to use.

Of course the Open-Transactions API has always been easy to use:
https://bitcointalk.org/index.php?topic=86710.msg1003087#msg1003087

I gave you guys a 2-year head start.

Any user-oriented application that I write, of course, will also be easy to use.

Can you explain to me how you think real world cash will make its way into this system?

For instance to replace current bitcoin exchanges, there needs to be some kind of "bank" entity that accepts cash and gives out a "CompanyABC USD cash value" that can be bought and sold from this company, and then into any other currency on the open transaction market?  Or do you think it is more likely that people will deal cash in person and then transfer a digital assets?

With or without OT, people will use exchanges and banks to move in-and-out of "real cash" (as you put it.) This is already occurring (see MtGox for example...)

The long-term solution--to eliminate exchanges entirely as a bottleneck--will happen with the Ripple protocol.

Also is there any way to integrate credit cards into such a system? Maybe some kind of "potentially revocable" asset? It would get traded around, but everyone knows there is a potential for it to be clawed back someday?

Of course there are already Bitcoin debit cards, so I would use existing services to do this.

Chargebacks are a real problem of the 20th century banking system. The companies who offer debit cards will have to deal with any risk here.

Users will probably not store all their money on a card anyway, but just enough for spending that night (with ability to transfer back-and-forth.)

And one more question I have regarding open transactions that I don't understand how it could work: Stock ownership. How can an issuer of a stock asset, know exactly how much of that asset a single person has? So you know how much voting power he has compared to other stock holders. I know that an issuer can see total stock in the wild, but how to verify how much a single Nym is in control of?

I haven't added a "pay dividend" API call yet, but it would be easy to do.

The server would just mail a cheque to the inboxes of stock owners, based on their % of ownership (which the server has access to.)

The long-term vision of OT includes full-scale corporate entities with voting groups, articles of incorporation, bylaws, different classes of stock, etc. We'll get there.

[MadSweeney]

With or without OT, people will use exchanges and banks to move in-and-out of "real cash" (as you put it.) This is already occurring (see MtGox for example...)

The long-term solution--to eliminate exchanges entirely as a bottleneck--will happen with the Ripple protocol.

+1 Can't wait for Ripple to be usable!

[jimbobway]

If I run OT what is the best way to profit from it?

[fellowtraveler]

If I run OT what is the best way to profit from it?

I guess eventually those who profit from running transaction servers will do so through various ways:

1. All expired cash reverts to the server. (Expired vouchers do, too.)

2. OT already has a built-in system for "usage credits" which are used up by API calls. You could sell these credits to your users, using any out-of-band method you prefer.

3. It wouldn't be too hard to add "transaction fees" to the server contracts, although I haven't yet done so.

[marcus_of_augustus]

If I run OT what is the best way to profit from it?

Maybe the obvious one is to become a trusted issuer running a competitive, professional service?

That could go along operating with a server, but is it not a necessity if you can find a competitive, professional server operation to run your issuing service on.

[markm]

If I run OT what is the best way to profit from it?

Run a client and come trade on my server.

-MarkM-

[Bitcoin Oz]

Hope glbse can support this soon so you can export your shares to different servers.

[da2ce7]

Hope glbse can support this soon so you can export your shares to different servers.

We are not too far in supporting most of the actions that GLBSE supports!  All of them could be done with a little scripting.

[Meatpile]

Hope glbse can support this soon so you can export your shares to different servers.

I aleady asked them if they will be supporting this, and no reply. They are completely different, they will not change everything just to support the same features they already have.

[fellowtraveler]

I aleady asked them if they will be supporting this, and no reply. They are completely different, they will not change everything just to support the same features they already have.

You are probably right about this. Their software is custom built, so I'm sure Nefario has been tuning it to his needs for months now, which would probably make it more and more difficult, over time, to switch to anything else.

I'm curious, what do you think are the most important features of GLBSE? Which pieces are critical in your opinion?

And which features do you think they already share with OT? (Such that switching software wouldn't result in any net functionality gain, as you described.)

I'm working on adding a "pay dividends" transaction type--will probably release a video on that soon.

I already have the theoretical capability (via the smart contracts code) to make entities with bylaws and with scripted clauses. Agreements can have parties, who can have agents, and asset accounts. But so far this hasn't yet reached the level of full-blown corporations.

What I don't have yet is voting protocols. Nor do I have hierarchical control over appointed agents, nor corporately-owned asset accounts (such that investment funds can flow in from market offerings, and later flow out again as dividends.) These things are on my roadmap, however.

I am adding payDividend now, which transfers the funds (in any other asset type, such as dollar dividends for pepsi shares) from the dividend source account into a server account, and then sends a voucher cheque to each shareholder's inbox, drawn on that server account. (These cheques will never bounce, since the funds were already transferred into a server account.) The amounts of these cheques will be based on # of shares ownership. ($X per share.) This way, the OT server can easily loop through all the "Pepsi shares" accounts, and send a dollar-denominated cheque to all the shareholders, without caring whether or not they even have a dollar account. The funds are all removed up front from the source account, and the recipients are guaranteed the cheque won't bounce (like a cashier's cheque.) There's only one receipt for the payer, and he doesn't have to individually sign a thousand different cheques (or a thousand different cheque receipts.) Clean and neat.

In phase 1, only the initial issuer of the shares (possessor of the private key) will be able to pay out dividends. Phase 2, we will have entities controlled by voting groups, who will be able to delegate their authority as needed--and who will be able to design their entities in a wide range of different corporate structures.

What else is important? What's important to you?

[Meatpile]

I think all of the voting stuff could be covered by third party apps, if open transactions just implemented the ability to prove you have a certain amount of asset at a certain point in time. I would assume only the issuer of the asset would have access to this amount proof?

[fellowtraveler]

I think all of the voting stuff could be covered by third party apps, if open transactions just implemented the ability to prove you have a certain amount of asset at a certain point in time. I would assume only the issuer of the asset would have access to this amount proof?

Voting isn't any different than paying dividends, is it?

Pay dividends: loop through all asset accounts for a particular type of shares. Then send a cheque to each owner, proportionate to the number of shares in the account. ($X per share.)
To do a vote:  loop through all asset accounts for a particular type of shares. Then tally the vote of each, proportionate to the number of shares in the account.

So this information wouldn't even need to be exposed to the issuer (paying the dividend) although it WOULD of course be available to the transaction server.
(And SHOULD be available to anyone who'd normally have access to audit data.)

OT someday also will be able to anonymize votes (using the existing "untraceable cash" code.)
To do this: loop through all the asset accounts for a particular type of shares. Then issue "cash tokens" to the owner of each, proportionate to the number of shares in the account. (The owner then uses these tokens to perform his vote, with the results being tally-able, yet untraceable.)

[Meatpile]

Implemented in the way you describe I see one possible problem: Say you allow voting on the 30th of the month, someone could buy up a ton of shares on the open market right before vote, get all these votes, and then sell out right away.

I think some scenarios could benefit from multiple points in time proof, like Nym1 had 1000 asset on oct 1, and Nym1 had 1000 asset on oct31. So then they get their fair share of votes.  (I guess if they knew exactly when these proofs were occuring they could still buy and sell at opportune times) Might have to make daily proofs or something.

I guess in a convulated fashion you could get around that with the current capabilities, by issuing oct1 votes, and oct30 votes, and then make a basket of both for the real vote.