You are absolutely right
But the general majority of the people investing in bitcoin do not have problems with this
They chose bitcoin which is already a risky investment and are not afraid of risk.
They should learn the importance of not losing money

syriven

Netvend runs on a centralized server. Its strength lies in offering access to an open, provably honest database to any script, within 3 lines of Python code.

Here's a script I wrote, to monitor new activity. I figured I'd post it here as a good example of how easily one can analyse netvend's database for some arbitrary use.

I wanted to write a script which would return any new events, but filter out the activity of the withdraw script. I also needed to filter out the activity of the script itself.


I now have a script that gives me an idea of if and how netvend is being used, besides the withdraw script and this script itself.

Introduction and Summary

I've recently finished the first prototype of netvend, a project I've been working on for about 9 months. Netvend can be thought of as a virtual vending machine, where users and developers can both spend and receive Bitcoin, for anything the Internet can think to offer or consume. If you or your script can offer some product, service, or art that someone else wants, netvend has the potential to monetize it, with very little additional effort from you.

Netvend's utility centers around all agents (user or script) having access to four basic commands:

• post any arbitrary data to netvend. No limits on total size, frequency of use, bandwidth, etc.
• tip credit (with resolution to the microsatoshi) to another agent, optionally referencing a post entry as a memo or request
• query the database for any part of its post or tip history, using any SQL SELECT statement
• withdraw any credit into bitcoin

Each command deducts credit from your agent, but the fees are on the order of 1/1000 of a single satoshi per command. I'll be giving out credit to anyone who wants to experiment with netvend--just respond with your agent's public address and I can send a tip. Or, just use the same seed the following links do, as that agent already has credit sitting on it meant for anyone to experiment with.

When the api is used to access netvend, a command is generated and signed by your agent's Bitcoin keypair, then sent to netvend. Netvend uses the signature to verify your agent's identity, deducts the appropriate fee, processes the command, and stores the command and its signature. This command history is accessible via the query command, meaning that the entire database can be audited and verified by any interested party.

