Official eMule-Board: Transfer Credit - Official eMule-Board

Jump to content


Page 1 of 1

Transfer Credit Rate Topic: -----

#1 User is offline   Mig92 

  • Newbie
  • Pip
  • Group: Members
  • Posts: 1
  • Joined: 22-January 19

Posted 22 January 2019 - 08:03 PM

I don't mind sharing, but waiting to complete downloads for days or weeks while I have uploaded 20TB and downloaded “only” 2 is frustrating. I know the “smart” strategy is to unshare everything except the files I am downloading, but I'm not THAT selfish.
The issue I have comes in part because I upload to client A and download from client B. To put my selfishness on the table: I would benefit if I could transfer credit from A to B. I understand concerns for TFT and the anti trading sentiment on this forum. However, I would challenge anyone to explain why uploading to A and downloading from B is trading.
The basic concept of a payment channel in crypocurrencies is that clients who don't know each other can transfer credit through a chain of intermediaries, where everybody only trusts and deals with their neighbors. In crypotcurrencies this trust between neighbours is enforced by what are called smart contracts.
I don't propose building blockchains and lightning networks, allthough I have to admit this was the starting point of my line of reasoning. My current line of thought is developed through process of elimination.
In essence I realized that we have a quantifiable means of knowing to what extent we can trust the clients we know. We already log it in the credit file. The easy algorithm to quantify the amount of trust we have in a client is 2*(ul-dl), but we can get more fancy, if we want. Our equivalent of a payment channel is asking people who “owe” us if our source “owes” them. And inversely, if someone enters our waiting list, we can ask the people we “owe”, if they happen to “owe” that client. By extension they can also pass on the question.
If the answer is yes we can transfer as much credit as we trust through the channel, and be on our merry ways.
Imagine the situation:
A has uploaded to B, who has uploaded to C, who has uploaded to D.
A now enters the waiting list of D. No credit here. However D is willing to upload to C,who is willing to upload to B,who is willing to upload to A. I think we can all agree routing the actual parts from D to C to B to A is not the most efficient use of bandwith, so I propose D upload to A and all clients update their credit files as if they had routed the amount of parts. In essence that is all.

We need some sensible precautions with respect to confirmation of the transaction. Everything else is efficiency of programming. We can borrow handsomely from path finding and tree searching wisdom to design an efficient implementation. We can supply credit partwise, or differentiate between max allowed credit and actual use of credits.
0

  • Member Options

Page 1 of 1

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users