Topic: Is there an import/export transaction patch? (Read 7098 times)

This is exactly why I made the following charts:
    https://bitcointalksearch.org/topic/on-the-wire-byte-map-opchecksig-diagram-knowledge-donation-29416

The address construction process is illustrated at the bottom.  Tx-serialization at the top.  And when you're finally an expert at those, you can take a shot at OP_CHECKSIG (don't forget to reverse endian before signing!).  Yeah, this stuff is complicated, but it's really a one-time investment.  I printed out a couple of these diagrams and keep them nearby when coding...

I have it ported into 0.4.0, but havent tried the qt version yet.

The patch is quite simple - any developer should be able to deal with it.

Can we get this rebased for the Qt codebase?

Just a thought.  Someone could make a public website for posting text based offline transactions.  Kinda a transaction "drop box".  The website would have bitcoind running and would import transactions and broadcast them to the rest of the bitcoind network.

So you make an offline transaction, save it as a text string to usb drive and then can copy & paste it into a website from any computer connected to internet.

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

http://pastebin.com/t7FyrPQp

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

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.

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

Thanks - I'll try that

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

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 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!

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.

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

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.

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

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.

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

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.

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?