Cross-posting from the bitcoin-development list:

I submitted a pull request yesterday that implements low-level "raw" transaction, and am looking for feedback on the API and help with trying to test/break it.

Design doc:  https://gist.github.com/2839617
Pull request: https://github.com/bitcoin/bitcoin/pull/1456
Test plan: https://secure.bettermeans.com/projects/4180/wiki/Raw_Transaction_RPC_Test_Plan

Playing around with this API on the command line I'm pretty happy with the level of abstraction and the way it interacts with existing RPC commands; for example, "createrawtx" is just like "sendmany" in the way outputs are specified.

The signrawtx method is the key new method; it takes a raw transaction, signs as many inputs as it can, and returns the same raw transaction with signatures. Typical usage would be:

Funds are sitting in a multisignature transaction output, and it is time to gather signatures and spend them.

Assumption: you know the multisignature transaction's [txid, outputNumber, amount].

Create a raw transaction to spend, using createrawtx.
Use signrawtx to add your signatures (after unlocking the wallet, if necessary).
Give the transaction to the other person(s) to sign.
You or they submit the transaction to the network using sendrawtx.
I don't imagine anybody but very-early-adopters or ultra-geeks will do this by calling these RPC methods at a command-line. They are really intended for people writing services on top of bitcoind. The service should be careful to include an appropriate transaction fee, or the sendrawtx method is likely to fail.

