Topic: PeerTrade - No central exchange, no escrow, no fiat. minimal risk. (Read 3809 times)

From March to August, no trades! Ballance zero for all currencies. Is this normal?

Hello,
Are people affraid of all these trading bots and new exchanges? "No esrcow"... thatsstrange too

Dear peertrade!

You have a great idea and I am interested in your project development.
I’m representing Teddmarketing communications agency. Our main goal is to help cryptocurrency related projects and bring them up to high level.
We are ready to assist you with website development and the following support.
Please let me know if you are interested.

This is a great idea and I applaud your effort. Just be aware that Ethereum:

https://www.ethereum.org/

will likely make your project obsolete.

I recommend checking out their test net and seeing if you take any ideas for your project away from it (or maybe focus on contributing to the Ethereum project/community)

Excellent.  You might be make history as the 1st person besides myself to perform a trade with the software.

I'll be happy to trade with you if you don't already have a counterparty lined up.  PM me or join #peertrade on freenode IRC to work out specifics.

hey, amazing work OP!
Will be trying it out tommorrow!

I'm in love with a carpe DIEM coin, which has 8 sec transactions, could perfect for peertrading.

I guess you mean, how do you find someone that wants to trade with you?

Well, at present, there is no orderbook so that's up to you.   You could post in this thread or start a new thread looking for counterparties to trade with.  Or start a google docs spreadsheet orderbook, as many altcoins have done before being listed on an exchange.

Once a few people have performed these trades and seem generally happy with the experience of executing trades using the PeerTrade mechanism, I will endeavor to create a shared orderbook of some type.

Hi metacoin.  Thanks for your interest and insightful comments.


That's nice to hear.      I'm glad someone is looking at the code.  Actually the main PeerTrade class should probably be refactored but I originally wrote the thing using all command-line flags and the interactive mode came later and I figured I was just prototyping anyway, so... it is what it is.


Good suggestion.  I increased the font size and now displaying full faqs.


Interesting idea.  A couple of issues though:

1) Nothing stops anyone from doing many trades of arbitrary size with himself at artificially low or high prices.  His signatures would be perfectly valid.  He still controls all the funds, so it doesn't matter what price he trades at.  Those would appear to be valid trades, and could still move the market.  This is actually why I didn't bother too much about transaction validation before, and I still think it is a showstopper.

2) It would also mean that both users must have FlorinCoin wallet installed.  That is a big hurdle given that PeerTrade is intended to enable trading of any two cryptocurrencies.

I suppose that another way to do it using any arbitrary CC would be to take the hash of the signed token(s) and store it in either OP_RETURN or a multi-sig output of the blockchains being traded.   Of course then, the peertrade.org website would need to have wallets running for every CC in order to verify, and that in itself is a big challenge anymore.

Going back to your approach, perhaps instead of the individual nodes writing to florincoin blockchain,  the signed data could somehow be included with the publish_trade() peertrade.org API, and then the server writes it to the FLO blockchain.  It still has the user's signatures, so I don't believe there is a trust issue with the server.   It would need to be thought through some more though.

Or if we make it an entirely optional feature, then the requirement to have florincoin installed is less of a problem.  But anyway we are back to "Trade data accuracy cannot be guaranteed".


That is the token identifier.  It is an md5 hash of token fields 2..10 concatenated.



Good question.  I will address it in the README.  It's a little involved to explain, so I need to figure out a good concise layman explanation.

The short answer is that either party trades first, for every single round.  The parties are actually leapfrogging eachother.  That's why there are actually num_round/2 sends instead of num_round sends.

Each time the total sent or total received amount changes, the code calculates which round "I" am at and which round "they" are at.  If I am behind or at the same round as "they", then "I" go ahead and send an amount to make up the difference.  When both parties using this logic, it has the effect of leapfrogging eachother, and the amount sent for most rounds (except begin or end) is typically amount_per_round*2.  However the amount ahead never exceeds amount_per_round.  If you look at the example trade I posted, you can see the round numbers displayed and see this leap frogging taking place, along with the ahead and behind amounts.

As for the actual very first send, that just depends on who starts the trade first.  But the very first send is actually a tiny "hello" amount to announce that the sending party has begun the trade.  This measure is taken in case the counterparty never begins trading at all, which I deemed a common scenario.  The hello amount is intended to be near the minimum_send amount of the cryptocurrency.  You can find the hello_amount defined in the coin_defaults.json file, configurable per coin.  The hello amount is deducted from the first "real" send so that the total_sent amounts come out to what the user would expect.  The send of the hello amount is the "+1" in the num_rounds/2+1 calculation.

