1 2014-09-24 00:38:14 <sipa> ;;diff
2 2014-09-24 00:38:15 <gribble> 2.9829733124040417E10
3 2014-09-24 00:39:30 <sipa> ;;calc 2.9829733*10**10 * 2**48 / 65535 / 2**64
4 2014-09-24 00:39:31 <gribble> 6.94538191253
5 2014-09-24 01:05:17 <earlz> Is there anything that could've caused a transaction's comment to become associated with the wrong transaction in bitcoin 0.9.1?
6 2014-09-24 01:05:43 <earlz> through the RPC interface
7 2014-09-24 01:06:02 <earlz> The only thing I see in the release notes is some missing locks... could that have caused weird race conditions?
8 2014-09-24 01:27:27 <phantomcircuit> earlz, what?
9 2014-09-24 01:30:53 <earlz> I'm trying to debug an issue. Basically I sent a tx A with comment X. Then, a few days later, I send tx B with comment Y. tx B is then reported as conflicted with A, and A has comment Y, and B has no comment
10 2014-09-24 01:31:23 <phantomcircuit> interesting
11 2014-09-24 01:31:40 <earlz> Could this have been caused by the missing locks in bitcoin 0.9.1?
12 2014-09-24 01:31:48 <phantomcircuit> no idea
13 2014-09-24 01:32:44 <sipa> i believe this is intentional
14 2014-09-24 01:33:31 <phantomcircuit> sipa, iirc gmaxwell & gavin did the tx conflict code
15 2014-09-24 01:33:40 <phantomcircuit> possibly one of them knows if it's intentional
16 2014-09-24 01:33:41 <sipa> wumpus & gavin
17 2014-09-24 01:33:45 <earlz> Like that's by-design that it would swap the comment field?
18 2014-09-24 01:33:47 <phantomcircuit> ah
19 2014-09-24 01:33:55 <sipa> it was added to make sure that when you receive a mutated version of a transaction, it would inherit the comment
20 2014-09-24 01:34:15 <sipa> and other metadata, as otherwise mutation can screw up accounting
21 2014-09-24 01:34:32 <sipa> but perhaps it shouldn't apply when you yourself do the double spending
22 2014-09-24 01:34:39 <sipa> ... how did you even do that?
23 2014-09-24 01:35:53 <sipa> B losing its comment i cannot explain, btw
24 2014-09-24 01:36:02 <earlz> I'm not sure. The wallet was under load and the RPC interface timed out after sending the RPC command for tx B
25 2014-09-24 01:36:38 <phantomcircuit> o.o
26 2014-09-24 01:36:39 <phantomcircuit> wat
27 2014-09-24 01:38:32 <earlz> So can comments for transactions ever be swapped or changed after they are sent, by-design?
28 2014-09-24 01:39:15 <sipa> swapped, no
29 2014-09-24 01:39:18 <sipa> copied, yes
30 2014-09-24 01:39:19 <phantomcircuit> earlz, are you using the comments for anything important?
31 2014-09-24 01:39:52 <earlz> they aren't vitally important, but they serve as a double check for accounting
32 2014-09-24 01:40:59 <phantomcircuit> earlz, so the comment has like an invoice number of something in it?
33 2014-09-24 01:41:05 <phantomcircuit> transfer request id?
34 2014-09-24 01:41:09 <phantomcircuit> something like that
35 2014-09-24 01:42:07 <earlz> yea
36 2014-09-24 01:42:55 <earlz> a unique id to serve as a double check that I don't do a double pay, in case the RPC interface times out or whatever
37 2014-09-24 01:46:27 <phantomcircuit> earlz, how large is your wallet.dat?
38 2014-09-24 01:46:45 <earlz> ugh... it's not small
39 2014-09-24 01:46:45 <phantomcircuit> or actually
40 2014-09-24 01:46:52 <phantomcircuit> im surprised that you're having issues
41 2014-09-24 01:46:58 <phantomcircuit> unless your wallet is truly enormous
42 2014-09-24 01:47:25 <earlz> define enormous lol
43 2014-09-24 01:48:03 <phantomcircuit> earlz, i didn't start to have timeouts until i had 450k outputs in a single wallet.dat
44 2014-09-24 01:49:20 <earlz> hmm.. let me check
45 2014-09-24 01:49:35 <earlz> it's definitely not small, but I'm not sure it's that large
46 2014-09-24 01:49:54 <earlz> I assume it'd depend on resources and such as well though
47 2014-09-24 01:49:58 <phantomcircuit> yes
48 2014-09-24 01:50:11 <phantomcircuit> sipa, actually this reminds me
49 2014-09-24 01:50:22 <phantomcircuit> there isn't really a reasonable way for normal people to deal with this
50 2014-09-24 01:51:00 <phantomcircuit> afaict the only way to deal with an rpc timeout for send calls is to stop bitcoind
51 2014-09-24 01:51:04 <phantomcircuit> restart
52 2014-09-24 01:51:14 <phantomcircuit> and manually verify that no transaction was generated for the call
53 2014-09-24 01:51:26 <earlz> How would you even manually verify?
54 2014-09-24 01:51:48 <phantomcircuit> earlz, check all of the transactions in listtransactions for the payto address
55 2014-09-24 01:51:58 <earlz> sift through the txlist, manually decoding times and all?
56 2014-09-24 01:52:02 <phantomcircuit> compare address/amount tuple
57 2014-09-24 01:52:22 <phantomcircuit> getting that right though is non trivial
58 2014-09-24 01:52:37 <phantomcircuit> i could see screwing it up myself actually
59 2014-09-24 01:53:09 <earlz> not to mention fees, if two payouts to the same address with the same amount are done in a close amount of time etc
60 2014-09-24 01:53:22 <earlz> bitcoind sucks :)
61 2014-09-24 01:54:00 <sipa> the wallet in it absolutely does
62 2014-09-24 01:54:29 <earlz> This was why the comment field was used, to avoid that whole mess... but if comments aren't reliable to not change over time... that doesn't actually help at all
63 2014-09-24 01:54:57 <phantomcircuit> sipa, unfortunately im not sure anybody else has made a better one...
64 2014-09-24 01:55:08 <earlz> So, a transaction comment can be replaced when there is a conflict, correct? Like by-design?
65 2014-09-24 01:55:59 <sipa> phantomcircuit: i think the bitcoind wallet does many things right in terms of best practices, but the implementation sucks
66 2014-09-24 01:56:15 <phantomcircuit> right
67 2014-09-24 01:56:22 <phantomcircuit> im not sure anybody else does it better though
68 2014-09-24 01:56:36 <earlz> The API for it sucks in multi-threaded scenarios... but the bitcoin protocol itself isn't too friendly for that anyway
69 2014-09-24 01:57:05 <phantomcircuit> earlz, give up and put all your rpc calls into a queue
70 2014-09-24 01:57:28 <earlz> But then, if the RPC times out...
71 2014-09-24 01:57:45 <phantomcircuit> you explode everything
72 2014-09-24 01:57:53 <phantomcircuit> which is sadly probably the correct behavior
73 2014-09-24 01:58:07 <phantomcircuit> automatically recoverying from a timeout for the send class of rpc calls is dangerous
74 2014-09-24 01:58:38 <phantomcircuit> earlz, im actually surprised that anybody has a large enough wallet that they're running into those issues
75 2014-09-24 01:58:55 <phantomcircuit> i've always had stuff designed that rpc calls failing would result in manual intervention
76 2014-09-24 01:58:56 <earlz> IS there anywhere #bitcoin-dev is logged? I need to pastebin this whole thing heh
77 2014-09-24 01:58:59 <phantomcircuit> and have never actually had to do it
78 2014-09-24 01:59:19 <earlz> And the problem is people mining into the wallet heh
79 2014-09-24 01:59:23 <chaosagent> earlz, you cant copy-paste?
80 2014-09-24 01:59:24 <chaosagent> yeah
81 2014-09-24 01:59:27 <chaosagent> v big wallet
82 2014-09-24 01:59:45 <earlz> irssi through tmux makes thigns slightly less easy... wait actually there should be a log file somewhere
83 2014-09-24 01:59:49 <Luke-Jr> earlz: if you receive with the same address twice, you are doing it wrong and any behaviour is acceptable ;)
84 2014-09-24 01:59:58 <phantomcircuit> earlz, oh i bet you have a ton of those little tiny eligius payouts
85 2014-09-24 02:00:03 <chaosagent> okay ill get you a pastebin
86 2014-09-24 02:00:11 <earlz> nah it's fine.. I got a log
87 2014-09-24 02:00:31 <earlz> er shit
88 2014-09-24 02:00:35 <Luke-Jr> earlz: can you confirm that you have never used importprivatekey?
89 2014-09-24 02:00:39 <earlz> I don't have logging configured eh
90 2014-09-24 02:00:47 <earlz> I can't :/
91 2014-09-24 02:00:57 <chaosagent> http://pastebin.com/GfwHzQb3
92 2014-09-24 02:00:57 <Luke-Jr> or at least that you sent the two transactions from the same computer/walletfile?
93 2014-09-24 02:01:04 <earlz> This is somehwat a second hand account of all this
94 2014-09-24 02:01:43 <wizkid057> tiny eligius payouts?
95 2014-09-24 02:02:07 <Luke-Jr> wizkid057: O.o?
96 2014-09-24 02:02:19 <wizkid057> Luke-Jr: <phantomcircuit> earlz, oh i bet you have a ton of those little tiny eligius payouts
97 2014-09-24 02:02:40 <Luke-Jr> earlz: so⦠same computer for those txs, or different?
98 2014-09-24 02:03:10 <earlz> same computer
99 2014-09-24 02:03:18 <Luke-Jr> earlz: same wallet.dat file?
100 2014-09-24 02:03:22 <wizkid057> Eligius shouldn't payout less than ~0.01 BTC... and 0.001-0.01 BTC manually no more than once per week...
101 2014-09-24 02:03:25 <earlz> There should never be a conflicted transaction at least
102 2014-09-24 02:03:30 <earlz> I'm not sure what lead to it
103 2014-09-24 02:03:58 <Luke-Jr> earlz: same wallet.dat file?
104 2014-09-24 02:04:09 <earlz> I'm not 100% sure.. probably though
105 2014-09-24 02:04:40 <Luke-Jr> you restarted bitcoind between the sends?
106 2014-09-24 02:04:50 <earlz> yea
107 2014-09-24 02:05:32 <Luke-Jr> how much time between?
108 2014-09-24 02:06:12 <earlz> months
109 2014-09-24 02:06:22 <Luke-Jr> hmm
110 2014-09-24 02:06:34 <Luke-Jr> so the first one failed months prior ..?
111 2014-09-24 02:07:51 <earlz> the first one wad fine. the secobnd was conflicted with the first months later
112 2014-09-24 02:08:07 <phantomcircuit> wizkid057, lots of people set those to pay directly to exchange wallets and stuff
113 2014-09-24 02:08:23 <phantomcircuit> so it ends up being spammy... bu tonly in the aggregate
114 2014-09-24 02:12:01 <Luke-Jr> earlz: you mean it confirmedâ
115 2014-09-24 02:14:46 <earlz> Luke-Jr: tx A was sent with comment X. Then, months later, tx B was sent with comment Y. The RPC call timed out while sending. When the daemon was restarted, it was revealed that tx B was conflicted, and it had comment X (instead of Y)
116 2014-09-24 02:15:22 <earlz> Like I said, no idea why the transaction was conflicted and how it was ever constructed
117 2014-09-24 02:23:48 <Luke-Jr> earlz: you did not answer whether tx A confirmed
118 2014-09-24 02:24:39 <dgenr8> earlz: that it the wallet's "syncmetadata" routing "helping you out"
119 2014-09-24 02:24:48 <dgenr8> s/routing/routine/
120 2014-09-24 02:25:54 <earlz> tx A confirmed and was completely normal
121 2014-09-24 02:25:59 <chaosagent> it got orphaned i think
122 2014-09-24 02:26:10 <earlz> er, see also chaosagent lol
123 2014-09-24 02:26:22 <chaosagent> and the comment for tx B is A'
124 2014-09-24 02:26:22 <chaosagent> get conflict with the orphaned tx A
125 2014-09-24 02:26:22 <chaosagent> send tx A with comment A'
126 2014-09-24 02:26:22 <chaosagent> send tx B with comment B'
127 2014-09-24 02:26:22 <chaosagent> tx A gets orphaned
128 2014-09-24 02:26:24 <chaosagent> A was sent 4 months ago
129 2014-09-24 02:26:34 <chaosagent> thats the full story
130 2014-09-24 02:27:00 <Luke-Jr> odd
131 2014-09-24 02:27:23 <dgenr8> by comment do you mean address label?
132 2014-09-24 02:28:58 <chaosagent> no
133 2014-09-24 02:29:06 <chaosagent> its called comment
134 2014-09-24 02:29:12 <chaosagent> its part of the tx
135 2014-09-24 02:29:14 <earlz> No, as in like the third argument to sendtransaction
136 2014-09-24 02:29:17 <chaosagent> yeah
137 2014-09-24 02:29:34 <earlz> er, sendtoaddress
138 2014-09-24 02:30:22 <dgenr8> Did A and B spend at least one of the same coins?
139 2014-09-24 02:32:07 <earlz> Well, A was listed as a conflict for B I think
140 2014-09-24 02:32:09 <dgenr8> that could happen if you used salvagewallet or were working with a copy of the wallet made at some point
141 2014-09-24 02:33:54 <dgenr8> at the time of the txmall worries, a method "syncmetadata" was added to make malleated txes look similar to each other, so it wouldn't matter which one got confirmed
142 2014-09-24 02:34:32 <dgenr8> ...as far as your account(/comment/addresslabel) balances are concerned
143 2014-09-24 02:34:35 <sipa> salvagewallet throws all metadata away
144 2014-09-24 02:34:53 <dgenr8> ah true that
145 2014-09-24 02:38:31 <dgenr8> if B also respent a second tx, clearly B can't be "sync'd" to both accounts
146 2014-09-24 02:39:25 <earlz> what do you mean?
147 2014-09-24 02:40:09 <dgenr8> just digressing on the syncmetadata idea. not in relation to your situation
148 2014-09-24 02:40:25 <dgenr8> somehow your wallet didn't know the coins were already spent
149 2014-09-24 02:42:18 <earlz> Not sure how that wouldhappen though'
150 2014-09-24 02:43:06 <Luke-Jr> chaosagent: comments are not part of the tx itself
151 2014-09-24 02:47:09 <dgenr8> A is not listed "as a conflict of B" (that would be nice). It's just "conflicted"
152 2014-09-24 02:47:25 <earlz> Well, true I suppose
153 2014-09-24 02:47:29 <earlz> let me check
154 2014-09-24 02:48:24 <earlz> Well, it has the "walletconflicts" array
155 2014-09-24 02:48:58 <dgenr8> there you go. just the ui doesn't tell you
156 2014-09-24 02:50:04 <earlz> Well, tx A has a lot of random conflicts, and then for tx B, the only conflict for tx B is tx A
157 2014-09-24 02:51:37 <Luke-Jr> how are you getting random conflictsââ
158 2014-09-24 02:52:01 <dgenr8> sounds like a bunch of txes were created by a wallet that didn't know about A
159 2014-09-24 02:52:11 <earlz> yea
160 2014-09-24 02:52:25 <earlz> there's like 12 conflicts listed for A
161 2014-09-24 02:53:15 <earlz> Maybe there was an orphan or somethign and those were spent before confirmations.. I'm not sure how that happened
162 2014-09-24 02:54:22 <phantomcircuit> earlz, mind if i ask, what is this for?
163 2014-09-24 02:54:43 <earlz> The big problem is that the double-check for double payment failed because tx B had it's comment field set to the same comment as tx A
164 2014-09-24 02:54:49 <earlz> phantomcircuit: I'm not at liberty to say
165 2014-09-24 02:54:58 <Luke-Jr> earlz: that sounds like you used importprivkey or dumpprivkey, both of which are unsafe and dangerous for just this kind of reason
166 2014-09-24 02:55:17 <Luke-Jr> earlz: there's probably a decent chance you've lost bitcoins
167 2014-09-24 02:57:01 <earlz> Well, this wouldn't have been such a problem if the comment field hadn't been copied to tx B
168 2014-09-24 02:57:33 <Luke-Jr> if tx B is conflicted, then it is invalid
169 2014-09-24 02:57:36 <Luke-Jr> no bitcoins were moved
170 2014-09-24 02:57:46 <dgenr8> i take it you have a system built on top of bitcoind "accounts" feature
171 2014-09-24 02:57:53 <earlz> no
172 2014-09-24 02:58:01 <earlz> Only comments is used as a double check
173 2014-09-24 02:58:13 <earlz> it's a really rare thing to ahve happened really
174 2014-09-24 02:58:36 <Luke-Jr> earlz: sounds like user error to me *shrug*
175 2014-09-24 02:59:15 <earlz> The main thing I'm need to know is if the comment field can be relied upon at all to not be changed
176 2014-09-24 02:59:44 <earlz> Because in that case, some rearchitecture is needed
177 2014-09-24 02:59:53 <dgenr8> i could do a patch that fixes syncmetadata to only sync equivalent txes (malleability clones). that would have fixed this. it is currently part of #4570
178 2014-09-24 03:00:18 <Luke-Jr> earlz: in any sane case, that should be correct; but it may be buggy
179 2014-09-24 03:01:18 <earlz> hmmm
180 2014-09-24 03:01:28 <earlz> I assume all bets are off when the RPC timesout anyway
181 2014-09-24 03:19:04 <justanotheruser> what is the best tool/library to create an SPV cclient to connect to full nodes?
182 2014-09-24 06:32:24 <michagogo> justanotheruser: bitcoinj, perhaps?
183 2014-09-24 09:12:01 <aschildbach_> What's up with the merging of 0.9.3? Why is it delayed?
184 2014-09-24 09:12:10 <aschildbach_> 0.9.3 sigs I mean
185 2014-09-24 09:58:58 <Happzz> the fee-calculation algorithm of bitcoin-qt (or another suggested way of calculating the "required" fees) documented anywhere?
186 2014-09-24 10:00:58 <rubensayshi> http://bitcoinfees.com/ + https://en.bitcoin.it/wiki/Transaction_fees + reading the source code ;-)
187 2014-09-24 10:04:53 <Happzz> thanks, rubensayshi
188 2014-09-24 10:05:53 <rubensayshi> after reading the 2 links, reading the source code should make enough sence to have verify you have all the details
189 2014-09-24 10:16:28 <michagogo> aschildbach_: it's delayed because someone hasn't gotten around to pushing the button, I expect
190 2014-09-24 10:19:17 <michagogo> s/'s/ was/
191 2014-09-24 10:29:34 <wumpus> michagogo: his notification was lost, his pull's merged now
192 2014-09-24 10:29:42 <michagogo> yeah, saw that :)
193 2014-09-24 10:44:57 <wumpus> in general there is no excuse to delay merging gitian sigs, the only checking I do before merge is that the right file names are added
194 2014-09-24 10:45:08 <wumpus> non-matching sigs is just evidence that something with the build process may be wrong, not areason to not merge them
195 2014-09-24 10:45:20 <wumpus> (but they all match luckily! :-)
196 2014-09-24 10:47:59 <michagogo> wumpus: and even that check, you don't always do :P
197 2014-09-24 10:48:23 <wumpus> michagogo: well I did catch your mistake the second time :)
198 2014-09-24 11:30:40 <aschildbach_> michagogo: I was just asking because all other sigs were merged. I wondered if something was wrong with mine.
199 2014-09-24 13:37:54 <justanotheruser> michagogo: probably. I was looking for something more C(++) based though
200 2014-09-24 14:02:49 <awm> http://fxmf.trusnab.ru/90816/5518039/
201 2014-09-24 14:04:57 <firelegend> awm:And that would be?
202 2014-09-24 15:42:09 <willermo> hello folks, i need a help, with bitcoinj how can i find the value for every vin within a transaction ??
203 2014-09-24 15:44:21 <sipa> you can't - either look up the former transactions whose outouts are beung spent, or require senders to give those
204 2014-09-24 15:47:54 <willermo> sipa: ok thanks!
205 2014-09-24 17:28:27 <Consolero> Good Evening everybody :)
206 2014-09-24 17:29:37 <Consolero> someone here that could help me out with a, maybe, simple question ont multibit?
207 2014-09-24 17:31:23 <Consolero> is there a way to feed multibit with console-commands, like in the bitcoind/core client?
208 2014-09-24 17:32:15 <sipa> i doubt that
209 2014-09-24 17:34:04 <Consolero> i've read about "walletTool" from Mike Hearn, which was integrated/or not ... but i could'nt find anything
210 2014-09-24 17:34:24 <kgk> wallettool is awesome
211 2014-09-24 17:34:34 <kgk> it's in the tools directory of bitcoinj
212 2014-09-24 17:35:31 <Consolero> so i have to get bitcoinJ running to send commands from WalletTool to Multibit?
213 2014-09-24 17:35:31 <kgk> https://github.com/bitcoinj/bitcoinj/tree/57bec6165baa0af72b21daea9100d330c068d8d7/tools
214 2014-09-24 17:36:28 <kgk> BitcoinJ is a java library. It's used by wallettool. wallettool is a standalone cli application that can be used to create a wallet and interact with the blockchain
215 2014-09-24 17:36:40 <sipa> bitcoinJ is a library - it's not "running", it's just a basis to build tools on top of
216 2014-09-24 17:36:41 <kgk> multibit also uses bitcoinj. but it's unrelated to wallettool
217 2014-09-24 17:36:46 <Consolero> i want to "create" a simple "forward" from incoming txs everytime a wallet is funded
218 2014-09-24 17:37:16 <sipa> that really requires interacting with the wallet, unless you're going to create the wallet manually entirely
219 2014-09-24 17:37:29 <sipa> *create the transactions manually
220 2014-09-24 17:37:54 <Consolero> in another approuich i realized that already...with the coreclient,..but i want/need a lightweight client
221 2014-09-24 17:38:21 <sipa> you'll have to modify multibit for that, i expect - but talk to hearn
222 2014-09-24 17:38:22 <kgk> does it have to be a multibit wallet? You could just use wallettool to create the wallet
223 2014-09-24 17:38:28 <Consolero> i guess, i will check out electrum. they have a console that can be fed
224 2014-09-24 17:38:56 <Consolero> no, im totally open to suggestions. but im not a "pro developer" :P
225 2014-09-24 17:40:26 <Consolero> goal is to have a wallet, that receives funds, just forwards it to another specified address and logs all relevant data (time, amount tx details etc)
226 2014-09-24 17:41:38 <sipa> may i ask why?
227 2014-09-24 17:43:23 <Consolero> i have some frinds, with businesses, that would accept BTC if i manage it for them
228 2014-09-24 17:44:22 <Consolero> in my actual setup that already works perfectly. but if i want to do that for multiple customers
229 2014-09-24 17:46:10 <Consolero> from the start: my actual setup runs on Windows... and i don't get it to manage multiple "wallets" - one runs just fine.
230 2014-09-24 17:47:01 <Consolero> so i decided to setup a linux machine with VMs and host every wallet/friend/client in a seperate instance
231 2014-09-24 17:47:40 <Consolero> but i have troubles to adapt my scripts to work with other wallets, as i lack "bitcoind"
232 2014-09-24 17:48:36 <Consolero> thats why im looking for an lightweight wallet, thats able to receive commands on events
233 2014-09-24 17:49:44 <Consolero> lightweight also because i dont want to have a separate 22GB used on every VM for a full blockchain
234 2014-09-24 17:51:07 <Consolero> any ideas on that?
235 2014-09-24 19:25:48 <Mikw> Hi all, can anybody out there help me figure out why I am getting 'Invalid Signiture' response when pushing my tranaction to the blockchain?
236 2014-09-24 19:27:38 <poutine> can you provide additional details needed to answer this question. Like how you're making the tx, and perhaps the raw tx
237 2014-09-24 19:32:43 <Mikw> ok ill send you the decoded hex tx
238 2014-09-24 19:33:11 <Mikw> { "lock_time":0, "inputs":[ { "prev_out":{ "index":0, "hash":"15da7570a337079f94712fe335746309c4bd327873d9f4607527a70c95f51632" }, "script":"483045022100c042b9b8807062cac6a2b0a3301cbd46f96c99531abfdae8b074679b689c754d022034dc0736ca881e25db7656ecc3e88dd785304f86f759ec8a921e2d4b739fad5c014104643ecd2fb2cd65aab59718eb36458a6388df53d68833bac9fea74b780c243e7d3b694cc81e2bc02
239 2014-09-24 19:33:24 <Mikw> hmm that is not easy to read...
240 2014-09-24 19:33:54 <Mikw> here is the hex-encoded tx
241 2014-09-24 19:33:55 <Mikw> 01000000013216f5950ca7277560f4d9737832bdc409637435e32f71949f0737a37075da15000000008b483045022100c042b9b8807062cac6a2b0a3301cbd46f96c99531abfdae8b074679b689c754d022034dc0736ca881e25db7656ecc3e88dd785304f86f759ec8a921e2d4b739fad5c014104643ecd2fb2cd65aab59718eb36458a6388df53d68833bac9fea74b780c243e7d3b694cc81e2bc02a86fdfff37215c4c66087726652cb61fe8e08112a62a0b429ffffffff0110270000000000001976a9141fbf5e275cddf25e6d07dfebf497df49cd917
242 2014-09-24 19:34:15 <Mikw> you can decode it easily at this address: https://blockchain.info/decode-tx
243 2014-09-24 19:35:12 <Mikw> i am making the transaction using NodeJS and the chain API
244 2014-09-24 19:35:12 <sipa> can you use pastebin or something instead of pasting here?
245 2014-09-24 19:36:54 <Mikw> yes one sec
246 2014-09-24 19:37:55 <Mikw> http://pastebin.com/Ue6MB3xC
247 2014-09-24 19:38:14 <Mikw> Decoded Hex Transaction: http://pastebin.com/Ue6MB3xC
248 2014-09-24 19:38:54 <dhill> encoded?
249 2014-09-24 19:39:38 <poutine> Your pasted raw tx is not valid, can you pastebin the raw hex encoded tx
250 2014-09-24 19:39:50 <poutine> I think it got cut off by your irc client
251 2014-09-24 19:40:04 <sipa> yes that's why i asked
252 2014-09-24 19:40:12 <Mikw> ok sorry one moment
253 2014-09-24 19:40:47 <gmaxwell> IRC cuts off at (IIRC) 510 bytes (not including overhead).
254 2014-09-24 19:40:52 <Mikw> http://pastebin.com/VbD4Ugjv
255 2014-09-24 19:43:05 <poutine> Mikw, This signature is invalid, the HASH160 of your pubkey should result in: 2402997072eeb8f8ab0b079c1f4f8d0d78f541b2, instead it results in 35d88b46d518e9628de2473a1d1eb4e8f5a506f7
256 2014-09-24 19:43:57 <Mikw> My code: http://pastebin.com/u9egi5iH
257 2014-09-24 19:44:12 <Mikw> take a look at my code that is generating this problem
258 2014-09-24 19:44:34 <poutine> You should probably ensure you don't post private keys in the future
259 2014-09-24 19:44:35 <poutine> but checking
260 2014-09-24 19:45:00 <Mikw> i thought about it, and theres only about 30cents on this address
261 2014-09-24 19:45:08 <Mikw> thanks
262 2014-09-24 19:49:07 <Mikw> im unsure about the part where I need to add previous tx hash for the input, do you know of a good way to source the input>
263 2014-09-24 19:49:23 <gmaxwell> Mikw: you seem to be trying to spend 15uiDurmVehWGCefZMiDUUBPvPHiLQHX17 using the key for 14HQSWnC6rh53RjKv6eateDwPCNNq3uvjT.
264 2014-09-24 19:49:43 <gmaxwell> The compressed and uncompressed versions of a point are _different public keys_, which is why the private key encodes which you're using.
265 2014-09-24 19:50:10 <Mikw> what am i supposed to be putting as my input?
266 2014-09-24 19:50:39 <poutine> you have no txouts controlled by that private key Mikw
267 2014-09-24 19:50:45 <poutine> you need the private key for 15uiDurmVehWGCefZMiDUUBPvPHiLQHX17
268 2014-09-24 19:50:58 <poutine> bitcoind dumpprivkey 15uiDurmVehWGCefZMiDUUBPvPHiLQHX17
269 2014-09-24 19:50:59 <Mikw> where does 15uiDurmVehWGCefZMiDUUBPvPHiLQHX17 come from?
270 2014-09-24 19:51:11 <sipa> Mikw: read up about compressed and uncompressed public keys first
271 2014-09-24 19:51:26 <Mikw> ok thanks for the suggestion, will do
272 2014-09-24 19:51:28 <poutine> Mikw, https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
273 2014-09-24 19:52:53 <Mikw> still, how did you get the address 15uiDurmVehWGCefZMiDUUBPvPHiLQHX17
274 2014-09-24 19:52:59 <Mikw> its not from my code
275 2014-09-24 19:53:05 <poutine> that page explains exactly that
276 2014-09-24 19:53:23 <poutine> it is from your code, it's derived from your key
277 2014-09-24 19:54:59 <gmaxwell> it's the address the txout you're trying to spen was paid.
278 2014-09-24 19:55:07 <gmaxwell> bitcoin-cli gettxout 15da7570a337079f94712fe335746309c4bd327873d9f4607527a70c95f51632 0
279 2014-09-24 19:55:16 <gmaxwell> ...
280 2014-09-24 19:55:17 <gmaxwell> "15uiDurmVehWGCefZMiDUUBPvPHiLQHX17"
281 2014-09-24 19:55:33 <gmaxwell> which also happens to be a different key which is _related_ to your private key.
282 2014-09-24 19:57:01 <Mikw> so you are saying that I can generate the uncompressed public key from the private key?
283 2014-09-24 19:57:25 <sipa> the private key has a marker saying whether its associated public key is to be compressed or not
284 2014-09-24 19:57:41 <sipa> presumably the software you used doesn't deal with it correctly
285 2014-09-24 19:58:00 <sipa> so you have coins sent to the compressed pubkey, but trying to spend it using the uncompressed pubkey
286 2014-09-24 19:58:03 <sipa> or the other way around
287 2014-09-24 20:00:03 <Mikw> i used brainwallet to generate these keys
288 2014-09-24 20:00:29 <Mikw> or atually no, I think i used blockcypher API
289 2014-09-24 20:01:40 <sipa> how did you generate the 5xxxx private key?
290 2014-09-24 20:03:44 <Mikw> call to the blockcypher API for a random address.
291 2014-09-24 20:03:56 <sipa> i have never heard about this, sorry
292 2014-09-24 20:04:13 <sipa> i would suggest not using random APIs for private keys...
293 2014-09-24 20:04:14 <Mikw> they return hex encoded public key, private key, and address
294 2014-09-24 20:04:26 <Mikw> how would you do this instead?
295 2014-09-24 20:04:26 <sipa> private keys in hex or in WIP?
296 2014-09-24 20:04:37 <sipa> use actual software yourself? like a wallet?
297 2014-09-24 20:04:43 <Mikw> sorry I think they are in WIP
298 2014-09-24 20:04:55 <sipa> then that API is broken
299 2014-09-24 20:05:29 <sipa> nor should you _ever_ use remote code to generate private keys
300 2014-09-24 20:05:33 <Mikw> sorry for being confusion, I am a student at a coding bootcamp with like 2 months of programming experience. Im kind of regretting choosing a bitcoin project as my first project...
301 2014-09-24 20:06:42 <sipa> do you see the problem with some remote party knowing what your private key is?
302 2014-09-24 20:07:21 <Mikw> yes, if they were recording them, they could just take my bitcoins at a moments notice
303 2014-09-24 20:07:29 <sipa> ok
304 2014-09-24 20:07:31 <sipa> don't do that
305 2014-09-24 20:07:48 <sipa> just a suggestion for the future :)
306 2014-09-24 20:08:25 <sipa> even if it's for a tiny amount, you'll need to figure out how to do it safely later anyway
307 2014-09-24 20:09:38 <Mikw> ha I really appeciate your advice
308 2014-09-24 20:09:53 <Mikw> http://pastebin.com/s8grP105 --> my code for getting btc addresses
309 2014-09-24 20:10:31 <Mikw> how would you securely generate addresses?
310 2014-09-24 20:10:44 <sipa> use any local bitcoin client
311 2014-09-24 20:10:57 <Mikw> such as?
312 2014-09-24 20:11:16 <Mikw> I need them generated automatically when user presses a button
313 2014-09-24 20:11:17 <sipa> bitcoind, bitcoinj, electrum, python-bitcoin, ....
314 2014-09-24 20:11:41 <sipa> if necessary, generate a 1000 in advance rather than doing it on the fly
315 2014-09-24 20:12:37 <Mikw> do you think that is how blockchain does it?
316 2014-09-24 20:12:47 <sipa> do not imitate blockchain.info
317 2014-09-24 20:13:23 <sipa> (and don't confuse blockchain.info with blockchain)
318 2014-09-24 20:14:17 <Mikw> ok, my bad
319 2014-09-24 20:14:24 <Mikw> why not imitate them
320 2014-09-24 20:14:51 <sipa> they often show wrong information, which takes weeks to fix
321 2014-09-24 20:15:40 <sipa> hosting a webwallet on itself is not really a good idea (as opposed to encouraging people to run wallets locally), doing it on the same site makes it vulnerable to much more attacks
322 2014-09-24 20:16:18 <sipa> systemic risk (what if the site goes down... many people can't access their money)
323 2014-09-24 20:16:50 <sipa> the site shows things in a confusing way (making it look like internally addresses have balances)
324 2014-09-24 20:17:55 <sipa> i understand the appeal and convenience of having web-based systems, but you shouldn't expect much appreciation for that model here
325 2014-09-24 20:18:24 <sipa> bitcoin finally makes you able to be in control of your own money... don't just give it away to a site that can do whatever
326 2014-09-24 20:19:40 <Mikw> i hear ya
327 2014-09-24 20:20:01 <Mikw> i am trying to get to that point with my knowledge but it is hard and slow...
328 2014-09-24 20:20:08 <Mikw> im working on it
329 2014-09-24 20:20:11 <sipa> good :)
330 2014-09-24 20:21:28 <Mikw> do you use the BitcoinJS
331 2014-09-24 20:21:32 <Mikw> library that is
332 2014-09-24 20:21:47 <sipa> i don't even know javascript
333 2014-09-24 20:22:18 <Mikw> i know almost nothing but JS
334 2014-09-24 20:22:57 <sipa> you'r eprobably better off in #bitcoin for general bitcoin stuff
335 2014-09-24 20:23:11 <sipa> if you have specific technical question, they're welcome here
336 2014-09-24 20:23:40 <Mikw> tx.addInput(whatDoIPutHere, 0)
337 2014-09-24 20:24:25 <sipa> I don't know. Look up BitcoinJS's documentation. If there is none, ask someone who knows. If you can't find that, use some other library :)
338 2014-09-24 20:24:33 <Mikw> they say I need a previous transaction hash, I assume this is different than a uncompressed public key
339 2014-09-24 20:24:40 <sipa> yes
340 2014-09-24 20:24:47 <sipa> sorry, this is too basic for this channel
341 2014-09-24 20:24:56 <sipa> please learn about bitcoin's data structures first
342 2014-09-24 20:25:19 <sipa> start here: https://bitcoin.org/en/developer-documentation
343 2014-09-24 20:28:01 <Mikw> ok, I appreciate that. My project is due in 2 days...
344 2014-09-24 20:28:10 <Mikw> you have helped me though
345 2014-09-24 20:28:14 <Mikw> thank you
346 2014-09-24 20:28:18 <sipa> yw
347 2014-09-24 20:33:18 <Luke-Jr> blockchain.info *constantly* shows misinformation which they never fix..
348 2014-09-24 20:36:03 <Eliel> they keep listing certain transactions as unconfirmed, even though they do show continuation transactions as confirmed :P
349 2014-09-24 20:36:49 <Eliel> I had a wtf moment with that until I realized it's just blockchain.info royally malfunctioning.
350 2014-09-24 20:41:29 <paveljanik> did you told them? ;-)
351 2014-09-24 20:41:42 <paveljanik> no one is doing so and they think they are the best 8)
352 2014-09-24 20:48:15 <Eliel> well, my experience with emailing them in the past leads me to expect nothing to change if I tell them :P
353 2014-09-24 21:45:02 <Mikw> hello all, is anyone familiar with the BitcoinJS library?
354 2014-09-24 21:56:48 <Mikw> hello all, is anyone familiar with the BitcoinJS library? If so, please message me.
355 2014-09-24 22:42:39 <SomeoneWeird> Mikw: still
356 2014-09-24 22:42:41 <SomeoneWeird> Er
357 2014-09-24 22:42:52 <SomeoneWeird> #bitcoinjs-dev
358 2014-09-24 23:51:24 <bassguitarman> What does ACK mean
359 2014-09-24 23:52:48 <belcher> acknowledge