There has been quite a lot of scholarly research on reputation system in the last 10 or 15 years; see http://scholar.google.com/scholar?q=reputation+system. This article looks particularly relevant for Bitcoin: Reputation Systems for Anonymous NetworksElli Androulaki, Seung Geol Choi, Steven M. Bellovin, and Tal Malkin Department of Computer Science, Columbia University {elli,sgchoi,smb,tal}@cs.columbia.eduAbstract. We present a reputation scheme for a pseudonymous peer-to-peer (P2P) system in an anonymous network. Misbehavior is one of the biggest problems in pseudonymous P2P systems, where there is little incentive for proper behavior. In our scheme, using ecash for reputation points, the reputation of each user is closely related to his real identity rather than to his current pseudonym. Thus, our scheme allows an honest user to switch to a new pseudonym keeping his good reputation, while hindering a malicious user from erasing his trail of evil deeds with a new pseudonym.
|
|
|
When I run, ./bitcoind getaddressesbylabel "" [ ]
Is it normal for it to give nothing, or what? Hmm, yeah, it's probably normal; I THOUGHT the default address was given an empty label; I'm wrong, they're given the label "Your Address". So: ./bitcoind getaddressesbylabel "Your Address" should work. Or just generate a new address, either with or without a label:
|
|
|
I am also running bitcond 1.3 (RC?) that satoshi just posted. How do I use it though? There aren't many docs on using bitcoind... it just said "starting bitcoin server", and my IP appears in the #bitcoin room on irc.lfnet.org. How would I figure out my bitcoin address, how many coins I have, send to other people, etc?
You can talk to the running bitcoind either by: 1. sending JSON-RPC calls; see http://www.bitcoin.org/wiki/doku.php?id=api for more details. 2. re-running bitcoind and giving it extra arguments; it will figure out that there's already a bitcoind running and will pass along the commands. For example, running "bitcoind help" gives you the list of commands it understands: bitcoind help getaddressesbylabel <label> listreceivedbyaddress [minconf=1] [includeempty=false] getreceivedbyaddress <bitcoinaddress> [minconf=1] getbalance getblockcount getblocknumber getconnectioncount getdifficulty getgenerate getinfo getlabel <bitcoinaddress> getnewaddress [label] getreceivedbyaddress <bitcoinaddress> [minconf=1] getreceivedbylabel <label> [minconf=1] help listreceivedbyaddress [minconf=1] [includeempty=false] listreceivedbylabel [minconf=1] [includeempty=false] listtransactions [count=10] [includegenerated=false] sendtoaddress <bitcoinaddress> <amount> [comment] [comment-to] setgenerate <generate> [genproclimit] setlabel <bitcoinaddress> <label> stop
To figure out what your bitcoin address is, run: bitcoind getaddressesbylabel ""(your default address has the empty string as its label). bitcoind getaddressesbylabel "Your Address" To figure out how many coins you have, run: or Regarding running headless: the non-daemon bitcoin will run via remote (e.g. ssh forwarded) X-windows, if you install the necessary X11-client stuff on your server.
|
|
|
Turning on the CAPTCHA for everybody has slowed the flow of coins from the faucet to a very manageable trickle.
Oh, and regarding anonymity versus non-anonymity: I was careful not to tie IP addresses to Bitcoin addresses when implementing the Bitcoin Faucet. So I remember that somebody at IP address 96.240.216.119 received bitcoins at 12:30pm today. And I remember that somebody with Bitcoin address 1P3rpbSybuGgeL1bRwCJFWbn4yBjRNQrbY
|
|
|
Scheduling should be easy; on Linux, just run a couple of 'at' jobs that either talk to Bitcoin via bitcoind command-line arguments or use curl to turn on/off coin generation.
Windows and Mac have similar, built-in abilities to schedule commands.
I think less time, effort, and attention should be paid to coin generation, and more to making bitcoin as easy to use as possible for trading.
|
|
|
I want to write an application that does stuff whenever bitcoins are sent to a particular Bitcoin address. Actually, that feature would be useful for the Bitcoin Faucet (it could monitor the donation address and keep it's display of how many bitcoins are available more up-to-date; currently I memcache the balance and only update it every 10 minutes or so). I want this new JSON-RPC call: monitorreceivedbyaddress(address, nConfirmations, url) address: bitcoin address to monitor nConfirmations: send notification after this many transaction confirmations url: POST detail of the transaction to this url (after nConfirmations) I'm thinking the POST data would look like: {"tx_id" : "...transaction id, maybe encoded into hex", "address" : bitcoin address being monitored "label" : label (if any) of the bitcoin address being monitored "amount" : amount being paid to address "confirmations" : number of confirmations "from" : [ "address" , "address" ] # Sending address(es) }
I don't think teaching the bitcoin client to do HTTP POSTs would be horribly hard; I might take a whack at implementing this myself...
|
|
|
Copy the wallet.dat file somewhere safe and secure. To be 100% belt-and-suspenders safe, shut down Bitcoin before doing the copy.
wallet.dat is: Linux/unix: ~/.bitcoin/wallet.dat Windows: %APPDATA%\Bitcoin\wallet.dat (I think; I don't run Windows) Mac: ~/Library/Application Support/Bitcoin/wallet.dat
|
|
|
Gavin, why don't you just block all served Bitcoin addresses? Would it be easy to generate them automatically?
It is easy to generate them automatically (it is easy to write code that asks the Bitcoin program to generate and return a new address).
|
|
|
I don't wanna be an #@!%!#% here, but ehh... I think the "5 BTC for FREE!" thing, is kinda... flawed...
"flawed" ?? I've been telling people it is a half-baked, I've-lost-my-friggin-mind idea! So far, I count it as a big success-- I've learned a lot that will help me with my next Bitcoin-related project, I've made a bunch of people a teeny-tiny bit happier, and I've personally invested just under $1.00 worth of bitcoins over the last two weeks. I did throw in the towel today and turned on reCAPTCHA for everybody getting bitcoins (it looks like somebody DID bother to write a robot to harvest coins through proxies). It was fun trying to come up with new, creative ways of detecting cheating, but I have more important things to work on.
|
|
|
Money can be used as both a means of exchange and a store of value. I plan on using Bitcoins as a convenient, very-low-cost means of exchange. I don't plan on saving a significant number of Bitcoins as a store of value. I like to invest in people who are doing productive things that grow our economy and make the world a better place, so when Bitcoins replace dollars I'll lend them to people by buying bonds or stocks. If you only use Bitcoins as a means of exchange, then you don't have to worry much about a sudden loss of faith in the system. If you use Bitcoins as a store of value... well, then you're a currency speculator, which can be highly profitable but is also highly risky. Whether you're hoarding dollars or euros or yen or Bitcoins...
|
|
|
So I've been watching the IP addresses of people getting 5 free bitcoins from the Bitcoin Faucet ( https://freebitcoins.appspot.com/ ). And I see some... uh, interesting patterns. Like these successful requests for coins: 79.117.152.158 - - [21/Jun/2010:12:17:02 -0700] "POST / HTTP/1.1" 200 1234 79.117.159.197 - - [21/Jun/2010:12:16:24 -0700] "POST / HTTP/1.1" 200 1234 79.117.135.236 - - [21/Jun/2010:12:10:23 -0700] "POST / HTTP/1.1" 200 1234 79.117.163.238 - - [21/Jun/2010:12:08:50 -0700] "POST / HTTP/1.1" 200 1234 79.117.155.23 - - [21/Jun/2010:12:08:07 -0700] "POST / HTTP/1.1" 200 1234
My apologies if there actually are a bunch of new bitcoin users using IP addresses in the 79.117 range... but I'm guessing somebody there is getting more than their fair share of free bitcoins. There are several suspicious requests from the 192.38.95.* address block, too. So I've made some changes to the Faucet. You won't notice them unless you try to cheat; if you do try to cheat, you'll have to solve a CAPTCHA to get coins. If that doesn't discourage cheating, I'll modify the code so that if it think you're trying to cheat it requires a CAPTCHA and only gives out a bitcoin nickel (0.05 bitcoins)...
|
|
|
I finished everything on my list to do for version 0.3. The code on SVN is about ready to release. Testing at this point is much appreciated.
I just finished creating a clean Amazon EC2 debian 5.0 machine image with everything I needed to compile bitcoind, and it compiled (using a variation of Laszlo's makefile.unix) and is running fine (just finished downloading the block chain). I'll let you know if it misbehaves. I had trouble compiling the gtk version, but I think that's because I did something wrong compiling wxWidgets. I don't need no stinkin' graphics (and am not a wxWidgets expert), so I'm not going to bother trying to fix that.
|
|
|
How about in the options menu you can turn it off or on, and specify an interval in minutes for how often it should display?
I say keep it simple; more choices isn't always better, it just makes it overwhelming and confusing for most users.
|
|
|
I misunderstood the problem. I hadn't noticed that bitcoin addresses could be either 33 or 34 characters long, which is why the Faucet thought your initial address was invalid.
I've fixed it.
|
|
|
But loosing 1 bitcoin in the ocean of a maximum of 21.000.000 coins seems significant to me, so not comparable to gold and jewelry. So only 21000 losses of 1000 coins can happen. That's not much!
But remember that each bitcoins can be divided into 100 million pieces, as needed. And the more valuable they become, the more careful people will be not to lose them.
|
|
|
nice service, but there was a problem with my first attempt to get the coins: "invalid BC address". So the first address generated by the bitcoin program didn't work - 1Dn51Rn2tmvARcsYkPe7Aw1sCAXw5oKnR
That's caused by a bug in one of the technologies I'm using behind the scenes (Google's App Engine). If you try again the problem should go away. I've got a couple of ideas on how to make it more reliable, but I'm still hoping Google finds and fixes the underlying problem...
|
|
|
Oil is what really backs the USD. (See: "Reserve Currency").
The biggest army in the world is what backs the USD.
If it was oil, then it seems to me the country with the largest oil reserves would be the world's reserve currency. It might be the biggest army, but I think the dollar is the world's reserve currency because the US has the largest productive economy in the world backing it. Unfortunately, we might be subject to a natural experiment in the next couple of decades that will show us the right answer; I can imagine that in 20 years the US still has the world's biggest army but some other nation has the world's largest economy. It would be really cool if Bitcoin Nation were the world's largest economy by then...
|
|
|
Thanks! I'll add the donation address to the bottom of the page.
I'm thinking of keeping the donation address the same, so donations to the Faucet are transparent to anybody who wants to see. I WANT donations to, and payments from, the Bitcoin Faucet to be NON-anonymous, so anybody can audit that address and see the flow of bitcoins through the Faucet.
(by the way, if anybody is looking for an interesting bitcoin-related coding project I think a website where you enter a Bitcoin address and it shows you a visualization of all the transactions that went to/from that address would be cool... extra credit if it let you browse the web of transactions... I'd be really curious to see what percentage of bitcoins withdrawn from the Faucet end up donated right back into it...)
|
|
|
I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.
Good idea or not, SOMEBODY will try to mess up the network (or co-opt it for their own use) sooner or later. They'll either hack the existing code or write their own version, and will be a menace to the network. I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it. I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel. That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...
|
|
|
So I'm writing a little tool that dissects the Bitcoin wallet.dat, mainly because I want to understand better exactly how Bitcoin works.
And I see that the outputs of transactions have a value (number of bitcoins) and a bunch of bytes that are run through the little Forth-like scripting language built in to bitcoin. E.g.: ['TxOut: value: 100.00 Script: DUP HASH160 6fad...ab90 EQUALVERIFY CHECKSIG']
First: it make me a little nervous that bitcoin has a scripting language in it, even though it is a really simple scripting language (no loops, no pointers, nothing but math and crypto). It makes me nervous because it is more complicated, and complication is the enemy of security. It also makes it harder to create a second, compatible implementation. But I think I can get over that.
Looking at the code, new transactions are verified by pushing the signature an then public key on the interpreter's stack and then running the TxOut script (did I get that right?).
Could I write code to create transactions with any valid script in the TxOut? E.g. could I create a TxOut with a script of: OP_2DROP OP_TRUE ... to create a coin that could be spent by anybody?
And is flexibility in the types of coins created the reason it is coded this way?
|
|
|
|