Here's my public key, or you can fetch it from the MIT pgp keyserver.  Or it is linked on the bitcoin.org homepage.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.9 (Darwin)

mQGiBEy8srURBADlAamWM3TkgAKyVBVftUsg5aZ3zOA5UAlg+yI/6bzfTkYLtspA
LQ6typamac9re+lqnWdDMa4qVwSmaOMxLOlGhCWWfmA38QprU+ZfuesnxWrVAMG8
TDHLT2vBCa+9iC50soo/imsDqqe6ujm7a+Pd1KSNvFR5KXgEgeEHSiyEqwCg3iAa
DH3lNWzNOgJgi8PUiszqbcsD/2mfNBYJsazYabXcbNdh8VheNnyK2KLUE8Lg1WzU
ld/Sd1gu67oPSFfTiFZ5OBjdHI/XmlFAT4r4eNy1IIf0nELJWWQ6hlzm0a0/DO4b
BUoapjUjAYWDyeeeALDHK7EQboqtwWBlRONyY/+yB9usgbvAK2khRlzBhQonGJEs
FpdQA/9bQzVgpEE1q/ZSnvLp0nOFA3E51SS9uvGGnAdQMjwDp7iGBzh7gRz4ko1k
LG3Sa5fNe21VvlKFcMTaZN9Pd5fDd7gEoDkjUDlf9lRX+YT5zf+SSoeCIGuNMVzs
f8Z2H414dYDOJPBkhYWcqFhGhz11QtWgug5n8GaewC2YOiPU8LQoR2F2aW4gQW5k
cmVzZW4gPGdhdmluYW5kcmVzZW5AZ21haWwuY29tPohmBBMRAgAmBQJMvLK1AhsD
BQku/geABgsJCAcDAgQVAggDBBYCAwECHgECF4AACgkQdYgkL74406h8rwCgyMwS
bwfJ+t3B2IRbhnDIsLo4UtAAnRqMmznLBNLe97fbWYjkcgiAkr2UuQINBEy8srUQ
CADLdLYPEFwz9DEMHoQID/USG6QBP8LXVWCy+84aWsR/SMP2k7BmqtiBEOAZvq9j
Tf4/6WoYkU++vDUiq2QefmCnUSfNiD7TcVAQOm631Kg7TkCQU3TZY5rzJ8DAoh2D
vMuYhWVr0grvlJcF6x0A2/YopfR1BO7SNq87LoG/ZqdbFgijNNePBXEfDGG0T0dg
XkZAKsf6v/rgQYWjSgOx1jn/cH7opoum4xyGLVDE+sU3aKBUwaWOV1hLUHWVwgC7
FwXs+nxWPVitR4Ri6aYGlFTrql9DbrQipaybFTRsbdlCrSEpwz5sKK/FE3aRSo5+
+X6fj590uOEPHtu9RDtBcCePAAMFB/9/hCzl8OVZER2fayOTwCauYbt/21D+RvQJ
67bFMMiPxEgWcyueZmpF2Z5KXc61z8mMa831wUNdkkcr2BSr2FEIArlpoynwYHPe
Kyzy1hhhXxdy7uOObicgPMnOx94ZRuvc/xD8LMDLbQ2tpAZn+TCXvwE7fvIxOCnr
6JKUmd2GpQKVnFSbfS9to3pImnZe8OLwoFoBXQ3CBViJo5vYLUHHH+OgIs28PV+8
fcQVJTUQpkDOjNg3fPFd8/YGzaE55+MTqacr5VoSR6aUweMpRCFHNb5PEv/HsY6m
4Q5ypXJBMwWZZlDtiPJnnTaWPwCZLFoj3zEE2VgVGSuoxUMDisPRiE8EGBECAA8F
Aky8srUCGwwFCS7+B4AACgkQdYgkL74406gxCQCfa3UFF31O14UKmnyuJFUTiik+
YBsAoLiC5B6DhN25fJRKWhdvih2hQWrX
=oDeQ
-----END PGP PUBLIC KEY BLOCK-----

