Daniel A. Nagy nagydani

MVP: Single-Node Swarm

Executive Summary

A means for Đapp projects to host their Swarm-based Đapp with a traditional web-hosting service. The Đapp uses Swarm's APIs to access its static assets and data, including modifications. Essentially, it is a single-node Swarm that provides the guarantees (with the obvious exception of censorship resistance) that the distributed Swarm network will provide, once fully operational. Using this product, Đapp developers can focus on developing their application with the confidence that it will become censorship resistant (i.e. "unstoppable"), once the Swarm network will support the features that it uses. The migration to decentralized Swarm will require an upgrade of the node's software and some changes in the configuration but

Sticky Content in Swarm

Introduction

Nodes in Swarm may wish to retain certain chunks for various reasons. For example, they might want to keep certain content available in Swarm either because their operator owns it or because they have been paid to do so. In this document, I propose an extension to Swarm's local database that would facilitate the management of such content.

Authors: Vlad Gluhovsky [email protected], Daniel A. Nagy [email protected]

Introduction

The objective of the presented algorithm is to generate a fair random bit after k blocks in face of an adversary controlling 0 < m ≪ 1 of overall hashing power. More specifically, we assume the adversary to be able to prevent a specific block from being finalized in the block chain with probability m. We consider a coin toss fair, if for any value attached to the outcome, it is possible to set k large enough that the expected cost of influencing the result is greater than the expected profit from doing so.

Algorithm Description

Keybase proof

I hereby claim:

I am nagydani on github.
I am nagydani (https://keybase.io/nagydani) on keybase.
I have a public key whose fingerprint is 84C6 4245 F039 5B32 71E5 B8A0 A47C 89CB C167 EFEF

To claim this, I am signing this object:

	1. Introduction

	Each node in the Ethereum network has a set of tags called "topics" by
	which other nodes may choose to associate with them. They may indicate
	capability, responsibility for certain information or functionality or
	any other attribute by which the node may wish to belong to a connected
	subnetwork of the Ethereum network. In this document, an infrastructure is
	outlined by which nodes of a certain topic may discover one another.

	The presented infrastructure can be used for two distinct purposes:

	In this document, I outline the tasks required for storing and
	presenting the Ethereum block chain and Web-based Ethereum Đapps in
	ipfs. Currently, ipfs is very good at locating and delivering content
	using a global, consistent address space and it has a very well designed
	and implemented http gateway. However, Ethereum's use cases require
	additional capabilities that ipfs currently does not provide.


	Redundancy and persistency

	2015/03/26 15:25:31 [SERV] Protocol Version: 59, Network Id: 100
	2015/03/26 15:25:31 [STATE] (+) 0000000000000000000000000000000000000004
	2015/03/26 15:25:31 [STATE] (+) e4157b34ea9615cfbde6b4fda419828124b70c78
	2015/03/26 15:25:31 [STATE] (+) 6c386a4b26f73c802f34673f7248bb118f97424a
	2015/03/26 15:25:31 [STATE] (+) cd2a3d9f938e13cd947ec05abc7fe734df8dd826
	2015/03/26 15:25:31 [STATE] (+) 2ef47100e0787b915105fd5e3f4ff6752079d5cb
	2015/03/26 15:25:31 [STATE] (+) e6716f9544a56c530d868e4bfbacb172315bdead
	2015/03/26 15:25:31 [STATE] (+) 0000000000000000000000000000000000000001
	2015/03/26 15:25:31 [STATE] (+) 0000000000000000000000000000000000000002
	2015/03/26 15:25:31 [STATE] (+) 0000000000000000000000000000000000000003