The new Qt-based client does not include an RPC client anymore, indeed. It can still function as an RPC server (-server), but for the client you need bitcoind.

Bitcoin transaction do not have a "from" address - they have inputs (which themselves may have had a to address in the previous output).

It is just a function of the difficulty and timestamps of found blocks. It's however more than just a windowed average.

I use an exponential window (so essentially, using all blocks ever, but those longer ago count significantly less), and perform some extrapolation by fitting a growing speed function through the data. The time factor for the exponential windows is listed in the graphs.

The encryption format in the wallet was specifically designed not to be crackable through rainbow attacks, so I'm afraid you're out of luck.

Bitcoin is not intended for microtransactions. Since all transaction are publicly maintained and verified, this has a significant cost to the network. This is a price many consider worth it, in exchange for having a medium that has all the properties Bitcoin provides, but it is not neglectable.

If you want to do microtransactions (in the long term) over bitcoin, I believe third-party services will be required, which can perform such transaction with far smaller overhead internally.

The encryption mechanism in the bitcoin client uses key strengthening to make sure an attempt costs around 0.1s (on your own system). It's possible that the attacker has thousands of units of specialized hardware for cracking passwords, but in general he won't be able to take a million guesses a second.

The size of the coinbase is limited to at most 100 bytes, and at least 2 bytes. This means that by using the 98 free bytes for merged mining or whatever purpose, the effect on the block chain is limited to 5 megabyte per year.

There are a few different issues here.

The first is the initiation of transactions. The OP_EVAL proposal above implies an address type of the form Base58(XXX + v), corresponding to a txout <OP_DUP OP_HASH160 <XXX> OP_EQUAL OP_EVAL>. This seems to be the primary reason for advocating OP_EVAL, and I'm not sure it should be. It is very powerful, but I keep believing that secondary protocols that negotiate a transaction output are the way to go (see this proposal for an idea). There may be some legitimate advantages as well though; Gregory had an example where hashed OP_EVAL scripts could be used to increase anonymity in case of OR-based outputs.

The second is the introduction of a new script language. By retrofitting OP_NOP1 as OP_EVAL, it does not necessarily need a block chain fork, and we have the ability to modify the semantics of the language. This has massive possibilities, and should be dealt with very carefully. This is independent from the introduction of a new address type - a simple <<script2> OP_EVAL> txout script can be used, with <script2> a txout script obtained through any means. I did a proposal for improvements to the script language here, but much more discussion is necessary before we do such a thing. Casascius' idea of two conflicting transactions makes me worry though - that may be enough to not use the OP_NOP-based mechanism at all.

Yes, the interface isn't very good right now. However, the next Bitcoin release (0.5) will most likely use the new Qt user interface, which fixes a lot of problems (including the one mentioned here).

And bitcoin gets taken over by a single botnet.

As scripts inside OP_EVAL can have different semantics from the original, we can use it to short-circuit introduce a new version of the script language.

I've written a draft for a new version here: https://gist.github.com/1262449

Rationale for the changes:

• Using the altstack for signatures avoids the need for bookkeeping on the stack in scripts that do complex checking (the altstack contains the data from scriptSig, the normal stack is used for evaluation)
• Using ECDSA pubkey recovery, we avoid encoding public keys in the block chain
• Low-level signature checking can be used to implement signed message checks in script, or more custom signature schemes
• A shorthand operation for the most common case (send to address) makes normal scripts shorter

This is correct.

I believe the solution is providing an RPC call that creates a preliminary transaction (which isn't broadcast yet), but can be inspected. At this point, it can either be committed (broadcast) or reverted through another RPC call.

This is not about complex scripts - although I consider the ability to transparently support complex script an advantage (which is true for both this proposal and OP_DROP).

This is about realizing that a static txout template itself has limitations.

For example: if I am using a webpage to buy something, I am already using the http protocol. Why do I need to carry the burden of getting the transaction broadcast and accepted on the network, instead of just sending it to him? The payee is the one who 1) already has the network infrastructure in place and 2) cares about getting his money.

Currently, addresses are the only well-supported way of initiating a bitcoin transaction. However, what bitcoin addresses are in practice is no more than a template for a txout script. In practice, such an address (typically a freshly-generated one) is communicated to the payer when a payment is requested, through a website, a QR code, e-mail, ...

If stop limiting ourselves to short strings to define a payment, a lot of possibilities open up. In the following gist i've written up a proposal for a full bitcoin payment protocol, that allows arbitrary scripts, makes the receiver responsible for getting the transaction accepted, optionally removes the burden of transaction fees from the payer, and allows easy tracking of actual individual payments.

https://gist.github.com/1237788

Comments, suggestions, ideas?

It seems I misunderstood part of the original suggestion.

Still, a few remarks:

• OP_EVAL sounds like a very elegant way of increasing the script language's power, with some nice possibilities like explained above.
• I agree we need to be extremely careful about this - the data accepted by a txout script being evaluates should always be protected by some form of hash script. One can argue that this is the responsibility of the sender to create a good script, though.
• Enabling an operation like OP_EVAL implies removing the IsStandard() test, as it essentially allows any script to bypass the test anyway. I'm in favor of relaxing IsStandard() and enabling more operations, but we need solid unit tests to verify that all involved scripts/operations verify fine.
• I do like the fact that using a hash-protected eval()ed script is not encouraged without the payee asking so (even if I know you have addresses A and B, there is no reason for me to expect that an OP_EVAL script with hash equal to the hash of script that checks for A AND B will be detected by your client as a spend to you
• I don't like the fact that we're using a static string for even more complex txout templates, it risks accidental reuse, is impossible to refuse once the string is published, and is hard to track. IMHO, the right solution for cases were more complex scripts are wanted is directly negotiating them with the receiver.

Bitcoin: mining our own business since 2009

@ByteCoin: OpenSSL currently doesn't expose a way for setting the random factor k manually when signing, so it would require at least part of the signing algorithm to be reimplemented (a version of ecdsa_sign_setup). I'm not sure this is worth the effort - on the other hand, the key recovery algorithm is also implemented manually already.

We currently sign the SHA256 hash of the message, after prefixing it with a fixed string. Would this theoretically not be vulnerable to a length-extension attack? If so, aren't we better of using HMAC-SHA256, or is that poinless without secret key?

Secondly, what do you suggest the ECDSA random value calculated from? Message + address? (a have a bit trouble following djb's paper - what does h stand for?)

EDIT: nevermind, it's derived from the hash of the message + private key

Types of transactions we haven't thought of yet.

The script system is rather flexible, and allows us to add new types of transactions in the future, without requiring the entire network including miners to upgrade to a new version.

Settings -> Encrypt Wallet...