How can Hunger Coin guarantee payback if you are lending the coins to people who may not pay YOU back?

I'm sorry, but "Hunger Invest" and "Hunger Lending" still sound like Ponzi schemes to me.

No, I don't understand.

To whom are you lending the bitcoins you receive?

Unless you can clearly explain, in small words that even I can understand, HOW you are getting the bitcoins to pay interest I'm going to assume that this is Yet Another Ponzi Scheme.

I understand how SatoshiDice makes money, and I have no issues with them generating lots of transactions.

If you were CHARGING interest then I would understand, and would have no issues with your service.

So: how will HungerCoins make money?  And don't answer "I can't tell you or everybody else will do it," that is the Ponzi-operator's standard answer.

Sweet!

Please don't play this.

If it gets popular, then it is just "use the blockchain to create a Ponzi scheme". It can scale up, using new transactions to pay a little more to older transactions made 2 or 3 blocks ago. That's is the essence of a Ponzi scheme.

If you want to test something, use the testnet.  That is what it is for.

mmm, no.

To be valid JSON, arg[1] must be:

WTF is Windows doing with the arguments?

Disclaimer: I don't do Windows.

But according to a quick google search, caret is the Windows cmd.exe escape character, and [] and {} are NOT special characters to cmd.exe.

So maybe this?

Solo miners, miners using p2pol, and mining pool operators will eventually have to upgrade.

RE: "Is there any web service to see the current ratio of v1 / v2?"

I bet if you ask nicely blockchain.info will create a page. I expect it to take a long time (a year or more) before 95% of the hashing power has upgraded and is producing v2 blocks.

The getblock RPC call will tell you a block's version number; if you're an old bash user like me then you can do something like:
... to see the version numbers of the last 100 blocks (I see 2 of 100 right now).

Start here maybe:
  https://github.com/gavinandresen/bitcointools/blob/master/deserialize.py#L262

Using bitcoind on a command-line?  What operating system?

Something is stripping off the double-quotes from the "txid" and "vout" keys before it gets to bitcoind.  If you're using bash on linux, then put single quotes around the arguments.  Like this:


I also corrected the second argument, the address is a string (strings in JSON are always "whatever") and the amount is decimal number-of-bitcoins.

If you do it, I'd suggest implementing it as a proxy that sits in front of bitcoind.

But before you do that, you should do some googling to see if somebody has already written a JSON-RPC-over-HTTP proxy that implements per-method access control.

Bitcoin version 0.7.0 release candidate 1 binaries are now available for download at:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.0/test/

Please use the issue tracker at https://github.com/bitcoin/bitcoin/issues to report bugs.

Notable changes:

Security
--------
* Fixed denial-of-service attacks (disk and CPU exhaustion) related to the alert system

Qt GUI
------
* Add UI RPC console / debug window
* Re-Enable URI handling on Windows, add safety checks and tray-notifications
* Add 2 labels to the overviewpage that display Wallet and Transaction status (obsolete or current)
* Extend the optionsdialog (e.g. language selection) and re-work it to a tabbed UI
* Merge sign/verify message into a single window with tabbed UI
* Improve error reporting at startup
* Fine-grained UI updates for a much smoother UI during block downloads
* Reorganize tray icon menu into more logical order
* Persistently poll for balance change when number of blocks changed
* Much better translations
* Added 'immature balance' display on the overview page
* (Windows only): enable ASLR and DEP for bitcoin-qt.exe
* (Windows only): add meta-data to bitcoin-qt.exe (e.g. description)

Bitcoin Improvement Proposals implemented
-----------------------------------------
BIP 22 - 'getblocktemplate', 'submitblock' RPCs
BIP 34 - block height in coinbase
BIP 35- 'mempool' message, extended 'getdata' message behavior

Core bitcoin handling and blockchain database
---------------------------------------------
* Reduced CPU usage, by eliminating some redundant hash calculations
* Cache signature verifications, to eliminate redundant signature checks
* Transactions with zero-value outputs are considered non-standard
* Mining: when creating new blocks, sort 'paid' area by fee-per-kb
* Database: better validation of on-disk stored data
* Database: minor optimizations and reliability improvements
* -loadblock=FILE will import an external block file

JSON-RPC API
------------
* Internal HTTP server is now thread-per-connection, rather than
  a single-threaded queue that would stall on network I/O.
* Internal HTTP server supports HTTP/1.1, pipelined requests and
  connection keep-alive.
* Support JSON-RPC 2.0 batches, to encapsulate multiple JSON-RPC requests
  within a single HTTP request.
* IPv6 support
* Added raw transaction API.  See https://gist.github.com/2839617
* Added 'getrawmempool', to list contents of TX memory pool
* Added 'getpeerinfo', to list data about each connected network peer
* Added 'listaddressgroupings' for better coin control
* Rework gettransaction, getblock calls. 'gettransaction' responds for
  non-wallet TXs now.
* Remove deprecated RPC 'getblocknumber'
* New blockchain checkpoint at block 193,000
* listtransactions output now displays "smart" times for transactions,
  and 'blocktime' and 'timereceived' fields were added


P2P networking
--------------
* IPv6 support
* Tor hidden service support
* Attempts to fix "stuck blockchain download" problems
* Replace BDB database "addr.dat" with internally-managed "peers.dat"
  file containing peer address data.
* Lower default send buffer from 10MB to 1MB
* proxy: SOCKS5 by default
* Support connecting by hostnames passed to proxy (-proxydns)
* Add -seednode connections, and use this for -dnsseed + -proxydns
* Added -externalip and -discover
* Add -onlynet to connect only to a given network (IPv4, IPv6, or Tor)
* Separate listening sockets, -bind=<addr>


Internal codebase
-----------------
* Additional unit tests
* Compile warning fixes

Miscellaneous
-------------
* Reopen debug.log upon SIGHUP
* Bash programmable completion for bitcoind(1)
* On supported OS's, each thread is given a useful name

Thanks to everybody who contributed to this release:
=======================================

Chris Moore
Christian von Roques
David Joel Schwartz
Douglas Huff
Fordy
Gavin Andresen
Giel van Schijndel
Gregory Maxwell
Jeff Garzik
Luke Dashjr
Matt Corallo
Michael Ford
Michael Hendricks
Peter Todd
Philip Kaufmann
Pieter Wuille
R E Broadley
Ricardo M. Correia
Rune K. Svendsen
Scott Ellis
Stephane Glondu
Wladimir J. van der Laan
cardpuncher
coderrr
fanquake
grimd34th
sje397
xanatos

Thanks to Sergio Lerner for reporting denial-of-service vulnerabilities fixed in this release.

If I recall correctly, the first testnet-in-a-box node should have all the coins.  The second starts with a zero balance / empty wallet (send it coins from the first if you need to...).

Right, that was one of the lessons learned from BIP16-- transactions redeeming non-standard inputs aught to be treated as non-standard. And they are, as of v0.6 (I think, I'm really good at forgetting when changes were introduced).

If the merchant is using stock bitcoind, then the non-standard transaction won't show up in their wallet until it appears in a block with 1 confirmation, making the security downgrade non-existent (it becomes a variation on the Finney attack).

The attacker will pay transaction fees to send those spammy inputs, and that has been a large enough disincentive that it hasn't happened.

That said, SelectCoins aught to be improved; ideally, it should never include an input if the fee for adding that input is greater than that input's value.

Or maybe it should just ignore inputs below the 'spam transaction' threshold for now, as being more trouble than they're worth.

That's wrong; you wouldn't be able to send a new-style transaction to a merchant unless they'd already upgraded and were publishing new-style addresses.

... which would actually just be BIP16 addresses, with the redemption script being something like  <ed25519_pubkey> OP_NOP1
(I'm wrong about needing a new bitcoin address type).

Obviously merchants wouldn't start doing that until a majority of miners were interpreting OP_NOP1 as OP_ED25519_VERIFY.

http://gavintech.blogspot.com/2012/07/off-chain-transactions.html

I don't think a new signature algorithm doesn't require a hard fork; redefine an OP_NOP as OP_CHECKSIGVERIFY2 that uses ed25519, create a new 'standard' transaction type that uses that new opcode, and a new bitcoin address type that corresponds to it, then start by rolling out miner support, etc. as sketched out here.

That would probably be better than a hard fork; I'm not sure what the transition plan would look like for old transactions if OP_CHECKSIG was redefined to use the ed25519 curve.

If the new transaction type was significantly cheaper, then cheaper transaction fees could incentivize people to upgrade their clients/wallets.

I don't think now is the right time to do any of that, mostly because I wouldn't be surprised if some solution for instant "off the chain" payments is adopted instead, in which case perhaps sep256k1 transaction cost will be negligible.

No, the main reason isn't anonymity the reason is so transferring bitcoins between accounts using 'move' doesn't require a blockchain transaction.

EITHER: requiring that the wallet be unlocked for the settxfee RPC call to succeed
OR: adding a new configuration option "-maxtxfee" (default: 0.01 maybe) that can't be set via RPC
 ...  seems reasonable to me.

We've had an implicit assumption that if an attacker gets access to the RPC interface you're sunk, and while I think that's true (attacker could run a tight loop of "sendtoaddress" that will fail until the moment you unlock the wallet to send some bitcoins somewhere), I also think security in depth is a good idea.

Can you open an issue on github please?

RE: gui not telling you about the fee:

Can you open a separate issue on github about that, too?  That's just a bug, in my humble opinion.

RE: seeds with a lot of entropy:

Every time I look at the academic literature on passwords/passphrases, I get more depressed about the feasibility of either giving users a secure passphrase that they will remember or getting a secure passphrase from them. I fear there will be a lot of lost coins if "brain wallets" get popular.

E.g. this 2012 paper: http://dl.acm.org/citation.cfm?doid=2335356.2335366