I've been thinking a lot about transaction IDs and how to gather signatures for multi-party transactions, too.

For the most part, I think all the details should normally be hidden from users-- I think "Select Transaction Type" is much too geeky.

Thinking out loud, and starting with what I think will be a very common use case:  buyer and seller and somebody to resolve disputes that arise (2-of-3 escrow).

Are you imagining all three are using a bitcoin client? In my head, one might be using bitcoin-qt, another a web-based wallet service, and the dispute resolution would be done by a company with a website. I don't think "we're all running bitcoin on our computers" will be the common case.

So here's how I see it working (my ClearCoin experience may be biasing me):

Buyer and Seller sign up with the escrow service. During signup, they each give the escrow service a public key.  How?
  -- Clunky way:  they poke a "Advanced.... New Public Key" button and then copy&paste a long string of hex
  -- Better way: they poke a link on the escrow status page that does some magic
     (maybe there's a bitcoin:sendnewpublickey?destination=https://www.clearcoin.com/newkey/user1234 URI type that can be made to Do the Right Thing)

Buyer or Seller then creates an escrow at the escrow service's website.
  -- Escrow service creates or assigns a keypair for their part of the 2-of-3
  -- Escrow service creates a newfangled bitcoin address using the 3 public keys.

Buyer sends bitcoins to the newfangled bitcoin address (by clicking on it at the escrow service's page-- it could be a bitcoin:... link)

Escrow service's wallet sees the payment to the newfangled bitcoin address, updates the status page.

Buyer tells seller they paid.  Seller checks the escrow status page, clicks on a "send me the money" link and ships the product to the buyer.

What does the "send me the money" link do?  It needs to get a signature from the seller for a transaction that spends from the 2-of-3 transaction and sends to the seller's wallet.  Another bitcoin: URI that does magical stuff?  (bitcoin:signtransaction?tx=...hex...&destination=https://www.clearcoin.com/... ) Or some other clunky copying-and-pasting of long hex strings?

Days later: Buyer gets the product and is happy. They visit the escrow status page and click on a "send THEM the money" link, which does more magical stuff. Or more clunky copying-and-pasting of hex strings.  In any case, the escrow service gets the second signature and sends the transaction to the bitcoin network, and the coins show up in the seller's wallet.

---

Couple of notes:

I don't see the newfangled-bitcoin-address being part of the buyer's or seller's wallet, and adding it to their wallet would be yet another step.

Need to think about what happens if the escrow service suddenly disappears... they can't steal any coins, but if neither buyer nor seller knows the public key the escrow service is using then they can't complete the transaction by themselves.  Perhaps the bitcoin: URI that the buyer uses to fund the transaction should include all the public keys and should be added to the buyer's wallet...

---

All of this would be much nicer if there was a more user-friendly, security-friendly representation of bitcoin addresses / public keys.

I hate to be a wet blanket, but if "they" wanted to stop this why couldn't "they" simply pass a law stating that it was illegal to buy or sell bitcoins?

Or "they" could impose a punitive tax on purchases or sales of bitcoins.

I suppose my point is: if "they" really want to make bitcoin illegal, then they will find a way to do it; I don't think creating bitcoin derivatives will help much on the legal front.

Depends on who "we" is and what corporate form the Foundation takes...

... but the one of the first orders of business will be more discussions with lawyers who know about those types of things.  

Bitcoin is revolutionary because it is decentralized, with no single point of control or failure.

However, over the last six months or so it has become obvious to me that the rest of the world isn't set up to interact with a radically decentralized system like Bitcoin, and I think forming a not-for-profit organization will be a positive step towards Bitcoin's long-term success.

I'm posting this to see if there is a consensus on what a Bitcoin Foundation should be.

To get the conversation started, here are some functions I think a Bitcoin Foundation could perform:

• Interact with the legal system, where a centralized entity is needed: for example, to hold the Bitcoin trademark, own/control the bitcoin.org domain name, etc.
  
• Act as a central library for accurate information about Bitcoin, so journalists and policymakers have an 'official' place to learn about Bitcoin.
  
• Collect donations to fund infrastructure necessary for Bitcoin's growth (organize regular developers' conferences or get-togethers maybe? pay for development of cross-implementation testing tools? pay core developers' salaries? create a certification/testing program for Bitcoin implementations? create a central clearinghouse for information about legal issues surrounding Bitcoin across the world?)
  

Other not-for-profit organizations that could be emulated:

• The Anti-Phishing Working Group (the APWG's chairman, David Jevans http://en.wikipedia.org/wiki/David_Jevans, is willing to help make a Bitcoin Foundation happen).
  
• The Tor Project
  
• The Apache Software Foundation
  

Are there others that work well, or are there examples of what NOT to do? Assuming there is rough consensus that a Bitcoin Foundation is a good idea, I would like to get something imperfect up and running quickly, with the expectation that it will evolve over time.

I think Casascius did the right thing.

He has no way of knowing how many people got the phishing email, and no other way of contacting people who might fall for the scam.

If you're upset because you have to poke the 'delete' button on your email one extra time... then I think you're overreacting.

Yes, but if you are spending a lot of time or effort trying to make money on an essentially unproductive activity then I think you should ask yourself if there's something else you could be doing that would be more effective at making the world a better place.

I think a lot of buy-low-sell-high, there-is-always-a-bigger-fool, or high-frequency trading fits into the "isn't making the world a better place" category. If you're competing for a bigger slice of a fixed-sized pie, I think you should think hard about what you could do instead to make the pie bigger for everybody.

Mmmm.... pie......

Thanks to Amir for agreeing to be the "BIP editor" and getting these up:

https://en.bitcoin.it/wiki/BIP_0011
https://en.bitcoin.it/wiki/BIP_0012
https://en.bitcoin.it/wiki/BIP_0013

You == me?

There's a sticky here about creating a pull request, it'd be most excellent if you could make you==you and fix the doc/readme-qt.rst file.

I'll try hard to remember to mention this for the 0.5 release notes, but I'll warn you I'm really good at forgetting things.

I don't know nuthin about error-detecting checksums, but I think the time it would take to implement it and argue about it would be better spent on more user-friendly, secure ways of making bitcoin payments. I haven't heard of even a single case of "I manually typed in a bitcoin address and the coins got lost because I made an undetected transposition error."

Yes. Although there might be a way of accomplishing the same thing without recursion:

Use case:

Imagine we want, in the future, to support "this" OR "that" transactions.  Where "this" and "that" are themselves possibly complex multisignature or escrow or whatever transactions.

Most straightforward way might be a new standard transaction that looks like:


So you'd redeem it by putting one script or the other on the stack (along with the signatures needed by the script).

So.... maybe you want to recurse so that the IF/ELSE script is itself part of a standard, single-hash OP_EVAL, so you can use a newfangled bitcoin address to send to it.  That would look like:


I am NOT proposing an IF/ELSE "this or that" standard script type; I think there is plenty of enough work to do to actually make secure wallets and in-the-chain escrow work.  But supporting limited recursion for non-standard or future transactions seems easy and safe...

(terminology footnote:  calling scriptSig+scriptPubKey "transactions" isn't accurate, the transaction is the bigger thing, but I'm not sure what else to call them; I hope y'all follow what I'm saying)

Draft BIPs, comments very welcome:

https://github.com/gavinandresen/bitcoin-git/wiki/BIP-OP_EVAL
https://github.com/gavinandresen/bitcoin-git/wiki/BIP-Bitcoin-Address-01
https://github.com/gavinandresen/bitcoin-git/wiki/BIP-M-of-N-Standard-Transactions

I pulled a Satoshi and decided to implement OP_EVAL to make sure it would actually work.
  https://github.com/gavinandresen/bitcoin-git/tree/op_eval

Not ready for pulling, expect rebasing/tweaking/changing. But it is fully working on the testnet.
(example transaction here)

The code puts "OP_EVAL" in the coinbase of generated blocks, so the rest of the network can see how many miners support it.

I gathered contact information for the top ten mining pools last week; when there is rough consensus on the details, I'll contact them to see if they have concerns and/or are willing to support OP_EVAL.

I started writing up BIPs for the various pieces of OP_EVAL, I'll post them soon.

Example possible BIPs:

URL syntax for bitcoin payments

New OP_EVAL scripting opcode for receiver-specifies-transaction

New bitcoin address format to support OP_EVAL

(I'm actually working on those two)


Informational:

Process for announcing/scheduling/implementing a potentially block-chain-splitting change.

-----------

You can browse through the PEP's at http://www.python.org/dev/peps/  to get some idea of the kinds of things that might be good BIPs; changes to the on-the-wire protocol to make blockchain downloads faster would certainly be appropriate.

Amir started the "get more formal about changes to bitcoin" ball rolling by creating BIP 0001, starting from the Python "PEP" / BitTorrent "BEP" processes.

The idea is to use BIPs for changes that may or will affect every bitcoin implementation (not to use them for proposed changes to one particular implementation).

I'd like to propose some minor changes to the process:

• I propose that BIPs be wiki pages, with a social convention that the Author gets final word if any editing wars break out.
• If he's willing, I propose that Amir take the role of BIP editor.
• I think bitcoin is still too small to have a specialized "bitcoin-ideas" mailing list; I propose that new potential BIPs be discussed either here or on the bitcoin-dev mailing list.

What are you optimizing for?  Ease of implementation? Wallet size?

Here's a naive implementation that I bet would work well in practice:

+ Sort potential inputs by priority (priority is #confirmations * amount)

+ Use the N highest-priority coins whose sum >= amount needed

If you want to optimize for fragmentation and/or paying of fees, then also do:

+ If the change transaction is larger than some threshold amount, then split it in half (or maybe split it into Y change outputs, each of which is about the size of the threshold amount).

+ If the change transaction is small and there are other small-valued/low-priority inputs available, add a few small-value inputs to merge them together.

You could also optimize for privacy (try to avoid using more than one input and/or always create multiple change outputs), or tweak the above rules to try to always avoid fees...

Double-huh?  You write your Mt.Gox account information on the deposit, Mt.Gox has all the information necessary to report to FinCen (because only upgraded Mt.Gox accounts can use the service) if required (if depositing more than whatever the daily/weekly FinCen requirements are, yada yada...).

What's up with the attitude Matthew? More ways to purchase bitcoin is a good thing...

So... what would convince you?  What if you could pay 10% of your expenses using bitcoin, and it cost you 1% less if you used bitcoin?

There are lots of chicken-and-egg problems that bitcoin has to overcome to compete with the dollars or euros we're all using now; I see two paths to bitcoin's success:

Maybe there are enough ideologically motivated people to form a self-sustaining economy. If even 1% of people find the idea of bitcoin attractive and started using it for 1% of their transactions that would still be huge.

Or maybe one or more 'killer apps' for bitcoin will emerge, giving it a foothold in certain markets. Maybe it will never expand beyond those markets, or maybe it'll slowly grow beyond them because of lower cost and higher tech.

If you're not excited by the idea of being an early adopter for what could be a massively influential idea, then you should probably come back in three or four years and either tell us "Told you it'd never work!" or join what should, by then, be a much more stable and easier-to-use system.

I never started with bitcoinjs/nodejs, because I'm not a JavaScript programmer (and I'm too busy to take the time to learn).

It would be lovely if somebody who is a JavaScript programmer decided to show me how easy it would be and took bitcoinjs/nodejs and created a really nice cross-implementation testing framework with a bunch of test chains.

RE: Mike's point that creating full-difficulty test chains is a pain in the ass:  I think that one-time pain is worthwhile, because I don't think we can count on every bitcoin implementor making it easy to run their implementation in a unit-test mode with super-low difficulty. And creating difficulty-1 blocks with a GPU is actually pretty darn quick...

Pass a 0 as the third argument to sendmany and it will send unconfirmed coins: