Proposing Nanocompensated Servers and a New Paradigm of Social Networking

[CatalyticDiscourse]

(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.

[1714822276]

1714822276

[1714822276]

1714822276

[1714822276]

1714822276

[Mike Hearn]

I admire your enthusiasm. I think you should examine this:

  https://bitcointalk.org/index.php?topic=244656.0

.. as it avoids the need for private/hidden deposit holding servers.

I would note that you can't assume merely charging money would make abuse go away. For background, I spent several years working in the Google abuse team, so am quite familiar with the challenges of building spam-free services at scale. Abusers come in all shapes and sizes, with all kinds of different "business models". Some of them are more profitable than others. CAPTCHAs often impose too low of a barrier to stop spam, even phone verification is sometimes insufficient. Look at buyaccs.com to get a feel for what accounts on various networks cost, some people still find it worthwhile even at 10 cents per account!

IMHO a better approach to fighting abuse with Bitcoin is this:

  https://bitcointalk.org/index.php?topic=140711.0

It allows the cost of abuse to be set high, but users aren't being microbilled for individual actions just for anti-abuse reasons - which always risks finding that users value the service less than spammers do You can of course microbill if that's your way to pay for the infrastructure.

[CatalyticDiscourse]

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

I think you should examine this:

  https://bitcointalk.org/index.php?topic=244656.0

.. as it avoids the need for private/hidden deposit holding servers.

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).

I would note that you can't assume merely charging money would make abuse go away. For background, I spent several years working in the Google abuse team, so am quite familiar with the challenges of building spam-free services at scale. Abusers come in all shapes and sizes, with all kinds of different "business models". Some of them are more profitable than others. CAPTCHAs often impose too low of a barrier to stop spam, even phone verification is sometimes insufficient. Look at buyaccs.com to get a feel for what accounts on various networks cost, some people still find it worthwhile even at 10 cents per account!

IMHO a better approach to fighting abuse with Bitcoin is this:

  https://bitcointalk.org/index.php?topic=140711.0

It allows the cost of abuse to be set high, but users aren't being microbilled for individual actions just for anti-abuse reasons - which always risks finding that users value the service less than spammers do You can of course microbill if that's your way to pay for the infrastructure.

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).

[Mike Hearn]

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.

The tipper can just use a regular Bitcoin transaction for that. There's no point allowing sub-satoshi tips, it would be impossible to ever cash out such tips unless you got hundreds of thousands of them (not gonna happen). A satoshi is already worth so little a 1 satoshi tip would probably be seen as insulting rather than helpful .... maybe if we see a few more orders of magnitude value improvement it might be useful

The issue with tipping is that even when it's very easy (like on reddit) people don't do it very much. I'm not sure you can get much data from it. But good luck.

[Peter Todd]

It's possible to create probabilistic payments in Bitcoin. The big picture idea is that you make a transaction, and 99.99% of the time it won't actually go through and the receiver doesn't get anything; 0.01% of the time it does for 1000x of the amount, enough to be useful. If the scripting language was more useful you could do this easily, but it's kinda useless right now so...

However there's a neat trick: you can prove to someone else that you tried to mine some coins. Now had you been successful, that share would have made it as a block, and the receiver would have got some Bitcoins paid out as part of the block reward. One really cool thing about that is these probabalistic payments can be anonymous - they aren't linked to any other coins.

Problem is, you need hashing power to mine. However you can pay someone else to mine for you, and to pay them you can use a trust-free micropayment channel like Mike's bitcoinj implementation. (remember that a micropayment channel only lets you combine multiple transactions to a single person into one, it doesn't let you make multiple small payments to multiple people)

Having said that, all this stuff is fairly complex, and none of it is implemented yet. Right now my advice is to use a off-chain service like inputs.io or easywallet and use their API. I haven't written any apps for either myself, but the API looks pretty simple to use. Sure they can go out of business and take the funds, but we're talking about tip sites and stuff - there's not a lot of money involved for any one person to lose. Myself I use both of those services all the time for day-to-day transactions, and Armory to keep my savings secure.

[ptshamrock]

This is amazing.


How can I invest in this?

Please make it possible to buy "shares" of the system e.g  an autonomous bootstrap mechanism..

[super3]

Ties in with something that I want to work on. The spam approach is not really a strong argument. Micropayments however is a good talking point.

[syriven]

Hey guys. I wrote a lot of the original code that was linked to in the original post.

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.

The tipper can just use a regular Bitcoin transaction for that.

No, the tipper can't actually just use a regular Bitcoin transaction for that. Personally, whether the sub-satoshi part of the idea is implemented isn't important to me. What's important is that these transactions can be done insantly and cheaply, and that they can be associated with a data entry as a memo (something it seems CatalyticDiscourse forgot to mention). How much does it cost to insert a row with just a few fields into an SQL table? I don't know the answer, but I know it's far less than a typical Bitcoin transaction cost, and that will be the fee that accounts are charged for making a tip.

A satoshi is already worth so little a 1 satoshi tip would probably be seen as insulting rather than helpful ....

Handing someone a penny is a hassle, because that person has to deal with a penny for the rest of the day. But what if you could just snap your fingers and increment their bank account by 1 cent? How would anyone ever get insulted or annoyed by that? It is, at worst, a neutral interaction, that doesn't even require acknowledgement from the recipient. And if 100 people do the same thing, hey, that guy's got a dollar suddenly. And remember: on the Internet, 100 people can be a very small amount.

