Bitcoin Forum
September 30, 2020, 03:47:04 AM *
News: Latest Bitcoin Core release: 0.20.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Project Development / Introducing netvend beta: tradenet for users/scripts to transact and communicate on: April 15, 2014, 04:48:02 AM
    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.


    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]
    2  Bitcoin / Development & Technical Discussion / Message Signing Issues on: September 20, 2013, 03:28:43 AM
    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 expects message length to be encoded:

    function numToVarIntString($i) {
    if ($i < 0xfd) {
    return chr($i);
    } else if ($i <= 0xffff) {
    return pack('Cv', 0xfd, $i);
    } else if ($i <= 0xffffffff) {
    return pack('CV', 0xfe, $i);
    } else {
    throw new InvalidArgumentException('int too large');

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

    Here's how the JS signing library (from encodes length before signing:

    numToVarInt: function (i)
        if (i < 0xfd) {
          // unsigned char
          return [i];
        } else if (i <= 1<<16) {
          // unsigned short (LE)
          return [0xfd, i >>> 8, i & 255];
        } else if (i <= 1<<32) {
          // unsigned int (LE)
          return [0xfe].concat(Crypto.util.wordsToBytes([i]));
        } else {
          // unsigned long long (LE)
          return [0xff].concat(Crypto.util.wordsToBytes([i >>> 32, i]));

    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 just uses chr(len(message)), which obviously only works when len(message) < 253.

    I'm assuming'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!
    3  Bitcoin / Development & Technical Discussion / Is this security solution a good idea? Is it new? on: June 21, 2013, 07:59:29 AM
    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]
    4  Bitcoin / Project Development / Introducing minisats: a transparent bitcoin nanopayment processor and more on: June 18, 2013, 08:03:15 AM
    I'm posting this on behalf of minisat-maker, since a tor user can't easily sign up on the forums:

    This is a heavily edited/updated version of the original overview, which I posted in the Bitcoin subreddit under minisat_maker. I'm looking for any criticism, comments, questions, or contributions. I posted to reddit when I had the idea--now that I have a prototype, I'm coming to you guys because I know you'll won't hold back and a lot of you know what you're talking about. Here's the idea:

    Introduction and Overview:

    At the most basic level, I'm working on an open-source, totally-transparent anonymous Bitcoin nanopayment processor. As awesome as it is to have the first peer-to-peer success of Bitcoin's magnitude, there are some innate perks to a centralized system that we can harness--most notably, ultra-small transaction costs and instant propagation of transactions. I believe that if we built an open and transparent centralized system and wrapped it as closely to Bitcoin/cryptography ideals as we could, we could get something pretty cool, and get a lot more than more efficient transactions. And really, with forking and cloning, a lot of the dangers of a centralized system are easier to work around or get away from.

    The core of the project is just a server that holds an account for any submitted bitcoin public address. After the user has deposited Bitcoins into the account or received funds from another account, the user can send signed commands to the server to direct the account. Each command (except for withdraw) has a fee associated with it: tiny amounts targeted to pay of the cost of the server processing the action. The fees will be ultra-small, something significantly less than a single satoshi. This is more comparable to a coin's ridges rubbing off after use than a middle-man taking a cut, and is less than 1/5000th of the default bitcoin transaction cost.


    -Data: Stores some data to the server. The data will be put into an open database, but could be encrypted. This could be used for a wide variety of things; I'll go into some examples below.

    -Tip: Send some amount of value to another minisat account, specified by their ID address. Optionally points to a data entry as a memo. If you specify a Bitcoin address that doesn't have a minisat account yet, one will be created for that address. The owner of the Bitcoin address can then always withdraw by sending a simple 'withdraw all' signed command.

    -Query: View any of the data on the server (Note that at the moment, the server isn't set up with this command, and relies on separate pages to retrieve data for free)

    -Withdraw: Transfers an amount of Bitcoins from the minisat account back to the regular Bitcoin address. This has no server fee, but of course would still require a Bitcoin transaction fee.

    Lowering the barrier-to-entry for new developers:

    The command interface is designed to be used by other programs, whether the programs are just nice interfaces or some sort of automated service.

    Traditionally, a developer who wants to incorporate bitcoins has to find an appropriate hosting service and pay for it, then develop their own attempts at security, and deal with bitcoind and jsonrpc, which (as far as I have found) is very difficult to debug. For me--a hobbyist programmer with no server experience--this was a pretty big mountain to climb.

    However, with my idea, a developer's code only needs to be able to sign messages and send the messages to a server (a library could be developed to make this even easier). They then have access to a method of using bitcoins that is both easier and more powerful than any other alternative. When the project is more secure (I'm not a security expert), they will also have better security--all with only a few lines of code and virtually no setup hassle. In fact, this part of the project is operational, aside from occasional downtime caused by some wonky behavior from bitcoind (see "progress so far").

    Data Analysis:

    All four database tables (accounts, commands, data, tips) will be publicly available. The 'commands' table stores each command and its signature, allowing anyone interested to verify that any action is legitimate. I am pursuing the idea of allowing users to run their own SQL SELECT queries on any of the 4 tables, and charging the user according to the load they put on the server.

    This is one area I am specifically looking for input. Although I'm using an SQL user that only has SELECT privileges and cutting the user-supplied clause at the first semicolon, it still makes me nervous. Are there any database experts that could give me some reassurance or warnings with respect to this? Does it make sense to charge according to the time the server takes to fill the request?

    Example Applications of Data Analysis:

    First, note that a person posting any data to the database will be aware that a lack of encryption is declaring something publicly viewable, which is really a much more realistic and secure way of dealing with the internet in the first place.

    Consider a tool that could perform the following algorithm:

    Given an account id, the tool could search for that account's biggest sent tips. Using the pool of accounts that those tips pointed to, repeat the process with their combined tips matching similar criteria. Continue for some small number of loops. At each iteration, take the pool of accounts, and display any non-encrypted (and therefore public; see “social implications”) data they've submitted matching some search criteria.

    What you'll get from this algorithm is a feed of public activity, sorted first by how much value you gave to the authors, and then sorted by how much value those authors gave to anyone else. Because the algorithm is effectively following donation trails, you'll never have to worry about spam, or "fake" accounts: you'll only be seeing something that you have given value to (at least vicariously).

    Now fill in the blanks with some examples. I'm sitting at home, up late because I can't sleep, and bored. My friend calls me up and says he really needs some pizza, but he's been drinking, and it's too late or he's too far away for anyone to deliver. He offers bitcoins for a late-night delivery to his house. I'm bored anyway, and I could use some more money, so I accept. When I get back home, I see he's tipped me with the memo "that pizza was awesome. thanks for the delivery man". A few days later, I see I've received a message from a stranger: "I see you delivered pizza last night super late. Would you mind delivering to my address for XX btc?". There may be some money attached in the form of a tip. He knows my friend through some degrees of separation, and he came across my friend's tip-and-memo when searching for "pizza delivery". If the price is right, I agree. If not, I ignore it or make a counter-offer. And suddenly, with no effort on my part, I have the opportunity to begin delivering pizzas for bitcoins.

    Start with your friends, and branching out will be easy, with almost any line of work. If you do what you're good at people will pay you to do it again, and specialization will become as natural as breathing. Need to break into a field? Offer your services for free, and just ask for a small tip with an honest memo.

    And beyond things that are just convenient or easy for you to do, consider all the things that you like to do. Let's say that you like working with small quadrotors, so you get one and start messing with it. One day you are able to program it to do something cool, so you make a video and post it somewhere associated with your account. If your friends think it's cool, they'll tip you for it, which both funds you and makes their friends more likely to hear about it. The cooler your video is, the more money you get from it, first from friends and then from strangers--and one day you could find that you have an ongoing crowdsourced fundraiser, moving enough money to you to buy a few more quadrotors and start working on something like this , and you're getting offers from strangers looking for work or offering it. Maybe someone will be coming to you, asking to tag along and help, requesting nothing more than a small tip and an honest memo...

    The sky is the limit with this kind of growth, and the better you are at it the better this will work. And besides the money you'd get, you can browse the tips with any number of algorithms, finding the most constructive criticism quickly. It's like a reddit comment thread, except you filter out everyone you'd never give money to, bring all your favorite posters to the top, followed closely by your friends' favorite posters. And if that algorithm doesn't suit you, just find another one or write your own.

    I could go on about the things I see this system enabling, but if you're still reading this then you probably get the basic idea by now. I'm posting here because I could use some help, and I'm hoping that this idea is exciting to someone else who wants to work on parts of the project that I'm less able to.

    I have the server set up at I'm having issues keeping bitcoind running (it will quit after a day or two for some reason), but when it's working you'll see I've written a basic javascript interface. It can issue commands for an account, although it relies on the user using some outside tool to sign messages (I've just been using bitcoin-qt for this).  Obviously, the interface is only a working prototype to give you an idea of what is going on / potentially possible. Getting a more user-friendly look and feel to this is something I could use some help on. If anyone's interested, I'm willing to spend the bitcoins I can (not much) on that kind of thing. I know it's not the most efficient way to do things, but the server takes commands via HTTP POST and returns any data through simple php echos.

    Progress So Far:

    Right now, the fact that bitcoind randomly quits is the only issue I'm aware of. Other than that, the server seems pretty stable and usable. It could and should be made more secure. This is another area I could use some help, and am willing to spend some bitcoins on.

    These days I'm working toward getting the bitcoind issue figured out, developing some sort of library for signing messages and interfacing with the server, and trying to get other people interested in the project--as users, developers, or contributors. There are still some design questions I haven't figured out. For example, is there a way we could make it provably trustworthy, considering that it's a centralized system?

    The somewhat-generalized server behvior is described here
    Again, the server is hosted on at the moment.
    All of the server code is on github:
    Someone began work on another client:
    Here are some examples of services that could be easily made, using this system:

    Let me know what you guys think! I'll be happy to send a tip with a few satoshis to anyone who wants to test it out. Forking is of course encouraged; I see the current server as a prototype for which we'll hopefully see many unique and independantly useful implementations.
    5  Bitcoin / Bitcoin Technical Support / bitcoind issues - segmentation fault?? on: May 11, 2013, 01:38:17 AM
    Sorry if this is a stupid question! I can't find any help from google, and there's a good chance I got myself into this mess accidentally somehow.

    A while ago, I got bitcoind running on my server. I happily used it for a while, writing simple php scripts to experiment and become familiar with its operation. This was all on testnet.

    I recently decided I wanted to start bitcoind from scratch. It turns out that I only kind of know what I'm doing. I deleted everything in .bitcoin and put a fresh copy of bitcoind in there. For a while, when I tried to run it through using ssh, it would tell me something along the lines of "Error while loading shared libraries: [some library]". I'd copy/paste the exact text, but now it won't even give me that anymore. When I try to run it now, it just gives me a segmentation fault.

    I'm not really sure what to do here. I'm not very familiar with Linux or ssh, and that could very well be how I got into this mess. Any help would be appreciated. If you guys need any more information, just ask me.

    6  Other / Beginners & Help / Issues with bitcoind on: May 11, 2013, 12:26:51 AM
    A while ago, I got bitcoind running on my server. I happily used it for a while, writing simple php scripts to experiment and become familiar with its operation. This was all on testnet.

    I recently decided I wanted to start bitcoind from scratch. It turns out that I only kind of know what I'm doing. I deleted everything in .bitcoin and put a fresh copy of bitcoind in there. For a while, when I tried to run it through using ssh, it would tell me something along the lines of "Error while loading shared libraries: [some library]". I'd copy/paste the exact text, but now it won't even give me that anymore. When I try to run it now, it just gives me a segmentation fault.

    I'm not really sure what to do, here. I'm not very familiar with Linux or ssh, and that could very well be how I got into this mess. Any help would be appreciated. If you guys need any more information, just ask me.

    7  Other / Beginners & Help / Best practices for storing private keys on server? on: April 11, 2013, 03:13:11 AM
    Sorry if this question has been asked before--I tried searching the forums, and I haven't found anything yet. I'm in the first phases of starting a website that will handle bitcoins, and I'm not sure what the best practices are for storing a private key. I don't know too much about security, but I know what hashing is and I understand in a vague sort of way how private keys/public keys/addresses are generated and how they work together. So with that in mind, I have a few questions:

    - What is the "most" secure way to store private keys, without putting them in cold storage? I'm assuming just throwing them in an sql table isn't the best thing...

    - Let's say I send bitcoins to an address, and a server somewhere in the world has the private key to this address, and manages the funds. How would an attacker find the server to attack it in the first place? Is there any way I could completely "hide" the server's location while still making transactions from it, thereby protecting it from attacks?

    - Another thought I had: Say I have the server generate a private key, give half of it to the user, and then store only the other half. The user could submit his half of the key at a later date, and the website could make transactions and then forget the user's half again. It seems like this would protect relatively well against attacks, as an attacker would need to get both pieces of information in order to do anything. Of course, the user must trust both that the server isn't storing the full key and that the server will always be acting in the user's interest; other than this drawback, is there some reason this implementation is a bad idea?

    Thanks in advance for any replies!
    Pages: [1]
    Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!