Bitcoin Forum
September 24, 2024, 12:30:50 PM *
News: Latest Bitcoin Core release: 27.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 [113]
2241  Economy / Marketplace / Re: Get 5 free bitcoins from freebitcoins.appspot.com on: June 14, 2010, 05:48:44 PM
The Bitcoin Faucet now shows how many coins it has available to give out (on the left-hand side of the page).  The number is only moderately accurate-- donations will take 5 or 10 minutes to show up in the balance.

I also implemented another anti-cheating measure that should make casual cheating a little harder (which I don't want to say too much about because that would make it easy for cheaters to know what to do).

I'm very pleasantly surprised at how well freebitcoins is working so far; thanks again to everybody who tried it out and who donated bitcoins to it!
2242  Economy / Marketplace / Re: Get 5 free bitcoins from freebitcoins.appspot.com on: June 14, 2010, 01:23:20 AM
Thanks, lachesis-- ฿50 to you for finding that bug!

I've changed the key and turned off debugging; I'll tighten up its security a little more tomorrow when I'm more awake.

And wobber: no, I didn't send you leet ฿
2243  Economy / Marketplace / Re: Get 5 free bitcoins from freebitcoins.appspot.com on: June 13, 2010, 03:05:50 PM
I've been able to drawn 50 BTC in minutes using Tor. Please add some address filter too, so the same address can't be used twice. I'll also provide a Tor blacklist if you'd like.
PS: I've paid back those BTCs.

How many public Tor exit nodes are there these days?  You've essentially blacklisted 10 of them already  Smiley

I am going to add a one-donation-per-bitcoin address rule to make it a teeny-tiny bit harder to cheat.  I don't want to blacklist anybody coming from Tor, though-- I think a lot of people using Tor will also be interested in Bitcoin.

I'll implement a CAPTCHA when (if?) the current service starts running low on coins (there are 1,570 bitcoins in the faucet right now!).
2244  Bitcoin / Bitcoin Discussion / Re: Multiple Bitcoin "Accounts" on: June 12, 2010, 12:39:34 PM
Actually, the "label" mechanism gives me what I need to keep the freebitcoins separate from other bitcoins in my server's wallet.

What I'd really like is to store wallets outside of the bitcoin program.  I'd like bitcoind to have these features:
 + Generate a new address, but don't store it in the local wallet file-- return the address and private key
 + Accept a transaction that is already signed; check that it is new/valid, and, if it is, broadcast. (if not, reject it)
 + Let me register a Bitcoin address that I'm interested in, and when it sees payments to that address 'tickle' a URL with details on that transaction.

Or, in other words, allow it to function as just a payment gateway.
2245  Bitcoin / Development & Technical Discussion / Re: Running on the Google App Engine on: June 12, 2010, 11:51:33 AM
So basically, you're running Bitcoin on a VPS and using an HTTPS connection from App Engine to signal it what to do? Why not just host the site on your server?
App Engine gives me:
 Free bandwidth and data storage (with the option to pay for what I use if I go over a gigabyte)
 Built-in, already-configured-and-tweaked tools like memcache and BigTable
 An architecture where scaling up is built-in (App Engine will automagically replicate my app and distribute it across Google's worldwide content distribution network if it gets a lot of traffic)

And all of that is administered by Google's sysadmins (who are WAY better at that than I am).

But mostly I did it as an experiment and because it was a technical challenge and because lately I'm an App Engine fanboy.  I would've been done a day earlier if I'd run everything on the same server and wrote the front end in PHP+MySQL.
2246  Bitcoin / Development & Technical Discussion / Running on the Google App Engine on: June 12, 2010, 04:09:43 AM
Joozero asked if I'd make the source to freebitcoins.appspot.com available, and I promised to start a thread explaining how I created it-- and here it is.

freebitcoins is running on the Google App Engine.  Well, the part you see is running on App Engine.

There's also a back-end bitcoind server running on a debian VPS that I've had for years.  The App Engine code makes JSON-RPC calls via the App Engine url fetching API.  Making that connection secure was a bit tricky; here's how I did it:

First, I connect to the VPS using https so the traffic is encrypted.

I need a secure connection because I add a secret pre-shared value to the JSON call.  I'm not going to make the full source for freebitcoins fully open source because I don't want to bother with constantly working to keeping that secret value secret.    I should hash the entire request with a secret key and an ever-increasing nonce, but I was lazy and I'm just not very worried about a man-in-the-middle attack between Google and my VPS.

I could have hacked my copy of the bitcoind C++ code to check for the secret value in requests and also modified it so it accepted connections from the Internet... but instead I wrote this little proxy server in Python that runs on the same box as bitcoind:
Code:
#
# WSGI Proxy into the bitcoind daemon (which only listens on 127.0.0.1 for security).
# Rejects non-HTTPs connections, or non-POST requests
# Rejects queries that don't include a pre-shared secret value
#
# Apache calls this because of a directive in /etc/apache2/sites-available/xyz.com
#

import hashlib
import urllib2

def application(environ, start_response):
  serverURL = "http://127.0.0.1:8332/"

  def error_response(message):
    response_headers = [('Content-type', 'text/plain'),
            ('Content-Length', str(len(message)))]
    start_response('500 Internal Server error', response_headers)
    return message

  if environ.get("HTTPS") != "1":
    return error_response("Insecure connections not allowed.")

  request = environ.get("wsgi.input").read()
  secret = request[0:32]
  json_request = request[32:]

  if hashlib.md5(" pre shared secret goes here "+json_request).hexdigest() != secret:
    return error_response("Authentication failed.")

  req = urllib2.Request(serverURL, json_request)
  response = urllib2.urlopen(req)
  json_response = response.read()

  status = '200 OK'

  response_headers = [('Content-type', 'text/plain'),
            ('Content-Length', str(len(json_response)))]
  start_response(status, response_headers)

  return [json_response]
The other end of the connection is also django+Python code running on App Engine:
Code:
import hashlib
import jsonrpc
from google.appengine.api import urlfetch

def make_bitcoin_request(server_url, server_secret, method, params):
  json_request = {
    "jsonrpc": "2.0",
    "id": str(time.time()),
    "method": method, "params": params
    }
 
  json_string = jsonrpc.dumps(json_request)
  secret = hashlib.md5(server_secret+json_string).hexdigest()
 
  try:
    fetch_result = urlfetch.fetch(payment_server,
                                  method="POST", payload=secret+json_string,
                                  headers={ 'Content-Type' : 'text/plain' })
  except urlfetch.Error, e:
    logging.error('make_bitcoin_request failed: '+str(e))
    logging.error('Request:'+json_string)
    return None
 
  if fetch_result.status_code != 200:
    logging.error('make_bitcoin_request failed; urlfetch status code %d'%(fetch_result.status_code))
    logging.error('Request:'+json_string)
    return None

  r = jsonrpc.loads(fetch_result.content)
  if r['error'] is not None:
    logging.error('make_bitcoin_request failed; JSON error returned')
    logging.error('Request:'+json_string)
    logging.error('Result:'+fetch_result.content)
    return None

  return r['result']

I'm happy with how it is working.  My biggest worry is that the bitcoind process might unexpectedly exit, or fill up the disk with debug.log messages, or just generally be flaky.  But so far so good...
2247  Economy / Marketplace / Re: Get 5 free bitcoins from freebitcoins.appspot.com on: June 12, 2010, 03:32:34 AM
Will you share the source code of your service? Smiley
I'd be happy to share the interesting bits, but the architecture is... um, unique.  I'll start a thread on the Development forum describing how I built it.
2248  Economy / Marketplace / Re: Get 5 free bitcoins from freebitcoins.appspot.com on: June 11, 2010, 07:27:15 PM
Showing the number of Bitcoins available is on my TODO list.  I just checked and the balance is up to 1,135 (thanks to whoever donated!).

And right now it is 5 bitcoins per IP address (not bitcoin address).  Not per-day-- just 5.  I want to start out conservatively, I will loosen it to 5 per (day?/week?/month?) if people start having lots of trouble because they get a dynamic IP address from their ISP that already got some.

RE: captchas:  yeah, I was gonna start out with a captcha, but I wanted it to be as simple and non-threatening as possible.  I don't think anybody who has access to hundreds or thousands of working public IP addresses would go to the effort of writing a bitcoin-harvesting robot, though I suppose somebody with a botnet might take a crack at it.  To make that tougher I could make it 5 bitcoins per IP AND 5 bitcoins per bitcoin address (so they couldn't have all the bots in the botnet using the same BC address).

2249  Economy / Marketplace / Get 5 free bitcoins from freebitcoins.appspot.com on: June 11, 2010, 05:38:45 PM
For my first Bitcoin coding project, I decided to do something that sounds really dumb:  I created a web site that gives away Bitcoins.   It is at: https://freebitcoins.appspot.com/

Five ฿ per customer, first come first served, I've stocked it with ฿1,100 to start.  I'll add more once I'm sure it is working properly.

Why?  Because I want the Bitcoin project to succeed, and I think it is more likely to be a success if people can get a handful of coins to try it out.  It can be frustrating to wait until your node generates some coins (and that will get more frustrating in the future), and buying Bitcoins is still a little bit clunky.

Please try it out and get some free coins, even if you already have more Bitcoins than you know what to do with.  You can get some and then donate them right back; the address is: 15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC
2250  Bitcoin / Development & Technical Discussion / Re: Technical clarifications on: June 11, 2010, 01:34:11 AM
I'll try to answer what I can:

0) Is it necessary to run a node if i want to have a wallet? Is it necessarily attached to some exact node or i can keep my wallet on flash drive for example and use it with any node? Where and in which form my account balance is stored?
You either have to run a node or trust somebody else (like MyBitcoin.com) to keep a wallet for you.

