1 2013-11-23 00:57:18 <Apocalyptic> hey
 2 2013-11-23 00:57:41 <Apocalyptic> why does signrawtransaction require the txid of the input the transaction is spending ?
 3 2013-11-23 00:58:08 <Apocalyptic> This information is already embedded in the raw tx we pass
 4 2013-11-23 01:00:26 <phantomcircuit> Apocalyptic, https://en.bitcoin.it/wiki/Raw_Transactions#signrawtransaction_.3Chex_string.3E_.5B.7B.22txid.22:txid.2C.22vout.22:n.2C.22scriptPubKey.22:hex.7D.2C....5D_.5B.3Cprivatekey1.3E.2C....5D_.5Bsighash.3D.22ALL.22.5D
 5 2013-11-23 01:19:16 <Apocalyptic> phantomcircuit, thank you but i find it unclear
 6 2013-11-23 01:19:21 <Apocalyptic> especially the "The optional second argument is an array of parent transaction outputs, so you can create a chain of raw transactions that depend on each other before sending them to the network"
 7 2013-11-23 01:19:54 <phantomcircuit> Apocalyptic, it's optional
 8 2013-11-23 01:20:14 <phantomcircuit> if you dont supply it the txid you're spending wont exist
 9 2013-11-23 01:20:19 <phantomcircuit> and it will be rejected as invalid
10 2013-11-23 01:20:48 <Apocalyptic> so it's not **really** optional, is it ?
11 2013-11-23 01:21:25 <phantomcircuit> Apocalyptic, it's optional if you want to chain transactions together
12 2013-11-23 01:21:28 <phantomcircuit> otherwise it's optional
13 2013-11-23 01:21:54 <Apocalyptic> you mean otherwise it's not
14 2013-11-23 01:21:58 <Apocalyptic> ok, I think i get it
15 2013-11-23 01:23:18 <Apocalyptic> my goal is to sign transactions and to broadcast them later, but I still don't know why I have to provide the txid once again
16 2013-11-23 01:26:21 <Apocalyptic> and the same goes for "scriptPubKey", I already have this info when I do decoderawtransaction
17 2013-11-23 01:27:09 <phantomcircuit> Apocalyptic, you dont unless you're doing what it says you would need to provide it for
18 2013-11-23 01:27:12 <phantomcircuit> which i assume you're not
19 2013-11-23 01:29:57 <Apocalyptic> when I only provide the first argument (the raw tx), it returns it and complete is false
20 2013-11-23 01:30:52 <Apocalyptic> so i guess not much signing has happened
21 2013-11-23 01:35:53 <Apocalyptic> Oh it got it, the scriptPubKey to provide is the one of the output i'm using as the input in this tx
22 2013-11-23 01:36:02 <Apocalyptic> so it's definitely needed
23 2013-11-23 01:36:13 <kjj> yes
24 2013-11-23 01:36:30 <Apocalyptic> <phantomcircuit> which i assume you're not // well i want this to be a valid tx to broadcast, so I do
25 2013-11-23 01:37:59 <kjj> imagine that you are making two transactions, starting with UTXO A.  newtxB is A->B, and newtxC is B->C.  You don't need to broadcast newtxB to make C, you can specify the info that will identify it on the command line
26 2013-11-23 01:38:36 <Polyatomic> Can I tell bitcoind to give me a notification when receiving coin ? walletnotify did not seem to work.
27 2013-11-23 01:39:00 <kjj> Polyatomic: it works, but the way it works may not be obvious.  how did you try to do it?
28 2013-11-23 01:41:01 <Polyatomic> added walletnotify when I open bitcoind from a command prompt on Windows OS.
29 2013-11-23 01:42:11 <kjj> ok, never tried it in Windows.  what command is it running?
30 2013-11-23 01:45:37 <Polyatomic> "C:\Program Files (x86)\Bitcoin\daemon\bitcoind.exe" walletnotify
31 2013-11-23 01:45:57 <kjj> walletnotify runs a program when a transaction hits your wallet
32 2013-11-23 01:46:27 <kjj> bitcoind.exe -walletnotify=c:\wn.bat %s
33 2013-11-23 01:46:48 <Apocalyptic> kjj, I think i'm trying to do a much simpler thing here
34 2013-11-23 01:47:04 <Polyatomic> oh , I thought I might get the little balloon in the bottom right corner like when Bitcoin-QT receives.
35 2013-11-23 01:47:14 <kjj> and then wn.bat does something.  the first arg to wn.bat will be the txid
36 2013-11-23 01:47:19 <Apocalyptic> i have a UXTO A, i want to sign A->B
37 2013-11-23 01:47:44 <Apocalyptic> Polyatomic, that's by default
38 2013-11-23 01:48:19 <Apocalyptic> (the balloon thing on receive)
39 2013-11-23 01:49:51 <kjj> if A is already known to the signing node, it should be easy to fetch scriptpubkey and redeemscript from previous RPC calls.  :)
40 2013-11-23 01:50:07 <Apocalyptic> that's the thing, A is not known
41 2013-11-23 01:50:15 <Apocalyptic> it's an offline node
42 2013-11-23 01:50:21 <kjj> then if it isn't known, you need to specify it
43 2013-11-23 01:50:35 <Apocalyptic> yeah i get that
44 2013-11-23 01:51:03 <Apocalyptic> now why do I need to specify the scriptPubKey hex instead of the address ?
45 2013-11-23 01:51:10 <kjj> I think I missed part of your discussion.  what problem are you having?
46 2013-11-23 01:51:54 <kjj> every utxo has a scriptpubkey, but they don't all have an address
47 2013-11-23 01:52:12 <Apocalyptic> point taken
48 2013-11-23 01:52:18 <Apocalyptic> wasn't aware of that
49 2013-11-23 01:52:19 <kjj> and even when there is an address, you can't count on being able to derive the scriptpubkey from it
50 2013-11-23 01:53:03 <Apocalyptic> of course, i don't count on it, it just seem to be needed for the wallet to know which key it has to use to sign it
51 2013-11-23 01:53:33 <kjj> but if you know the previous address, and have a good idea what sorts of tranasctions you are going to be working from, you can derive the most common form and get by with that most of the time
52 2013-11-23 01:54:03 <Apocalyptic> so providing an address or the scriptPubKey does seem equivalent in this case
53 2013-11-23 01:54:10 <kjj> the signing node doesn't need to know the keys either, those can be specified
54 2013-11-23 01:54:27 <Apocalyptic> as a 3rd argument yeah
55 2013-11-23 01:54:55 <gmaxwell> Apocalyptic: but that totally breaks in a multisignature case, for example.. you really don't know the scriptpubkey except by providing it.
56 2013-11-23 01:55:43 <Apocalyptic> alright, i was assuming i deal with a single-sig case