Variable length integer, from the bitcoin protocol.

It states very clearly in the wiki:
Here it makes sense.

But the problem is, when I do getblocks with hash_stop set to zero, I get back inv where the count field is "fd f4 01"
Now, if I parse it according to the spec, it give me value 753 (0xfd + 0x01f4). While in fact the proper value is 500 (0x01f4)

So which one is wrong; the spec or the value inside the message?
Or am I wrong somewhere?

testnet seems to be pretty useless ATM because it doesn't introduce new blocks with a reasonable intervals.
you want to test something and you have no idea how long you will need to wait for a new block.

Sorry, I know it's already my 4th post in a row, but I've been working on this today and I did some changes which you may want to know about.
They are already committed so feel free to try them.

1.
Now the transaction file is just a raw binary data - it makes it much easier to look inside and make sure that this is the actual transaction and nothing more (like previously, there was some extra data hidden in an encoded string).
First of all the file should always start with "01 00 00 00" and always end with "00 00 00 00". Inside there is the actual transaction data which follows the tx format.

2.
Since the data is binary you cannot just pass it as is via the JSON-RPC api.
Therefore the "importtransaction" command expects now a hexdump of the raw transaction data (not base58 string anymore).
(if you have only the binary file its very easy to get the hexdump, i.e. by doing: xxd -p -c 9999 < transaction_file.btd)

3.
"gettransaction" does not return "rawdata" field anymore.
Instead I added a separate command "exporttransaction", which accepts one or two arguments.
The first argument is always the transaction id (trid)
If you omit the second argument, you will get back a hexdump of the requested transaction (same one as "importtransaction" expects).
If you specify the second argument, it will be taken as a filename of where the binary dump of the transaction will be stored.

4.
The user interface did not really change since the previous version.
But the transaction file it creates is now a binary dump of the transaction.
And the same kind of binary dump file is expected when you're doing "Settings/Import transaction..."

OK - I found the problem. Fixed and committed - same branch.
And now I can honestly answer: yes, file that is written contains just exactly the rawdata, no more no less.


But I am actually thinking of changing the format of this file from base58 encoded to a raw binary.
I realized that encoding it to base58 is just stupid.

Unfortunately binary data, though very convenient, cannot be used via RPC.
So for RPC it should be either a hexdump, base64 or just a name of a file where the data shall be written to / read from.
Any suggestions/preferences?

OK, I figured what is in this extra red data.
It's just a local data about the transaction itself, like previous inputs, time received, from me, spent, etc...
No private keys

Anyway, since it isn't really needed and it sort of discloses the wallet's privacy, it should not be a part of the rawdata - sorry about that.
Now, getting rid of it is easy - all I need to do is to cast CWalletTx to CTransaction before serializing it (streaming into CDataStream).

But I need to test this solution, because as I mentioned before there is something wrong now when importing such a transaction.

To be honest, after playing with it a bit, I see that there is something more, but I have no idea what it is yet - hopefully none of our private keys

I just stream the serialized data of the CWalletTx object to CDataStream type of object and then base58 it - and that's the content of the file.

But I noticed that usually the file is bigger than you would expect from the actual format of the tx block - it doesn't end at the lock_time but is longer...

I'm trying to figure out what this extra data is.

For example the raw data is something like this (hex dump):
0100000001e09722a04b6d59b796400175a27e176d74c961dfdcf62977b0
cbb71f3b2fd298010000008c493046022100848d897094aab29d1e105fa7
5eacf05555aacc8e5549bbf589aa782d45ec9c67022100accc37c07b4eb5
b9cb51399316c27627553508080683d11ea0feae91c3d8ee1d0141047563
e0e76cfc078a6b17e7200055600fa4d582abc668faf0bfc9c81e0ab69adf
e6be15ee1836a051f2267663a04e7ac3a5d7e91563b716160a930b056f88
20e9ffffffff02c0ea3cb8000000001976a91438f5e3d8482464cf4e28ff
65c9eeeff649b4af0588ac40420f00000000001976a9148278277b7bec93
a2c3105dfc728095a1fe59e92788ac0000000046872868790906ace71712
65e7527ab687426e29d8e89796ba01000000000000079b86811375cb41c4
9d5ab0af6875e9a871bad066113e0e884066c4a47ebda0619a5c700c685f
3bb03d82ac326cbd18c4a30b0de4f8ef3337429afb691607cecc267c5815
d47389a19e006a591f24c9a00f7c006f952524b863a37ec4c53092a6c3ba
812604ca430d86aa05ccff9cd0d93ad6d2322d4f5949effdadf417e9e1d0
e32a329d6d49c44291c28a9a633bd3220782a7a54ed218a9a465bdbdcf1a
73269306ddeba86fde2d56a3350c9a65487031fb7f9abf8577e7bc215f76
d867466a5e673fc8e147c079d959f1e106f571e51462cb4b80ea61c39340
665ef2cddf1b0200000000020b66726f6d6163636f756e7400057370656e
740230310000000000cf4e1c4e0001

