Bitcoin Forum
August 09, 2025, 06:45:45 AM *
News: Latest Bitcoin Core release: 29.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Bitcoin Discussion / Re: The Bitcoin Debit/Gift Card? on: May 09, 2011, 04:36:23 AM
Using a non-smart-card means you would have to trust the merchant not to just take all the Bitcoins on the card.  This works for gift cards that are good at a single merchant but it doesn't really work for generic currency.
Yes, but then when you pay with a bank card, you have to trust that the amount you're authorizing is the same as shown on the screen, and when you use a credit card, you have to trust the number isn't being skimmed and stored somewhere. There have been cases of people opening up gas pumps and such and installing skimmers inside the machine, so you could never tell it was there.

The main thing is those machines are issued by banks, have various tamperproofing systems, and if you do get ripped off you have the bank to complain to. How do you be sure a random Bitcoin card reader is safe, and where do you go if you get scammed?
2  Bitcoin / Bitcoin Discussion / Re: POLL: How many bitcoins do you CURRENTLY have? on: May 09, 2011, 04:31:07 AM
0.05. Cheesy I don't have any equipment to mine with and they're surprisingly difficult to buy if you don't have PayPal, so...
3  Bitcoin / Bitcoin Discussion / Re: Is it actually possible to ban P2P networks? on: May 07, 2011, 10:56:26 PM
I haven't used Tor or read much about how it works, but I'd heard it's rather poorly designed and has had a few security issues in the past. If that's the case, it's more an example of a system with design flaws that got used against it than a successful blocking of P2P in general.
4  Bitcoin / Project Development / Re: Bitcoin monitor script for Conky [Updated: v92704] on: May 02, 2011, 08:07:43 AM
Updated to add MtGox ticker data. Adds a dependency on LuaSocket. It's structured to be fairly simple to add support for any JSON HTTP URL, so feel free to ask.
5  Bitcoin / Bitcoin Discussion / Re: Max Number of Bitcoins - Then What on: April 24, 2011, 06:34:16 AM
Yes, the fee system does seem a bit iffy to me. Will miners make enough from it to be worth keeping their mining operations going? If all but a few miners drop, won't those few have control of a significant portion of the network's processing power? How will users know what's a good fee to add to each transaction?

It kinda bugs me especially that the fee is set to zero by default, since a lot of people probably won't bother to change it. 0.01 might be a saner default. I doubt people are going to complain about such a small fee that they can disable if they want, but enough will leave it on that there should still be a decent amount going around.
(Just make sure people know it's there - they're likely to get angry at a "hidden fee", even if it can be disabled and no matter how small it is.)
6  Bitcoin / Bitcoin Discussion / Re: Bitcoin security - "big room" analogy on: April 24, 2011, 06:31:07 AM
Interesting analogy. Your last paragraph seems to be missing some line breaks though (and would look better if you used the HTML <ul> and <li> tags rather than a "handmade" list). I'd also go into trying to explain, after that last paragraph, why it's impossible to forge and steal things - just simple explanations like "because you need x information to do so, and if you don't have it, calculating it would take trillions of years".
7  Bitcoin / Bitcoin Discussion / Re: Physical bitcoins, take 4 on: April 21, 2011, 05:48:18 AM
I like the idea of physical Bitcoins, but I think paper isn't going to be very feasible. No matter what system you come up with to try to secure the keys, someone will find a way around it. It is like DRM in a sense: you're trying to stop "the bad guy" from copying information (the private key), while still letting "the good guy" access it. Difference is instead of "the bad guy" being someone who wants to copy music they paid for, it's someone who wants to copy a key before passing now-useless cash on to some poor sap.
Never underestimate the resources, smarts, and time crooks have to dedicate to their work, especially when it involves essentially stealing money (from the sucker they pass the bill to after copying it). There are a few of us and thousands of them who'd love to be able to give themselves free money.
That's not to say I don't think we should even consider some kind of physical/printed currency. I just don't think it'll be as simple to prevent fraud as some seem to think.

What I think would be more feasible and useful is using SD cards and USB sticks as coins and wallets. These days you can get 32GB of each for under $100. For use as coins you'd want not one large card but many small ones (even 1MB should be plenty) - probably everyone has a few laying around, and for such small sizes I'd imagine they'd cost only a few cents each.

