View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001369 | GNUnet | file-sharing service | public | 2008-06-19 08:36 | 2012-11-05 18:34 |
| Reporter | amatus | Assigned To | Christian Grothoff | ||
| Priority | low | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.9.4 | Fixed in Version | 0.9.4 | ||
| Summary | 0001369: Add trust_spent to CS_fs_reply_content_MESSAGE | ||||
| Description | A client might want to know how much trust was spent in receiving the reply to a query. Either to display to the user, or maybe to attach some priority to the content if it were to automatically reinsert it. | ||||
| Tags | No tags attached. | ||||
|
|
We won't do this, and here is why: 1) the peer could lie about it 2) we could never know if he lied 3) if we acted on it, the peer could manipulate our behavior 4) if peers gave honest replies, their honest answers could be abused (see economy paper: if I know that you don't charge me, I could (ab)use your idle resources knowing that I would not get charged/penalized) 5) if peers gave honest replies, adversaries could deduce details about their load (which would -- to a small extent, but nevertheless -- reduce the anonymity of their local user(s)). So in conclusion, this feature would rely on honest peers hurting themselves, which violates one of the core principles of the design: peers act primarily to help themselves and all data that we act upon is somehow (cryptographically) validated to be accurate. |
|
|
The peer must have some idea of how much effort it put into filling a request, weather that be how much trust it thinks it spent, or how many retries it sent, or how many seconds it took to get the response. That information is just thrown away when it could be recorded and sent to the client. Maybe giving the user an idea of how hard it was to get their search results or file downloads, or I was thinking of using such a metric for gnunet-fuse because I want to automatically re-publish every block it downloads with some kind of meaningful priority. |
|
|
Oh, I misread something: you're talking about the CS-reply message, not the P2P reply message. Big difference. Obviously on the CS-side we don't have to worry about trust/anonymity and other things (I somehow missed the "CS" part and just read "content reply". Certainly we could add some information to the CS-reply, the question is what data is actually worthwile. Trust *offered* (not spent, that's what got me on the P2P-path), is one metric. Number of queries transmitted maybe another good metric to have (we could spend almost no trust but transmit it 500 times...). |
|
|
Implemented in SVN 22219. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-06-19 08:36 | amatus | New Issue | |
| 2008-06-22 10:06 | Christian Grothoff | Note Added: 0003526 | |
| 2008-06-22 10:06 | Christian Grothoff | Status | new => closed |
| 2008-06-22 10:06 | Christian Grothoff | Resolution | open => won't fix |
| 2008-06-22 14:02 | amatus | Status | closed => feedback |
| 2008-06-22 14:02 | amatus | Resolution | won't fix => reopened |
| 2008-06-22 14:02 | amatus | Note Added: 0003532 | |
| 2008-06-26 01:38 | Christian Grothoff | Note Added: 0003557 | |
| 2010-05-27 11:40 | Christian Grothoff | Project | GNUnet 0.8.x => GNUnet |
| 2010-05-27 11:54 | Christian Grothoff | Priority | normal => low |
| 2010-05-27 11:54 | Christian Grothoff | Product Version | current SVN => |
| 2011-11-04 11:10 | Christian Grothoff | Status | feedback => confirmed |
| 2011-11-04 11:10 | Christian Grothoff | Category | GAP => file-sharing service |
| 2012-02-21 21:54 | Christian Grothoff | Product Version | => Git master |
| 2012-02-21 21:54 | Christian Grothoff | Target Version | => 0.9.4 |
| 2012-05-03 01:17 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2012-05-03 01:17 | Christian Grothoff | Status | confirmed => assigned |
| 2012-06-23 10:36 | Christian Grothoff | Note Added: 0006137 | |
| 2012-06-23 10:36 | Christian Grothoff | Status | assigned => resolved |
| 2012-06-23 10:36 | Christian Grothoff | Fixed in Version | => 0.9.4 |
| 2012-06-23 10:36 | Christian Grothoff | Resolution | reopened => fixed |
| 2012-11-05 18:34 | Christian Grothoff | Status | resolved => closed |
