No, that's the point:  you can take any validly signed bitcoin transactions, tweak the signature(s) in various ways, and create variations that are also validly signed but have a different txid. We've known that for a long time.

You cannot change where the coins came from or where they go or any other information about the transaction that is covered by the signature(s).

And the current reference bitcoin implementation will simply take the first variation it sees and consider it valid. Sergio is saying that if there are any merchants doing their own double-spend detection they should be aware of this issue.

My daughter's review-- "wow, these are really good nuts!"

Thanks D, we'll be ordering more!

Okey doke.  I thought they had some firmware that knew how to talk over USB (or ethernet or whatever), too.

I thought the consensus was that the mining devices just need a little extra software onboard to increment extranonce and recompute the merkle root.

I don't know nuthin about hardware/firmware design, or the miner<->pool communication protocols, but it seems to me that should be pretty easy to accomplish (the device will need to know the full coinbase transaction, a pointer to where the extranonce is in that transaction, and a list of transaction hashes so it can recompute the merkle root).

Transactions do not have an input address.

They have one or more inputs, which may or may not correspond to one or more addresses.

If you have a CScript, then you can call:

What are you trying to do?

If you held a pre-signed transaction that sends the funds back to you with a lockTime of 1 Jan 2013 that would work.

Lets see... thinking out loud...

Start by asking the exchange for a brand-new public key to use for their half of the 2-of-2 transaction. Call the send-coins-into-2-of-2 transaction "F" (for Fund).

You create and sign that transaction, but don't broadcast it yet.

Use it's transaction id to create a second, one-input-two-signature, lockTime=1/1/2013 transaction that refunds the coins to you.  Call that "R" (for Refund).

Send R to the exchange and ask them to sign it using that brand-new public key they gave you. The exchange checks the lockTime and then returns R and the signature to you. You check the signature, and if it is good, broadcast F (and keep the half-signed R someplace safe).

If 1/1/2013 rolls around and you want your coins back, you sign your half of R and broadcast it.

---

I'd have to think a little harder than I want to right now about whether or not signing R knowing only txid==HASH(F) opens up the exchange to attacks. I can't think of any, but the exchange providing a signature when it doesn't know the details of exactly what it is signing makes me nervous.

You could send the unsigned R and the signed-but-not-broadcast F to the exchange and trust that the exchange will not broadcast F unless they agree to sign R.

---

I think holding on to pre-signed-but-not-broadcast-yet transactions is a technique "we" don't think about enough.