It is also important to understand that the code is not simply running in a loop and printing out "this is what I've sent and received since i started".  Rather, it is querying the wallet software each time for the total amount ever sent and received by my trade-unique address. This is why the resume trade feature works so seamlessly.

An interesting thing to note about the example trade I posted is that Alice's trading screen shows her perpetually behind.  This is because it is a 0 confirmation trade and she is receiving Bob's sends within the ~5 sec polling window.  So we never actually see the moments in time when she is ahead.  But we do in a 1+ confirm trade.  Possibly the trade display in this 0 confirm case could be improved.

You can read the method peertrade::perform_trade() for all the details.


yes, I don't see why not.  That would actually facilitate the token exchange between the parties.

The only hurdle is that right now PeerTrade only runs in interactive mode.  So the website would need to use Expect or something like that to read prompts and send input.  If there is demand, I suppose an API of some type could be added.   Even if it is just a wrapper library that uses Expect under the covers.


yes, it is a bit of a hairball.  Originally the software let both parties choose their own confirm time.  Technically there is no reason why that doesn't work.  But I changed it to a single minconf specified in the token because:

a) It is one less decision point for party B that receives the initial token from party A.  I tried to make that process as streamlined as possible.

b) if party A wants to do a quick trade using 0 or 1 confirms, and party B decides they require six confirms, then they have just made party A hostage to their time schedule.  Whereas when specified in the token, then both parties can see what it will be and either agree to proceed or abort and re-negotiate.

I did address that point briefly in the README.


It certainly can get confusing.  The approach the code uses is to always look at (and name) things according to the perspective of the user running the software. I don't believe that "coin_receive_address" is ever exposed in the UI though.

Oh, I think you may be referring to the display of the token fields on the website.

At present, the code does not differentiate between a party A token a party B token, and both use the same field names.  Perhaps that could be revisited.  In practice it is possible to tell them apart because party A token does not include a value for the send_coin_address, but the party B token has values for both send and receive addresses.

So the website could do something clever and name the fields according to "buy" or "sell" sides for example.  My original thinking was that the token data should be displayed just exactly as it is, without interpretation.

Anyway, I'm open to the idea of a glossary.  Just not sure what should actually go in there.


cool, thanks for setting that up.   I'll hop on IRC in a bit.  


:-)    Time will tell.   I hope it can be useful for people.

PeerTrade team,

This is an incredible idea and I am very impressed with the quality and organization of your code.

One suggestion I have off the bat: please work on the readability of your FAQ! The font is too small, and it is bothersome how I have to click on each section to read it.

Can we work together on a solution for this? Florincoin is the first coin to add transaction-comments, a useful feature for decentralization of permanent historical data. I want to create a fork of PeerTrade that adds this process to the regular PeerTrade protocol:

BEFORE TRADING BEGINS

• Token A is created by user 1 and signed by user 1 using their address in the Token. Token A and its signature are then sent to user 2.
• Token B is created by user 2 and signed by user 2 using their address in the Token. Token B and its signature are then sent to user 1.
• User 1 and User 2 both publish the Tokens and their signatures to the Florincoin blockchain.

DURING TRADING

• After a round, find the last transaction created by the sendtoaddress command.
• Select the address from the first input in that transaction.
• Sign a message with this user's Token address as well as the address in the input transaction that says something like "Trade 1: I have traded 0.05 Xcoins to in transaction , I am awaiting their response which should be 0.10 Ycoins.", or "Trade 2: I have received 0.10 Xcoins from in transaction and I am now sending 0.05 Xcoins to via the transaction , this completes our PeerTrade".
• Send each message along with its signature and the addresses used to sign into the Florincoin blockchain, where it is mined and timestamped in a block.

Each message could be broken down into storing only the minimum relevant information, much like the base64 encoded Token.

In this way, a decentralized trust-based system could be parsed from the Florincoin blockchain as long as users are willing to pay a minimum transaction fee of 0.2 FLO per PeerTrade round (currently 0.2 FLO costs $0.0007). If someone wishes to execute a transaction with 10 rounds of trading and gain reputation for it in a decentralized network, they would be required to pay 2 FLO for that PeerTrade transaction (0.2 per round).

