Topic: P2P Trading Protocol for Bitcoin draft proposal - looking for comments (Read 579 times)
November 16, 2013, 07:05:03 AM
Bitmessage seems great, I'm going to start working on a proof of concept with it.
November 16, 2013, 05:41:51 AM
Quote
I can just say that I haven't found any obvious cons with using Bitmessage as the messaging foundation, that's why I am looking for comments.
I would encourage to use BitMessage for messaging as its proof of work offers a reasonable mechanism against flooding.Besides, there is already a 1000 peers in BM network.
My project Paysty which aims to be a p2p exchange (and already allows for p2p bank transfer<->BTC exchange) will be using Bitmessage as the messaging layer. (I'm working on it as we speak). If you want to know more about BitMessage's potential, jump on #bitmessage on freenode
November 16, 2013, 05:13:51 AM
Could you give a TL;DR for that PDF paper.
(And also put that TL;DR in your original post. Scanning through 6 pages of a technical whitepaper without knowing what to expect in it is no fun)
(And also put that TL;DR in your original post. Scanning through 6 pages of a technical whitepaper without knowing what to expect in it is no fun)
A sybil attack is someone creating false identities to overcome trust in a DHT/p2p network, this paper describes a method to counter that with social links:
3.2 A simple sublinear protocol - http://imgur.com/BCWJW8c
However, I don't even know that this is needed. As we are building a trading network, one could simply offer escrow services on the network as items of trade and it would automatically allow trusted agents with reputation.
Also, let me know what would be the pros and cons of using Bitmessage for the messaging layer in your proposed system?
I can just say that I haven't found any obvious cons with using Bitmessage as the messaging foundation, that's why I am looking for comments.
November 16, 2013, 05:05:47 AM
I like the idea! It is simple yet has anything you want from an exchange protocol! Keep up the good work!
November 16, 2013, 04:57:35 AM
Could you give a TL;DR for that PDF paper.
(And also put that TL;DR in your original post. Scanning through 6 pages of a technical whitepaper without knowing what to expect in it is no fun)
Also, let me know what would be the pros and cons of using Bitmessage for the messaging layer in your proposed system?
(And also put that TL;DR in your original post. Scanning through 6 pages of a technical whitepaper without knowing what to expect in it is no fun)
Also, let me know what would be the pros and cons of using Bitmessage for the messaging layer in your proposed system?
November 16, 2013, 04:47:57 AM
Quote
This is discussed in the last section of the paper.
I did read that section before asking my question.
I got the impression that the only way to know whether or not it was Bob who sent the message is to check the signature on that message.
Is it not so? If it is not, then how?
The signature is checked before peer's relay it to other peers, not every single peer in the network.
A network of trust, this is also strong against sybil as described here - http://pdos.csail.mit.edu/papers/sybil-dht-socialnets08.pdf
Peers can accept trusted from trusted messages as those reasonable to view, and before executing a trade are welcome to take the processing power to verify the message signature themselves.
November 16, 2013, 04:44:34 AM
Quote
This is discussed in the last section of the paper.
I did read that section before asking my question.
I got the impression that the only way to know whether or not it was Bob who sent the message is to check the signature on that message.
Is it not so? If it is not, then how?
November 16, 2013, 04:38:20 AM
Quote
All messages they send to the network include a corresponding digital signature verifying the message.
A potential attacker impersonates an existing peer Bob with good reputation and starts flooding the network with fake messages as if coming from Bob. All other peers will have to check the digital signatures of the fake messages before such messages get discarded. What is the mechanism to prevent such flooding and subsequent consumption of CPU resources of those peers who check the signatures?
This is discussed in the last section of the paper.
Spamming of messages across the network
Peers can simply not accept, and more importantly as it is a p2p protocol not relay messages for peers with negative or low ratings. This gives everyone the chance to start from 0 and grow their influence through their rating.
November 16, 2013, 04:37:08 AM
Quote
All messages they send to the network include a corresponding digital signature verifying the message.
A potential attacker impersonates an existing peer Bob with good reputation and starts flooding the network with fake messages as if coming from Bob. All other peers will have to check the digital signatures of the fake messages before such messages get discarded. What is the mechanism to prevent such flooding and subsequent consumption of CPU resources of those peers who check the signatures?
November 16, 2013, 04:17:40 AM
Jump to: