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.
Commands:-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
http://www.youtube.com/watch?v=pp89tTDxXuI , 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
http://192.155.86.107/. 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
https://github.com/minisats/minisats/wiki/Server-BehaviorAgain, the server is hosted on
http://192.155.86.107/ at the moment.
All of the server code is on github:
https://github.com/minisats/minisatsSomeone began work on another client:
https://github.com/minisats/minisats-clientHere are some examples of services that could be easily made, using this system:
https://github.com/minisats/minisats/wiki/example-automated-uses-of-serverLet 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.
