Distributed (well, it can be) secure WOT

[cuddlefish]

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.

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.

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.

[1715243521]

1715243521

[1715243521]

1715243521

[1715243521]

1715243521

[ByteCoin]

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]

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.

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]

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:

*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

• Bruce Wagner's personal efforts & http://btcnearme.com/
• Bitcoin Local - http://www.tradebitcoin.com/ Lots of dealers exchangers in the Northeast
• Ubitex - http://ubitex.org/ubitex/ new site - under construction!
• edit http://blackandyellowpages.com/ - this applies too, more info here
• edit 2 bitmarket.eu - not cash dealer, but interested in GPG integration
• edit 3 dduane's Bitcoin Cambio

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]

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:

*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

• Bruce Wagner's personal efforts & http://btcnearme.com/
• Bitcoin Local - http://www.tradebitcoin.com/ Lots of dealers exchangers in the Northeast
• Ubitex - http://ubitex.org/ubitex/ new site - under construction!
• edit http://blackandyellowpages.com/ - this applies too, more info here
• edit 2 bitmarket.eu - not cash dealer, but interested in GPG integration
• edit 3 dduane's Bitcoin Cambio

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]

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]

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]

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