For the voting problem:

It would probably be best to give each voter a "yes" and "no" address that they are expected not to share with anybody else. They can then vote by sending the right number of bitcoins to one of those addresses.

You can decide what happens if they send to both addresses.

If you want the vote results to be public, then you can pre-publish before the vote a hash of the list of all addresses and voters. Then after the vote publish the list; everybody can make sure it hashes to the correct value, that it has the right list of voters, that it has twice as many addresses as voters, and each voter can check to make sure the addresses assigned to them are on the list.

And the voters could then look at the transactions in the blockchain during the voting period, to those addresses to audit the vote.

There's probably a complicated crypto protocol you could put on top to make the votes anonymous-but-verifiable, too -- so even the vote organizer doesn't know who voted for what.

"We" thought of that (where "we" was actually Khalahan and Pieter and Gregory, if I recall correctly).

The string "Bitcoin Signed Message:\n" is prepended to the message as salt, then that's SHA256-hashed twice, and the hash is what is signed/verified. Sign anything you like, it won't reveal information about your keys (unless your OpenSLL implementation has a broken random number generator and doesn't generate unique signing nonces).

That makes sense. If you think BCX will succeed and are immoral, then the way to profit at the exchange's expense is transfer a lot of LTC in to an exchange and sell them for BTC during the fork.

If the attack is successful then the LTC deposit is rolled back and you can sell them again. Assuming there is somebody still willing to buy them.

In any case, lots of buying before the attack then lots of selling while the fork is being created is the pattern I would expect to see. Of course, that is the same pattern as a plain pump-and-dump scheme...

Yes-- bitcoind creates BIP16 multisig transactions (using BIP13 addresses). Because a BIP16 transaction doesn't reveal public keys until the first spend, if an attacker has only one of the public keys (and the multisig address has been funded but never spent) they won't be able to figure out that the key is helping to protect a large multisig-protected balance.

Yes, but if Bob and Alice keep the 2-of-2 multisig address secret, then you, the rat, will have no idea that they key you managed to steal is one of the two keys needed to open the fridge.

That's why I say that sending the change back into the same multisig address every time is somewhat bad for security...

Yes, that was announced before (see the thread about the raw transactions api).

In a wisdom-of-crowds system, the promise comes from faith that somebody in the future will still find bitcoins valuable, and be willing to give you something in return.

True, it isn't a promise from one particular institution or person to redeem for one particular something else, so it doesn't fit your definition of 'backing.'  But I trust The Crowd more than I trust any one particular institution (especially institutions like governments, who have a long history of breaking promises).

See my recent "Is store of value enough?" blog post for more thoughts along these lines.

There's a prettier version of this here: https://gist.github.com/3161162

Goal:
Multi-person 'cold storage' wallet, using the upcoming 0.7-release 'raw transactions' JSON-RPC api (geek's multisig):

Setup:
Alice generate a public/private keypair. She prints them out and stores them somplace physically secure offsite as a backup. She secures the private key in a way she can easily access.

Bob does the same, then Alice and Bob exchange public keys and both form a 2-of-2 multisig address using addmultisigaddress and verify that it's the same for both of them.

0.1 BTC are sent to the multisig address, then Alice and Bob follow the spend procedure to make sure it works properly. If it does, the multisig address is fully funded as the secure 'cold' wallet. Public keys, multisig address, and funding/spending Transaction IDs and amounts are kept in a spreadsheet accessible to Bob and Alice (and potentially anybody else interested in auditing; Google Docs or DropBox or any other document-sharing solution works).

To detect security breaches, Alice and Bob should send a token amount of bitcoin (say 1 BTC) to the public keys that they are using, and should never spend those coins. Both addresses should be monitored by both Alice and Bob, and if they see coins being spent they should assume that the corresponding private key has been compromised and transfer the multisignature coins to a new, secure multisig address with fresh keys generated on devices that have not been compromised.

Spend:
Alice selects enough unspent transactions to withdraw the amount she wants and cover fees. She updates the Google Doc document and marks the funding transactions as 'PENDING SPEND'.

She calls createrawtransaction with those inputs and one or two outputs:

• Output to the address where the withdrawal is going
• Change output, back to the multisig address

She calls signrawtransaction, passing in her private key, and then send the half-signed transaction to Bob (via email or any other method).

Bob calls decoderawtransaction and checks with Alice to make sure the transaction is OK (Bob and Alice either communicate in advance via phone or Bob calls Alice to verify the transaction details).

Assuming all is OK, Bob calls signrawtransaction and then sendrawtransaction to broadcast to the network. He marks the PENDING SPEND inputs in the shared spreadsheet 'SPENT', and adds the change output (if any) to the spreadsheet as a new potential input for future spends.

Variations/notes:
Depending on the level of security felt to be necessary, securing the private keys might involve encrypting them with pgp and a passhprase and storing them encrypted on the computer or in the cloud. Or storing them in a LastPass secure note. Or storing them on a passphrase-protected IronKey USB stick. Alice and Bob don't necessarily have to follow the same procedure for securing their private keys.

If Alice or Bob suffer any sort of security breach or some period of time goes by (1 year?), they should generate new keys and a new address and send all funds to the new address.

If Alice and Bob do this more than twice, a little front-end tool that automated much of the process would be a worthwhile investment; that tool could be a prototype for adding complete multisig support to Bitcoin-Qt. Then again, it might just be easier to add support to Bitcoin-Qt in the first place.

Extending this so any two of (Alice,Bob,Carol) can authorize a transaction out of the wallet is straightforward, and would prevent loss of funds if any one of them completely lost access to their private key. Or if even more security is needed then requiring all three authorize withdrawals is also straightforward.

Sending the change back into the same multisig address is somewhat bad for both security (the public keys associated with the address are revealed at the first spend transaction) and privacy. This can also easily be extended to use two (or more) Hierarchical Deterministic Keys (see BIP 32), with a new multisig address generated for any change on every withdrawal.

Alice and Bob might be one person, of course, using two different computers.

What partial pre-image?  I assume the message being hashed is "Transfer THIS domain to THAT public key." (with probably a timestamp thrown in there that can't be too far ahead or behind current network time and, of course, a long nonce)

I imagine the hash-for-hire services would just ask their clients for the public key; I know I wouldn't want a hash-for-hire service to have access to my site's private key, they could sell it out from under me!

RE: a personal website or small domain being evicted: yep. You should offer to sell out for a couple bitcoins less than it will cost that big, evil corporation to find an eviction hash so at least you get compensated. There's very little difference between "legitimate little guy who's last name happens to be Ford" and "domain squatter."

Good advice that I expect will be widely ignored: only invest in what you know.

So-called high yield investments are (almost?) always dressed-up Ponzi schemes. If you "invest" in them then please lick your wounds quietly when they implode. And if you're one of the lucky few who make money on them, don't expect me to admire your investing wisdom, any more than I'd admire the number-picking brilliance of a lottery winner.

That's a really great idea!

I think that's a type of all-pay auction; I wonder what an economist who's an expert on auctions would think....

Gentle reminder to the other bitcoin developers: it is generally best not to feed trolls.  Use the ignore button.

I am not a lawyer, but I believe the answer depends on how bitcoins are classified by the Securities and Exchange Commission.

If they're a currency then insider trading rules don't apply. But last time I looked the legal definition of 'currency' in the U.S. was the money issued by a recognized government.  The only insiders for a currency are the people who issue it (I bet there are strict rules on trading of any kind by Treasury or Federal Reserve employees who have inside knowledge).

If Bitcoin gets classified as a commodity, then I'm not sure what rules apply. If an employee at Apple knows that the next generation iPad is going to use a lot of unobtanium, buys a bunch on the unobtanium exchange, then sells after the announcement for a profit are they guilty of insider trading?  Probably...

If Bitcoin gets classified as a security, then I'm pretty sure insider trading rules would apply.

As always, if you're an employee at, oh, I dunno, Walmart and you know that Walmart will start accepting Bitcoin next March (I can dream, can't I?) and are tempted to buy a bunch of coin now I'd suggest you talk to a lawyer first.

That sounds more complicated than it needs to be.

If you can assume some mixers are honest and won't disclose what they added to the mix, then just do a series of pair-wise mixes.

E.g.

A and B communicate securely and create a transaction that has 2 inputs and 2 outputs, all of the same amount of bitcoins (A and B might need to send-to-selves to get the right sized outputs).  The output order is randomized. They each sign their input (after checking to make sure their output goes to them).

A could then repeat with C, then D and, assuming B, C, and D aren't all actually the same person recording his IP address and the mixes, would have a coins linked to the wallets of A/B/C/D.  I believe after a few mixing steps a simple clustering analysis would think everybody who participated in the mix is sharing one big wallet (but I know very little about that stuff, and I wouldn't be surprised to find out there are more sophisticated clustering techniques that look at transaction times and overall transaction ordering that might be able to see through the fog and figure out who is who).

If all the other participants in the mixes are actually the same person (Sybil attack) then I believe no matter WHAT algorithm you use you're sunk.

My intuition is that if you can make the pairwise-mixing case work, then involving more than 2 people at once might be a useful optimization.  But you should start with the 2-person case and prove it is secure before getting more complicated.

I asked FINCEN about de-centralized virtual currencies a few weeks ago; here's what I got:
  http://dl.dropbox.com/u/38065353/FincenFOIA.pdf

Only the first page is interesting.  Reading between the lines, it looks like they're thinking about us.

You'll be able to run as a 'hidden service' that is advertised to other nodes running on the Tor network and get incoming Tor connections in the next release.

See https://github.com/bitcoin/bitcoin/blob/master/doc/Tor.txt  for details (send thanks to Pieter Wuille for doing the work).

RE: hard drive space:  Pieter has been busy optimizing HD usage, too ("ultraprune"), but that work isn't finished yet.

Yes.

It was pulled into what will become the 0.7 release a while ago.

Documentation is now on the wiki:  https://en.bitcoin.it/wiki/Raw_Transactions

I decided not to abbreviate "transaction" -- none of the other RPC calls use abbreviations. And the features have been tweaked a little bit.

There are some nice unintended-but-useful things you can do with it-- as documented on the wiki page:

Re-broadcast a transaction
If you want to re-broadcast a transaction right away, you can use the getrawtransaction and sendrawtransaction API calls to do that. As a bash shell-script one-liner it would be:
(note that Bitcoin-Qt/bitcoind automatically re-transmit wallet transactions periodically until they are accepted into a block).

Validate a transaction without broadcasting it
If you have a raw transaction and want to make sure all of it's signatures are correct, you can use the signrawtransaction API call. Pass in the hex-encoded raw transaction, any inputs that bitcoind doesn't yet know about, and an empty array of private keys to use to sign the transaction. Passing an empty array of private keys will prevent signrawtransaction from doing any signing; if it returns "complete":1 then all of the existing signatures are valid and there are no signatures missing.

Starting with OWASP is good advice.

But if you are holding other people's bitcoins, just securing the app is not enough. You need people who have experience securing money telling you how to create processes to make sure you're not the victim of embezzlement, that you are complying with legal requirements, keeping adequate records, keeping customers' funds separate from the funds used to pay expenses, that regular audits are done to detect problems early, and so on.

+1

My bank must be weird, they let me withdraw more than X and let me carry a negative balance for a little while (a service they charge for).

With the accounts feature, if you have an account containing X bitcoins there are two ways to overdraw it:

1. Using the move command. Negative balances have a lot of use-cases, and last time I checked accountants know how to deal with negative account balances.

2. Using the sendfrom command, if a transaction fee is required then the fee is charged to the "sendfrom" account and may take it negative.

Are you sometimes using "sendtoaddress" and sometimes "sendfrom" ? Or are you using both the GUI (designed for a single user's wallet) and the RPC?  If you want to use the accounts feature, don't do that, always use "sendfrom".

Better accounting for transaction fees is a valid complaint, always deducting the fee from the "sendfrom" account can be annoying. It doesn't violate accounting principles, though; if you want the transaction fee to be paid from some other account, then you just sendfrom() and then move() to adjust account balances.

If you really want to find something about the accounts feature to complain about, then you should complain that it doesn't scale.

What do you mean "send from A" ?  Are A and B accounts or bitcoin addresses?

The reference client does not send coins "from" an address; when you send coins they are chosen from any of the available inputs in your wallet.

If you receive 50 BTC to an address associated with an empty account "A", then move those 50 bitcoins to account "B", then make the RPC call:
  sendfrom "A" <to_address> 50

... you will get an error "Account has insuficient funds"


I have no idea what 2112 is talking about RE: accountants having trouble figuring out how the accounts feature operates.  It is very much like separate accounts at a bank, where dollars and coins flow in, are credited to accounts, and then flow back out (debiting accounts).  If I take a bag of cash to the bank and have it deposited into my account, I don't expect to get exactly the same bills and coins out the next time I make a withdrawal, and I shouldn't be surprised if the bank uses those coins and bills for withdrawals from other accounts.