Bitcoin Forum
December 02, 2016, 08:30:19 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Distributed (well, it can be) secure WOT  (Read 1053 times)
cuddlefish
Full Member
***
Offline Offline

Activity: 126



View Profile
May 04, 2011, 12:25:36 AM
 #1

So say Alice wants to do some transaction with Bob. Bob and Alice both have RSA keys of a decent length.

Before the transaction takes place, Alice gives Bob a piece of JSON that contains her public key fingerprint, a unique transaction ID, her email address (optional) and a UTC timestamp (Or, for bonus crypto points, the current block number!). Bob signs it with his key, and gives Alice the signature; Alice verifies it. Then Bob does the same to Alice. I'll call this JSON-1 because I am unimaginative.

Then the transaction takes place.

Now, Alice creates and signs a piece of JSON that contains her unique transaction ID, another timestamp, Bob's entire public key, a rating for Bob from -5 to 5, and an optional comment. Bob does the same with Alice's key, transaction ID, and timestamp. This is JSON-2.

Bob and Alice then submit all of the JSON (both the JSON generated before and the JSON generated after the transaction) to a trust server. This can be anything that can host a text file and look it up with a key: a DHT comes to mind.


Quote from: Case 1
They are both very happy with the transaction. The next time Bob deals with someone, he sends him both the pieces of JSON Alice signed. The other party can verify it and see that Alice trusts Bob. Then the other party sends Bob's public key to several trust servers, to see if the trust servers have any JSON-1s signed with Bob's key that do not have a matching JSON-2. There are none, in this case, so Bob's rating is whatever Alice gave him.


Quote from: Case 2
Alice rated Bob negatively. The next time Bob deals with someone, he doesn't send the JSON about the transactions with Alice, because they'd bring his rating down. But when the other party sends Bob's public key to several trust servers, they come back with Alice's JSON-1, or both JSON-1 and JSON-2. If only the JSON-1 comes back, then Bob gets counted as getting the maximum negative rating. Otherwise, Bob gets the rating in the JSON-2.

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

Posts: 1480710619

View Profile Personal Message (Offline)

Ignore
1480710619
Reply with quote  #2

1480710619
Report to moderator
1480710619
Hero Member
*
Offline Offline

Posts: 1480710619

View Profile Personal Message (Offline)

Ignore
1480710619
Reply with quote  #2

1480710619
Report to moderator
1480710619
Hero Member
*
Offline Offline

Posts: 1480710619

View Profile Personal Message (Offline)

Ignore
1480710619
Reply with quote  #2

1480710619
Report to moderator
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
May 04, 2011, 12:54:05 AM
 #2

So say Alice wants to do some transaction with Bob. Bob and Alice both have RSA keys of a decent length.

It's not necessary to bring RSA into it unless you have special needs like blinding or a lack of message expansion. If Bob and Alice use Bitcoin then they both have perfectly serviceable public/private keypairs. It also sounds like you only want to sign so ECDSA is fine.

Your protocol has at least the flaw that an attacker BadBob can generate very large positive ratings for themselves by creating multiple DummyAlices who give positive ratings for large numbers of arbitrary transactions. This is because, in your scheme there's nothing making sure that the Bitcoin transaction referred to is a transaction involving either Alice or Bob at all.

ByteCoin
cuddlefish
Full Member
***
Offline Offline

Activity: 126



View Profile
May 04, 2011, 12:56:43 AM
 #3

So say Alice wants to do some transaction with Bob. Bob and Alice both have RSA keys of a decent length.

It's not necessary to bring RSA into it unless you have special needs like blinding or a lack of message expansion. If Bob and Alice use Bitcoin then they both have perfectly serviceable public/private keypairs. It also sounds like you only want to sign so ECDSA is fine.

Good point.
Quote
Your protocol has at least the flaw that an attacker BadBob can generate very large positive ratings for themselves by creating multiple DummyAlices who give positive ratings for large numbers of arbitrary transactions. This is because, in your scheme there's nothing making sure that the Bitcoin transaction referred to is a transaction involving either Alice or Bob at all.
Yes, there is, since the signature is checked. Bob's trust is entirely based on Alice's key.

PLATO
Sr. Member
****
Offline Offline

Activity: 277


Subversive


View Profile WWW
May 04, 2011, 03:35:47 AM
 #4

The advantage of using GPG (RSA) keys is, first off, that there is already a sizeable WOT based upon these keys. Second, GPG keys seem to be a useful platform for several under-development WOT networks. If we limit this system to Bitcoin ECDSA keys, it's only useful for Bitcoin. I think that it's important that we pick a standard API to exchange WOT data across different sites. This interoperability would be great.

Pasting from my post here:
Quote from: PLATO
*snip*
The primary means of 'getting in' for most new users will be cash. There are a handful of projects that are attempting to set up a global network of cash-to-bitcoin-to-cash dealers; the ones I know about are


We should integrate all of these efforts right now, while they're all still in development. It's inevitable that some efforts will fail, so we should try to make the system robust enough to absorb those failures. We should have a common way to identify a particular exchanger that is exportable to multiple websites (i.e. a GPG key.) #bitcoin-otc already has a significant web of trust set up, and it's not hard to integrate import that into other applications.