For coins, you'd put a private key (or a few) on a card and hand it out. To redeem the coin you put it into your PC and copy the key into your client. SD cards are roughly the size of a coin and just about everyone has a reader for them (and if not they're cheap and have many uses) so this works nicely. MicroSD is a bit small (easily lost) but has some advantages like being usable in modern phones; keeping them in the plastic case they come in could help with the size issue.

For wallets, you'd put a few coins into a wallet file stored on a USB stick. You could hand those out too (like "bills", being physically larger than SD cards) or use them like a bank card - put the stick in, transfer a few coins.

Advantages of this are that you'd be using ordinary SD cards and USB sticks, that are too small in capacity to be of much other use, can be "refilled", and can hold other data besides just the coins. So you could include some notes or media with a payment. For example when paying your bills, just send in a card/stick containing the balance and a text file holding your account number. (Granted if you can pay bills in bitcoins, you'd probably do so over the Internet, but anyway...)

Obvious problems:
1) People can still easily copy the coins and then hand them out again.
2) A merchant can copy your entire wallet when you put the USB stick in to pay.
3) While small-capacity cards would presumably be cheap, nobody sells them anymore.
4) Being given an SD card or USB stick, you have no way to know if it even has any coins on it.

#3 I think is the big thing here. While you can walk into your favourite overpriced electronics store and buy a 32GB card for not much, you can't buy 32768 1MB cards at all. Nobody makes 1MB cards anymore.
What you'd have to do is start up a small business selling small cards/sticks for just this purpose. I imagine you could convince a manufacturer in Asia to make you a few thousand small ones for not too much, which could even be stamped with the Bitcoin logo. You earn back the cost by starting up an exchange; someone sends you some amount of money (plus a few cents to cover the cost of the card and postage), you send back a card with that amount on it.

Now, if you already have these cards being manufactured for you, you can go on to add some security features. Say, reading the card destroys it, or the card comes encased in something similar to their plastic cases which must be destroyed to get at the card itself (so you know a card not in such a case is no longer valid). Those ideas kill reusability, but I'm not coming up with any ideas that don't. Ultimately they'd be more like checks than coins, and nothing stops someone from writing you a bum check either.

For "wallet" USB sticks, the most secure thing to do would just be to keep only a little in it at a time, so that anyone who copies it won't get much. Of course that isn't very convenient. What you might have is a stick that unfolds to expose a simple numeric display and keypad, where you type in a balance, then press OK, and it allows only that much to be taken out. One way to do this would be to make "change" - store several keys worth 0.5BTC, 1BTC, 5BTC, etc, and it passes on to the reader only enough keys to make that balance (rounding up if necessary), just like you'd give a cashier only enough coins to make the balance (but if you don't have any pennies maybe giving a nickel to cover the last 3 cents).
Having such intelligence in the stick itself would of course increase its cost, but you'd only need one - you wouldn't be handing these out to people like you would with coins; they'd function more like a bank card.
You could eliminate the need for a lot of complexity in the design by just having it emulate an ordinary removable disk, with one partition where you can store files like any ordinary disk, and one reserved for the coin keys. When you hit OK, the appropriate keys are readable from the raw partition (no filesystem) and removed from memory on read. Writing a program to handle this on a PC would be dead simple. The device could also be powered by the USB port itself, reducing a lot of physical complexity.


I think no matter what you do, it's going to be somewhere between difficult and impossible to make physical bitcoins that don't carry the risk that they've already been digitally spent (or if you use SD cards, that they don't actually contain coins at all). It boils down to being given an object which is said to have value, but which becomes worthless through an action that can be done without physical access to the object. You have to trust that they won't do that, because there's really not much you can do to prevent it. I also think the future of Bitcoin for in-person transactions is in smartphone apps, not distributable tokens. But if you could make tokens and smart USB sticks work, that'd be pretty damn cool. Tongue
8  Bitcoin / Development & Technical Discussion / Not able to run bitcoind and GUI at same time on: April 19, 2011, 03:50:01 AM
At least on my Xubuntu machine, any attempt to start the graphical client fails with the message: "Cannot obtain a lock on data directory /home/rena/.bitcoin.  Bitcoin is probably already running." So, any time you want to use the graphical interface you need to first shut down bitcoind, losing all your connections. Or you can leave the GUI open all the time (sitting in taskbar since the option to minimize to tray is disabled), which is kinda inconvenient and makes the daemon not really a daemon anymore.

