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 has been 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.
The text was updated successfully, but these errors were encountered:
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
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It's not clear what sort of tampering you are talking about in section 3.4.3:
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.
The text was updated successfully, but these errors were encountered: