Yes, would you be interested in building?

Yes, but if two blocks are found with the same difficulty then they are considered equal work-wise (even if one has a smaller hash value-- the "Bits" field in the block is used to compute chain work, not the block hash).

If there are several valid tip-of-block-chain choices all of which have the same work, then miners are free to build off whichever one they like. The rule everybody (I think!) is using now is "build off the one seen first."

Transactions have multiple inputs and outputs.

If you have 0.5BTC inputs, then 50 of them will be bundled together and a transaction with 50 inputs and one output will be created.

... but that's not what will actually happen. A 50-input-transaction will be over the "small enough to be free" transaction size limit, so 51 will be bundled together and a transaction with 51 inputs and two outputs (one to the destination, one back to you for any change leftover after paying the transaction fee) will be created.

There is no ledger, there are just transactions with inputs and outputs.  Your bitcoin balance is the sum of all the outputs to addresses that you own that haven't yet been used as input to another transaction.

+1 for vector76's hypothesis.

If mybitcoin was running bitcoin behind Tor, and had just one connection (through a Tor exit node) to the rest of the bitcoin network, then they'd be particularly susceptible to this 1-confirmation attack.

Bitcoin addresses are not public keys-- they are hashes of public keys (RIPE-MD-160 hash of the SHA256 hash of the public key, with a version number and checksum, to be annoyingly specific).

I agree that associating a message with a bitcoin transaction would be spiffy.

I'd say the short answer to "is it possible to accept them again in the near future" is no (where "near" is in the next six months).

I agree with Maged-- before enabling new opcodes, I'd like to see a peer-reviewed academic-style paper that works through the security implications of the existing set of opcodes and gives a nice framework for thinking about new (or disabled old) opcodes. Doing that is way outside my own personal level of expertise; I know only enough about designing secure algorithms to know that I  have no idea whether or not re-enabling OP_XOR would have security implications for bitcoin.

Same goes for enabling nLockTime / transaction replacement, although I suspect that proving that transaction replacement doesn't open up any subtle attacks may be harder than proving security properties of opcodes.

Yes, I'll send... oh, I dunno, $200 or so worth of bitcoins at a time to the Faucet.

RE: not holding the EFF in high esteem: I still strongly support the EFF. They're good people working to make the world a better place, and I trust them to know better than I do whether or not accepting bitcoin donations is good for both them and the bitcoin project.

Update:

The EFF donation account/address was at mybitcoin, so half of them are gone.

I received 1,879 from the mybitcoin claims process.  They are now safe in an offline, encrypted wallet; here is the transaction:
 http://blockexplorer.com/tx/4b32ed2f7c1422ced7f1f0be88b2afe355c59180be72e942df085d93f1c8737a

---

According to block explorer, 3515.06 BTC were donated to the donation address I had for them:
 http://blockexplorer.com/address/1MCwBbhNGp5hRm5rC1Aims2YFRe2SXPYKt

49% of that would have been about 1,722 BTC, not 1,879. I'm guessing the difference is because of donations from other mybitcoin customers just crediting the eff account without generating a block-chain transaction.

Before sending coins to the Faucet, I think I'll create a patch to always send "change" to the same address, so it is really easy to keep track of these bitcoins and make sure they're not sent anywhere other than the Faucet.

RE: negative account balances:

There is (was?) a patch proposed with an RPC call to prepare a send transaction, which would lock the inputs involved and return the transaction fee and a transaction id.  And commit/reject RPC calls, which take the transaction id and either commit it or rejects it.  That's the only really right way to estimate transaction fees before sending. I haven't reviewed the patch, and I don't think it has been thoroughly tested; there might be denial-of-service attacks possible or odd edge cases (e.g. could one customer who decides to go to lunch while the "this transaction will cost you 0.0005 BTC, OK/Cancel?" dialog is open tie up the entire wallet's balance, making sends fail for everybody?)

There's also an estimatetxfee patch, but the problem is that between the time you estimate the tx fee and the time the send happens the state of the wallet might change, making the estimate wrong.

The real question is why should customer A pay a transaction fee just because customer B funded their account with tons of tiny transactions? If customer A puts 1,000 bitcoins in their account and pays 0 fee, they're going to be pretty upset at you if you charge them to withdraw THEIR money from the account.

For ClearCoin, I just treated transaction fees as a cost of doing business, and refunded customer accounts when a send resulted in a transaction fee (via the RPC move method from a special FEES account that I pre-funded to cover transaction fees).

So sends look like:
  sendfrom "account" <to> <amount>
    ... return txid
  gettransaction <txid>
    ... return txinfo
  if txinfo says a fee was paid:
    move "FEES" "account" <amount-of-fee-paid>


RE: static addresses

I don't follow.  You mean have one address per account?  You could call getaddressesbyaccount and the return the first address or (if empty array) return getaccountaddress?  Or if you create an account when a user signs up for your service, call getaccountaddress and then you KNOW that getaddressesbyaccount will return at least one address.

Really?  You do realize that will just start an arms race with maxmint; he or she will write code to detect and ban bots, somebody will deploy bots via multiple IP addresses to workaround, maxmint will be forced to add a CAPTCHA, etc...

maxmint: it can be kind of fun to try to scam the scammers.  If you detect them, just never let them win (but don't tell them you're not letting them win).

However, they'll eventually figure out you're doing that.  The only way to win the arms race is to make it more expensive for the scammers to win than the reward.  If I recall correctly, getting around one-per-IP-address and CAPTCHA restrictions costs a scammer a few US pennies.  If you're giving away 1BTC worth $10, then you'll have to make sure the scammers will have to solve several thousand captchas to win.

Two different encryption schemes and/or passwords seems like a bad idea to me, both from a code maintenance/security point of view and from a usability point-of-view.