After all of these messages have been sent to the Florincoin blockchain, a parser could easily scan the blockchain for PeerTrade transactions and display them in a readable format. Using a block explorer or independently verifying each transaction via a local RPC call, the community can verify each PeerTrade transaction easily.

Reputation systems can be built upon this as well. Of course, it is easy to "cheat" a reputation system like this by trading with yourself constantly, so the mechanism for acquiring trust would likely have to be worked out by whoever decides to parse the Florincoin blockchain for this information. The most simple solution is to create a standalone community forum or start a thread in the reputation section of this forum. That would be okay for now.


Questions

1. What is the significance of the first parameter in the PeerTrade token? For example, "240489462c32717444e06efba3c02304" in this PeerTrade token:
Which, when base64decoded, results in this:
http://peertrade.org/view_token.html?token_id=240489462c32717444e06efba3c02304

2. Can you add clarification to the trading process and answer the question "who trades first?" in the FAQ and add it to the github README? This is incredibly important, and doesn't seem to be stated clearly anywhere.

3. I think the answer is "yes", but do you think this can be used to host a "vending machine" type website where a server can list coins they have for sale that are distributed via BTC PeerTrade payments?

4. In trade_time_estimates.ods, you list only one column for "min_confirm", but different coins require different confirmation numbers to remain safe. For example, for Bitcoin, 6 confirms is good enough for most transactions, but for Florincoin 6 confirms isn't good at all. Shorter block time means waiting for more confirms to be really sure that there will be no double spend. Especially in newer alt-coins with low hashrates, the chance of a double spend attack is high when a dishonest miner gains a head start with a lucky streak of a few blocks at low difficulty.


Suggestions

1. Let's work on defining some language that will be used to describe the relevant data in a PeerTrade transaction. Maybe add a glossary to the website. I'm not certain whether or not it's good to always call a certain address the "coin_recieve_address" or "coin_send_address", since it's different depending on the context of the user we're talking about, and it gets confusing.

2. IRC


IRC

I have registered #peertrade on webchat.freenode.net, if you wish to take over channel rights please join the channel so I can begin this process. I believe IRC will be an important first-step to building a community that uses this software. Of course, I'll have to audit the code myself before encouraging anyone to join and use it, but it seems legitimate upon first impression.


Lastly, thank you for providing this software to the community. Hopefully it is used to its potential.

:-)    I like your enthusiasm.

I'm not actually sure yet that it is, or will be awesome.  This is a simple idea I had, and I ran with it.  And now I'm releasing it to the community in a useable form to find out if the community finds it useful before I invest too much more time and effort into it.  I'm an engineer, not a salesman, so I try to tell it like it is, and not to oversell.

As I state in the README, it could be that the network fees prove too high for practical use, or that coin developers complain about all the small transactions it puts into the blockchain, causing bloat, or that people are unhappy with how long trades take with 1+ confirmations.   Also, it requires that both parties have running fully synced local wallets for both cryptocurrencies.  That's fine for miners, but a hurdle for average folk.  So yeah I guess that miners, traders, and crypto enthusiasts would be the typical users, not your average Joe with just a blockchain or coinbase wallet and a cryptsy account.

All that said, I still think it is useful, and should find a niche.  If only because I would prefer to trade this way than to rely on centralized exchanges.

But if someone announces a better zero-trust decentralized exchange solution available today, I'd jump on that instead.

It will be awesome when the community norm is to exchange cryptocurrencies right from our local wallets without transferring to a third party first.  However that happens.  I'm offering one solution.

This is only awesome if done right with killer features!

The PeerTrade software would normally be running on your local machine, along with your wallet(s).  If the attacker has access to your local machine, then s/he can likely already send your wallet coins away in a single large transaction, unless your wallet is encrypted and locked.  PeerTrade is not needed for that type of attack.

This is why cold storage is the best idea for large amounts, and internet-connected wallets are called "hot".

Perhaps you mean, what's stopping them from modifying the PeerTrade code itself before the user downloads it?   Well, nothing really if the attacker can convince the user to download the software from an alternative location and install it.  Of course, that's true of just about any software.  social engineering.

The one situation where a modified (trojan) PeerTrade software could be useful to an attacker is if the user already trusts PeerTrade and decides to let PeerTrade unlock their encrypted wallet by entering their passphrase into PeerTrade.  Then a modified version of the software could do something malicious that some other generic trojan the user downloaded could not.  Note that the wallet unlocking feature is an optional convenience, and the user is given the option to unlock their wallet themselves manually directly in the wallet software.

