The Bitcoin Foundation does help pay for dev efforts; it pays me, Wladimir, and Cory Fields (and gives quarterly grants to fund other worthwhile efforts).

I disagree with the original poster; Bitcoin development is increasingly decentralized over time. It started out as centralized as it could possibly be-- Satoshi wrote all the code himself (or herself or their-selves).

Now we have multiple implementations, multiple altcoins, and multiple wanna-be-Bitcoin-2.0 contenders, all with their own dev person-or-team (well, some altcoins probably don't have any developers).

As for your specific ideas: go for it. If you think they're good ideas, implement them (or hire or convince somebody to implement them) and see what happens.

Feel free to create some; code here: https://github.com/gavinandresen/paymentrequest

transactions send via sendrawtransaction are always debited from the default "" account. Raw transactions and accounts are not designed to work together, use one or the other .

And preferably not accounts: unless somebody steps up and volunteers to make the accounts feature "industrial-strength" (scalable, integrates with whatever back-end database your company is using to track user information, can be robustly backed up, etc) it is very likely it will be deprecated and then dropped.

There is a lot of competition for the free transaction area in blocks these days; you need a much higher priority to get confirmed quickly, 57.6 million is not enough any more.

A future version of the reference implementation wallet will automatically estimate the priority needed.

On further testing, it looks like OSX and Linux payment protocol requests with the released 0.9.0 binaries are not vulnerable.

The released Windows 0.9.0 binaries are vulnerable, so Wladimir just sent an alert message urging everybody running 0.9.0 to upgrade.

Check again; see the use of CKeyingMaterial/CPrivKey which uses a secure_allocator (which asks the operating system not to swap the memory to disk, and which zeros memory on free). If I recall correctly, the RPC importprivkey should be the only place where the normal memory allocator is used (the keys exist as ordinary hex strings in memory before they are processed by the importprivkey code).

Careful review (and testing and patches) is always welcome, of course. You shouldn't trust my famously faulty memory.

https://github.com/Lekensteyn/pacemaker is a little SSL server to test SSL clients for heartbleed vulnerability.

I installed Bitcoin Core version 0.9.0 on my Mac (compiled against the vulnerable openssl 1.0.1f), created a web page to launch a payment request fetch from pacemaker...

... and I get good news:

Step-by-step so you can help test on other OS'es :

• git clone https://github.com/Lekensteyn/pacemaker.git
• cd pacemaker
• python pacemaker.py
• Run Bitcoin Core GUI version 0.9.0
• In your browser, visit https://bitcoincore.org/~gavin/heartbleed.html  

pacemaker.py should report a connection, and then either say "Client returned blah bytes" or "Possibly not vulnerable"

It looks to me like pacemaker.py IS working; visiting https://127.0.0.1:4433/ in Chrome pacemaker tells me:

This isn't a definitive "no need to worry even if you HAVE clicked on payment-protocol-enabled bitcoin: links at an untrustworthy website" ... but given the evidence I've seen, it seems to me extremely unlikely anybody's private keys have been compromised.

For low-priority transactions, it doesn't look to me like many miners are accepting lower fees.

Right now, a 999-byte transaction paying the reference-implementation-default fee of 0.0001 BTC will wait 2-3 hours to get into a block.

A typical 250-byte transaction paying the default 0.0001 BTC fee will see its first confirmation in 5 or 6 blocks (about an hour on average). If you want your transaction to confirm quickly, then right now you need to pay about double the default fee.

Some results running https://github.com/bitcoin/bitcoin/pull/3959 (more review/testing welcome) :

Sounds familiar...

... I think I ran into a similar problem that turned out to be ssh being upset that the file permissions on the id_dsa file used to login to the virtual machine were too permissive (because I was running from a FAT32-formatted USB stick that didn't support file permissions at all, if I recall correctly, which I probably don't).

This was a release process bug; I re-built/signed/uploaded the OSX .dmg to fix it (and updated the SHASUMS files).

The warning is harmless, and no code was changed, so if you don't want to re-download and install you don't have to.

Thanks to lots of hard work from Luke Dashjr and Cory Fields we should (fingers crossed!) have deterministic OSX builds working before the next release, which will make this kind of error impossible.

Thanks, k99 and Vitalik, that helps clear it up.  I've put "On Transaction Fees, And The Fallacy of Market-Based Solutions" on my to-think-about-deeply list.

I'm curious about this, though:


If my contract needs more than 16 computational steps to execute, then other people CAN send transactions to it to intentionally bankrupt it? That is what I was worrying about when I said "publish the attacker's transaction and take the fee but ignore any other effects of the transaction, but you'd have to be careful to design THAT mechanism so it couldn't be abused."

Okey dokey... so how do fees work in Ethereum?

Or do you have some other clever distributed way of preventing flood-the-system-with-bogus-contracts DoS attacks?

How do transaction fees work in Ethereum?

One of the non-obvious reasons Bitcoin works is transaction fees are based on the size (in bytes) of the transaction. And since there are no loops executing a transaction, CPU usage is bound by transaction size.

If CPU usage to verify a transaction is NOT related to the transaction size, then you open yourself up to denial-of-service attacks. Like:

Create an Ethereum transaction with a (huge!) fee that will pay for 60 seconds of CPU execution time.
... but craft it so execution takes 61 seconds (or, heck, make it an infinite loop, maybe you'll tickle a bug in the execution termination code).

Now broadcast it.  It will be rejected for insufficient fee, but only after peers have wasted 60 seconds of CPU time. And if the transaction is rejected, the attacker won't pay the fee.

Then tweak it slightly and broadcast it again, maybe from a different IP address if you got banned for bad behavior.

---

I haven't thought deeply about whether or not there is a way to punish the attacker; my first thought would be to publish the attacker's transaction and take the fee but ignore any other effects of the transaction, but you'd have to be careful to design THAT mechanism so it couldn't be abused.

I'm usually pretty careful not to call people names.  Did I screw up?

I DO think there are lots of crazy conspiracy theories. I might even believe some of them myself, but that doesn't make me crazy (just "almost certainly wrong.").

RE: child exploitation:  Good example.  We all agree that child exploitation is BAD, right?

We might disagree about what (if anything) we should DO about it, but isn't it worth discussing whether or not there is something we MIGHT do about it?  For example, maybe offering mostly-anonymous bounties to reward anybody who gives information that leads to the arrest and conviction of people abusing children for profit or pleasure is a good idea.  Maybe those bounties could be paid in Bitcoin.

Maybe that is a terrible idea that will have awful consequences, but instead of rational discussion there's a knee-jerk GOVERNMENT BAD! that, in my humble opinion, is counter-productive to making the world a better place.

I don't like people assuming that they know what I'm thinking, or assume that because I'm willing to talk to people that I agree with those people, or assume that because I'm pragmatic about regulation I "want regulation."  For the record:  I'm mostly libertarian, I think we'd be just fine if we replaced 99.911% of regulations with voluntary, private, market-based solutions. But that ain't gonna happen any time soon.

Bilderberger meetup is in Barbados this year.  But don't tell anybody, it is a secret.


PS to dewdeded: Mike Hearn and I both own non-US passports, so putting us on Team USA is funny. We should be Team Global Conspiracy (mmm... gotta get T-shirts made...).

No, not possible, given what we know about the properties of SHA256 hashing.

I've accepted an invitation to do a question and answer session at the Council on Foreign Relations (CFR) in Washington, DC on Thursday, February 6, 2014.

I've been told anything related to the Council on Foreign Relations tickle's peoples Grand Conspiracy buttons, so I thought it would be best to be open about exactly what will happen. I hope it doesn't spark as long a thread as my visit to the CIA, but Bitcoin is a lot bigger than when I visited the CIA...

Anyway, here's the invitation I received:


The format of the event will be a 90-minute question&answer session, moderated by somebody yet-to-be-determined. It will be "on the record," meaning press could be invited to attend and recordings and/or transcripts may be posted on CFR's website.

The audience will be CFR members and invited guests (and maybe press); it is not open to the public. I am not getting paid by the CFR.

Bah, I forgot to code-sign the Windows .exe. Expect an updated .exe and SHASUMS soon.

https://gist.github.com/gavinandresen/5616606 sketches out one way to do it.

You disgust me. Participating in a ponzi is immoral.

You might as well ask "Anybody know some good scams I can make money from?"

Do something productive that makes the world a better place instead.

It looks like maybe some pools have reacted; the average block size is going up:
  http://www.quandl.com/BCHAIN-Blockchain/AVBLS-Bitcoin-Average-Block-Size

For those that haven't, the relevant bitcoind command-line arguments are:


Adding:
... to your bitcoin.conf and re-starting bitcoind (or running with the command-line arguments) will really help with the transaction crunch.

I'm still hard at work (nearly done!) on making the reference implementation much smarter about transaction fees, but until wallet software gets smarter about fees we need to rely on big pools doing the right thing so Bitcoin users don't get frustrated by long transaction confirmation times.