Your account balance is stored in a Berkeley DB file called 'wallet.dat' (what directory depends on your operating system; on my Mac it is ~/Library/Application Support/Bitcoin/wallet.dat, on linux it is ~/.bitcoin/wallet.dat, not sure about PCs).

The only application that can read wallet.dat is the bitcoin code, and the database structure isn't documented anywhere besides the bitcoin C++ source code.
Quote
1) Do i need to download whole network transactions log to be able to validate received coins?
Theoretically, no, but the code to do lightweight validation hasn't been written.
Quote
2) How user protected from potential situation when some node is hacked(or modified) and using his id (public key) to send money from his account? It looks possible when everything is sychronyzed between everybody.
Satoshi is planning on encrypting the wallet database, so you'd need to enter a password to read it.  (and they need to get your private keys to generate transactions-- those are what are stored in the wallet.dat)
Quote
3) Which data exactly passed between 2 nodes during transaction? (or just show me place in source code where to look)
4) Can somebody please write more details about transaction fee: why is it needed, how and in which cases it's used and so on.
Dunno.
Quote
5) Is there any any plans on decentralizing node list (i have figured out from irc that bitcoin is currently not really decentralized, because nodes getting in touch by joining irc channel on freenode).
There's another thread about this in these forums; maybe we should start a "Satoshi's TODO list" thread and get folks to volunteer to help out.
Quote
6) Do i correctly understand that after some point in time nobody will have ability to generate new coins? we'll just use fixed amount of existing ones.
Fewer and fewer coins will be created over the next N years (where N is-- what, 20?).  That's a feature, not a bug...