The issue with tipping is that even when it's very easy (like on reddit) people don't do it very much. I'm not sure you can get much data from it. But good luck.

I completely disagree.

First of all, tipping on Reddit is only easy if you already know how to use the tool and have an account. For me, at least, I had to do some googling before I found out that the documentation is on the sidebar of the bitcointip subreddit. Then, to deposit or check funds, you have to send a message to /u/bitcointip and wait a bit for a response. This might not seem like much time to wait for someone who's used to waiting for Bitcoin confirmation times, but for the average Internet user, having to wait even 30 seconds starts to become a big downside to using the service. Further, this service still charges 0.0002 BTC per tip, which means that it's not a good indication of whether people are willing to send or receive smaller tips. I believe we have yet to see a good tipping service.

Secondly, imagine that you have the ability to instantly send a tip to someone at negligible cost to yourself, and imagine further that doing so will not only send them a bit of money, but it will also effectively pay for a bit of advertising for them. Each time you send a tip, everyone who's tipped you is more likely to see the content of whoever you've tipped to. I don't know about you guys, but if I had only a few bitcents on a network like that, I'd be happy to tip even tiny amounts to others, and I'd be happy to receive small tips as well. Even if the funds are negligible, the fact that I'm financially endorsing them, or being financially endorsed, won't go unnoticed. I believe that users will be happy to populate this tip history, with the knowledge that they're defining, in their own little corner of the network, how valuable certain content is.

[syriven]

This is amazing.


How can I invest in this?

Please make it possible to buy "shares" of the system e.g  an autonomous bootstrap mechanism..

What do you mean by an autonomous bootstrap mechanism?

I don't see this working as anything but a non-profit, open-source system, since a lot of its long-term appeal depends on total transparency. If there's any money to be made here, it will be through either building systems on top of it that extract their own fees (like message mixers or automated fund handlers), or donations from users.

[syriven]

Bumping this to say that I've implemented the server, along with a Python api (https://gist.github.com/Syriven/6648792) for interfacing with the server, with some help from others. I'm calling the server "NetVend".

I've announced a pre-beta phase on reddit: http://www.reddit.com/r/Bitcoin/comments/1mtwzp/announcing_netvend_prebeta_for_interested/

I am extremely excited about this project, and it seems to be coming together. I'd be more than happy to provide NetVend credit to any developers who want to experiment with the server, and there is some credit sitting in an account that can be accessed by calling netvend.setSeed('correct horse battery staple'). Feel free to use this account to fund experimentation, but try to be conservative!

I've written a short example script that operates as a service on NetVend. It facilitates user-vs-user rock-paper-scissors betting, and is only about 140 lines long. https://gist.github.com/Syriven/6648609

[phillipsjk]

I think I found a major design flaw in the proposal:
If the sever wants to get paid, the owner of the server must have a private key only they know. However, if the user is expected to sign all transactions with the the same key: they must also know it. The implication is that if the user was to withdraw funds, they don't actually need to ask the server permission. Because you are micro-billing by the table entry, it would cost extra money to delete all of their posts as well. Doing so automatically may upset users who did not do this on purpose. For example, Bitcoind automatically spends from all coins the user has access to. However, to sign messages, the user must have the corresponding private key in their wallet. There is also the issue where the user much unlock their wallet for mundane status updates: mostly defeating encryption.

One conceptual problem with the design is that bitcoin addresses are not intended to be account numbers. Apparently Bitcoind supports "accounts" that do not actually correspond to specific coins at all (it is possible to have a negative Bitcoin account balance). When sending coins to the server, there may be more than one coin sent. Each coin will have its own input and corresponding private key. With the use of coinjoin transactions, these may not even all be controlled by the same entity. Stealth addresses may mitigate some of these concerns.

Using Elliptic curve Diffie-Hellman (ECDH) we can generate a shared
secret that the payee can use to recover their funds. Let the payee have
keypair Q=dG. The payor generates nonce keypair P=eG and uses ECDH to
arrive at shared secret c=H(eQ)=H(dP). This secret could be used to
derive a ECC secret key, and from that a scriptPubKey, however that
would allow both payor and payee the ability to spend the funds. So
instead we use BIP32-style derivation to create Q’=(Q+c)G and associated
scriptPubKey.

- [Bitcoin-development] Stealth Addresses

BTW, that reddit link appears to be circular: linking back to the same post for the "the technical writeup". I also don't understand how the rock paper scissors example can properly work if all of the database entries are public and verifiable. The code does not require both submissions be submitted at the same time. I am not even sure that would be technically possible since relational databases need to serialize updates.

I also feel that "wallet seeds" (essentially a brain wallet) should not be supported. You say yourself that "to handle money, a deep understanding of... the intricacies of using Bitcoin is required." You go on to say the the goal of netvend is to "(provide) every  internet user (with) easy and cheap access to a neutral server that solves many of these problems." Brain wallets are very insecure unless you know what you are doing. People tend to overestimate the entropy of their passphrases. "Wallet seeds" should not be used: even for examples. If people insist on using a "wallet seed", they can go to brainwallet.org and copy the resulting private key from there.