This is all accessed pseudonymously, and no signup is required. The only thing you need to access netvend is Python 2.x, the netvend api, and netvend credit (for now, I'm giving away credit to anyone who wants to experiment). In the very near future there will be apis for other languages.

How to use netvend

If you'd like to try out netvend right away, this link explains how to create an agent and use the 3 basic commands (plus the withdraw command) to interact with netvend. It also includes a seed with some credit already on it, so you can try out netvend without worrying about making a deposit.

Alternatively, there is the more abstracted netvendor module that allows you to quickly expose any arbitrary Python algorithm to the netvend community through "vends" (messages with payments attached). With only around 20 lines of Python code, your script can begin accepting payments, serving requests, and even automatically withdrawing any earned credit into bitcoin. With a few more lines of code, the script can pay for and use other scripts exposed in the same way as part of its own algorithm, without any cooperation from the original developers of those scripts. In the same way, someone else might include your script as part of their own algorithm.

As I said, both of these links reference an agent seed that has credit already on it. Feel free to use this agent yourself to try out netvend. If you want you can even tip some credit away to your own, private agent--just don't take more than a few satoshi at once, as even a single satoshi is enough to fund hundreds of commands.

The module explained in the second link is ultimately less powerful, but much simpler for anyone who just wants to expose an algorithm to payment in exchange for serving requests. The first link deals with the more basic api, which would be needed to make something more specific than a simple paid service. It's what I'm using to develop the chat program mentioned below, and ultimately this basic api will lead to the most exciting uses of netvend.

Current state of netvend

At the moment, netvend is similar to an Internet without websites, and its immediate utility is limited to cloud storage, networking / credit handling among an application's clients, and a very basic, low-level form of communication among developers. There's simply no community yet to interact with. However, netvend applications can be developed very rapidly once the framework is understood, and it won't take much to begin to grow netvend's community of services, and therefore its utility.

Short-term potential of netvend

Any application that requires either networking or credit handling can be built with netvend as its backend. In many cases, netvend would offer a few unique benefits that can't be found on any other platform or tool.

For example, I'm putting together a chat program as the first example application of netvend. The chat program simply adds the prefix of "chat:[subject]:" to the message a user enters, and posts it to netvend. Meanwhile, it queries netvend for all posts with the same prefix and displays them. Each user uses their own agent, and this is all that's needed to facilitate a simple netvend chat program. Not only is this chat program extremely simple to develop for a project involving networking, but many positive characteristics of netvend are passed onto the chat program automatically:

• Pseudonymity is not only supported, but encouraged and the default.
• All messages are automatically cryptographically signed by each user's agent, and can be independently verified by any interested party.
• The community is open by default: someone else could make a competing netvend chat program, yet still share the same chat history and community.
• Because netvend is available to any device with http access, clients can be built for other platforms relatively easily (although at the moment, the device must have Python 2.x to run the netvend api).

These benefits apply to any applications that need a central hub of communication/networking: chat programs, games, social networks, content aggregators, and more. I believe a lot of open-source projects would benefit from access to an open, secure community that's already functional (and can be easily accessed), rather than having to develop and use a private server that needlessly isolates its community from competing/complementary tools.

Netvend allows competition between interfaces to a community, without fracturing the community itself. New clients with unique features could have a real chance at success, without having to overcome the incredibly massive inertia of the network effect.

As another example of what I see in the short-term future of netvend, it would be a fairly simple project to create an email-like tool that supported sending credit with each message. By using this program with a specific agent, within minutes, any person in the world could begin to offer any product, service, or art they see a demand for, and get paid for it. Recall that this can be done pseudonymously, and without any signup required beyond an initial deposit.

Technically, Bitcoin already makes this possible, but the logistics of the process are simply too much for many projects. Where and how do you advertise? How do you prove your service's quality? Where do you store your history, and how do users know to trust it? For many people who have something to offer, the list goes on, and any one of these problems can cast the entire project into infeasibility. With netvend, many of these problems disappear, allowing any content provider to connect with a paying audience with nothing more than Python and an Internet connection.

Netvend offers a central, cryptographically secure hub for this kind of transactional activity, and exposing this framework to a user through an interface will be a simple matter. Automatic, unfakeable, and unerasable history for each agent ensures both that honesty is easy to prove, and that dishonesty is hard to hide. This will become even more true as tools are developed to analyse an agent's history, and as the community learns how to process netvend's history.

For example, if I want to set up a service where I offer math tutoring, all I have to do is offer it for free at first, and I can begin to build my reputation. Then, either manually or with a tool designed for it, anyone can see for themselves whether I actually deliver, whether my help is any good, and how people respond to me.

The same tool I'd use to offer a math tutoring service could be used for any kind of content-based service: contracting, professional advice, art-on-demand, counseling, medical/legal advice, etc. As it is, one would have to wait for something like coinMD to show up before offering their own medical advice for bitcoin, but netvend exposes a tradenet to anyone who has anything to offer, regardless of whether it fits into a mold someone else has already happened to build.

In the same way that netvend scripts can incorporate each other, human-driven services can interact easily in the same way. For example, if someone I'm tutoring in math asks me a question that's only a little out of my area-of-expertise, I can enlist the help of another professional to fill the gaps in my own knowledge, and deliver a more complete answer in turn.

Because scripts and human-driven services will both be accessed and used in the same way (through tips that reference data entries, or vends), scripts can incorporate human-driven services, and vise-versa.

Long-term potential of netvend

As services and tools are built with netvend as their backend, netvend will begin to accumulate a community and history built from transactions, communication, and other social activities. This community will be transparent and open to anyone: all non-encrypted information that's stored on netvend can be viewed, analyzed, and sorted by any agent with as much as a satoshi of credit.

One of the more exciting things I see this leading to is a truly neutral, transparent, open-source social network and content aggregator--a sort of combination between the reddits and facebooks of today, where anyone can build a tool that has complete access to all of the non-encrypted information on the network. Imagine Reddit with a search function that isn't trash, or Facebook with a choice of interfaces, and all offered without ads, as the server is already compensated with each use.

Granted, users would have to pay for the network--as with all netvend tools--but only enough to cover the actual cost of processing. Facebook only costs about $5/year per user, according to a quick google search. I don't think I'm alone when I say that's well worth a transparent, open, ad-free Facebook that I can access through any client anyone wants to write, and which doesn't actively isolate me from every competing social network.

Conclusion

In short, netvend offers some utility right away, like cloud storage, pay-per-use backend networking / credit handling, and a very basic form of a tradenet. In the very near future, I see a lot of simple tools being developed for netvend like chat programs, tradenet tools, agent history analyzation, and a growing network of various services and scripts. Each new netvend tool or service will increase netvend's utility. At the same time, the design and code of netvend itself (which is, of course, completely open-source) will be exposed to more minds than my own (and certainly better server administrators), and will evolve and fork to serve its community better as time goes on.

In the long-term, I believe the community and network of tools will grow into its own, unique resource, offering a hub for both social communication and transactional activity, which anyone can access and participate in. Because this network is open to any developer that has an idea for a new feature, I see it eventually outpacing any currently-existing alternative, given some initial momentum.

So--let me know what you think, and thanks for reading![/list]

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

Great, thanks for the help and the links! They were just what I needed.

Hey guys. I'm using message signing/verification in the project I'm working on. The server (php) will verify a message signature to authorize actions from the client (theoretically any language, but right now both JS and python).

All the signing/verify libraries work well together for any message under 253 characters--but when they need to store the message length in more than one byte, things get really hairy. I've tried fixing things myself, but I'm not even sure what to use as a reference anymore. If anyone can point me in the right direction, or just tell me which bit of source code to use as a reference, I'd be very grateful.

Here's how the php sig verification script (from https://github.com/scintill/php-bitcoin-signature-routines) expects message length to be encoded:


This code only agrees with brainwallet.org's method, again, if the length of the message is less than 253.

Here's how the JS signing library (from https://github.com/bitcoinjs/bitcoinjs-lib) encodes length before signing:


I already know of one bug in the JS code: i<<32 evaluates to 0. I'm not too worried about that at the moment, though, because i'm still trying to get that second case to work.

The python signing library (from https://github.com/vbuterin/pybitcointools) just uses chr(len(message)), which obviously only works when len(message) < 253.

I'm assuming brainwallet.org's implementation is right, but before I try to redesign all of the other tools according to how that tool behaves, I figured I'd come to you guys and make sure I'm on the right track.

I'd be more than happy to fix whichever of these is broken if I only knew for sure which one was right, or if I was pointed to an implementation that was right. I'm just having a lot of trouble getting started, as I'm new to both cryptography and open-source development (it takes me a while to dig through someone else's code and find what I'm looking for).

Alternatively, if there are better-tested libraries out there for these languages (or others!) for signing/verifying Bitcoin messages, I'd love to hear about them.

Thanks in advance for any help you can offer!

I'm working on a project that might share some goals with yours. It doesn't have a name yet, but here's the most recent thread:

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

It's a bit long, so I'll just mention the parts that seem relevant to you. The server charges microamounts for each small action, and can therefore accommodate any use a developer could dream up. Information could, of course, be encrypted--it's just a matter of writing that feature into the tools that access the server.

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.

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


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.


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.


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.

Yeah, $77,000 is more than enough for "a couple of months" for sure.

It's because it's essential to the goal of the project to allow the users to control their account actions (including withdrawing) without allowing the user to directly control the bitcoins they've deposited. This means the system needs two private keys for each account: one to authorize non-withdraw account actions, which the user must own; and another to authorize withdraws, which the user must not own.

It's similar to how a traditional bank must lock up the actual cash deposited, but allow users other means of controlling the funds. The setup allows the bank to offer services that cash alone is incapable of (like instant transfers to other users or debit card services), while still allowing the user to get the actual cash back at any time through an internal withdrawal process. It's true that the bank now technically has two points of vulnerability (identity theft and physical bank robberies), and I know that the bank's extra security is a part of the metaphor that doesn't apply to my project. However, even if the bank had security comparable a potential customer just handling the cash directly, the extra services offered by the bank may make it useful to certain customers.

Well, this gets into the design goal of the project, so I'll try to give you a summary. As I said earlier, someone's working on a better writeup of it (might be done within the week?), and we'll post it here when it's done.

The only reason server B will create a Bitcoin transaction is to accomodate a user's "withdraw" command. All other operations don't actually involve sending the coins anywhere, and are be done entirely on server A. The project is centered around using this setup to offer of the some perks of a server-based system (instant, cheap payment to another user, possibly with sub-satoshi denominations) while preserving many of the perks of Bitcoin (transparent, developer-friendly, open-source, verifiable), and adding memo functionality. The particular combination of characteristics found in this system lead to extremely intriguing development possibilities.

I just noticed an error in my original post, and now Wolf0 and cp1's responses make way more sense.

I said "Server B actually has the private keys to the users' accounts", but that's terribly misleading. The users are the only ones that have the private keys needed to sign commands and authorize actions on server A. What server B (and no one else) has, is the private key(s) that actually own any bitcoins that any user has deposited. So in order for a user to direct their Bitcoins, they send a command signed with their private key to server A, which is eventually scanned by server B. Server B then verifies that the command is legitimately signed by the user, signs a Bitcoin transaction using the keys that actually own the coins, and sends that signed transaction back to server A to broadcast.

Well, there are a few characteristics of the project that may mitigate this (although I am certainly not a Tor/security expert):

First, server B will be contacting server A and no one else (but maybe this is just as easy to snoop?).
Second, server B can query server A at random intervals, and can realistically wait anywhere from 10 minutes to an hour between queries.
Third, because the server is designed to be used by other programs, there will be a whole class of queries (some through Tor) that query server A in an "automated", or "regular" way. Knowing nothing else about server B, how would you begin to narrow down this large pool of candidates, each of which has their own interest in retaining privacy?
Fourth, it will be trivial to actually move server B as often as you want, or change server B's connection habits, since server A never needs to know where server B actually is or when it will act.


If an attacker can attain a user's private key, that's a failure of the user to remain secure, not a failure of the server. Neither server ever asks for the user's private key, so the only security risk here is the one inherent in any cryptography at all: how to protect your private key, when you (should) know very well that no one should have to ask for it.

By the way, thank you all for this discussion. It's putting me miles ahead of where I would be if I was stuck with searches and individual research.

As I'm currently imagining it, server A actually doesn't ever need to initiate communication with server B. I'm not sure about the specifics of how Tor operates, but wouldn't this mean that an attacker couldn't find server B, even if server A is compromised?

Well, this is all a proposed security setup for the Minisats project, which has a (very dry) summary here: https://bitcointalk.org/index.php?topic=237042.0 (someone's working on a better writeup of it, which we plan to post here on the forum when it's done in a few days). It's a long read, so I'll try to summarize the relevant parts here:

The first reason that comes to mind is that the server is designed to be used by other programs, and (as far as I know) to require a developer to use Tor would significantly shrink the amount of people that could use it, and defeat much of the "ease-of-use" appeal of the project. Also, most commands sent by users will not involve Bitcoin transactions directly, and for these commands it's essential that there is as little lag as possible. There may be other reasons that aren't occurring to me, since I haven't actually directly considered your question before.

Basically, the front-end must be as easy as possible to find and access, but the portion that actually verifies and authorizes Bitcoin transactions must be as difficult to find as possible. Thus you have two servers: A transparent, fast, public server A, and a hidden server B.

Would you mind explaining this a bit more? How would an attacker find the origin of a message sent from server B?


In my specific case, server B would be scanning server A for commands signed by specific users with their address. No matter how much an attacker compromised server A, they couldn't actually fake a signed command, and server B would verify the legitimacy of signed commands before doing anything.


What exactly makes this expensive--is it the risk analysis specifically? In my case, the risk analysis is as simple as checking to make sure the command is legitimately signed by the user before performing the action.

I'm curious about what you guys think about the following security setup:

Server A is publicly hosted at some domain name or ip address, and this server takes signed commands from Bitcoin users to perform various actions. Server B actually has the private keys that own any bitcoins the users have deposited, and nothing--not even server A--knows where server B is. When a user wants to perform an action that requires a Bitcoin transaction, server A posts this command publicly somewhere. Server B regularly checks for these commands, connecting through a Tor-like service to obscure where the query came from. When it sees that a Bitcoin transaction is required, it signs the transaction and sends the signed transaction to server A (again through a Tor-like service), and server A then broadcasts the transaction.

This basically allows a server to remain completely unfindable, since the only network actions it performs are outgoing and through Tor. If a server is unfindable, then the private keys can't be snatched.

Has this idea already been discussed? Am I missing an important detail that makes this less airtight than it seems?

[Edited to clarify some confusing wording]