Can the GUI app not simply work as a frontend to bitcoind, letting it run at all times?
9  Bitcoin / Project Development / Bitcoin monitor script for Conky [Updated: v92704] on: April 19, 2011, 03:33:32 AM
Here's a quick Lua script I wrote for the system monitor Conky to display Bitcoin network/mining status, account balance, transaction history and MtGox ticker data. It's a little messy but it works. Tongue Requires Json4Lua and LuaSocket, talks to an instance of bitcoin[d] on the local system.

Code:
--[[ Bitcoin Lua script for Conky, by Rena. Build #92704.
Usage: Add a "lua_load" line to your .conkyrc to load this script,
then add variables to your config:

${lua bitcoin_balance [account name]}
 (You can also use lua_bar, lua_graph, etc. A graph might be interesting for
  those who perform a lot of transactions!)

${lua bitcoin_info format string} (or lua_parse)
 Format string is any string (can contain line breaks), in which any instance of
 %foo% is replaced with the value of the variable foo output by
 "bitcoin getinfo". Cannot contain multiple spaces; use ${tab} for alignment.
 (This is a limitation of how Conky passes strings to Lua.)

${lua bitcoin_transactions account num format} (or lua_parse)
 List up to 'num' recent transactions (most recent first) on an account. Account
 name must be quoted if it contains a space, can be * for all accounts. Format
 works same as bitcoin_info.

${if_empty ${lua bitcoin_running}}...${else}...${endif}
 To display text only if Bitcoin is/isn't running. bitcoin_running returns an
 empty string when Bitcoin running and '0' when it isn't, so that if_empty can
 be used like a normal 'if'.

${lua mtgox_ticker format string} (or lua_parse)
 Works same as bitcoin_info. Field names are those under 'ticker', so e.g.
 write %high%, not %ticker.high%.

Send bug reports, suggestions, flames, cat photos and whatever else
to ('moc.liamg\064rekcahrepyh'):reverse().
Send spare change to 15R7dpxfWuDrQY9CtUzMsg6A7sKMdWbTd3 why not.

Version history:
-92704:
 -Added mtgox_ticker() and ability to fetch JSON URLs. (Adds dependency on
  LuaSocket.)
 -Changed keypoololdest to a formatted date. Raw timestamp is keypoololdest_raw.
-92432: Initial release. ]]

local json = require('json') --http://json.luaforge.net/
local http = require('socket.http') --http://luaforge.net/projects/luasocket/

--options
local UpdateFreq = 5*60 --only update once every this many seconds
local SignPlus = '${color3}+' --prefix for positive numbers
local SignMinus = '${color2}-' --prefix for negative numbers
local DateFmt = '%H:%M:%S %y/%m/%d' --strftime date format
local FeeEmpty = '-.--' --string to display for %fee% when empty

--state
local Account = {} --indexed by account name
local LastQuery = 0 --last time bitcoin was called
local QueryCache = {}
local URLCache = {}

--[[ Send a query to bitcoin.
This function caches queries so that bitcoin is only called once per UpdateFreq
to avoid creating a lot of needless overhead by spawning processes over and
over. ]]
local function bitcoin_query(query)
local now = os.time()
LastQuery = now
local cache = QueryCache[query]
if cache then
if os.difftime(now, cache.Time) < UpdateFreq then
return cache.Result
end
else
QueryCache[query] = {}
cache = QueryCache[query]
end

--hack: redirect stderr to stdout and look for either an error message or
--what looks like JSON data.
local data, found = '', false
local app = io.popen('bitcoin ' .. query .. ' 2>&1')
for line in app:lines() do
if line:sub(1,6) == 'error:' then
if line == "error: no response from server"
or line == "error: couldn't connect to server" then
Running = false
return nil, "Bitcoin not running"
else
Running = false --presumably...
io.stderr:write("Bitcoin: " .. line .. "\n")
return nil, line
end
elseif found then data = data .. line
elseif line:sub(1,1) == '{' or line:sub(1,1) == '[' then
found = true
data = data .. line
end
end
app:close()
Running = true --well it must be, we just talked to it.

cache.Time, cache.Result = now, json.decode(data)
return cache.Result
end

--[[ Fetch JSON data from a HTTP URL.
This function caches queries in URLCache so that the same URL isn't accessed
more than once per UpdateFreq. This is a simple naive cache that only works if
the URL is exactly the same each time.
On success, returns JSON data as table.
On failure, returns nil and error message. ]]
local function get_json_url(url)
if not URLCache[url] then URLCache[url] = {LastQuery=0} end

local now = os.time()
if (now - URLCache[url].LastQuery) < UpdateFreq then
return URLCache[url].LastResult
end
URLCache[url].LastQuery = now

