Hi metacoin. Thanks for your interest and insightful comments.
This is an incredible idea and I am very impressed with the quality and organization of your code.
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.
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.
Good suggestion. I increased the font size and now displaying full faqs.
How accurate is the trade history on PeerTrade.org?
PeerTrade.org makes no claims regarding accuracy of the published trading information. In fact, we openly acknowledge it can be manipulated and are open to any workable proposals for fixing that.
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:
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".
Questions1. What is the significance of the first parameter in the PeerTrade token? For example, "240489462c32717444e06efba3c02304" in this PeerTrade token:
=== BEGIN PEERTRADE TOKEN ===
MjQwNDg5NDYyYzMyNzE3NDQ0ZTA2ZWZiYTNjMDIz
MDR8MXxTVFJ8c2JmTDl6dlRnU0VZcmsxNGU4TTRh
QXdiSnR5bWtuTnl1M3wxNXxCRkN8QkhOR21HUjFl
Qlk1ZDhScG5YR2J6TG5ETjNYaUt3TTV6U3wyMHwx
MHwwfDMzNzg4MmRj
=== END PEERTRADE TOKEN ===
Which, when base64decoded, results in this:
240489462c32717444e06efba3c02304|1|STR|sbfL9zvTgSEYrk14e8M4aAwbJtymknNyu3|15|BFC|BHNGmGR1eBY5d8RpnXGbzLnDN3XiKwM5zS|20|10|0|337882dc
That is the token identifier. It is an md5 hash of token fields 2..10 concatenated.
// Token format, version 1
//
// Field Contents
// 1 Unique ID for this token. ( md5 of token data )
// 2 Token format version number. For future use.
// 3 receive coin symbol
// 4 receive coin address
// 5 receive coin amount
// 6 send coin symbol
// 7 send coin address
// 8 send coin amount
// 9 number of exchange rounds
// 10 minimum number of receive confirmations
// 11 crc checksum of previous 10 fields.
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.
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.
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?
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.
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.
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.
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.
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.
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.
cool, thanks for setting that up. I'll hop on IRC in a bit.
Lastly, thank you for providing this software to the community. Hopefully it is used to its potential.
:-) Time will tell. I hope it can be useful for people.
