First, thanks for taking the time to read and respond.


Thanks for the link. One of the first things we noticed about micropayment channels is that each payment must eventually be resolved into a traditional Bitcoin transaction (involving traditional confirmation times and transaction costs) before the receiver can use the funds. However, one of the fundamental features of the server we've described is the ability to tip another account any amount (possibly sub-satoshi) instantly and cheaply. This feature of the server is an important one for social networking and other applications, and the only way to do this is to use a deposit holding server. In addition, each of the available commands--tip, store data, query, and withdraw--must be able to charge less than a single satoshi in order to accurately transfer the cost of processing to the user without vastly overcharging (this is true at today's price of Bitcoin, and of course will only get more true as the price of Bitcoin rises).


The primary reason for the microbilling is, in fact, to pay for the infrastructure and processing. The fees will be vanishingly small to the casual user: the service could be used for years with a single small deposit.

We acknowledge that charging for each action doesn't prevent all forms of abuse, but it does guarantee that the server is never freeloaded. This is important because it allows the server to accept a request from anything, whether it's a bot or a person, and allows services to be built on top of the server without an approval process or cooperation from some centralized party. Amateur or professional, for-fun or for-profit, encrypted or transparent--it makes no difference--the server is funded.

Spam is another problem, and charging for each action is only the smaller part of our solution to this. The more important feature of the server is the ability to incorporate tip-history into data-browsing algorithms, which is detailed in the paragraph under "A New Paradigm of Social Networking" that begins with "A particularly intriguing...". This idea is very exciting to us. To sum it up, an algorithm can follow tip-trails outward from a legitimate user's identity to find new, valuable content, while any spam remains buried. That means that for any given user, this type of algorithm would prioritize subjectively valuable content, as judged by tips from that user and their network, over everything else. In this light, spam means any content that has not received any (or has received very little) voluntary tips from the user or their associates--not only unwanted advertisements, but any unwanted content.

For anyone to get their content seen by a given user who hasn't chosen to follow them, they must get a financial endorsement from some identity that the user has already valued. This will only be possible if that identity is willing to send a tip at their own expense (which is a good indication that it has some value), or if the identity is paid more than the tip amount (which is really just a grassroots version of legitimately paid advertising).

