Topic: please delete - page 5. (Read 18351 times)

It also maybe doesn't make a whole lot of sense to try to peg the value of a real actual transfer of value to a pretend, play-acting, maybe it might turn out to be real but we won't know for six months unit of purported value.

I once thought maybe the simplest approach would be to make a PPUSD-fund of which the actual number of USDs that actually lasted the full six months without getting reversed would be kept track of, so that one could figure out the average actual value of each PPUSD currently in the fund and either value them at that average each or only value those that are over six months old.

I thought maybe it could work with things like game subscriptions. Have games people subscribe to at, say 10 PPUSD per month, and in the seventh month and thereafter they start to receive some blockchain based currency coins in addition to whatever the usual perks people who have not been in a full six months might get. (An allowance of game-gold for their character? An edifying newsletter all about the wonderful world that will open up to them in six months time... five months time, wait for it... three months... etc...)

-MarkM-

But, in the end, all you'll have is irreversible USD on top of reversible USD, with the same incompatibility-based fraud problems, where people will buy irreversible with reversible, and reverse their transaction. There won't be any benefit in that system besides off loading fraud into exchanges.

The pegged currency could be used to create a P2P exchange between USD and bitcoin and allow for irreversible and psuedonymous payments of units of USD value.

This is not doable when units of USD value can only be exchanged electronically through existing payment networks (which aren't irreversible or pseudonymous).

The issue is that getting money into Ripple with some level of trust is that it's as difficult as getting the money into Bitcoin with some level of trust. This suggestion seems like it's trying to mask the Bitcoin issue by covering it up with something else with exact same issue. There's also the problem if having to build out both, Bitcoin and Ripple networks to get this to work, as opposed to just a bitcin network by itself (network among people I mean)


What's the point of having a currency that has a fixed exchange rate with USD and centralization, if you can just use USD with centralization?



Completely agree with the first point. I think the fear regarding the second is that those exchanges may not last, and they make HUGE targets for government takedowns. People may not want to keep their money with the exchange if they fear it may be shut down and they can lose everything at any time. The man question for this whole problem is how or where to store the fiat money...

It seems for now there is a necessity to change from a local currency to bitcoin because we don't have enough things to purchase with bitcoins.  Once enough products and services are willing to be exchanged for bitcoins and/or people are paid with bitcoins the use of exchanges won't be a central issue.

Why not just have the P2P exchange allow for trading on the central exchanges (Mtgox, Intersango, ect) using their API?

The central sticking point with all of this is establishing a cryptocurrency which has a fixed exchange rate vis-a-vis the USD. This can be done with
a) some centralization, but b) without any direct interaction with the fiat system whatsoever

I think the Trust problem/part can be solved by a variation of the ripple network : http://ripplepay.com/faq/

But you will need to create a more anonymised version of Ripple so that relationships are not known to all parties; maybe announce 2nd or third degree relations. The full chain of relations is on an encrypted system-specific-blockchain.

After a trade/exchange is confirmed, the system will send out alerts to participants asking for fiat to be passed along the network to eventually reach the trade partners. The system will calculate the most optimised route with least steps. Failure by Ripple participants to carry out an exchange to a trusted node, will result in a penalty to them.

A series of IOU's can also be established to minimise the amount of actual physical transfers needed to carry out the transaction.

