Topic: The Holy Grail! I wish I could kiss the author of Bitmessage on his face. - page 12. (Read 92719 times)

From what I've read, Bob has to put in some crypto currency as collateral, so that if he disappears with the money, he'll actually end up losing more than he took from Alice. Is this right? If yes, how can Bob be sure that whoever he pays collateral to, won't disappear with that?

Hello everyone

fellowtraveler,
It appears to me that you need an API command in Bitmessage to generate an address from the "Silver_Asset_ID+Server_A_ID+EURO_SEPA" string without actually adding it to the software's collection of addresses; this way Bob or Jorg could then subscribe to the address.
So it appears to me that we need three more API commands:
getDeterministicAddress
addSubscription
deleteSubscription

Shall I add them?

Ok, let's crowdfund that

Fellowtraveler has been determined to see OT succeed since introducing it many moons ago. I have pointed out the need for OT, as have others, to key developers on the forums/IRC which fell on deaf ears.
Only the latest fears of de"gox"ification has opened everyone up to the possibility that we had the solution in front of us all the time. This is not a download once, free mined coins, windows-only easy pie GUI. This solution requires work by server dudes, graphics guys/gals and architecture.
BMOT is a framework that opens a new playground. SCAMMERS WON'T LIKE THIS PLACE and traders must play fair. No more speculation walls or bit* scams allowed. Bitcoin and altcoins acting cooperatively and contracts/commodities/PMs from legitimate sources or GTFO! This has a built in stop button! No more jungle tactics. The strong will survive and thrive, but the newbies can cling to the strong instead of being fleeced by the wolves.
TLDR;
FT has waited for the perfect moment to reintroduce Open-Transactions.
OT with BM can setup groupings of pooled interests.

smart people working like this beats academia by a mile

fellowtraveler went from idea, peer review, to increased funding (literally cash in hand) and collaboration in less than 24 hrs. 

A colored coin issuer can demand KYC info from anyone converting in/out directly through that issuer.

Therefore the issuer is compliant. (Consult an attorney -- that's my opinion, and it's not legal advice.)

This is no different than MtGox is today: users are giving each other BTC all the time outside of MtGox -- but only the ones who cash out through a MtGox bank wire actually have to cough up their identification info.

This is similar to what I have proposed. Stick the BTC in a multi-sig voting pool for safety, and then use Open-Transactions escrow and Open-Transactions markets for the actual exchanges.

(Except in my proposal, everything is automated.)

Bye bye Ripple.

Bye bye Ripple.

More step-by-step...

1. Wallet uploads BTC to voting pool, in order to trade them around on an OT server.
    -- AND/OR --
1. Wallet uploads colored coins to voting pool, in order to trade them around on an OT server.

Also notice that the colored coin issuer does not directly issue anything onto an OT server. Issuers can issue directly onto OT servers, but I suggest using colored coins and voting pools in order to break that link.
2. From this point, it's easy to use Open-Transactions for escrow, and for market trading, on that OT server.
   (Server is unable to forge receipts internally, nor steal from multi-sig pools externally.)
3. Using a discovery layer (Bitmessage, IRC, etc) users who are not already on the same OT server can discover each other, and select a server to meet on, to complete the trade / escrow. (This can all be automated inside the client software.)
4. The same discovery layer makes it easy to wire funds from one server to another, through other users.
5. The same discovery layer makes it easy for users to discover each other for SEPA transfers, facilitated by OT's escrow capabilities.
6. These SEPA transfers could also be performed by services, who are themselves just "other users." (This is the basic concept of Ripple "gateways" as far as I can tell.) OT escrow is used here to remove trust.
7. Even credit lines could be issued cross-server, now that the discovery layer is solved.
The specifics of the discovery/OT protocol are in the paste bins at the top of this thread.
All conversions for a particular user are performed by his own wallet, in a user-centric fashion.
We need to move away from a provider-centric mindset, and instead become provider-independent -- demoting servers from "authorities" to mere "cloud commodities." (For examples of this concept, see Diaspoa and Tahoe.)