Nice work!

That's almost exactly the direction I'm heading with the cross-platform testing framework I've been working on, although I was planning on storing blocks in JSON format and was planning on using Python's Twisted/Trial framework to feed the different chains to the implementations to see if they accept or reject them.

I got sidetracked by the 0.5 release and then sidetracked again because I couldn't resist experimenting with the "OP_EVAL" idea and multisignature bitcoin addresses...

Corrupting how? Did they install 0.5 and then downgrade (is it a backwards-compatibility issue)?
Did it get corrupted when they encrypted?
Anything interesting in their debug.log?

Thinking out loud:

If miners (or other nodes) not relaying transactions starts to become an issue, "we" could write code to detect and discourage it.

Detecting: the node says it is a full node but you get many fewer 'inv' messages from it compared to your other peers.

Discouraging: you refuse to relay or build on any new-block messages that you get from that node.

See https://github.com/gavinandresen/bitcoin-git/tree/discourageblocks for a framework for the 'discourage' part.

I can't resist, the problem of how to bootstrap a new chain in the face of massive, hostile hashing power fascinates me.

CoinHunter, what will happen to SolidCoin if, God forbid, you get hit by a bus? What are the plans for the trusted CPF wallets? Do your heirs get control of them?

And what if SolidCoin is wildly successful-- so successful that each SC is worth 1,000 euros? Will somebody still need 1 million of them (so have to be a euro billionaire) to be trusted?

None taken.  I've been trying pretty hard lately NOT to be The Central Authority, I don't want the job and I think the whole idea is contrary to the Zen of Bitcoin.

kano, you seem to be under the mistaken impression that I am King of Bitcoin.

I told you that if you don't like the getmemorypool RPC method, you would need to gain consensus either on the Dev&Tech section of these forums or the bitcoin-dev mailing list. That's how bitcoin works-- rough consensus, not "submit requests to the King" or "petition the Central Committee."

This forum is for "Technical discussion about Satoshi's Bitcoin client and the Bitcoin network in general. No third-party sites/clients..."

Would Open Transactions discussions be more appropriate in Off-Topic or Alternative Clients ?