RE: developing your own version: are you thinking of creating a second bitcoin implementation that is compatible with the existing C++ one  (good idea, in my opinion)?  Or creating a similar-but-not-the-same system (bad idea, in my opinion)?
2251  Economy / Economics / Trust/backing... on: June 08, 2010, 06:07:59 PM
In another thread venom said:
Quote
Give people some kind of assurance that there isn't a way that the operator of the currency can just start minting bitcoins at will.  It's probably irrelevant at the moment - but imagine if BC$ was as popular as e-gold in its heyday - the owner, if he were less than honest, could essentially be an Internet millionaire spending his own currency at will around the interwebs.   In theory it's possible with any digital currency - but at least, the theory behind the digital gold currencies is that if all else fails, you can call them up and redeem physical gold (I'm referring to c-gold, e-gold, Pecunix, GoldMoney, and probably many others) so you have something 'tangible' as backup.  What is BC backed by?  Just saying, these might be things that a skeptic will ask himself before wanting to use this currency.
So the short answer is that BC is backed by mathematics/cryptography and the "wisdom of crowds"; assuming there's no flaw in the algorithms, and assuming that there is no grand conspiracy of more than half of the BC nodes, it is impossible to inflate the currency or make fraudulent payments.

I don't believe in grand conspiracies, so that doesn't worry me.  And I can't see any flaw in the algorithms... but that's where I'm skeptical (there might be bugs in the BC code, but those can and will be easily fixed).

Are there any professional cryptographers looking at Bitcoin?
Or will they only get interested if/when Bitcoin gets popular?

2252  Bitcoin / Bitcoin Technical Support / Re: Noob question on: June 08, 2010, 03:44:41 PM
It took me over a week to generate any coins, then I generated two blocks (100 bitcoins) in just a few hours  (running bitcoin on my 2GHZ dual core mac laptop).

While it is fun to see bitcoins generated "out of thin air", it is much more important to figure out how to make them easier to buy and easier to spend.  Since you're not a programmer/developer, I'd like to hear any ideas you have on how to make bitcoin less geeky and more user-friendly.
2253  Bitcoin / Development & Technical Discussion / Compiling bitcoind on unix/linux on: June 08, 2010, 03:33:24 PM
It took me a while to figure out where to get the wx_gtk2ud-2.9 library needed to compile bitcoind, so I thought I'd share for anybody else who's not a wxWidgets expert:

Code:
If you want to build bitcoind, the no-gui bitcoin daemon, you need the wxWidgets 'base' library.
After untarring the wxWidgets source:

cd /usr/local/wxWidgets-2.9.0
mkdir buildbase
cd buildbase
../configure --disable-gui --enable-debug --disable-shared --enable-monolithic
make
sudo su
make install
ldconfig