I've been asked a couple of times: why doesn't signrawtx handle the BIP 0010 (https://en.bitcoin.it/wiki/BIP_0010) transaction format?

I considered parsing/writing BIP 10 format for raw transactions, but decided that reading/writing BIP 10 format should happen at a higher level and not in the low-level RPC calls. So 'raw transactions' are simply hex-encoded into JSON strings, and encoding/decoding them is just a couple of lines of already-written-and-debugged code.

------

Here is the help output and example use for all the new RPC calls:

listunspent [minconf=1] [maxconf=999999]
Returns array of unspent transaction outputs
with between minconf and maxconf (inclusive) confirmations.
Returns an array of 4-element arrays, each of which is:
[transaction id, output, amount, confirmations]

E.g:  listunspent 1 2
Returns:
[
    [
        "2881b33a8c0bbdb45b0a65b36aa6611a05201e316ea3ad718762d48ef9588fb3",
        0,
        40.00000000,
        2
    ],
    [
        "894a0fc535c7b49f434ceb633d8555ea24c8f9775144efb42da85b853280bcd7",
        0,
        50.00000000,
        1
    ]
]

getrawtx <txid>
Returns hexadecimal-encoded, serialized transaction data
for <txid>. Returns an error if <txid> is unknown.

E.g.: getrawtx fce46ea2448820f7bb8091b5f5e3fd75b7b267e60b9a22af88a9eeabfb084233
Returns:
01000000016d40da062b6a0edcaf643b6e25b943baf103941589d287e39d6f425d84ae8b1c00000 0004847304402203fb648ff8381d8961e66ef61ab88afe52826a5179b8a7312742c8d93785ca563 02204240ea12de1211fffab49686f13ca0e78011d1985765be6e6aa8e747852f897d01ffffffff0 100f2052a0100000017a914f96e358e80e8b3660256b211a23ce3377d2f9cb18700000000


createrawtx [["txid",n],...] {address:amount,...}
Create a transaction spending given inputs
(array of (hex transaction id, output number) pairs),
sending to given address(es).
Returns the same information as gettransaction, plus an
extra "rawtx" key with the hex-encoded transaction.
Note that the transaction's inputs are not signed, and
it is not stored in the wallet or transmitted to the network.

E.g.: createrawtx '[ ["fce46ea2448820f7bb8091b5f5e3fd75b7b267e60b9a22af88a9eeabfb084233",0] ]' '{"mqYmZSQQuAWNQcdwBrDwmtTXg2TLNz748L":50}'
Returns:
{
    "version" : 1,
    "locktime" : 0,
    "size" : 85,
    "vin" : [
        {
            "prevout" : {
                "hash" : "fce46ea2448820f7bb8091b5f5e3fd75b7b267e60b9a22af88a9eeabfb084233",
                "n" : 0
            },
            "scriptSig" : "",
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 50.00000000,
            "scriptPubKey" : "OP_DUP OP_HASH160 6e0920fc26383dc7e6101bc417cf87169d0cedbd OP_EQUALVERIFY OP_CHECKSIG"
        }
    ],
    "rawtx" : "0100000001334208fbabeea988af229a0be667b2b775fde3f5b59180bbf7208844a26ee4fc00000 00000ffffffff0100f2052a010000001976a9146e0920fc26383dc7e6101bc417cf87169d0cedbd 88ac00000000"
}

signrawtx <hex string> [<prevtx1>,<prevtx2>...]
Sign inputs for raw transaction (serialized, hex-encoded).
Second argument is an array of raw previous transactions that
this transaction depends on but are not yet in the blockchain.
Returns json object with keys:
  rawtx : raw transaction with signature(s) (hex-encoded string)
  complete : 1 if transaction has a complete set of signature (0 if not)

E.g.: signrawtx "0100000001334208fbabeea988af229a0be667b2b775fde3f5b59180bbf7208844a26ee4fc00000 00000ffffffff0100f2052a010000001976a9146e0920fc26383dc7e6101bc417cf87169d0cedbd 88ac00000000" '["01000000016d40da062b6a0edcaf643b6e25b943baf103941589d287e39d6f425d84ae8b1c00000 0004847304402203fb648ff8381d8961e66ef61ab88afe52826a5179b8a7312742c8d93785ca563 02204240ea12de1211fffab49686f13ca0e78011d1985765be6e6aa8e747852f897d01ffffffff0 100f2052a0100000017a914f96e358e80e8b3660256b211a23ce3377d2f9cb18700000000"]'
Returns:
{
    "rawtx" : "0100000001334208fbabeea988af229a0be667b2b775fde3f5b59180bbf7208844a26ee4fc00000 0009100473044022007f3ba1b8bdc156f2340ef1222eb287c3f5481a8078a8dad43aa09fd289ba1 9002201cc72e97406d546dc918159978dc78aee8215a6418375956665ee44e6eacc115014752210 2894ca6e7a6483d0f8fa6110c77c431035e8d462e3a932255d9dda65e8fada55c2103c556ef01e8 9a07ee9ba61581658fa007bf442232daed8b465c47c278550d3dab52aeffffffff0100f2052a010 000001976a9146e0920fc26383dc7e6101bc417cf87169d0cedbd88ac00000000",
    "complete" : false
}

sendrawtx <hex string>
Submits raw transaction (serialized, hex-encoded) to local node and network.
E.g.: sendrawtx 0100000001334208fbabeea988af229a0be667b2b775fde3f5b59180bbf7208844a26ee4fc00000 0009100473044022007f3ba1b8bdc156f2340ef1222eb287c3f5481a8078a8dad43aa09fd289ba1 9002201cc72e97406d546dc918159978dc78aee8215a6418375956665ee44e6eacc115014752210 2894ca6e7a6483d0f8fa6110c77c431035e8d462e3a932255d9dda65e8fada55c2103c556ef01e8 9a07ee9ba61581658fa007bf442232daed8b465c47c278550d3dab52aeffffffff0100f2052a010 000001976a9146e0920fc26383dc7e6101bc417cf87169d0cedbd88ac00000000
Returns:
error: {"code":-22,"message":"TX rejected"}

(Rejected because it doesn't have all required signatures, if it was accepted it would return the transaction id)

Relevant discussion here:
  http://crypto.stackexchange.com/questions/779/hashing-or-encrypting-twice-to-increase-security

You're a crazy-man.  Crazy in a good way... ever do any APL programming?

Once upon a time bitcoin.org called Bitcoin "anonymous" but that was a mistake, and for at least two years "we" (core developers) have tried to be careful to say that, at best, Bitcoin is pseudanonymous.

I tell reporters that Bitcoin is more private than using any other online payment method, but less private than cash (unless you know a lot about how it works under the covers and jump through several hoops to keep your identity secret).

Where did you read that bitcoin is supposed to be anonymous?

You just poked one of my pet peeves: the Y-axis on your Euro chart doesn't start at zero, so you're exaggerating it's volatility.

No, I don't have a prototype.

The hardware is real and very cool, but they've got a lot of work to do on software and user interface and manufacturing process and marketing and distribution and.... .  Expect the design to change before you can actually buy one. And like all really innovative projects (and to quote the MythBusters) "Failure is always an option."

Answering detailed questions about exactly how it works right now would be a waste of time, because I think before it ships most of the answers will be different. The meeting in Vienna was for bitcoincard to get early feedback on whether or not they're headed in a good direction.

RE: why would you want a bitcoincard versus just using your cellphone:  I personally think you'll want both; I'm trying to convince them that the bitcoincard could be a perfect "second device" for multisignature transactions. Cell phone viruses and trojans and malware will be the next big wave of security vulnerabilities.

I've been switching back and forth between writing a spec for it ( https://gist.github.com/2839617 ), implementing it ( https://github.com/gavinandresen/bitcoin-git/tree/signrawtx ), writing up a test plan ( https://secure.bettermeans.com/projects/4180/wiki/Raw_Transaction_RPC_Test_Plan ) and testing.

My goal is to get all that done by the end of this week and have it in the 0.7 release.  But lots of things could make it take longer.

I actually created and spent some "input from wallet a", "input from wallet b" private testnet transactions earlier this week (I'm working on some lower-level RPC commands for bitcoind -- see https://gist.github.com/2839617  for the half-baked spec).

Somebody could build a transaction-combining service on top of those low-level RPC commands, although I suspect to be really resistant to sophisticated network analysis doing "one or more inputs from A in,  one or more from B in, ApayToSomebody Achange BpayToSomebodyElse Bchange out" won't help much.  There is a lot of prior work on "mix networks" and maintaining anonymity, and the only thing I know about it is that it is a hard problem to get right.

RE: the 100/120 difference:

Check my work, but I think this is the scenario where it would matter and cause headaches:

You generate a block 100 blocks before a difficulty adjustment.

Then you spend the coinbase exactly 100 blocks later, in a block in the next difficulty period. And, let's say, whoever you send the bitcoins to spends that transaction again immediately.

Now imagine a really wacky scenario where you're reorganized onto a shorter-but-has-more-difficulty block chain.  That could happen if you were disconnected from the main bitcoin network for a while.

Your coinbase-spend transaction and any transactions that depend on it can't be included in the main chain because they're immature, so they get dropped from everybody's memory pool as "trying to spend an immature coinbase."  I'm not sure what then happens; I think you'd eventually retransmit them and get them into the main chain, but that could take a while.

Yes... but having peers with a completely different block chain from you connect is a good way to shake out obscure bugs.  Like Bitcoin-Qt's "how many blocks are in the valid chain" code getting fooled...

Bitcoin-Qt ?  Sounds like a bug in the "estimate how many blocks there are based on what your peers tell you" bug.

Signatures are BER-encoded data structures, and can be an arbitrary number of bytes (if they're DER-encoded, which is the strict subset of BER encoding, then they're 70-something bytes).

Public keys are either 33 or 65 bytes (not counting the "push the next N bytes onto the stack" CSCript opcode).

I've got to say you make me nervous; you seem to be following a "make it work for a couple of test cases then move on" style of development, which is a bad way to create a secure, robust codebase.

PS: I sympathize with you RE: OpenSSL's lack of documentation....

I just got stuck-- looks like somebody is serving up the testnet2 blockchain to testnet3 nodes that connect to them (that's what is causing the 'nBits below minimum work' message).

Re-running to connect to a real testnet3 node is getting me the correct blockchain (with 6,905 blocks).

I think consolidating everything under one domain is dangerous and against the decentralized nature of the Bitcoin project.

I'd love to see somebody resurrect the Visual C++ makefile and build instructions (and let us know if we've accidentally added and gcc-specific code), so Windows developers didn't have to spin up a VM and cross-compile everything.

As to why your builds are different:  no idea, but you can look at the file-by-file checksums in the bitcoin-build.assert file to see exactly what is different.

I should lie and say I'm feeling extra generous to miners this morning and wanted to give them an imaginary 50 BTC fee...

How would you use a 'getaddressbalance'?  What are you trying to do?

Start with an empty wallet.  I send you 100 BTC to address 'foo'. Then you send somebody else 1 BTC.

Internally, a new change address with 49 (edit: 99) bitcoins is created, so getaddressbalance 'foo' would return zero. Would that ever be the right answer?

I love you guys, and hope you're being wildly successful... but:

Plugging in "Deposit $200, get $192" for a cash deposit and then finding out I'll actually have to bring $204.95 or $201.58 because of an extra third-party processing fee feels like bait-and-switch to me. Don't you know in advance how much the payment processors will charge?  Does it vary based on location or something?

Ummm....

When you run something like: 
... bitcoind creates a network connection to localhost:rpcport and talks to the running bitcoind process via the JSON-RPC protocol.

So it doesn't matter what user the process is running as, what matters is securing access to the JSON-RPC network port, keeping the rpcpassword a secret, and preventing attackers from getting in and copying wallet.dat.