Bitcoin Forum
August 19, 2022, 10:17:17 AM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Bitcoin Discussion / Features of a bitcoin reputation system. on: February 27, 2011, 12:19:14 AM
Lately I've been thinking that a community reputation system for bitcoin would be a very useful thing. I know that other people ( have had similar ideas, but reading that thread I am confused about how the reputation system would actually work in practice, and the idea of a combined stock trading + credit rating + reputation system seems  quite fuzzy to me.

I come to you bitcoin forum, to ask for your advice.

What features would you like to see in a bitcoin reputation system? What successful reputation systems have you used in the past?

The most important qualities I can think of are:

* Must be resistant to sybil attacks. A sybil attack is where one entity constructs multiple fictional personas to rank another entity either up or down. See

* Must be free. I don't think charging for this service would lead to widespread community adoption.

* Must be easy to use & understand. While I like the idea of the #bitcoin-otc web of trust, I feel that the need to IRC adds an additional barrier to entry. In addition, the system must be simple enough for ordinary users to master.

* The service itself must be trusted. I think an opensource model would go along way to help this.

* Should allow both quantitative and qualitative feedback. Quantitative feed back is the kind where you rank a user in a way that can be ultimately resolved to a number (positive/negative, I trust this person completely/mostly/a little/distrust), while qualitative feedback is the kind where you describe your experiences with a person (“A+++ trader, would trade again, prompt payment” etc). Ebay is an example of a mixed system.

* Should be resistant to social pressure to only leave positive feedback. Users should be able to feel like they can rank honestly. I'm not sure how this gels with the point above or not.

* A user chosen level of anonymity.  Users should be able to link other accounts (bitcoin forum/facebook/twitter etc) with their reputation system account, or not, as they choose. Though facebook accounts et al can of course be faked, linking to an account that seems like a real person or company with a long history and obvious interactions with other users would increase confidence.

* An api to allow easy integration with other services. This should allow both read & write access to the reputation system.

One option I am exploring is a web of trust model with two rating options, “how much do I trust this person” and also “how much do I trust this person's ranking judgment”.  Because just because I trust you not to rip me off doesn't mean I trust you not to make poor decisions when it comes to other people. This model would be more resistant to sybil attacks because unless I or someone I knew trusted a sybil account there could be a million sybil accounts on the system and I wouldn't even notice. A decay function ( the further you are away from me in the network, the less your opinion matters) + the ability to decide how much I trust another persons judgment would further reduce the problem of sybil attacks. User ranking of trust and judgement is private to a particular user and is only exposed through the indirect means of people who's judgement I trust. This will encourage honest rankings 

Having an api would mean we could easily "plug-in" other reputation systems into this, i.e. there could be a bitcoin-otc account that reflects the current "opinion" of bitcoin-otc about a particular user (Q: how to link resolve bitcoin-otc user to the reputation system user?). How much you trusted bitcoin-otc as a reputation provider would then be up to you.

How to mix this with a qualitative system allowing arbitrary user feedback I'm not sure of.

This is largely a subjective system, i.e. there is no network wide view of the trustfulness of a particular user (though I suppose one could be calculated), only the view from a particular perspective.

One problem I can see is how new users know who to trust in the first place. If I have no one I trust the judgment of the system effectively becomes useless.

Please let me know your thoughts.
2  Bitcoin / Development & Technical Discussion / "getheaders", how do they work? on: February 03, 2011, 12:53:18 PM
In the course of writing a thin client I'm trying to use the getheaders command to download the initial blockheaders rather than the entire blockchain. As far as I can tell I'm sending the correct packet but no one ever responds with "headers".

The raw packet is:

f9beb4d967657468656164657273000041000000c21430dc016fe28c0ab6f1b372c1a6a246ae63f 74f931e8365e15a089c68d619000000000000000000000000000000000000000000000000000000 00000000000000000000

This should be (from reading the source code)

f9beb4d9... to ...c21430dc raw packet headers
01 varint representing the number of start hashes in the block locator (1)
6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 32 byte hash of genesis block
0000000000000000000000000000000000000000000000000000000000000000 32 byte null stop hash

In theory this should starting pushing "headers" packets in my direction containing block headers starting after the genesis block.

Am I doing anything obviously wrong?
3  Bitcoin / Development & Technical Discussion / Unfinished bitcoin client on: January 27, 2011, 01:57:47 AM
I am slowly working on a bitcoin-android client, but as i have so many projects on the go right now it might take me a while.

I don't really care about the bounty so much as seeing another implementation, so here is what I have to date, which will hopefully help other people writing other implementations.

This code is unfinished, largely untested and probably a bit shit. Java is not my native tongue so I probably use incorrect idioms all over the show. It does contain however:

Base58 encoding/decoding
Keypair generation and signing
Serialisation routines
The beginnings of a blockchain class
A bouncy-castle provider refactored to not interfere with androids bouncy castle
+ other bits and pieces

Though there is no licence file consider this code released under the GPL
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!