I'd humbly suggest adding the above to the build-unix.txt file...  Satoshi, is there a preferred way to submit patches?

27 Aug 2010:  This is no longer necessary-- bitcoind doesn't require wxwidgets at all any more.
2254  Bitcoin / Bitcoin Discussion / Re: Anybody generating on Amazon EC2? on: June 03, 2010, 11:47:32 PM
One Amazon "EC2 compute unit" is, according to them, approximately equal to a 1ghz 2007 Xeon processor (that's a m1.small).

Judging by my laptop generating experience, there's no way an m1.small instance would generate enough ฿ to be profitable.

The heftiest instance you can buy ("large CPU") is 20 units big, and costs $0.231 per hour; with bitcoins selling for about a half a penny each it would have to generate 46 per hour (or about a block an hour) to break even.  Ummm.... no, that does not compute.

RE: how did I get hashes-per-second on my mac:  I applied laszlo's patch to a version I compiled from source code.
2255  Bitcoin / Bitcoin Discussion / Anybody generating on Amazon EC2? on: June 03, 2010, 06:55:01 PM
Has anybody tried generating bitcoins on Amazon EC2 instances?  If you have, how many coins/day are you getting (and on what type of instance) ?

If nobody has already, I might do some experimenting and get some back-of-the-envelope estimates for $/bitcoin using Amazon EC2 spot instances.

(I've had zero luck generating any coins over the last week on my couple-year-old Macbook Pro, which only does 150-200K hashes per second)
2256  Bitcoin / Development & Technical Discussion / Re: Hostnames instead of IP Addresses on: June 03, 2010, 02:29:56 PM
Seems like $ would be inviting confusion, since it's followed by numbers that can look kind-of like a dollar amount:
19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3$64.20.45.38

means send $64.20 to my bitcoin address ?

Hyphen or underscore would be less confusing, but I think period would work really nicely:

19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3.64.20.45.38
19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3.skypaint.com

The advantage of that last one is it is a valid URL;  if a user pasted that into Firefox's URL bar or searched for it in Google the website owner could display a helpful web page explaining how to pay.
2257  Economy / Trading Discussion / Re: For a website taking payments with bitcoins, better: IP or bitcoin addresses? on: May 31, 2010, 04:16:59 PM
To get back to the original question, paying to a bitcoin addresses displayed on an https: webpage secured with a valid certificate is better.

When the bitcoin client supports secure connections to IP addresses, then paying to an IP address displayed on an https: webpage secured with a valid certificate will be just as good (security-wise, anyway).

Bitcoin doesn't try to solve the "am I paying who I THINK I'm paying problem" -- we need HTTPS and signed certificates and DNSSEC for that (or something similar).  Bitcoins are a small but really important piece of the payment puzzle...
2258  Economy / Trading Discussion / Re: For a website taking payments with bitcoins, better: IP or bitcoin addresses? on: May 30, 2010, 04:27:13 PM
Quote from: gavinandresen
I don't see the security risk of being able to intercept or eavesdrop on a Bitcoin transfer.

When sending to an IP address, BitCoin contacts the IP address without any authentication/encryption and requests a new BitCoin address, which is also sent back in plaintext. You then send the BitCoins to that address in the normal way. A man in the middle can intercept this request and send back their BitCoin address. You will then securely transfer BitCoins to the wrong person.
Ahh, right, I see; I hadn't thought through the mechanism of the pay-via-IP-address functionality.

That brings up another possible man-in-the-middle attack for HTTP connections:  if you see a Bitcoin address on a non-secure web page, you can't be sure that you're seeing the correct address (a man-in-the-middle might have replaced it with THEIR Bitcoin address).  And ditto for sending your Bitcoin address to somebody to request payment (e.g. send it via email or in your forum signature and it might get replaced before being displayed to people who want to send you money).


2259  Economy / Trading Discussion / Re: For a website taking payments with bitcoins, better: IP or bitcoin addresses? on: May 29, 2010, 07:16:36 PM
It's not just an issue with proxies. Since there's no authentication, any "man in the middle" can intercept your BitCoin transfer, including your ISP and other people on your wireless connection. It's like logging into your bank's website without HTTPS.
I don't see the security risk of being able to intercept or eavesdrop on a Bitcoin transfer.

All transactions are broadcast to all Bitcoin generating nodes, anyway, and the transactions are impossible to alter or forge (because they're digitally signed).

A man-in-the-middle could drop the transaction, but SSL doesn't fix that-- if they're relaying SSL traffic they could drop your SSL-encrypted transaction, too.

There are good non-security-related reasons for encrypting Bitcoin transaction traffic, though (makes it harder for governments/ISPs to do deep packet inspection to selectively drop Bitcoin traffic, for example).
Pages: « 1 ... 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 [113]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!