Can you expand on "private keys in base-58 export format are great for swapping around" -- what's the use case?  Who are you swapping with, and how?

Couple of things:

First, I want to squash the "Satoshi mined a bunch of bitcoins on his own before releasing the bitcoin chain" idea.  He publicly announced bitcoin version 0.1 six days after he generated the genesis block: January 9, 2009:
  http://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html

According to the block chain history, he generated about 10 blocks total before the announcement.  And we know that he didn't pre-generate blocks because the genesis block contains a quote from the January 3rd Financial Times newspaper.

Second, I have no problem with alternative block chains, I just don't personally like how this particular alternative block chain is being promoted and developed and introduced. In particular, I think it is unfair to keep hundreds of thousands of whatever-coins for yourself, and it is unwise to think that a bitcoin variation that is "almost exactly like bitcoin, only different because... well, just because" will ever have anything more than speculative value.

So... I got this unsolicited email:


... and I'm trying to figure out why my immediate reaction is "yuck."

I guess I just don't see the point of IxCoin.  I just spent some time looking back through all the original poster's messages, and I don't see any prior discussion of goals of IxCoin, how it should be designed, etc.

If the goal is to let more people be early adopters of a new cyber-currency, then it seems to me giving early bitcoin adopters a bunch of IxCoin goes against that goal.

Half-baked thoughts on transaction relaying (I agree that it may become a major problem because there are no incentives to properly relay transactions right now):

I think writing code to reliably detect that a peer isn't relaying transactions is possible. Something like:
 Generating a new transaction:
  Pick a connected peer at random "P"
  Relay new transaction to all nodes EXCEPT P
  If, after a little while, P doesn't tell us about our new transaction then it is likely P is not relaying properly.
   (assumption is that we are not P's only connection, and it will get the transaction from its other peers)

And I think something like the above could be one of the metrics used to measure "ill-behaving peers" (other metrics might be number of double-spend transactions or orphan blocks received, number of spammy-looking transactions received, etc).  If a peer is too ill-behaved, the penalty could be shunning-- drop its connection and add its IP to a temporary refuse-connections list.

(maybe lesser penalties make sense, too-- maybe order-of-relaying is based on good behavior, so the code announces new blocks/transactions to better-behaved peers fore worse-behaved peers).

If cheating miners find themselves disconnected from the rest of the network, that is a strong incentive not to cheat.

I'd really like somebody with a lot more network design experience than me to run some simulations and see what network behavior would be like with/without rules like I'm proposing.  Or tell me that disconnecting ill-behaving nodes is a terrible idea because it makes it easy for an attacker to shatter the network into a gazillion pieces...

FYI: I started a discussion of development priorities for the next release or two on the bitcoin-development mailing list:
  https://sourceforge.net/mailarchive/message.php?msg_id=27928380

-wallet=foo.dat  command-line param would be easy (unless you allow an absolute path, in which case the code that detects whether two instances of bitcoind are trying to write to the same wallet would have to be changed).

But if you pass it on the command-line, then wallet-stealers can just adapt and look in the process list to figure out where the wallet is.  If you put it in the bitcoin.conf then the wallet-stealers can also look in the bitcoin.conf to figure out where it is.

I like the 'deterministic wallet' idea that's been floating around (enter a password passphrase at startup, and keys are magically derived from that password passphrase and never touch the disk at all).

Seems like there would be a clever way of combining that with white-box cryptography to make the private keys extremely trojan-resistant.

In which case the wallet-stealers will just rewrite the bitcoin address/amount after you press the "send coins" button...

---

Edited to replace 'password' with 'passphrase'

It will get pulled/released faster if you help test it.  Pull the patch, compile a custom bitcoind, then run it and report any bugs.  If you don't find any bugs, add a short note either here or in the PULL request.

Testing is currently the bottleneck for getting new features...

Everybody likes this feature, and it feels like it is very close to being ready for inclusion.

There are two reasonable requests in this thread that I think should be implemented before this is pulled:

1. Pieter's change to the API, so the <pubkey> is extracted/verified from
  verifymessage <bitcoinaddress> <signature> <message>

2. ByteCoin's request that the <signature> be industry-standard-base64-encoded instead of hex or base58 encoded.


The nonce/no-nonce argument seems like "angels dancing on the head of a pin" to me; seems to me the tiny iota of theoretical added security (...sometime in the future maybe when SHA256 is broken or partly broken...) isn't worth the extra complexity.

Alternative algorithms for determining the "best" block chain would be a good research topic, I think.

Model or simulate either a 'natural' block-chain splits (X% of the network gets disconnected for time T) or attacks (attacker with 51+% of hashing rate double-spends a transaction by surprising the network with a N-length better block chain).

Then see what the behavior is like under different potential algorithms for determining the best chain-- the one we have now (most difficulty always wins) or some variant (like more recent blocks are given greater weight).

And think really hard about potential attacks, especially mixed-mode attacks (what if the attacker can mount a Sybil attack on one of the big mining pools?  Or can DOS one or more of the big mining pools? etc)

I'm curious to hear what other people think.  I shut down ClearCoin when the value of its wallet threatened to get so large I was no longer comfortable self-insuring it with my own personal bitcoins.  It is still shut down because I haven't found a group that I would trust to run it securely (and I don't want to take the time to raise the money and hire experts to run it properly).

We are starting to see well-capitalized, experienced companies creating bitcoin businesses; at this point, I think if you are holding other people's bitcoins then having insurance or posting a bond to self-insure up-to-some-value for each account is reasonable.

In my view, if your business model for your free service doesn't cover the cost of insurance or a bond, then you're just pushing a lot of hidden risk onto your users.