If we have multiple sites using information from a single web of trust, we should decide on a common API to communicate between those sites. Right now, the OTC database records a user ID (gpg key), a rating from -10 to 10, and a notes field. This is fine for -otc, but other sites will likely want to record additional information in their own webs.

Some stuff that might be saved in a WOT database: contact information, services offered, currencies offered, availability times, trade volume limits, rough GPS coordinates.

If we agree on a protocol such that all sites can share data, we can make the whole Bitcoin economy a 'decentralized exchange.' When any one site fails, another can take its trust database and start with that. To avoid tampering the databases should probably be public knowledge.

An attacker can always make as many shill accounts as they want, but it will be difficult to gain enough trust to perform repeated scams. A smart WOT database could go as in-depth as desired while calculating trust ratings. Perhaps it can identify if a subset of users consistently rate each other highly, but rarely rate outside their local group. Then, when one of these scams someone, the others in that subnet can have slightly lowered trust ratings for later transactions.

I imagine that we will see some really neat trust algorithms evolving.
cuddlefish
Full Member
***
Offline Offline

Activity: 126



View Profile
May 04, 2011, 04:15:46 AM
 #5

The advantage of using GPG (RSA) keys is, first off, that there is already a sizeable WOT based upon these keys. Second, GPG keys seem to be a useful platform for several under-development WOT networks. If we limit this system to Bitcoin ECDSA keys, it's only useful for Bitcoin. I think that it's important that we pick a standard API to exchange WOT data across different sites. This interoperability would be great.

Pasting from my post here:
Quote from: PLATO
*snip*
The primary means of 'getting in' for most new users will be cash. There are a handful of projects that are attempting to set up a global network of cash-to-bitcoin-to-cash dealers; the ones I know about are


We should integrate all of these efforts right now, while they're all still in development. It's inevitable that some efforts will fail, so we should try to make the system robust enough to absorb those failures. We should have a common way to identify a particular exchanger that is exportable to multiple websites (i.e. a GPG key.) #bitcoin-otc already has a significant web of trust set up, and it's not hard to integrate import that into other applications.

If we have multiple sites using information from a single web of trust, we should decide on a common API to communicate between those sites. Right now, the OTC database records a user ID (gpg key), a rating from -10 to 10, and a notes field. This is fine for -otc, but other sites will likely want to record additional information in their own webs.

Some stuff that might be saved in a WOT database: contact information, services offered, currencies offered, availability times, trade volume limits, rough GPS coordinates.

If we agree on a protocol such that all sites can share data, we can make the whole Bitcoin economy a 'decentralized exchange.' When any one site fails, another can take its trust database and start with that. To avoid tampering the databases should probably be public knowledge.

An attacker can always make as many shill accounts as they want, but it will be difficult to gain enough trust to perform repeated scams. A smart WOT database could go as in-depth as desired while calculating trust ratings. Perhaps it can identify if a subset of users consistently rate each other highly, but rarely rate outside their local group. Then, when one of these scams someone, the others in that subnet can have slightly lowered trust ratings for later transactions.

I imagine that we will see some really neat trust algorithms evolving.

Well, there's a reason a WOT is called a WOT... don't just count all incoming trust ratings, only count with N-distance < 5 or so.

cuddlefish
Full Member
***
Offline Offline

Activity: 126



View Profile
May 04, 2011, 07:42:37 AM
 #6

Does this clear it up?
<cuddlefish> Before you do a transaction, each party signs a bit of data that establishes that they are going to transact with eachother
<cuddlefish> Afterwards, they rate eachother and sign the ratings.
<cuddlefish> if 2 people said they were going to do a transaction, but the one you're trying to check ratings for won't tell you how it turned out
<cuddlefish> you can be very suspicious

PLATO
Sr. Member
****
Offline Offline

Activity: 277


Subversive


View Profile WWW
May 04, 2011, 07:44:51 AM
 #7

Does this clear it up?
<cuddlefish> Before you do a transaction, each party signs a bit of data that establishes that they are going to transact with eachother
<cuddlefish> Afterwards, they rate eachother and sign the ratings.
<cuddlefish> if 2 people said they were going to do a transaction, but the one you're trying to check ratings for won't tell you how it turned out
<cuddlefish> you can be very suspicious

I wrote up detailed instructions for doing this with GPG - http://wiki.bitcoin-otc.com/wiki/GPG_Contract
nanotube
Hero Member
*****
Offline Offline

Activity: 485


View Profile WWW
May 08, 2011, 05:15:24 AM
 #8

it's a good idea - though the presence of double-signed contract should be optional. would mostly be useful for cases where you (for whatever reason) decided to transact without a contract, and then got scammed and want to post a negative rating. Smiley obviously for a positive one, both parties would be willing to make the contract ex-post.

then, just post these bits of data onto any distributed data store, and you can have 'aggregator' services providing data lookup.

Join #bitcoin-market on freenode for real-time market updates.
Join #bitcoin-otc - an over-the-counter trading market. http://bitcoin-otc.com
OTC web of trust: http://bitcoin-otc.com/trust.php
My trust rating: http://bitcoin-otc.com/viewratingdetail.php?nick=nanotube
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!