Hmm?  testnet accepts non-standard transactions today (I've been doing some experiments with multi-sig transactions on the testnet).

I just tagged the git tree "v0.5.0rc1". If you are able, please compile and help test.

See the INSTALL file at the top of the source tree for instructions on compiling. Binary releases for at least unix and mac should be available in the next day or two (there is a show-stopper bug on Windows, and we could use help from people familiar with cross-compiling using mingw to update the Windows build process).

Major bugs you should be aware of:

Wallet does not relock on Win32

Major changes from version 0.4:

Switched from wxWidgets for the GUI to Qt, using Wladimir J. van der Laan's bitcoin-qt. Why? We didn't have any wxWidgets programmers contributing fixes or improvements.

New JSON-RPC commands:

getmemorypool : alternative to 'getwork' that provides everything needed to construct a block with a custom generation transaction.
listsinceblock : Get all transactions in blocks since block [blockid]
signmessage/verifymessage : sign/verify a message with a wallet public/private keypair

Deprecated JSON-RPC features:
'midstate' data item from getwork requests

Deprecated JSON-RPC commands that have been REMOVED:
setlabel
getlabel
getaddressesbylabel
getamountreceived
getallreceived
getreceivedbylabel
listreceivedbylabel

Run: git shortlog --no-merges v0.4.0..
... to get a complete list of changes, and thanks to everybody who is contributing!

Huh?  getmemorypool discussion is/was here:  https://bitcointalk.org/index.php?topic=39088.0

I'll just note that I'm damned if I do pull stuff that has some discussion here (and no objections raised), but damned if I don't pull stuff that first had no discussion, and then had a little discussion with some dissent.

This is why I don't pull additions or major changes to RPC commands without at least a couple of people looking at them and either saying "yup, that's exactly how I would do it" or "it'd be better if...."

I agree with Mike, the -coinbaser <cmd> should be separate from setauxwork.

Does setauxwork interact with the new getmemorypool RPC command at all?  Should it?

And should there be a listauxwork RPC command?

Good news: I'm just about to get a Bitcoin-Qt version 0.5 Release Candidate 1 out, with a much-improved GUI.

Bad news: all the translations for the old wxWidgets Bitcoin are obsolete, and the process for making translations is different.

Is anybody willing to write new translations?  Here's what you'll need to know:

• Three translations already exist: de nl and ru.
• Translations are stored in ".ts" files in the src/qt/locale folder
• The 'QT Linguist' tool can be used to create translations
• ... or maybe an online tool like Transifex could/should be used to crowd-source the work

And is anybody willing to take the job of coordinating translation efforts, figuring out if Transifex is a good tool to use, and writing some documentation to make it easy for people to create and submit new translations?

Mmmm.... Twisted....

I started defining a BitcoinProtocol class derived from twisted.internet.protocol.Protocol for my cross-implementation at-the-network-level testing project.  I plan on using Twisted and Trial (the Twisted unit testing framework) to feed canned block-chains to "empty" nodes and make sure they Do The Right Thing (reject blocks that violate the blockchain rules or contain invalid transactions, accept blocks that contain weird-but-valid transactions, etc).
  https://github.com/gavinandresen/Bitcoin-protocol-test-harness/blob/master/BitcoinClient.py

Anyway, the BitcoinProtocol class might be a good place to start for anybody who wants to do some python-based bitcoin network programming.  Good example to demonstrate is a little dump-blocks tool I wrote to spit out a blockchain in JSON format:
  https://github.com/gavinandresen/Bitcoin-protocol-test-harness/blob/master/dumpblocks.py


(I'm a Twisted newbie, so improvements, suggestions, etc are very much appreciated)

RE: 0-confirmation OP_EVAL transactions:

I think I'm doubly-wrong.

OP_EVAL transactions are non-standard to old clients, so they are dropped before being added to the memory pool.  Old clients will not relay them, old miners that follow the IsStandard rules won't put them in blocks.

When a transaction comes in that depends on a transaction that is not in the block chain or memory pool, it is shunted into the orphan transaction pool, and isn't listed by listtransactions or show up in the GUI until all of its inputs are satisfied.

The risk would be a rogue miner putting invalid OP_EVAL transactions into blocks, which would trick old clients into showing transactions that depend on them as 0/ or 1/unconfirmed.


RE: "but bitcoin addresses are UGLY and the WRONG way to do it!"

Okey dokey.  If I recall correctly, people were saying exactly the same thing about URLs 10 years ago (...google... yup).

If your argument is OP_EVAL is possibly insecure... it seems to me it is much easier to reason about the security of OP_EVAL than to reason about the security of URI schemes or schemes for passing around a transaction to be signed or using SIGHASH_ANYONECANPAY.

I agree that protocols for passing around either transactions or signatures are needed, I just don't think agreeing on what those protocols aught to be will happen anytime soon (how much you want to bet there will be a protocol buffers versus JSON debate that rages on for at least six months?)

RE: writing up a full design doc: I've always admired the IETF's "rough consensus and running code" approach to standards-making, so I'll be happy to write up a full design doc after I've got running code.  Actually trying to IMPLEMENT multisignature transactions has taught me a whole lot about what will work in practice and what won't.


Finally, to try (in vain, probably) to focus discussion:  The use cases I care about are:

1. A user running bitcoin on a device that gets infected by malware. I want them to be able to subscribe to some service that will provide transaction confirmation for any outgoing bitcoin transactions above a certain amount per day (like my bank does with my ATM card).

2. And I want them to be able to have a 'master wallet key' stored in physical form in their safe-deposit box so they can recover their wallet if they forget their passphrase or lose all their backups.

OP_EVAL appeals to me because I can see EXACTLY how to make those use-cases work with minor variations to the infrastructure we have today for performing bitcoin payments.

He wouldn't have included NOP1 through NOP10, either.

I file this under "Satoshi is a genius, part 9,432".  It gives a smooth upgrade path using the same blockchain if ECDSA or SHA256 start to get fragile.

Attacking old clients by sending them coins with "will-never-be-satisfied-but-they-can't-tell-that" inputs is a concern-- it is basically the Finney attack, but anybody will be able to try to pull it off and there is no time constraint.

However, I think the benefits of being able to send to a truly secure address FAR outweigh the risks, I don't think it will be difficult to get people to upgrade to a newer, more secure client, and accepting 0- or 1-confirmation transactions is always a bad idea.

I also think you're exaggerating the impact-- OP_EVAL does not invalidate all of the security review that has been done so far, especially if the scripting language being EVAL'ed is unchanged from what we have today.

(PS: the latest git-head QT bitcoin contains a working bitcoin URI handler)

In an effort to keep discussion on track, I split the discussion of Lamport versus Bernstein signature schemes into its own thread.

So: can anybody think of any potential attacks that would be enabled by having a standard form:

... spent by providing:

The simplest <serialized script> would be <pubkey> CHECKSIG.


Things that occur to me or were brought up in the IRC discussion:

• Denial-of-service if <serialized script> is allowed to contain OP_EVAL.
  
  Proposal on the table is to completely disallow recursion, which eliminates that threat.  I'm tempted to allow limited recursion (max 2 levels deep maybe) because it would allow some really cool things to be done in the future....
  
• Stealing coins because old miners/clients will not verify the signature hidden inside <serialized script>.
  
  If 50+% of the hashing power on the network support OP_EVAL, then transactions that pass the <scripthash> check but fail the signature check inside the <serialized script> would be accepted as valid by old miners and clients, but would fail to confirm because they would be rejected by the majority of miners.
  
  That CANNOT be used to trick exchanges or people using old software, because the old software will not recognize the new script form, and will simply ignore the transaction-- you will not get "0/unconfirmed" OP_EVAL transactions displayed in old versions of Bitcoin. Wrong again!  See casacius' excellent response.
  
• Creating or modifying <serialized scripts>
  
  Maybe there's an attack waiting to happen because an attacker could trigger a buffer overflow bug by doing something like:
  <safe serialized script>  119 OP_ADD  OP_EVAL
  But if there is a buffer overflow bug in an implementation's transaction script interpreter, then an attacker can almost certainly just send a "tx" message containing a non-OP_EVAL script that triggers the bug. OP_EVAL certainly does mean one more thing for an implementation to get right, but it isn't actually very hard to implement if you're already able to validate "tx" messages.
  

Any other attacks anybody can think of? If implementations are strict in which transaction forms they'll accept as "valid AND mine (counts towards my wallet balance)", but liberal in what transaction forms they'll accept as "valid, but I can't spend it" then it seems to me the risks are small.

... but isn't it the signatures that give each transaction its unique identity?  I may be wrong, but without the signature hashes I think you can get two different transactions (two transactions that are exactly the same as far as scriptPubKeys, but spend different outputs) that hash to the same value, which would cause all sorts of problems, including replay attacks re-using old signatures.


Interesting... too radical a change for right now, in my opinion.  (I think Pieter's proposal is too radical a change for right now, too... I'm on the fence about whether OP_EVAL is too radical a change, but I think the advantages outweigh the risks).


Pieter's proposal is <signature+2bits>

I voted no because of the fine-print in your original post.

I think setworkaux is OK, but I don't like "doesn't work on windows" changes to support one mining pool.

Good idea. Who wants to volunteer? I'm too busy...

Wow, so many great ideas!

RE: There is already code to warn the user if they are on a minority chain more than 6 blocks long-- see GetWarnings():

It just warns, it doesn't stop you from generating/sending transactions. Perhaps if the longer fork is more than 120 blocks ahead it should.

ByteCoin: we can prevent the scenario you describe (generate a block with a NOP1/EVAL transaction whose validity is different in old and new clients) by:
1. Requiring that EVAL transactions be valid if the EVAL is interpreted as a no-op.  New clients can replace EVALs with no-ops and re-evaluate them to make sure that is true.
2. Waiting until a majority of hashing power has upgraded before turning on EVAL.

gmaxwell:  I really like the idea of implementing key recovery to save space in the block chain. It can also be done in a backwards-compatible way if only CHECKSIGs "hidden inside" of EVALs support it (CHECKSIG would be aware of whether it was being executed inside of an OP_EVAL, and if it was it could use a compressed version of the public key instead of the full public key).

All the ideas about figuring out what percentage of miners have upgraded:  seems like that deserves its own discussion thread.