local text, status = http.request(url)
if (not text) or (status < 200) or (status >= 300) then
URLCache[url].LastResult = 'Error: ' .. tostring(status)
return nil, URLCache[url].LastResult
end

local err
URLCache[url].LastResult, err = json.decode(text)
if URLCache[url].LastResult then return URLCache[url].LastResult
else return nil, err
end
end

--[[ Conky splits args at space, regardless of quotes. So if arg begins with a
quote, look for end quote and piece the string together.
note that this fails if there are multiple spaces in a row since Conky
compresses them into one. ]]
local function readquotedarg(args, idx)
idx = idx or 1
local str = ''
if args[idx] and args[idx]:sub(1,1) == '"' then
if args[idx]:sub(-1) == '"' then
return table.remove(args, idx):sub(1, -2)
end
str = table.remove(args, idx):sub(2)
while args[idx] and args[idx]:sub(-1) ~= '"' do
str = str .. ' ' .. table.remove(args, idx)
end
return str .. ' ' .. table.remove(args, idx):sub(1, -2)
elseif args[idx] then return table.remove(args, idx)
else return nil
end
end

--[[ Check if Bitcoin is running. ]]
function conky_bitcoin_running(...)
local now = os.time()
if Running == nil --don't know
or os.difftime(now, LastQuery) >= UpdateFreq then
bitcoin_query('getinfo') --make some random query to find out
end
return Running and '' or '0' --for Conky if_empty
end

--[[ Balance for particular account. ]]
function conky_bitcoin_balance(...)
local args = {...}
local account = readquotedarg(args) or "Your Address" --default account name

--create status table for this account if not done already.
if not Account[account] then Account[account] = {
LastUpdate = 0, LastBalance = 0
} end

--Query bitcoin to find account balance.
local info = bitcoin_query('listaccounts')

--display negative balance to signal error, since some Conky functions
--expect a number.
if not info then Account[account].LastBalance = -1 end

Account[account].LastUpdate = now
return tonumber(Account[account].LastBalance)
end

--[[ Recent transaction list. ]]
function conky_bitcoin_transactions(...)
local args = {...}
local account = readquotedarg(args) or "Your Address"
local numshow = tonumber(args[1]) or 5
local fmt = table.concat(args, ' ', 2) --format string

local info = bitcoin_query(('listtransactions "%s" %d'):
format(account, numshow))

--add some convenient fields to info
for i = 1,#info do
if not info[i].sign then --cache means these may already be set
info[i].sign = (info[i].amount > 0) and
SignPlus or SignMinus
info[i].absamount = math.abs(info[i].amount)
info[i].absfee = info[i].fee and math.abs(info[i].fee) or
FeeEmpty
info[i].rawtime = info[i].time
info[i].time = os.date(DateFmt, tonumber(info[i].rawtime))
info[i].fee = info[i].fee or FeeEmpty
end
end