(Note: The server and the idea of using it for social networking, described below, both came from a post on Reddit a while ago: reddit.com/r/Bitcoin/comments/1evg5n/proposingintroducing_a_centralized_and/. After reading that and contacting some of the people involved in the project, we began writing this post simply to break down and explain some of these concepts more clearly. However, along the way we've become familiar enough with the ideas to contribute some of our own thoughts.)

Introduction / Abstract:

In this article, we'll introduce the concept of a nanocompensated server, and show how a specific type of nanocompensated server can lead to a new paradigm of social networking.

Traditional free services (like Reddit, Imgur, forums, etc.) must impose restrictions to avoid "abuse". Things like CAPTCHAs, prevention of alts, and IP tracking are all annoyances that we've come to assume are necessary to curb this abuse. The traditional alternative is fee-based services, which cost the user at least the cost of a Bitcoin transaction--about five cents--along with the effort of payment.

In contrast, a nanocompensated server uses internal processing to charge tiny, sub-satoshi fees that scale for each and every action requested of it, nibbling away at an initial deposit. The user may then request any number of trivial or complex actions without traditional restrictions and without further effort of payment. In our specific case, these fees are negligible--a casual user could make a very small deposit and use the service for years. The server can never be abused, the user is never restricted, and no further payment is requested.

By implementing a nanocompensated server that is transparent and signature-based, and offers arbitrary data storage and fund transfers between accounts, a backend server for social networking is created that has some very exciting characteristics:

• completely transparent and verifiable (any non-user-approved meddling would become immediately mathematically obvious)
• harnesses the competitive and cooperative powers of open-source development without requiring a slow contribution-approval system (like github's push/pull system)--all without fracturing the social data itself
• not only allows tipping, but has tipping embedded into the system--tipping will be even easier than posting a comment
• enables the use of an unlimited number of fully anonymous aliases, while eliminating problems of spam and abuse
• cryptographically responsible behaviors (like message signing and data encryption) will become trivial to perform for even casual users
• puts the control of privacy into the users' hands, removing it from any centralized systems

Transparent Signature-based Nanocompensated Server for Data Storage and Tipping

The server will store a Bitcoin address for each account it maintains. For the account to be used, a command must be sent to the server, signed with the corresponding private key. Each command and its signature will be stored and publicly viewable, so any interested party can easily verify the legitimacy of any action. Again, each command has a fee, drastically less than one satoshi, deducted from an initial deposit, to pay off the very small server cost of executing the command.

An account can direct the server to perform the following commands:

• Send some amount of value to another account, specified by a Bitcoin address (hereafter referred to as "tipping"). If the system has no account for the specified address, an account will be created for it (again, the owner of the specified Bitcoin address can control this new account via signed commands). Because this system is server-based, the tips have the following advantages over traditional Bitcoin transactions:
  
  • instantaneous
  • sub-satoshi denominations
  • microscopic fees (deducted from an initial deposit)
  • no tip is too small (no "dust")
• Publicly store arbitrary data to the server (encrypted or not) under the account's identity
• Query any public data stored on the server (commands, accounts, tips, or stored data)
• Withdraw funds to a Bitcoin address through a traditional Bitcoin transaction

A Note on Deposits, Withdrawals, and Security

We understand security is a critical issue, and are especially eager for feedback on this section.

We envision two servers: one public, and one hidden. The public server knows no private keys at all, and completes, without assistance from the hidden server, all actions other than withdrawals. The hidden server knows the private key to the "deposit address". When the public server notices a new Bitcoin transaction has been sent to the deposit address, it creates an account for the sending address of the transaction (if it doesn't already have one), and adds the value of the Bitcoin transaction to that account's balance. When a signed withdraw command is received, the public server deducts the funds from the account and stores the withdraw request in a public database. The hidden server, at semi-regular random intervals, queries the public server's databases through Tor. It first verifies that the public server's records are legitimate by checking signatures, then checks to see if any new withdraw commands have been made. If there are legitimate (correctly signed) withdraw commands, the hidden server signs the necessary Bitcoin transactions, then sends the signed transactions to the public server. The public server then broadcasts the signed transactions, completing the account's withdraw command. Note that this will all be accomplished without the public server needing to know anything about the behavior or location of the hidden server. Because the public server has no private keys to steal, and assuming the hidden server stays truly hidden, the only way an attacker could steal Bitcoins would be to actually steal an account's private key from the account holder--which would, of course, only yield that single account's funds.

A New Paradigm of Social Networking

What would a social network look like, if the described server were used as a backend for the social data?

Most importantly, there is no way to subversively affect the system. The server will ignore any command without a correct signature, and record the signature of each authorized command--allowing any interested individual to verify the legitimacy of any action.

The basic implementation of a social network is vastly simplified. After rudimentary data upload and browsing tools are created, users can begin to use the social network. Then, because the data will be non-proprietary and public, any other developer can upgrade these tools or create better ones that operate on the same data. The tools will quickly evolve to include features like message encryption/decryption, signature verification, and any other desired features. People may own the tools, but no one can control the data. This opens up the network to the competitive and cooperative powers of open-source development: any imagined feature can be immediately implemented by any capable developer, yet the social data is never fractured.

The development of supplementary tools is similarly simplified. Without any approval process, a developer can make an app to analyze public social data, and/or post data under an address that the tool owns. With a user's permission (via a private key or a signature request), tools that post data on the user's behalf can be easily created. Now this new social network has an absurdly simple API for app development, and does not require any approval beyond that of the developer and the user. All a developer needs is a new idea for a way to contribute to or interpret the data, and the entire network is open to the innovation. (The ease with which a developer can make a tool to interact with the server isn't limited to social applications, but that's too large of a subject to get into here)

In addition, this network would have tipping not just enabled, but embedded into the system. As stated before, the tips are virtually free compared to traditional Bitcoin transactions, finalize instantly, and can handle much less than a satoshi of value. Imagine a social network with a "tip" button that has microscopic fees, no minimum tip amount, and a memo field--and is as easy to use as a "like" button.

A particularly intriguing application of the last two points is the incorporation of tipping history into data-browsing algorithms. For example, instead of limiting a search to a discrete group of individuals that the user has designated as friends, an algorithm could follow a trail of tips sent from the user's account (or any other specified account or group of accounts). Following tip-trails outward from an account has many advantages over other types of searches: results can be ordered by how much the user has valued the author, as measured by first-degree tipping (user -> author) or nth-degree tipping (user -> other account(s) -> author); the user can hear from new identities found via tip trails; and spam is completely avoided, as no one will tip to an identity that provides no value.

With most services, alt accounts are at most tolerated, but not encouraged, and certainly not made convenient. However, with this server, a tool could easily facilitate unrestricted identity management--not only allowing, but encouraging a user to maintain an unlimited number of anonymously distinct identities, without the tool attempting to track or report the sources. This is possible because any action requested of the server is immediately compensated, and by using the above described data-browsing algorithms, spam will be hopelessly buried.

Because the server is almost entirely derived from cryptographic principles like identity management, message signing, and data encryption, these aspects will tend to trickle up into anything built from it. For example, user privacy is vastly simplified: Either a user chooses to encrypt data, or the data will be public. If a user wants to send a message privately, they can now replace a centralized system's ulterior motives and unreliable security with easy-to-use encryption. Just as Bitcoin harnesses cryptography to enable secure management of money, this social network would pave the way for easy, secure management of information and social activity.

In summary, this system--a transparent signature-based nanocompensated server for data and tipping--enables a social network with unprecedented characteristics: Open-source, dynamic development; unlimited developer access for both data uploading and analyzing; embedded, powerful tipping more flexible than traditional Bitcoin transactions; a potential to mine the public tip history to yield incredibly meaningful ranking of content; and solid, cryptographic handling of information, social activity, and privacy.

Logistics of Implementation

Once the servers can accommodate each of the four commands dependably (tip, store data, query data, and withdraw), and simple data upload and browsing tools are developed, any user can begin using the social network. From this base of functionality, the development of other, wide-ranging tools that harness the functionality of the server can be independently developed, upgraded, and supplemented, while the social data and community grows.

For anyone interested in implementing the server, source code for a mostly-functional example of an earlier design of the idea can be found at github: https://github.com/minisats/minisats. This project includes php code for the server, which takes commands via http requests and tracks funds in nano-satoshi increments, and a simple javascript/html example of interfacing with the server, which requires users to manually sign generated commands.

Feedback and Potential

We've been exploring this set of ideas for some time, and we think it's ready for implementation. We're looking for criticism, questions, and comments, and most of all, we're hoping to generate some momentum to move this idea into reality.

Aside from social networking, the possibilities we foresee springing from this type of server amaze and astound us. We believe the nature of the server will enable a new era of collaborative creativity, while providing a new environment for unprecedented innovation. Even so, it seems clear to us that we're only seeing the tip of the iceberg. As we imagine and explore this basic idea, we continue to encounter and examine entirely new applications, which we hope to write about in the future.

We have some ideas we'd like to discuss with the community here, particularly in the Project Development section.

The idea is very difficult to sum up, but we're calling the core idea a transparent, signature-based nanocompensated server for data storage and tipping. We have prepared a post that explains this concept and shows how it can be used as a backend for an unprecedented type of social network. One example of the benefits that could be seen from this system is internal processing of deposits for fees and tipping, which would enable users to tip each other instantly, without a Bitcoin transaction cost, and without worrying about dust.