... while I would expect the transaction data to only be the blue part. So what is this red stuff at the end? I have no idea, but I'm going to find it out.

Thanks - I actually appreciate positive feedback more than donations.
So try it and then let me know if you liked it.
But don't trust me - review the changes, they are not big.

I posted my address before, but will put it into my signature.

Today I improved the GUI a bit. Now it isn't a hack anymore, but a proper user interface.

To export a transaction made in an offline client, you double click on it in the main window.
When the transaction info pops up there will be the additional button "Export".
After clicking the button a "Save File" dialog will open - specify the folder where you want to save the transaction file (USB disk, I assume, unless you still use floppies )




For importing there is a new menu option Settings/Import transaction...
After choosing it "Open File" dialog will show up, so point it to the file you created before.



Moreover, if you try to re-import a transaction that already got into the blockchain, you will be notified (so you know you don't really need to do it).




It actually works quite nice. At least as far as I could test it.
So I committed it to the same branch.
https://github.com/piotrnar/bitcoin-impexptx


I figured that you could also use this functionality not necessarily for security reasons, but also for convenience.
For instance you make an appointment with someone to sell him bitcoins for cash.
He gives you his bitcoin address in advance, you backup your wallet, make the send transaction (just make sure to do it offline!!!) and export it into a file.
The next day you go to his house, he gives you the cash and you give him the file.
He imports the file into his client, you wait together for 2 blocks or so (suggest a bier during this time) to make sure that the transaction gets validated... and viola! You gave him bitcoins and didn't even need to bring your wallet along (except for the one to store the cash you got).
And if the transaction doesn't happen (because you realized that the guy wanted to screw you over) you just destroy the file and recover the backup of the wallet.
This way you can sell your bitcoins without even having access to internet

That would indeed be a better option, rather than fetching data from Block Explorer.

Got it - cheers!

I think the only thing that is worth merging ATM is the export part - it doesn't hurt and can be useful.
Import, as I said, is just not reliable and shouldn't get released in this form... Maybe after we make it reliable, so importing once would be enough.

The rest of the output of gettransaction is just useless for this.
Of course you can move everything to your online PC, but importing of the transaction will only use the rawdata anyway.
So why don't you just give it the rawdata only and spare the JSON-parsing part.

From the user's point of view, there will be a webform, textarea where he puts the raw tansaction data, clinks "Send" and that should do all the job he needs.

What happens inside?
There is a simple PHP script that stores the given rawdata in an SQL table.
The table has at least 3 columns:
1) rawdata
2) trid (will be returned by a first call to "importtransaction")
3) timestamp (when the last import was issued for this transaction)

In the background you have a cron function that kicks in every minute or so.
It looks into the SQL table and:
1) Immediately calls "importtransaction" for any transaction that has not been imported yet - sets trid and timestamp accordingly.
2) Checks http://blockexplorer.com/tx/XXXX to verify if any of the transactions imported before are already confirmed - if so: remove it from the table.
3) If a last time of a transaction is more than 30 minutes (and it is still in the table) - call "importtransaction" with it again, updating the timestamp  to the current time.

That's it - in reality its easier to implement than it sounds.

What you need is PHP, SQL and a running bitcoin server with the "importtransaction" patch.
But it doesn't need to be a secured node, because it does not store any money, only injects transactions into the network.

You could also think of making a simple command line tool that would connect to an existing bitcoin node (no need for "importtransaction" patch) and just announce the transaction using the standard bitcoin protocol. But I'm not sure how complex this solution would be, is there some handshake or something...

I'm glad you like it.

