Is there an import/export transaction patch?

[Alex Beckenham]

Cool, can't wait to try this

[1714897383]

1714897383

[1714897383]

1714897383

[1714897383]

1714897383

[riush]

Yay! There is also a patch for a 'getrawtransaction' command which can be used to check for confirmations, instead of blockexplorer.
https://github.com/forrestv/bitcoin/tree/getrawtransaction

[piotr_n]

Yay! There is also a patch for a 'getrawtransaction' command which can be used to check for confirmations, instead of blockexplorer.
https://github.com/forrestv/bitcoin/tree/getrawtransaction

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

[piotr_n]

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

[SgtSpike]

This is EXCELLENT (though I haven't actually tried it yet)!  I will definitely be making use of this.  Where can I send a donation? 

[piotr_n]

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.

[Alex Beckenham]

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.

Thanks heaps, I'll be sending you a coin too (once my client is connected next).

[riush]

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

Bravo! This looks really great now. Unfortunately I still can't figure out my problem with wx, so I couldn't test it yet

However, I have added support for importing and rebroadcasting into webtc:
https://forum.bitcoin.org/index.php?topic=12403.msg384505#msg384505

I'm assuming the file that is written contains just exactly the rawdata, no more no less.

[sacarlson]

This looks like a very good idea to me.  I've added this to the list of things to be added to MultiCoin so that your features can be used on many other crypto chains including namecoin, weeds, beer, and others that don't even exist yet.  For more details about MultiCoin see http://forum.bitcoin.org/index.php?topic=24209.msg300830#msg300830

[piotr_n]

I'm assuming the file that is written contains just exactly the rawdata, no more no less.

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.

[piotr_n]

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.

[piotr_n]

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?

[piotr_n]

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..."

[jago25_98]

Nice work, so the thing we want eventually is an "Make offline payment" (aka export the transaction), then on another wallet/client "Publish offline payment" (aka import transaction and rebroadcast)

This is very handy. I'd love to see it in the mobile client or perhaps even a standalone client that works on a provided wallet.dat , ability to send by bluetooth and SMS

[piotr_n]

After all I must say I've been using this fork with my offline wallet and so far it was working pretty well.
I didn't need to re-import a transaction even once.

If anyone wants I also made a simple tool for myself that dumps the content of the transaction file.
http://pastebin.com/jyBG3SUj
(use it only with files you made yourself!)

Though, I did not know how to show the destination addresses so it's probably not so much useful
Any hint about that welcome.

[John Tobey]

If anyone wants I also made a simple tool for myself that dumps the content of the transaction file.
http://pastebin.com/jyBG3SUj
(use it only with files you made yourself!)

Though, I did not know how to show the destination addresses so it's probably not so much useful
Any hint about that welcome.

Hint: you will need the SHA256 hash function and bigints for base-58 encoding, so it will complicate your nice little C program a bit.    The OpenSSL library provides both.

Line 86: doczytaj(buf, sl);

(I guess "doczytaj" means "discard".)  If those discarded bytes are

Code:

76 a9 14 {20 bytes} 88 ac

then you have a standard script, and the bitcoin address is found by this function where those {20 bytes} are the "RIPEMD-160(SHA-256(public key))" part.

Thanks for the nice work, I look forward to trying it!

[piotr_n]

Thanks - I'll try that

"doczytaj" means something like "read it up"
(it's in polish)

[piotr_n]

Thanks - I'll try that

Or maybe I won't... :|

I know exactly which 20 bytes you mean, I could probably handle some simple crypto myslef, but my god... version concatenated with the RIPEMD SHA256 of it, then concatenated with 4 bytes of SHA256 of SHA256 of the RIPEMD stuff... just so it could finally be base58 encoded....  

It couldn't be more complicated, could it?

Though, I guess some test vectors with intermediate steps would help me a lot

[John Tobey]

my god... version concatenated with the RIPEMD SHA256 of it, then concatenated with 4 bytes of SHA256 of SHA256 of the RIPEMD stuff... just so it could finally be base58 encoded....  

The 20 bytes are already RIPEMD-of-SHA256ed.  You "just" need a double-SHA256.

It couldn't be more complicated, could it?

It was... shall we say... optimised for time-to-market.  Satoshi had double-SHA256 handy and chose to devote time to other things than perfecting the address format.

[piotr_n]

OK, got it.
It wasn't that hard after all.
Thank you, John!

http://pastebin.com/t7FyrPQp