 Show Posts
|
|
Pages: [1] 2 »
|
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. The PeerTrade model is two party peer to peer only. So you need to (somehow) find someone that is willing to trade a given amount of coins at a given price.
How does the system work
|
|
|
|
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. |
|
|
|
This is only awesome if done right with killer features!
:-) 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. |
|
|
|
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. 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!
|
|
|
|
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=== PeerTrade Main Menu ===
You have 0 incomplete trades pending.
You have completed 19 trades to date.
Your options:
[B]egin a new trade
[V]iew a token
[I]ncomplete trades list. Resume/Cancel
[C]ompleted trades list
[A]ll trades list
[Q]uit
What's your pleasure? b
=== Begin a new trade. ===
We need to establish the trade parameters.
You will be given a chance to review all details after they are entered.
Have you received a PeerTrade token from the counter party? [y/N] :
What is the symbol of the currency you are buying? bfc
What is the symbol of the currency you are selling? str
checking for running BFC wallet... OK
checking for running STR wallet... OK
How many BFC are you buying? 20
How many STR are you selling? 15
How many rounds of exchange? [10]
How many receive confirmations do you require? [0]
--- Trade Parameters Thus Far ---
Buy 20 BFC, Sell 15 STR
Send to Address: Not Yet Known ( STR )
Receive at Address: BHNGmGR1eBY5d8RpnXGbzLnDN3XiKwM5zS ( BFC )
Min Receive Confirmations: 0
Number of Rounds: 10
Initial Send: 0.01 STR
Send Per Round: 1.5 STR ( maximum amount risked )
Receive Per Round: 2 BFC
We will obtain the counter party payment address via a token exchange. Any key to continue.
--- Exchange Tokens with Counterparty ---
We created a token containing your payment address and trade parameters.
SEND THIS TOKEN TO THE COUNTER PARTY NOW
( via email, chat, sms, bitmessage, etc )
=== BEGIN PEERTRADE TOKEN ===
NmM5MDk4NzY4MmZkMTE5ZmExYzE0ZmQ4YjJiNjI0
NmV8MXxCRkN8QkhOR21HUjFlQlk1ZDhScG5YR2J6
TG5ETjNYaUt3TTV6U3wyMHxTVFJ8fDE1fDEwfDB8
M2ZhYmM5ZDY=
=== END PEERTRADE TOKEN ===
Have you sent the token? [Y]es, [N]o, [C]ancel y
--- Now we wait ---
The counter party should initiate a trade with your token, and send you a reply token.
Don't worry about me. I'm a computer. I don't mind waiting. ;-)
Please enter the counter party token and press enter or [C]ancel:
=== BEGIN PEERTRADE TOKEN ===
MjQwNDg5NDYyYzMyNzE3NDQ0ZTA2ZWZiYTNjMDIz
MDR8MXxTVFJ8c2JmTDl6dlRnU0VZcmsxNGU4TTRh
QXdiSnR5bWtuTnl1M3wxNXxCRkN8QkhOR21HUjFl
Qlk1ZDhScG5YR2J6TG5ETjNYaUt3TTV6U3wyMHwx
MHwwfDMzNzg4MmRj
=== END PEERTRADE TOKEN ===
checking for running BFC wallet... OK
checking for running STR wallet... OK
== Ready To Begin Trade ==
Buy 20 BFC, Sell 15 STR
Send to Address: sbfL9zvTgSEYrk14e8M4aAwbJtymknNyu3 ( STR )
Receive at Address: BHNGmGR1eBY5d8RpnXGbzLnDN3XiKwM5zS ( BFC )
Min Receive Confirmations: 0
Number of Rounds: 10
Initial Send: 0.01 STR
Send Per Round: 1.5 STR ( maximum amount risked )
Receive Per Round: 2 BFC
Tip PeerTrade Author: 0.075 STR ( 0.5%. Optional )
Please note that if the counter party sends more coins than expected per round, then we will also to catch up.
All systems go. [A]bort, [B]egin, or [C]hange Tip? b
--- Beginning trade Buy 20 BFC, Sell 15 STR ---
2014-03-24 10:36:05 -07:00 -- [0] Sent 0 of 15 STR [0] Rcvd 0 of 20 BFC Ahead: 0 STR
2014-03-24 10:36:12 -07:00 -- [0] Sent 0.01 of 15 STR Ahead: 0 STR
2014-03-24 10:36:21 -07:00 -- [0] Rcvd 0.001 of 20 BFC Ahead: 0 STR
2014-03-24 10:36:25 -07:00 -- [1] Sent 1.5 of 15 STR Ahead: 1.5 STR
2014-03-24 10:36:34 -07:00 -- [2] Rcvd 4 of 20 BFC Behind: 1.5 STR
2014-03-24 10:36:38 -07:00 -- [3] Sent 4.5 of 15 STR Ahead: 1.5 STR
2014-03-24 10:36:42 -07:00 -- [4] Rcvd 8 of 20 BFC Behind: 1.5 STR
2014-03-24 10:36:47 -07:00 -- [5] Sent 7.5 of 15 STR Ahead: 1.5 STR
2014-03-24 10:36:55 -07:00 -- [6] Rcvd 12 of 20 BFC Behind: 1.5 STR
2014-03-24 10:37:00 -07:00 -- [7] Sent 10.5 of 15 STR Ahead: 1.5 STR
2014-03-24 10:37:04 -07:00 -- [8] Rcvd 16 of 20 BFC Behind: 1.5 STR
2014-03-24 10:37:10 -07:00 -- [9] Sent 13.5 of 15 STR Ahead: 1.5 STR
2014-03-24 10:37:18 -07:00 -- [10] Rcvd 20 of 20 BFC Behind: 1.5 STR
2014-03-24 10:37:26 -07:00 -- [10] Sent 15 of 15 STR Ahead: 0 STR
Sent 0.075 STR tip to PeerTrade author. Thank-you, and may it return to you 1000 fold!
Trade is complete!
started: 2014-03-24T10:36:04-07:00
ended: 2014-03-24T10:37:26-07:00
duration: 1 minutes 22 seconds
--- Publish Trade Data To Api.peertrade.org ( Optional ) ==
Publishing your trade helps to set currency prices and establish a viable market.
Would you like to publish this trade? [Y/n]
Trade Published. Trade ID: 7705b53b-44d1-55e8-eee1-b7a5543e5079
******* BACKUP YOUR SENDING WALLET *******
Backup your STR wallet now, or you could lose funds.
Any existing wallet backups may be obsolete.
For the full explanation, read
http://bitzuma.com/posts/five-ways-to-lose-money-with-bitcoin-change-addresses/
It wouldn't hurt to backup your receiving wallet also
although this trade would not affect it.
You have been warned.
******************************************
Press Enter to Continue:
=== PeerTrade Main Menu ===
You have 0 incomplete trades pending.
You have completed 20 trades to date.
Your options:
[B]egin a new trade
[V]iew a token
[I]ncomplete trades list. Resume/Cancel
[C]ompleted trades list
[A]ll trades list
[Q]uit
What's your pleasure?
Alice receives a token from Bob and uses it to initiate the trade=== PeerTrade Main Menu ===
You have 1 incomplete trades pending.
You have completed 20 trades to date.
Your options:
[B]egin a new trade
[V]iew a token
[I]ncomplete trades list. Resume/Cancel
[C]ompleted trades list
[A]ll trades list
[Q]uit
What's your pleasure? b
=== Begin a new trade. ===
We need to establish the trade parameters.
You will be given a chance to review all details after they are entered.
Have you received a PeerTrade token from the counter party? [y/N] : y
=== Begin a trade with token from counter party ===
The token you received from the counter party contains trade details.
Please enter the counter party token and press enter or [C]ancel:
=== BEGIN PEERTRADE TOKEN ===
NmM5MDk4NzY4MmZkMTE5ZmExYzE0ZmQ4YjJiNjI0
NmV8MXxCRkN8QkhOR21HUjFlQlk1ZDhScG5YR2J6
TG5ETjNYaUt3TTV6U3wyMHxTVFJ8fDE1fDEwfDB8
M2ZhYmM5ZDY=
=== END PEERTRADE TOKEN ===
checking for running STR wallet... OK
checking for running BFC wallet... OK
--- Trade Parameters ---
Buy 15 STR, Sell 20 BFC
Send to Address: BHNGmGR1eBY5d8RpnXGbzLnDN3XiKwM5zS ( BFC )
Receive at Address: sbfL9zvTgSEYrk14e8M4aAwbJtymknNyu3 ( STR )
Min Receive Confirmations: 0
Number of Rounds: 10
Initial Send: 0.001 BFC
Send Per Round: 2 BFC ( maximum amount risked )
Receive Per Round: 1.5 STR
The trade will use these parameters. [C]ancel or [N]ext [c/N] :
--- Send Token to Counterparty ---
We created a token containing your payment address and trade parameters.
Please send this token to the counter party you are exchanging with.
( via email, chat, sms, bitmessage, etc )
=== BEGIN PEERTRADE TOKEN ===
MjQwNDg5NDYyYzMyNzE3NDQ0ZTA2ZWZiYTNjMDIz
MDR8MXxTVFJ8c2JmTDl6dlRnU0VZcmsxNGU4TTRh
QXdiSnR5bWtuTnl1M3wxNXxCRkN8QkhOR21HUjFl
Qlk1ZDhScG5YR2J6TG5ETjNYaUt3TTV6U3wyMHwx
MHwwfDMzNzg4MmRj
=== END PEERTRADE TOKEN ===
Once the counter party enters your token, the trade can begin.
Any key to continue
== Ready To Begin Trade ==
Buy 15 STR, Sell 20 BFC
Send to Address: BHNGmGR1eBY5d8RpnXGbzLnDN3XiKwM5zS ( BFC )
Receive at Address: sbfL9zvTgSEYrk14e8M4aAwbJtymknNyu3 ( STR )
Min Receive Confirmations: 0
Number of Rounds: 10
Initial Send: 0.001 BFC
Send Per Round: 2 BFC ( maximum amount risked )
Receive Per Round: 1.5 STR
Tip PeerTrade Author: 0.1 BFC ( 0.5%. Optional )
Please note that if the counter party sends more coins than expected per round, then we will also to catch up.
All systems go. [A]bort, [B]egin, or [C]hange Tip? b
--- Beginning trade Buy 15 STR, Sell 20 BFC ---
2014-03-24 10:36:19 -07:00 -- [0] Sent 0 of 20 BFC [0] Rcvd 0.01 of 15 STR Ahead: 0 BFC
2014-03-24 10:36:30 -07:00 -- [0] Sent 0.001 of 20 BFC [1] Rcvd 1.5 of 15 STR Behind: 2 BFC
2014-03-24 10:36:41 -07:00 -- [2] Sent 4 of 20 BFC [3] Rcvd 4.5 of 15 STR Behind: 2 BFC
2014-03-24 10:36:52 -07:00 -- [4] Sent 8 of 20 BFC [5] Rcvd 7.5 of 15 STR Behind: 2 BFC
2014-03-24 10:37:03 -07:00 -- [6] Sent 12 of 20 BFC [7] Rcvd 10.5 of 15 STR Behind: 2 BFC
2014-03-24 10:37:14 -07:00 -- [8] Sent 16 of 20 BFC [9] Rcvd 13.5 of 15 STR Behind: 2 BFC
2014-03-24 10:37:28 -07:00 -- [10] Sent 20 of 20 BFC [10] Rcvd 15 of 15 STR Ahead: 0 BFC
Sent 0.1 BFC tip to PeerTrade author. Thank-you, and may it return to you 1000 fold!
Trade is complete!
started: 2014-03-24T10:36:08-07:00
ended: 2014-03-24T10:37:28-07:00
duration: 1 minutes 20 seconds
--- Publish Trade Data To Api.peertrade.org ( Optional ) ==
Publishing your trade helps to set currency prices and establish a viable market.
Would you like to publish this trade? [Y/n]
Trade Published. Trade ID: {7705B53B-44D1-55E8-EEE1-B7A5543E5079}
******* BACKUP YOUR SENDING WALLET *******
Backup your BFC wallet now, or you could lose funds.
Any existing wallet backups may be obsolete.
For the full explanation, read
http://bitzuma.com/posts/five-ways-to-lose-money-with-bitcoin-change-addresses/
It wouldn't hurt to backup your receiving wallet also
although this trade would not affect it.
You have been warned.
******************************************
Press Enter to Continue:
=== PeerTrade Main Menu ===
You have 1 incomplete trades pending.
You have completed 21 trades to date.
Your options:
[B]egin a new trade
[V]iew a token
[I]ncomplete trades list. Resume/Cancel
[C]ompleted trades list
[A]ll trades list
[Q]uit
What's your pleasure?
|
|
|
|
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.
|
|
|
|
So I can do this with someone using the same math without peertrade. So what's the point of using the service?
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. |
|
|
|
This is a very well known way to trade, and most would find this not very inspiring. Don't be discouraged when not a lot of members showed interest.
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. The key is implementation and interface. If you can have this interface where you set all the details of the trade and put it in "ready mode", it will complete the full deal bit by bit fully automated whenever a buyer/seller accepts, it would be a killer.
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. What you need is some screen shots of the interface or a video of an actual deal on youtube, then comments and ideas will come.
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. |
|
|
|
Why don't you risk that small amount but instead the exchange can escrow that amount so it's risk free?
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. |
|
|
|
From a brief glance it would appear you only support copy/paste Bitcoin clones (via the RPC), what if I want to trade BTC, XRP, NXT, will it support these different cryptocoin implementations?
If they implement the RPC api for sendtoaddress(), getreceivedbyaddress(), and listtransactions() then they would work. At present I have no plans to support them especially, but that could possibly change. Have you thought about some sort of reputation system, it could be used so that a trade between two reputable people could be broken down into less fractions, requiring less fees.
yes, I have considered a reputation system. It is mentioned in the README todo list. A simple system could be implemented just by including a unique userid (guid generated on each node) in the peertrade token. Then peertrade.org could just display how many published trades each user has. Could also attach comments. Edit: Oh, I see there is no shared orderbook.. PeerTrade simple allows to users to break up a transfer.. Sorry, not as impressive as I first thought  Yeah, PeerTrade is not complex. It is a simple idea. But it does enable transferring large sums with an arbitrarily smaller amount of risk, eg sum/100 or sum/1000. I find centralized exchanges to be much riskier than that. PeerTrade doesn't have its own peer network at present, so there is no shared orderbook in that sense. I am considering adding a central orderbook on the website, and users would be emailed when there is a match. Not ideal, but possibly workable. a dedicated p2p network + orderbook would be outside my expertise. But if anyone here is interested in creating such a thing, you'd be welcome to join the project. Another idea is use counterparty or mastercoin as a shared orderbook. I'm not sure of the feasability of that yet. Anyway, thanks for your comments! |
|
|
|
Ok, I changed the copy on the website to something a bit more sales-y. Ask yourself these questions: Are you fed up with online exchanges that keep losing or stealing your coins? Are you tired of begging them to list your favorite altcoin?
I sure am.
That's why I created PeerTrade. It is simple text-mode software you run on your own computer that connects to your local wallets and enables direct 2-party trades without any central exchange in the middle.
PeerTrade turns a single large exchange into many smaller exchanges, so that only a small amount is ever risked by either party.
So you can exchange coins with confidence directly from your local wallets that you personally safeguard. Plus you can exchange any cryptocurrency for any other without being limited to primary markets.
Right now I am looking for feedback on the core exchange software, so there is no orderbook yet and you will need to find someone to trade with on your own. But plans for an online orderbook are in the works also. Such an orderbook would only list trades and find matches. You would still run the PeerTrade software to execute the trade.
You may get started by downloading PeerTrade and reading through the detailed README file.
|
|
|
|
|
You are a true blue bitcoiner countryfree. i salute you, and thanks for the feedback.
|
|
|
|
Well sure I will be happy to upgrade and improve it if people are actually using it. So far though it seems like pulling teeth to even get anyone to download the software and try it out. I'm not sure if my explanation is not adequate, or people just don't like the idea, or what. It's hard to interpret inaction and silence. Of course I am biased but I think the software is pretty neat. I don't like the central exchanges and this software enables me as a miner to trade altcoins directly with other miners, even the unlisted coins. Now it's true that I could lose a non-zero amount of coins if the other party is untrustworthy, but I get to control exactly what that amount is, and to me that small risk is totally worth it. Like a cost of doing business, or like exchange fees. I think that when people try the software they will be surprised how easy it is to use. It is text-mode, but it walks you through the trade process step-by-step and tries really hard to auto-configure connections to your wallets, and remember settings for next time. Anyway, thanks for the encouragement roslinpl. But each project must be upgraded in future isn't ? just to make it better, more stable etc. And for now it looks very good! Good job! |
|
|
|
in what upgrades? The trading software is working now and is available on github. Just download it and give it a try. I am happy to perform a test trade with anyone that does so. If you mean the website peertrade.org, well I would like to get some feedback from people using the trading software before I devote more time to adding significant website features. If people find the underlying trade mechanism useful, then it becomes worthwhile to build an orderbook around it for matching trades. well I must say this project is very interesting!
I would like to see how it will be developed in the upgrades.
|
|
|
|
Anyone want to trade? Here's your chance to be the Hal Finney of PeerTrade.  |
|
|
|
Wow. This is an interesting concept. I would be very interested in this
Cool. Do you have any altcoins you'd be interested in trading? If you download the PeerTrade software we could give the system a test run. Here's a few I could trade: ELP, STR, IFC, LBW, RVD, ASC, QRK. RPC, DRK, SNC. Would trade any of the above for BTC, LTC, DOGE, PPC. Or for just about any coin, really... it can be a small trade. ;-) |
|
|
|
|
So it's been 24 hours since I started this thread and so far not a single reply. I had hoped some people would try the software out, or at least that there would be some questions and comments. Or someone saying it's a dumb idea, or something.
Silence is golden I guess.
If there were genuine interest, I was planning to work next on building out the peertrade.org website with an orderbook system, so it could match orders, then notify the parties so they could perform the trade. This would essentially be a full exchange website except that the exchange would never hold a single satoshi of the traded funds, and markets would be determined by the decentralized traders, not the exchange.
I am honestly surprised by the complete lack of interest in this project given how many have been burned by all these exchanges getting hacked or absconding with funds. And also how people have had to beg cryptsy and the other exchanges to get their new coins listed. I know there are many coins out there with people holding and mining them, that are not listed on any exchange.
So I'd like to take a little poll. To anyone reading this, I'd like to know your state of mind:
a) Interested, but need more examples/help to get started.
b) Interested, but I don't have anyone to trade with.
c) Very interested. Downloaded software and looking for someone to trade with.
d) Confused. What does this thing do again?
e) Contemptuous. It's a bad idea from the get-go.
f) Lazy. Waiting for a system with an orderbook to find trading partners for me.
g) Risk Averse. I don't want to risk a single satoshi (of any cryptocurrency) when I'm trading, even if I control the max risked amount and it enables a fully decentralized exchange.
h) Uninterested. This all sounds too difficult.
i) Uninterested. I'm happy with the existing exchanges, or I don't trade altcoins.
Or just post your comments.
Thanks!
|
|
|
|
|