Yes, the UI method is a bit of a hack, but since I was expecting trust issues here I though it would be better to change as little as possible.
But if you like it I will add buttons - should be fun.

Maybe someone would like to setup a web service where you can paste a raw transaction to announce it into the bitcoin network.
That would be a nice thing and not really hard to implement - then the end user only needs the export part (in the offline client).
The service itself could take care of re-broadcasting, i.e. if the transaction does not show up in Block Explorer after some time.
I could create such a service, just don't have a server to run it on.

Sort of.
But you don't really need to "Make offline payment"
You just do a traditional payment, but since the client is disconnected from the network you need to transfer its content by other means, not via a network.
And then "Publish offline payment" - sound like a catchy term

I have added it to my client - no problem to export a transaction, but importing it into an online node is a bit tricky...

From what I see the node does not re-broadcast transactions which do not originate from its own wallet.
So the transaction gets broadcasted once (while you're importing it), but then never re-broadcasted.

The good thing is that you can always import the same transaction again to get it re-broadcasted (if you see that it hasn't been noted by the network). But this is obviously not a user friendly solution so I'm not pushing this.
I'm thinking how to improve it, but it seems that making it robust would require lots of changes all around the source code.
Any ideas welcome.


Anyway, if anyone needs such a function, the patch is ready.
Except the issues I've mentioned, it seems to do the job well - as for me the security it gives me is worth the additional hassle.
And the changes are quite simple, very easy to review.
Depending if you prefer RPC or UI - you need to modify one of the cpp files.
If you plan to use only the UI method you don't need to patch the rpc.cpp file - and vice versa.
https://github.com/piotrnar/bitcoin-impexptx


Just a quick manual.

So after you sent some coins using the standard interface in your offline client you need to export the transaction from here and import it into an online client.
You can choose one of the two methods:

1. The UI method.
Double click on the sent transaction which you want to export, the popup opens and the raw transaction data (base58 encoded) gets copied to your clipboard. Just close the popup - the data will be in Clipboard.
So you need to transfer the content of the clipboard to the online PC, then click on "Send Coins" and paste the raw transaction data into the "Pay To" field. Leave the amount empty and click "Send".

2. The RPC method.
"gettransaction" returns now an additional field "rawdata" - the value of this field is what you need to move to the online PC. It is of course the same value that would get copied to Clipboard if using the UI method.
In the online PC there is a new API command "importtransacion" - execute it with only one parameter, which is the "rawdata" value returned by "gettransaction" in the offline PC.

In both cases every time you re-import, the transaction should get re-broadcasted.
So you should definitely redo it if you see that it hasn't been confirmed after a few blocks.

The "rawdata" string is just a base58 encoded binary dump of the transaction (from "version" to "lock time" - both inclusive).

That's it - have fun

ok, I'll take it. unless someone familiar with the code will get there sooner

that would work.
but import/export of a private key seems equally complicated

How about that, it got confirmed after all!  
Thanks for your answers, guys - now I see that its possible.

@gmaxwell, the original software indeed wasn't letting me to make that transaction without a fee.
So I had to force it, by some means...

that's ok, it was just a tiny amount - probably too tiny

Thanks for the answer.
This saves me a lot of waiting for something that would never happen

Thanks, that's what I was thinking of if I eventually have no other choice.
But there must be a way... this system is not that complex. Since I'm not in a hurry here I'd rather prefer to create such a patch myself, instead of stressing myself in an online mode.
Just checking if maybe it's just unnecessary.

I got paranoid and I moved my savings wallet to a separate PC that has a bitcoin client (so I can check my account's balance), but is never to be connected to the network. I just bring the blockchain there on a flash disk and use the client with the -rescan switch.
But this is more of a read-only mode, just to check my balance.
Money is nothing if you cannot spend it.
So since I am already so paranoid, I am wondering now: how am I going to spend that money without connecting my wallet to the internet?

Has anyone created a way to export a signed transaction from an offline bitcoin client into a file, and then import this transaction into an online client (obviously without the wallet), so it would get broadcasted to the network?

Is there any patch/forked source tree, which does that?
I can deal with the source code - no problem.
Just don't want o re-invent the wheel, if someone has done it already.

EDIT:
If you want to try this patch: https://github.com/piotrnar/bitcoin-impexptx
How to use it: https://bitcointalk.org/index.php?topic=28278.msg383312#msg383312