--transactions seem to be listed oldest first, so reverse iterate.
local res = ''
for i = math.min(numshow,#info), 1, -1 do
res = res .. fmt:gsub('%%([%w_]+)%%', info[i]) .. '\n'
end
return res
end

--[[ General info. ]]
function conky_bitcoin_info(...)
local args, info = {...}, {}
local fmt = table.concat(args, ' ') --format string

--query Bitcoin and parse results.
local info = bitcoin_query('getinfo')

if not info.keypoololdest_raw then
info.keypoololdest_raw = info.keypoololdest
info.keypoololdest = os.date(DateFmt, tonumber(info.keypoololdest))
end

--generate and return output string.
LastInfoStr = fmt:gsub('%%([%w_]+)%%', info)
LastInfoUpdate = now
return LastInfoStr
end

--[[ MtGox info. ]]
function conky_mtgox_ticker(...)
local args, info = {...}, {}
local fmt = table.concat(args, ' ') --format string

local data, err = get_json_url('http://mtgox.com/code/data/ticker.php')
if data then MtGoxLastResult = fmt:gsub('%%([%w_]+)%%', data.ticker)
else MtGoxLastResult = tostring(err)
end
return MtGoxLastResult
end

Example config:
Code:
${color1}BTC${hr}
${if_empty ${lua bitcoin_running}}${lua_parse bitcoin_info Balance:${tab 40}${color0}%balance%${color1}
Tx Fee:${tab 40}${color0}%paytxfee%${color1}
Connections:${tab 10}${color0}%connections%${color1}
Blocks:${tab 40}${color0}%blocks%${color1}
Oldest:${tab 40}${color0}%keypoololdest%${color1}
Difficulty:${tab 20}${color0}%difficulty%${color1}
Version:${tab 40}${color0}%version%${color1}}
${lua_parse bitcoin_transactions * 5 %sign%%absamount% %confirmations%${tab 16}%absfee%${tab 16}%time%}
${else}${color0}NO DATA${endif}
(Ugly ain't it? Tongue But the result looks quite nice! Screenshot here as it's too big to attach to the post. :p)
10  Bitcoin / Project Development / Re: Stealthcoin on: April 19, 2011, 02:28:39 AM
Just run it when the computer isn't in use (nobody logged in)? I assume all 200 machines aren't in use 24/7. Tongue
11  Bitcoin / Development & Technical Discussion / Re: Detect if Bitcoin is running? on: April 19, 2011, 01:51:38 AM
That's the kind of thing I was looking for. Of course that means anyone using my script also has to use that branch. Will that change be in the official client in some future version?
12  Bitcoin / Bitcoin Discussion / Re: newbie questions: fee estimation, file size prediction, ISP blocking on: April 19, 2011, 01:05:27 AM
I wonder if an attacker could harm the network by taking over the IRC server it uses?
13  Bitcoin / Development & Technical Discussion / Re: Detect if Bitcoin is running? on: April 18, 2011, 06:27:46 AM
Hmm, both of those rely on Unix shell commands and redirection. I was hoping for something like a PID file I can check that only exists when the server is running. I can do similar just by appending 2>&1 to the command I call from Lua, but as far as I know there's no guarantee that io.popen() will actually execute the command the way a shell would rather than, for example, just passing everything after the first space as the parameter to the program being called.
I can use sockets as well, but that requires adding LuaSocket, and I was hoping not to depend on any external libraries. Lua doesn't provide much on its own (it focuses on being simple and lightweight) so that may prove difficult to avoid...
14  Bitcoin / Development & Technical Discussion / Detect if Bitcoin is running? on: April 18, 2011, 05:51:58 AM
What would be the proper/best way for a script to tell if bitcoin[d] is running? I'm writing a Lua script that calls `bitcoin getinfo` and similar commands, and I see it outputs a message to stderr if the server isn't running, but Lua doesn't provide any standard way to read stderr, so I was hoping there's another way to check?
15  Bitcoin / Development & Technical Discussion / Re: Time for a threat down? on: April 18, 2011, 05:23:23 AM
Increasing the transaction fee helps your transaction go through during a spam attack yes, but how does John Q Public know what would be a good value to use at the moment? I imagine most will just leave it at the default setting of zero; some will set it to 0.01 and forget about it. It'd help if the client could automatically suggest a fee amount for each transaction that will probably get it handled reasonably fast.
As well, if high-budget spammers are flooding the network with transactions with large fees, one would need to out-fee them to defeat the spam, no? People would start to get annoyed if they had to pay a $1 fee on every transaction. And if said spammers are also major miners, wouldn't they even be able to reclaim a lot of their own fees, thus keeping the attack going?

# Malware unrelated to bitcoin could extract the relevant contents of wallet.dat and steal the money. Protecting the wallet with a good symmetric crypto would manage some of this risk, but I think that it would be advisable to have wallets with nontrivial amounts of bitcoins associated with them on removable media such as USB drives.
On this point: from what I've seen, your wallet has to be in ~/.bitcoin/wallet.dat as long as the client is running. That makes using a removable device not very convenient. This could be improved with some minor tweaks to the client:

  • Allow entering paths to where one or more additional wallets may reside. (These would be on removable media, so wouldn't necessarily be present all the time.)
  • If one of these files suddenly comes into existence (i.e. the media containing the file was inserted), automatically import the address list from it. Keep the file closed most of the time; open it only when needing to access it.
  • If one of these files suddenly disappears (i.e. the media was removed), automatically remove those addresses again.
  • The user can use Truecrypt or whatever other mechanism they like to encrypt the media.
  • Be able to automatically transfer funds from ~/.bitcoin/wallet.dat to any wallet stored on external media whenever the media is connected. This turns the local wallet file into basically just a buffer holding any received funds that haven't been saved to external media, so there's little risk of it being stolen. (In theory we could run without a local wallet file and keep the transactions in memory until media is present, but that risks losing them if the machine crashes.)

It's pretty much guaranteed that the more popular Bitcoin becomes, the more malware will be out there specifically to steal wallets, and also do things like hijack the Bitcoin process itself to automatically send transactions to some spammer. Encrypting the wallet won't stop a program from just reading the decryption keys out of memory. Eventually - at very least, when the user wants to send money - everything necessary for a trojan to steal the wallet and/or make some transactions of its own will be available. The best way to prevent this is removable media - no malware can access memory that isn't physically connected - so it makes a lot of sense to make it as convenient as possible to use removable media.

Related: easy importing/exporting of bitcoins/wallets to/from files, so that one can distribute them by putting them on cheap removable media and passing it to someone. For the non-technically-inclined to use this, it should as simple as "export 10BTC to a file" and "drag file into your Bitcoin client window". (Maybe even pop up a window with a coin icon and the instructions "drag this icon to a folder to save the coins to a file".)

(and while we're at it, can we move ~/.bitcoin to ~/.config/bitcoin to avoid cluttering the home directory? >.>)
16  Bitcoin / Hardware wallets / Re: Android Bitcoin Wallet on: April 18, 2011, 04:48:57 AM
What about a remote blockchain?  A symlink over the Internet, or a blockchain 'server' that can scan the blockchain for these Android clients whenever the Internet is available.

We will be releasing an android client soon, coupled with a server that does exactly this.
For Linux, it would be enough to have a frontend that just connects to the machine via SSH or similar secure protocol and talks to bitcoind. I assume the Windows client has a similar "headless" interface, and there are SSH ports for Windows as well, though I've never used them so I don't know how easy they are to use.
17  Bitcoin / Development & Technical Discussion / Re: Feature request for Bitcoin client on: April 18, 2011, 04:04:50 AM
Windows lets you select multiple rows via CTRL+left mouseclick, same thing for a couple of them via Shift+click.
ok, i selected, now how i print it?
I don’t know of any way to do that, just count the highlighted rows manually.
Unfortunately Windows doesn't normally provide any way to export the contents of a list like that. However there are some freeware utils that can do it. One I've used in the past is SysExporter. I haven't used Windows in a few years though so I don't know if that's still around.

I think what would help more than gridlines is alternating row background colours (say white/light blue). As for serial number it sounds like he just wants each transaction numbered sequentially (first ever to/from that address is #1, then #2...) for convenient sorting (especially if you could click on the column headers to sort). Though I imagine a date would do just as well, as long as it sorted numerically (by timestamp) rather than sorting the date strings themselves as text as some silly programs do...

(Another trick to count rows is to just click the first one, then keep pressing the down arrow, counting the presses until you hit the bottom. Also useful for counting string length.)
18  Bitcoin / Bitcoin Discussion / Re: Calling all MEN... on: April 18, 2011, 12:05:12 AM
The only thing that can truly stop Bitcoin is a massive societal resentment which is highly improbable.
Just start convincing people that it contains a backdoor. Present some crypto mumbo-jumbo, some snippets of random computer code, etc as evidence. How many will make any attempt to verify the claim - or even really understand it - before simply going "zOMG BITCOIN IS A SCAM!!1!cos(0)"? Who is this mysterious Satoshi guy and why does he remain anonymous? Etc.
19  Bitcoin / Bitcoin Discussion / Re: Odd pattern in BitcoinMonitor on: April 17, 2011, 11:48:40 PM
That seems like the best way. Each request doesn't result in an immediate transaction but instead just enters into a queue. You look at the queue and see if the requests look suspicious before approving them manually. Designed right it wouldn't be foolproof, but it could be handled entirely by one person - they'd just have a list like IP, account name, time, and a checkbox (and select/deselect all buttons), say 100 items per page, and could just approve or deny them en masse.
There is risk of denying a legitimate request that happens to be in the middle of a ton of spam, but just add a note to the page explaining this risk. People shouldn't be too upset that someone who's giving away free money might miss their request. :p

For those suggesting Javascript games and such, you should know that the browser is no more than a user interface. Whatever you achieve in the game, the browser has to report back to the server - a bot can just tell the server anything it wants. So the only secure mechanism is to make it work similar to mining, where the client - be it a browser or a bot - has to do several minutes' worth of computation to figure out a valid response to send to the server, and each response is only valid once.

It's worth noting though that in my experience, browsers and OSes of all types suck at limiting CPU usage by Javascript, and a script doing heavy computation like that can bog down the entire machine. So it's not a really user-friendly solution... :/
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!