An IOU can be purchased by members wanting to join the network-they "announce" to the system that they are willing to contribute $50 FIAT; the next time a transaction can be completed by passing through this "new member" the system will ask this new participant to pass the $50 to the next link (who would be a friend of theirs) and hence gaining the person a $50 credit in the system. {this section about IOU's needs more thinking and eloboration- their are probably gaps)

But basically I think that the Ripple system has a lot to offer.

 

marked. Looking forward to seeing where this goes.

Cryptocoin to Cryptocoin trades are not too difficult. Fiat is the hard part obviously. I have what might actually be a workable method for fiat but am doing a lot of careful consideration and fine tuning of the idea. Where there are potentially large sums of money at stake one can't be careless. I will post it if I feel that it is worthy. Keep sharing your ideas. I have been following and analyzing all of them.

All Best,

Michael

Great concept. It would be very useful/awesom.

That's already a fairly easy thing to do with multi signature transactions. And cryptocurrencies aren't a problem that we're trying to solve. A cryptocurrency exchange is not subject to banking regulations, does not require bank accounts, and in worst case scenario can be run from a completely secret Tor .onion site. Being able to make fiat currencies like USD or Euro work in a distributed fashion is the difficult problem that needs to be solved.

Take a look at this post https://bitcointalksearch.org/topic/m.769090

Federation in this case only means that they are all sharing parts of the same workload and they all export their order books in the same format and have the same trading API. In a sense peers is probably a more accurate term. They wouldnt even need to exchange any information with each other since the actual trade takes place completely in one exchange.

Probably the mistake we are making is considering merchants like Dwolla. USD also needs to be stored in anonymous devices such as visa giftcards or single use credit cards. This would imply that exchanges need a merchant account and this would probably bring down the number of exchanges to say, 1000. Not very high, but not low enough to crush simultaneously.

Can someone set up an exchange to steal money? sure. But they wouldnt get very far since they would be labelled scamsters. If they wait until they have enough customers before stealing money it wouldnt make sense anymore since  its far more profitable to take transaction fees on millions of transactions than to steal a few thousand dollars.

The exchanges wouldnt actually hold the user's money but only charge the visa when filling a transaction. This means they dont need to register as a financial service.

There's still a problem of someone setting up an exchange just to steal money (how will the federation work?), and an even worse problem of Dwolla (example) downloading the client, monitoring all available exchanges, and shutting down accounts of anyone who shows up on that public exchange list.
Don't mean to shut you down, but this problem is tough to crack.

The trust problem does not have a mathematical solution at p2p level.

A realistic solution for the present could be a federated set of exchanges.

While the fears of a government take down of a handful of exchanges is credible, they will never be able to take down say, 10000 exchanges, especially if new ones keep popping every now and then. This would require the client to be able to gather the best bid/ask from a large set of exchanges but this is not that hard to have a few aggregating services that do it for us.

So you could place a bid at any exchange, but when you accept a bid, it goes directly to the exchange that has the best bid with the size that you want.

Use case 1:

A places a bid to buy 1 BTC at $5 at a random exchange X1.
  Fiat Money is transferred from A's bank/dwolla account to his exchange account at X1
  A bitcoin wallet is created for A in X1 if needed.

After some time, A's bid becomes the best bid.

B accepts the Bid.
  Client software sends BTC to X1 and Fiat account info.
  X1 removes the bid and moves $5 into B's fiat account
  X1 moves 1BTC to A's account.

This could be made a bit faster I suppose but the trust problem would be moved from user level to exchange level. A user always has the option of choosing a small set of trustworthy exchange or splitting his transactions among several exchanges to reduce risk of any one bad exchange.

Mike, any updates on the tests or solutions?

Watching.

Good. I am very curious as to what the solution is.

Why not simply focus on the Cryptocurrencies and avoid Fiat trades? Traders can use their own Fiat exit of choice once the cryptocurrency is in their own wallet. (this could possibly avoid govt regulations since its simply Virtual Goods trades)

It would be nice to have the network act as escrow (8+ nodes as so) confirming the terms of the trade.
Orderbook, trade history and escrow is the bare minimum, in my opinion.
So a trader submits a Limit order wanting to buy Bitcoins with Namecoins, the network takes the bitcoins and places it into an escrow account, then waits for a matching order. Partial fills okay, Fill-or-Kills, and time limits enforced.

Oh, and the network collects the fees for acting as escrow.

Just thinking out loud.

Each participant of the ripple network "trusts" one or more participants with a certain amount.
System will find one or more participants nearby who will give you USD 100.
In the future, you will settle your debt with one or more different trustees, using either USD or BTC.

Please see video for an example :
http://www.youtube.com/watch?feature=player_embedded&v=f9KqSgRZYgg