You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 13, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 13, 2023. It is now read-only.
It's not clear what sort of tampering you are talking about in section 3.4.3:
BitSwap nodes keep ledgers accounting the transfers with other nodes. This allows nodes to keep track of history and avoid tampering
To be honest, this seems like a very important section of the paper, if not the most important, but it's unclear why a rational peer wouldn't loose their ledger.
When activating a connection, BitSwap nodes exchange their ledger information. If it does not match exactly, the ledger is reinitialized from scratch, losing the accrued credit or debt. It is possible for malicious nodes to purposefully "lose" the Ledger, hoping to erase debts.
bitswap is notoriously underspecified in DRAFT 3. DRAFT 4 will do better.
To be honest, this seems like a very important section of the paper, if not the most important, but it's unclear why a rational peer wouldn't loose their ledger.
this is a feature, like any other. A peer repeatedly losing a ledger erodes trust. with all of these what you want is the nodes to be free to measure whatever parts of the interaction they deep relevant and decide trustworthiness themselves. goal is to ship an ok base case and a few interesting choices
Activity
jbenet commentedon Jun 26, 2015
bitswap is notoriously underspecified in
DRAFT 3.DRAFT 4will do better.this is a feature, like any other. A peer repeatedly losing a ledger erodes trust. with all of these what you want is the nodes to be free to measure whatever parts of the interaction they deep relevant and decide trustworthiness themselves. goal is to ship an ok base case and a few interesting choices