Bitcoin Forum
January 16, 2021, 06:24:47 AM *
News: Latest Bitcoin Core release: 0.20.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: PeerTrade - No central exchange, no escrow, no fiat. minimal risk.  (Read 3702 times)
peertrade
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
March 26, 2014, 07:40:16 AM
 #21

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.
1610778287
Hero Member
*
Offline Offline

Posts: 1610778287

View Profile Personal Message (Offline)

Ignore
1610778287
Reply with quote  #2

1610778287
Report to moderator
1610778287
Hero Member
*
Offline Offline

Posts: 1610778287

View Profile Personal Message (Offline)

Ignore
1610778287
Reply with quote  #2

1610778287
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1610778287
Hero Member
*
Offline Offline

Posts: 1610778287

View Profile Personal Message (Offline)

Ignore
1610778287
Reply with quote  #2

1610778287
Report to moderator
1610778287
Hero Member
*
Offline Offline

Posts: 1610778287

View Profile Personal Message (Offline)

Ignore
1610778287
Reply with quote  #2

1610778287
Report to moderator
BenAnh
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500


View Profile
March 26, 2014, 08:01:59 AM
 #22

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.

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.
peertrade
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
March 26, 2014, 08:19:24 AM
 #23

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.
BenAnh
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500


View Profile
March 26, 2014, 08:23:35 AM
 #24

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.
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!
peertrade
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
March 26, 2014, 08:27:22 AM
 #25

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

Code:
=== 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

Code:
=== 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]

Code:

--- 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.
Code:

--- 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
Code:

--- 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
Code:

== 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
Code:

--- 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
Code:

--- 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

Code:

******* 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:

Code:

=== 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

Code:
=== 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  

Code:

=== 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

Code:

=== 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
Code:

--- 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] :
Code:

--- 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
Code:

== 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
Code:

--- 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

Code:

--- 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}
Code:

******* 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:
Code:

=== 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?
peertrade
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
March 26, 2014, 08:46:45 AM
 #26

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!
BenAnh
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500


View Profile
March 26, 2014, 08:57:53 AM
 #27

This is only awesome if done right with killer features!
peertrade
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
March 26, 2014, 09:29:38 AM
Last edit: March 26, 2014, 09:51:28 AM by peertrade
 #28

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.

metacoin
Sr. Member
****
Offline Offline

Activity: 434
Merit: 255


balance


View Profile WWW
March 26, 2014, 12:14:25 PM
 #29

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.

Quote
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:

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 <trade partner's address> in transaction <txid>, I am awaiting their response which should be 0.10 Ycoins.", or "Trade 2: I have received 0.10 Xcoins from <trade partner's address> in transaction <txid> and I am now sending 0.05 Xcoins to <trade partner's address> via the transaction <txid>, 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:
Code:
=== BEGIN PEERTRADE TOKEN ===
MjQwNDg5NDYyYzMyNzE3NDQ0ZTA2ZWZiYTNjMDIz
MDR8MXxTVFJ8c2JmTDl6dlRnU0VZcmsxNGU4TTRh
QXdiSnR5bWtuTnl1M3wxNXxCRkN8QkhOR21HUjFl
Qlk1ZDhScG5YR2J6TG5ETjNYaUt3TTV6U3wyMHwx
MHwwfDMzNzg4MmRj
=== END PEERTRADE TOKEN ===
Which, when base64decoded, results in this:
Code:
240489462c32717444e06efba3c02304|1|STR|sbfL9zvTgSEYrk14e8M4aAwbJtymknNyu3|15|BFC|BHNGmGR1eBY5d8RpnXGbzLnDN3XiKwM5zS|20|10|0|337882dc
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.

peertrade
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
March 26, 2014, 07:16:47 PM
Last edit: March 26, 2014, 07:30:48 PM by peertrade
 #30

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.  Smiley    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.

Quote
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.

Quote
Quote
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".

Quote
Questions

1. What is the significance of the first parameter in the PeerTrade token? For example, "240489462c32717444e06efba3c02304" in this PeerTrade token:
Code:
=== BEGIN PEERTRADE TOKEN ===
MjQwNDg5NDYyYzMyNzE3NDQ0ZTA2ZWZiYTNjMDIz
MDR8MXxTVFJ8c2JmTDl6dlRnU0VZcmsxNGU4TTRh
QXdiSnR5bWtuTnl1M3wxNXxCRkN8QkhOR21HUjFl
Qlk1ZDhScG5YR2J6TG5ETjNYaUt3TTV6U3wyMHwx
MHwwfDMzNzg4MmRj
=== END PEERTRADE TOKEN ===
Which, when base64decoded, results in this:
Code:
240489462c32717444e06efba3c02304|1|STR|sbfL9zvTgSEYrk14e8M4aAwbJtymknNyu3|15|BFC|BHNGmGR1eBY5d8RpnXGbzLnDN3XiKwM5zS|20|10|0|337882dc
http://peertrade.org/view_token.html?token_id=240489462c32717444e06efba3c02304

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

Code:
       // 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.

Quote
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.

Quote
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.

Quote
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.

Quote
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.

Quote
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.  

Quote
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.
peertrade
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
March 26, 2014, 07:42:43 PM
 #31

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
imaginary_coinputer
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
March 27, 2014, 03:24:00 AM
 #32

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.
peertrade
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
March 27, 2014, 06:33:38 AM
 #33

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.
A L X N D R
Newbie
*
Offline Offline

Activity: 2
Merit: 0


View Profile
April 13, 2014, 02:26:44 PM
 #34

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)
teddmarketing.com
Member
**
Offline Offline

Activity: 92
Merit: 10

TeddMarketing agency


View Profile WWW
April 14, 2014, 04:05:14 PM
 #35

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.

TeddMarketing: Curiosity. Creativity. Cryptocurrency.
gondel
Legendary
*
Offline Offline

Activity: 1722
Merit: 1003


View Profile
April 14, 2014, 08:54:14 PM
 #36

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

Activity: 536
Merit: 501


EMC


View Profile
August 12, 2014, 06:43:59 AM
 #37

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

Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!