{"action":"created","issue":{"url":"https://api.github.com/repos/ethersphere/go-ethereum/issues/757","repository_url":"https://api.github.com/repos/ethersphere/go-ethereum","labels_url":"https://api.github.com/repos/ethersphere/go-ethereum/issues/757/labels{/name}","comments_url":"https://api.github.com/repos/ethersphere/go-ethereum/issues/757/comments","events_url":"https://api.github.com/repos/ethersphere/go-ethereum/issues/757/events","html_url":"https://github.com/ethersphere/go-ethereum/issues/757","id":336750864,"node_id":"MDU6SXNzdWUzMzY3NTA4NjQ=","number":757,"title":"Spam protection of Swarm through modifying GC rules","user":{"login":"nagydani","id":374934,"node_id":"MDQ6VXNlcjM3NDkzNA==","avatar_url":"https://avatars2.githubusercontent.com/u/374934?v=4","gravatar_id":"","url":"https://api.github.com/users/nagydani","html_url":"https://github.com/nagydani","followers_url":"https://api.github.com/users/nagydani/followers","following_url":"https://api.github.com/users/nagydani/following{/other_user}","gists_url":"https://api.github.com/users/nagydani/gists{/gist_id}","starred_url":"https://api.github.com/users/nagydani/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nagydani/subscriptions","organizations_url":"https://api.github.com/users/nagydani/orgs","repos_url":"https://api.github.com/users/nagydani/repos","events_url":"https://api.github.com/users/nagydani/events{/privacy}","received_events_url":"https://api.github.com/users/nagydani/received_events","type":"User","site_admin":false},"labels":[{"id":86320164,"node_id":"MDU6TGFiZWw4NjMyMDE2NA==","url":"https://api.github.com/repos/ethersphere/go-ethereum/labels/enhancement","name":"enhancement","color":"84b6eb","default":true},{"id":944641465,"node_id":"MDU6TGFiZWw5NDQ2NDE0NjU=","url":"https://api.github.com/repos/ethersphere/go-ethereum/labels/localstore-refactor","name":"localstore-refactor","color":"53fcb5","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2018-06-28T19:31:00Z","updated_at":"2018-06-29T14:31:13Z","closed_at":null,"author_association":"NONE","body":"Nodes get paid through Swap only when they serve a chunk upon a retrieval request. Thus, Swap incentivizes them to store _profitable_ chunks, i.e. ones that can be expected to be requested soon.\r\nTherefore, it is both in the node's best interest and, as argued below, that of the network, not to treat fresh uploads and syncs identically to retrieval requests, when deciding about which chunk to garbage-collect in the event of saturated storage.\r\n\r\nOne common method of keeping chunks ordered by expected profitability is to keep them in a queue, and move a chunk that has been requested to the head of that queue, whereas garbage collection is performed on the tail. With a suitable data structure, such as a doubly linked list, all aforementioned operations have *O(1)* complexity. Newly synced or uploaded chunks (the two are indistinguishable) can be inserted at the *k*=int(*αn*)th position where *n* is the size of the queue and *α* is a constant real parameter between 0 and 1. Note that while finding the *k*th element in a queue is an *O(k)* complexity operation, tracking the *k*th element requires *O(1)* operations at each update of the queue.\r\n\r\nEven an arbitrarily powerful DDoS attack flooding the network with bogus chunks cannot force a guaranteed fraction (namely *α*) of the most popularly requested chunks out of Swarm. Yet, new uploads are not immediately garbage collected, thus a simple flooding attack won't make uploads impossible either, especially if the uploader is willing to pay the Swap price of moving their content to the front of the queue.\r\n\r\nOf course, the latter option is available to the DDoS attacker as well, but it is not free. The larger the Swarm and the more storage space the nodes have, the more expensive it becomes to effectively DDoS it and a large part of the costs gets directly transfered from the attacker to honest nodes."},"comment":{"url":"https://api.github.com/repos/ethersphere/go-ethereum/issues/comments/401372116","html_url":"https://github.com/ethersphere/go-ethereum/issues/757#issuecomment-401372116","issue_url":"https://api.github.com/repos/ethersphere/go-ethereum/issues/757","id":401372116,"node_id":"MDEyOklzc3VlQ29tbWVudDQwMTM3MjExNg==","user":{"login":"homotopycolimit","id":12838530,"node_id":"MDQ6VXNlcjEyODM4NTMw","avatar_url":"https://avatars3.githubusercontent.com/u/12838530?v=4","gravatar_id":"","url":"https://api.github.com/users/homotopycolimit","html_url":"https://github.com/homotopycolimit","followers_url":"https://api.github.com/users/homotopycolimit/followers","following_url":"https://api.github.com/users/homotopycolimit/following{/other_user}","gists_url":"https://api.github.com/users/homotopycolimit/gists{/gist_id}","starred_url":"https://api.github.com/users/homotopycolimit/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/homotopycolimit/subscriptions","organizations_url":"https://api.github.com/users/homotopycolimit/orgs","repos_url":"https://api.github.com/users/homotopycolimit/repos","events_url":"https://api.github.com/users/homotopycolimit/events{/privacy}","received_events_url":"https://api.github.com/users/homotopycolimit/received_events","type":"User","site_admin":false},"created_at":"2018-06-29T14:31:13Z","updated_at":"2018-06-29T14:31:13Z","author_association":"NONE","body":"or as we just discussed in the standup, we can treat chunks that were requested locally through HTTP requests similarly to synced chunks. That is, we don't insert them at the top of the chunk queue but at some α (either same as for syncing or different α).\r\nThis prevents \"local binge watching of swarmflix\" to completely flush out the local swarm cache of popular/proximate chunks."}}
{"actor":{"display_login":"homotopycolimit"}}