Why do you assume that?

A pool operator will have hardware capable of validating X transactions per second.  Right now, with low transaction volume, X is much bigger than current transaction volume, no matter what kind of hardware the pool operator is using.

If we assume Bitcoin is successful, eventually the number of transactions to be processed will be bigger than X.

The pool operator will have an incentive to sort transactions by the fee minus how expensive they are to process, and drop transactions that cost too much.   (or maybe implement some more complicated strategy like Mike's assurance contracts-- I have no idea how it will evolve).


Miners have an incentive to lie about transaction fees to clients-- they want higher fees, so even though they might accept 0.001BTC for a transaction they might tell clients that the fee is 0.005BTC.

Clients should be able to get a pretty good idea of what transaction fees are needed (if any) to get a transaction into the block chain just by watching 'tx' and 'block' messages and seeing what miners are actually doing, instead of trusting miners to tell the truth about what they are doing.

What do I personally think?  I think it was mean, and luke-jr shouldn't have done it.

But if your system has a requirement "everybody will play nice" then your system is broken. You have to assume that people will try to break what you build (and also have to assume that nobody is perfect so you'll have to have a way of fixing your system when you find out it is broken).

So my heart feels sorry for CoiledCoin; my head thinks it is possible Luke-Jr did all the altchains a favor by demonstrating a problem that needs to be solved. And I'll re-iterate what I say in my "Be Safe" post:  only invest money or time in altcoins (or Bitcoin, for that matter) that you can afford to lose.

My prediction for 2012:

Peer-to-peer pool technology will mature (will get easier to install and run), and p2pool's will be more than 25% of bitcoin hashing power by the end of the year.

I love that idea!  Point your camera at the product, confirm payment, and you're done.

RE: changing prices:  I wonder if you could make little QR-code-capable LCD or e-ink displays cheap enough to put 20 of them in a vending machine.

It'd also be a great opportunity for practical jokes, like making the machine vend... oh, I dunno, Nerds^TM along with their popcorn.

Because we don't have infinite programming resources, and we've been busy working on low-level stuff that will lead to solutions that will fix the "my hard drive crashed" and also the "my computer got infected by malware" and "my house burned down along with my computer and all of my USB thumbdrives" disaster scenarios.

I hate to inject gloom and doom into a fun topic like vanity bitcoin addresses... but y'all should be aware that one of my longer-term goals for the Bitcoin system is to make bitcoin addresses disappear. I hope Bitcoin software 10 years from now tells users "You're about to pay 11 micro-Bitcoins to Amazon.com" and not "2mRwtf8blahblahblah". And I'm not alone, I know Mike Hearn feels strongly about making bitcoin addresses go away for ordinary users.

If you do spent lots of time creating The World's Best system for mining vanity bitcoin addresses, please don't be upset or surprised if you find it is obsolete when "Bitcoin 2017 Turbo++ Enhanced Edition" is released.

The consensus from Tuesday's IRC meeting is to replace OP_EVAL with "pay-to-script-hash" -- a simpler, safer-but-less-powerful alternative for creating bitcoin addresses for multisignature and future more-complex transactions.

So please read the BIP: https://en.bitcoin.it/wiki/BIP_0016
And the source: https://github.com/gavinandresen/bitcoin-git/tree/pay_to_script_hash

Important dates:
Feb 1 deadline to try to get 50+% of hashing power to express support.
Feb 15: "full validation" pay-to-script-hash switchover date (assuming success on Feb 1)

Just thinking out loud...

... but vanity addresses using 1-of-2 multisignature transactions and BIP 13's new bitcoin address format could be orders of magnitude easier to generate.

You'd start with a normal keypair.

And simply compute the hash of the public key and another, arbitrary, "I don't have the private key but I don't care" public key (in an "OP_1 <public_key> <don't care public key> OP_2 OP_CHECKMULTISIG" transaction type).

You'd always spend the funds sent to the vanity address using pk1.

No expensive ECDSA addition or multiplication required, just lots of SHA256/RIPEMD160 hashing and base58 encoding and string comparing.

-----------

Widespread use of the new pay-to-script address format will have to wait until "everybody" upgrades to support it, though. And it does make transactions larger (2 public keys instead of 1) than the find-the-right-private-key solution.

Newer versions do this already.

Don't be sad-- it hasn't been wasted at all. Most of the work was making multisignature transactions work properly, the OP_EVAL part was a small amount of code (which becomes an even smaller amount of code under the new PayToScriptHash scheme, which is one of the reasons I like it).

And re: new cycle of coding/testing/etc taking 3 more months:  I'm going to propose slipping the schedule by two weeks, which means a "network is fully validating the new transaction types" of Feb 15 instead of Feb 1.

Ok, here are three:

Authorities gather enough circumstantial evidence to get a warrant.  They raid the guy's house/office, and find a wallet on an unencrypted hard disk with private keys corresponding to "B".  That should be enough evidence to convict.

Or the guy thinks he's being clever by breaking up his 10,000 BTC into 50 BTC chunks and slowly, over time, transfers them to new wallets C, then D.  Then deletes B and C.
But he doesn't realize that the graph of transactions he is creating would be IMPOSSIBLE to happen by chance if wallets B and C belonged to innocent bystanders (what are the chances that, say, 10,000 stolen bitcoins were broken up into a bunch of pieces and then just happened to end up later in the SAME wallet?)

Or somebody with lots of connections to the bitcoin network is figuring out (with pretty good precision) what IP address each transaction is coming from. The guy doesn't use a proxy to hide his IP address, and the transactions from A->B->C->D all appear to come from IP addresses allow assigned by the same Internet Service Provider in the guy's town. The authorities subpoena the ISP and find out the guy was assigned those IP addresses when the transactions hit the network.

----

All of the above is why I say it is hard to be anonymous when using Bitcoin, and I'd urge you not to do anything with bitcoins that would prompt The Authorities to bother getting subpoenas/warrants to try to figure out who you are.

Good Idea.  How are you creating the files?

What language are you writing in?  Anybody want to volunteer to write a Satoshi-bitcoin unit tester in C++ that parses ThePiachu's format? Or do you already have code that runs them? Committing a gazillion Script unit test cases to src/test/scriptTests/ sounds like a very good idea to me.

Wallet.dat files don't get corrupted very often; blkindex.dat or addr.dat corruption is much more common (which makes sense, they are much larger and changes all the time as new blocks are added/indexed).

A lot of reported "database corruption" has been Berkeley DB log file incompatibility (the .dat files are compatible between 4.* releases and across operating systems; I know the log files are NOT compatible from 4.7 to 4.8, I think they're cross-OS compatible too but could be wrong about that).

The Satoshi bitcoin code could certainly do a better job of helping users recover from any/all of the above, although I personally think that development time would be better spent on the "what if my computer catches fire" scenario-- can we make it really easy for users to securely backup and restore their wallets off-site?

The Bitcoin price ($4) was the NPR Planet Money podcast's indicator for their Tuesday, Dec 27 episode:
  http://www.npr.org/blogs/money/2011/12/27/144323325/the-friday-podcast-the-rest-of-the-story

The client doesn't support multisignature transactions yet.

You can do 2-of-3 (overseer holds 2, so can always spend, you hold 1) instead to accomplish the same thing. I suppose having the overseer put transactions in the block-chain that everybody can see might make you and the people you're paying trust them more...

TrundleNet (no reason)
Transactinator (T13 for short)
Eleventy (because eleven is my favorite number)

Disclaimer:  I'm a Tor newbie and networking stuff isn't my strong suit, you probably know more about it than I do.

But: I fixed a Tor-related bug for version 0.6 a few days ago.  In particular, I moved all of the "turn this on or turn this off if running over Tor" to one spot (in the init.cpp file) and reworked the code so that you can override all of those decisions via command-line or bitcoin.conf switches (e.g. specify -nolisten=0 to set nolisten to false so you DO listen even if running a port 9050 proxy).

Yes.  That would be a "1 of 2 signatures required" multisignature transaction.
That you can't do. If the coins were stolen, the thief can just sign them away.

I suppose you could do a "2 of 2 signatures required" and then have the overseer only approve transactions that were ALSO 2-of-2 required (where 1 was the overseer's signature).  A thief could take your coins away, but wouldn't be able to spend them without the overseer's OK.  The overseer wouldn't be able to take them back, though.

More complicated schemes are probably possible if you want to trust the overseer completely... but if you and the person you are paying trust the overseer completely then why bother using bitcoin transactions at all?  Just hold accounts at the overseer and they can transfer balances or reverse transactions as they like....