50 BTC (or whatever) deposit, tied up for a minimum of a year (don't want somebody putting down 1,000 BTC deposits the day before a vote, voting 20 times, then canceling their 20 sockpuppet memberships and getting their deposit back immediately) is an interesting idea.

Call me paranoid, but I don't see many third parties who I would trust to not get hacked and to properly identify anonymous people. I don't see that third parties would have a strong incentive to do a good job at that. And delegating that piece of really core functionality feels like the wrong way to go to me.

For the record: I think it would be great to come up with an easier way for people to remain anonymous but still be Foundation members. I say "easier" because I'd guess with enough effort you could use a (physical) mail forwarding service and an anonymous email service to sign up with a fake identity. I suppose the mail forwarding service is like an identity-checking service.

RE: one vote per bitcoin: there seems to be some notion that Foundation member will be voting on things like "should a change to the core protocol be rolled out to support XYZ."

Umm, no. Foundation members will be voting for (and lobbying) board members who will decide things like "should the bylaws be changed to allow anonymous memberships" or "how much Foundation budget should be dedicated to X and how much to Y." The number of bitcoins you own has nothing to do with those kinds of organizational decisions.

Technical changes will happen as they have for the last couple of years-- get rough consensus in the developer community then convince miners and merchants and users to upgrade.

No, no, no: to do it right, you "accidentally" slip a hint to a reporter a month before you launch....


(to the humor-impaired:      )

So... if the membership agrees with your "bugs" then they'll get fixed.  Like I said, the vision is it will be a member-driven organization. And like I said, I find it is much more effective to start with something imperfect and improve it over time rather than try to get everything exactly right and make everybody completely happy at the start.

My personal opinion on the "bugs":

Name:  I like the name.  It can be changed if the membership decides on something better.

Hosting company: could easily be changed; it likely will be. I highly doubt Cloudflare is a government honeypot for anything besides catching DDoS botnet operators.

Identities/voting: Please see "Sybil Attack" for why we're requiring names, mailing addresses and emails. If you've got a magical way of identifying anonymous people please send me the source code, I could use it for the Bitcoin Faucet.

Privacy policy: fair point, there should be a privacy policy on the website.

US based: if Patrick (Foundation's lawyer) was Finnish we would probably be Finnish-based. That's the whole "perfect is the enemy of the good" thing (and I really don't want to have a month-long discussion about which legal jurisdiction is the least likely to declare Bitcoin Foundation illegal, which would be best for getting donors tax deductions, and whatever other arguments we could have).


One of the things that I think will be fascinating to watch is how users and miners organize themselves (or not) to elect people to the Board. I'm not going to pretend that the current composition of the Board is perfect-- I have no idea if some arrangement would be better. But it seems to me before making a statement like "there should be more of X on the Board" we should either get some experience under our collective belts to see how things work OR find an example of a similar, successful organization that works.

As DeathAndTaxes says, there is a weak vulnerability there for clients that are performing initial block download.

It is weak because try-to-fill-up-disk attacks take a long time to pull off, the results are boring (you managed to fill 10 gigabytes of my terabyte hard drive? meh), recovery is pretty easy, and the attacker has to wait around for potential victims to connect to them.

There are a bunch of optimizations to initial block download that could be done; the most obvious is fetching headers for the entire best blockchain starting at the best-block, then 'backfilling' block data in the background.  That would let a new user get up and running very quickly, and would get rid of the vulnerability.

Jeff probably skims this sub forum for the same reasons I do-- entertainment, to keep my mind open to new ideas, and the chance that there will actually be some good ideas.

If nobody steps up and volunteers to help with this, we'll have to drop support for OSX 10.5 in the next release.

Right now?  What if we did that and it turned out the second public/private algo was broken first? ECDSA is a NIST standard that has been very well studied and has no known vulnerabilities.  There are much, much, much higher items on the development TODO list, like figuring out a nice GUI for multi-device transaction authorization.

I did write up plans for migrating to a new algorithm here:
  https://gist.github.com/2355445  (See the "using a quantum-resistant digital signature algorithm" example at the end).

hazek, you're really annoying me.

First, you edited my OP and broke all of the links changing .org to .com.
Then you sent me a PM asking if it would be ok to move this thread to Service Discussion.  WTF?  If discussion of the Foundation isn't a good topic for the main Discussion forum what is?

Now you spout off about 'Gavin this, Gavin that.'

It isn't easy to piss me off, but, I'm sorry, you're really pissing me off. Bounties?  Really?  Point me to a successful security-critical open source project where bounties pay the rent.

I haven't tried kickstarter-like fundraising?  http://blockchain.info/address/17XvU95PkpDqXAr8ieNpYzSdRDRJL55UQ8  is the address for the Bitcoin Testing Project, which has received a grand total of 72 BTC, which isn't nearly enough to pay a QA grunt, let alone a QA lead.

You say "why change, Bitcoin has been working great for me!"

It hasn't been working great for me; I'm frustrated by the lack of resources and all of the distractions I have to deal with as the unelected, un-asked-for de-facto leader of this amazing experiment. I'm excited about the Foundation, because it is bringing together dedicated, effective people who all want Bitcoin to succeed.

Huh.

That's a problem with BIP 20-- it doesn't say how the parameters are encoded.  I assumed they were encoded the same way as http URLs (application/x-www-form-encoded) because the bitcoin: scheme is very similar to the http scheme (where everything after the ? is x-www-form-encoded); are they not?

Microsoft/authenticode assumes one trusted master key (I think? Can a binary be signed by multiple keys?)

That is contrary to the no-central-authority idea, and it would be nice to avoid that.

However, given that Apple and Microsoft are both going in the direction of "thou shalt be a registered developer to distribute software for our OS" a central signing process for at least the initial install seems inevitable.

This is one of those "interact with existing systems that do not consider the possibility of radically decentralized solutions" hurdles that the Foundation can help jump; I expect the Foundation will soon be a registered Apple and Microsoft developer, and downloads will be signed with certificates owned by the Foundation.

The alternative is downloads only geeks can use (because only geeks know how to turn off cert checks) or binaries signed by me personally. And I don't want to be a single point of failure; having an organization that will hopefully outlive me is a better solution.

The best solution would be multi-signed binaries and a decentralized web of trust system, but we're not there yet.

Thanks for all the positive, constructive feedback (those of you who gave positive, constructive feedback). I'm not going to address conspiracy theories, mostly because I'm not seeing most of them because of who I've got on my ignore list.

The points people made here about the Foundation making Bitcoin MORE decentralized are, from my point of view, exactly right. To take one example, I don't want to be the centralized decision-maker who figures out who should or should not be on the bitcoin-press mailing list that is on the bitcoin.org homepage any more. To take another: if there is money for the development team, I don't want to decide how to split it up (I've got an obvious conflict of interest).

RE: why Peter and why not anonymous members and why DC and why not a different process to start:

Because I'm pragmatic.  I like to actually get things accomplished instead of endlessly talking about doing things. Everybody on the initial Board are people who get things done.

My biggest fear is not that the Foundation will become some massively powerful entity controlling Bitcoin; my biggest fear is that the Foundation will turn into Yet Another Ineffective Bureaucracy, employing a few people who do nothing but put out meaningless press releases.

RE: confirmation-of-payment emails:  that will be done soon.

RE: bylaws:

In the spirit of openness, the Foundation bylaws are on github:
  https://github.com/pmlaw/The-Bitcoin-Foundation-Legal-Repo/tree/master/Bylaws

Creating forums or mailing lists where Foundation members can communicate is on the very short-term TODO list.

Thanks again to everybody who has already joined, it is exciting to see people from all over the world get involved!

Is there a good open source piece of code we can use to test to make sure we're generating good entropy?

These bugs should be investigated and fixed (Sergio can you open issues on github?), but I'd like a test we could periodically run to make sure they stay fixed. Even better is if the code could monitor itself and let the user know if there's a problem with entropy generation.

Y'all can stop speculating:
  https://bitcointalk.org/index.php?topic=113400

I'm pleased to announce the launch of the Bitcoin Foundation:

The Bitcoin Foundation is modeled on the Linux Foundation. I think Linux is a great "role model" for Bitcoin; it is a very successful open source project that really embraced the notion of "open," encouraging the use of the core technology for a wide range of applications.

I hope that the Bitcoin Foundation will help do the same for Bitcoin.

Of course, "the Foundation" won't do anything at all-- people get things done. I want the Bitcoin Foundation to be an open, member-driven organization, and hope that you or your organization will not only become a member but will help the Foundation accomplish its mission.

Please visit the Foundation website for details, and please keep in mind that nothing is set in stone; the structure of the Foundation can be changed by a vote of its members, and exactly what the Foundation does will largely depend on who is willing to step up do the work to make things happen.

To any of you feel like you should have been invited to be part of the group who defined the initial structure and purpose of the Foundation: I apologize. But in my experience the larger the group, the longer it takes to get things done, and it has been 11 months since I first posted about the possibility of forming a Foundation.

---

In what will doubtless be an ineffective attempt to fend off the trolls, here are some answers to what I expect might be commonly asked questions:

Q: Is this the infamous September Announcement?

Yes.

Q: How do we know you won't just take our bitcoins and run?

We won't. The initial Foundation board members are all people with well established reputations using their real names.

Q: How do we know you won't lose our bitcoins to hackers?

We'll be using a cold wallet, with the private key securely backed up, for most of the Foundation's funds; in the near future I expect we'll be using a multisignature cold wallet, with keys controlled by multiple Board members to keep the funds even more secure.

Q: Is this just a front for the CIA? What is the hidden agenda?

No. And there is none.

Q: The Foundation is a corporation, and corporations (especially US corporations) are evil.

OK. So don't join-- go form your own non-corporate non-evil organization, or just ignore the Foundation and do whatever you think is right.

Q: How, exactly, is the Foundation going to spend the money it gets?

That depends on how many bitcoins it gets from memberships and donations. See Peter's "Letter from the Executive Director" for the current list of priorities, and see the Linux Foundation website for an idea of the types of things I hope the Bitcoin Foundation will be doing, assuming it has the funds.

---

Finally, thanks to Peter Vessenes, Patrick Murck, Mark Karpeles, Charlie Shrem, Jon Matonis and Roger Ver who stepped up and did the work necessary to get this started.