If PeerTrade begins to become adopted, i will be sure to publish checksums of each release download so that the user can verify they have a valid version.  That is what standard package management systems do.  It's a pity github doesn't seem to do that automatically.

anyway, thanks for the comments!   I'll sleep on the escrow thing.

Ok, Bob and Alice decided to trade 20 Butterflycoin ( BFC ) for 15 Starcoin (STR).  

If they were best buddies, they could simply send eachother the full amounts, but they only know eachother from a web forum, so they opt to use PeerTrade.  

Below is what each party sees.  Note that this is presently text-mode, but could just as well be a GUI wizard.

Bob initiates the trade and defines trade parameters

---

Alice receives a token from Bob and uses it to initiate the trade

Just saying if this can be done automatically, what's preventing a hacker to inject malicious code to withdraw thousands of accounts with small amounts = BIG!

I will need to think through this when I'm fresh.  ( Late now. )   If it can be done with multi-sig, that would be a lot cleaner than invoking a 3rd party.

Don't you think now it's safer that you only escrow that small amount and this means no risk whatsoever to anyone instead of risking a small amount? So you want everyone to risk a small amount or risk nothing at all with PeerTrade? Think about it, how tough or how difficult to get this done and the benefit is huge if implemented properly.

Yes!  You absolutely can.  If both of you wish to sit at your computers waiting for each payment and then entering in the next one.  All 20 or 100 or 500 or whatever of them.  The point of the software is to coordinate and automate this tedium that almost no one would be willing to do, much less two people at the same time.

I started writing the software because I asked the question:  what prevents two parties from exchanging directly instead of using a centralized exchange?  And the answer was that neither party trusts the other party with all the funds, so no one wants to send first.   But if those funds can be broken down into small enough pieces, then neither party cares so much about a particular chunk and it also isn't very profitable to scam people, especially when it means damaging your reputation.

Like, I wouldn't just send you $100 dollars all at once.  But if I could just send a dollar at a time, and I get a dollar worth of value back from you each time, then hey why not?

Also, I should point out that PeerTrade is not really a service.  It is software that you run on your own computer under your control.  So a second very important point is that you never have to transfer your coins to a "service" such as an exchange that have proven themselves unreliable over and over again.

So I can do this with someone using the same math without peertrade. So what's the point of using the service?

Good feedback, thanks.  That's actually why I released this now rather than spending any more time on it.  I wanted to find out if there would be much interest.  So far, the answer seems to be no.

You say it is well known.  Perhaps the idea is, though I haven't seen it discussed anywhere, and I'm likewise unfamiliar with any other software that implements it.  Can you point me towards software that does this, or towards some documentation or discussion of the idea?

Uninspiring or not, I have heard so much complaining about centralized exchanges I had hoped more people would be willing to at least download the software and give it a quick try before dismissing out of hand.  


Yes, that it is pretty much what it does.  See the example trade in the 2nd comment of this thread -- the actual exchange of funds is fully automated.  I have tried to make the setup as simple as possible.  For example, the software tries very hard to auto-configure wallet connections, deal with encrypted wallets, and so on.  It presents a wizard that guides the user through the trade process.  Actually, all the setup stuff was the hard part.... I had the exchange code written the first day.

 * Bob enters in the currency symbols to trade, how much to buy and sell, how many rounds, and min_confirmations.  
 * The software generates a token that encodes this information and also a newly generated receive payment address.  
 * Bob sends the token to Alice.  
 * Alice enters it into her PeerTrade, and it generates a token with the same info and a newly generated payment address.  
 * Alice sends this to Bob and starts the transfer.  
 * Bob enters in Alice's token, which gets verified, and starts the transfer.
 * Exchange runs, fully automated on both sides until it completes.
 * If exchange is interrupted by either party, it can be resumed on both ends.


I will post a full a..z exchange from both points of view, for starters.   I agree a video would be helpful.  I'm not skilled at video production.  I'm hoping someone else can do that.  

Again, thank-you for your insightful comments.

There is no "exchange" entity to perform the escrow.  The transfers are direct between the 2 parties.  That's the point.

If we introduce an escrow agent between the parties, then we are back to trusting a third party.  In theory, yes we could do a lot of small transfers so we are only trusting the third party with a little bit at a time, but it is also doubling the number of transfers which means at least doubling the time and network fees.  I don't believe it is workable, and anyway it is not PeerTrade.

Of course anyone is welcome to fork the code and introduce a third party escrow if desired.