Topic: Open-Transactions announcement: new GUI mock-ups / Monetas (Read 3384 times)

You have the same problem with Ripple: unless you're depositing XRP, you will have a currency issued by someone who's backing its issued currency with real cash (or Bitcoin or clams).

So that will be the point of entry for fiat -> digital currency, and there's your exchange.

Unless I'm missing something.

Don't we want people with good information to contribute without needing to retain large amounts of capital?

"I know what will turn this company around!"
Buy low
Vote smart
Price goes up
Sell high

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.

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.)

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?

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?

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.

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

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

Run a client and come trade on my server.

-MarkM-

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.

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.

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

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

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


Of course the Open-Transactions API has always been easy to use:
https://bitcointalksearch.org/topic/m.1003087

I gave you guys a 2-year head start.

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


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.


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.)


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.

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

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-

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?

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-

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?