1 2013-11-29 00:00:08 <warren> so this is just equally buggy
  2 2013-11-29 00:00:10 <Luke-Jr> the behaviour didn't change, other than the 10k => 1k
  3 2013-11-29 00:15:55 <diki> i was wondering
  4 2013-11-29 00:16:13 <diki> we won't exceed 4 bytes of varaible length encoding anytime soon, right?
  5 2013-11-29 00:16:20 <diki> *variable
  6 2013-11-29 00:16:40 <warren> petertodd: Luke-Jr: any idea why DEFAULT_BLOCK_PRIORITY_SIZE - 1000 was used?  just arbitrary?
  7 2013-11-29 00:16:41 <lianj> diki: how?
  8 2013-11-29 00:16:47 <diki> how what?
  9 2013-11-29 00:16:58 <edcba> did you calculate the max length ?
 10 2013-11-29 00:17:47 <diki> the max length would be a uint64_t, no?
 11 2013-11-29 00:18:03 <lianj> yes, want to send 4GB+ blocks?
 12 2013-11-29 00:18:55 <diki> No, I was asking if you think that 4 bytes will be enough for a long time, I don't plan on adding support for >4 bytes varint encoding in my blockchain parser
 13 2013-11-29 00:19:19 <diki> well, 5 if you count the first byte
 14 2013-11-29 00:19:23 <diki> but all the same
 15 2013-11-29 00:19:28 <lianj> you think blocks or txs even are ever allowed to be larger than 4 gb
 16 2013-11-29 00:19:44 <diki> No, I am aware of the limitations
 17 2013-11-29 00:35:40 <sipa> lianj, diki: only tx/txin/txout counts are varint coded; block sizes are just uint32's
 18 2013-11-29 00:36:05 <diki> sipa:I think he meant differently when he said blocks.
 19 2013-11-29 00:36:19 <sipa> yes, but that's not relevant
 20 2013-11-29 00:36:21 <diki> You know, 4GB blocks including transactions etc
 21 2013-11-29 00:36:53 <sipa> you'd need over 2^32 txouts before you need larger varint support
 22 2013-11-29 00:37:23 <sipa> which neans at least a block of 36 GB at least
 23 2013-11-29 00:37:40 <lianj> even better :D
 24 2013-11-29 00:41:28 <Auctus> how big is the blockchain with txindex=1 ?
 25 2013-11-29 00:45:52 <gmaxwell> Auctus: txindex=1 adds another ~1.4GiB right now, the blocks directory with it is ~16GiB.
 26 2013-11-29 00:46:20 <Auctus> gmaxwell, you know pretty much everything, don't you? :)
 27 2013-11-29 00:47:09 <sipa> gmaxwell: what do you get when you multiply 6 by 9?
 28 2013-11-29 00:50:54 <gmaxwell> sipa: 42
 29 2013-11-29 00:57:07 <sipa> Auctus: he does indeed know everything...
 30 2013-11-29 01:01:01 <SomeoneWeird> sipa, lol
 31 2013-11-29 01:29:22 <warren> yep... just got a 24KB free tx into the mempool
 32 2013-11-29 01:30:18 <BustyLoli-Chan> is there a way, using bitcoind, to figure out the sending of a transaction on a wallet address?
 33 2013-11-29 01:34:16 <sipa> BustyLoli-Chan: listtransactions rpc?
 34 2013-11-29 01:34:26 <sipa> BustyLoli-Chan: or the -walletnotify option
 35 2013-11-29 01:35:13 <BustyLoli-Chan> list transactions only tells me where I've sent money
 36 2013-11-29 01:35:22 <BustyLoli-Chan> or what address I've recieved money on
 37 2013-11-29 01:35:26 <sipa> yes
 38 2013-11-29 01:35:32 <BustyLoli-Chan> I want to know who sent me the money
 39 2013-11-29 01:35:37 <sipa> you cannot
 40 2013-11-29 01:35:41 <BustyLoli-Chan> what address the money I was sent came from
 41 2013-11-29 01:35:43 <BustyLoli-Chan> why not?
 42 2013-11-29 01:36:00 <sipa> if you need to distinguish senders, give them distinct addresses
 43 2013-11-29 01:36:04 <BustyLoli-Chan> blockchain.info https://blockchain.info/tx/53a1121008bd8ee7f1ca955d390fbc1afeac073e81cf30445602b02c21628e09?show_adv=true tells me the transaction and who sent it
 44 2013-11-29 01:36:10 <BustyLoli-Chan> how did they figure it out?
 45 2013-11-29 01:36:15 <sipa> bitcoin transactions do not have a 'from' address
 46 2013-11-29 01:36:41 <sipa> they have inputs, and each input refers to the output of a previous transaction
 47 2013-11-29 01:36:55 <sipa> those outputs can potentially have identifiable addresses
 48 2013-11-29 01:37:11 <sipa> but that does not tell you send the money, or where you can send it back
 49 2013-11-29 01:37:24 <sipa> only what key previously controlled the funds
 50 2013-11-29 01:37:51 <BustyLoli-Chan> so there is no way to figure out who sent a transaction?
 51 2013-11-29 01:38:06 <sipa> yes, give each sender a different address
 52 2013-11-29 01:38:34 <BustyLoli-Chan> even if I do that how do I send money back to that address?
 53 2013-11-29 01:38:55 <sipa> if you need to send money back, ask senders for a refund address
 54 2013-11-29 01:39:20 <sipa> or, wait until the new upcoming payment protocol takes off
 55 2013-11-29 01:39:36 <sipa> which implicitly creates a refund address for every transaction
 56 2013-11-29 01:39:47 <BustyLoli-Chan> but what about http://diceoncrack.com which is unfortunately down at the moment
 57 2013-11-29 01:39:54 <sipa> and adds it as metadata to the payment
 58 2013-11-29 01:40:04 <BustyLoli-Chan> I sent them money for a bet
 59 2013-11-29 01:40:10 <BustyLoli-Chan> without ever telling them my wallet address
 60 2013-11-29 01:40:20 <BustyLoli-Chan> and when I won they sent me the money
 61 2013-11-29 01:40:40 <sipa> no idea what that is
 62 2013-11-29 01:40:43 <BustyLoli-Chan> also they have static addresses
 63 2013-11-29 01:40:54 <BustyLoli-Chan> which don't seem to change
 64 2013-11-29 01:41:27 <sipa> yes, there are several sites that infer the refund address from the previous outputs consumed in a transaction
 65 2013-11-29 01:41:45 <sipa> that,s a bad practice, as it doesn't work with shared wallets
 66 2013-11-29 01:41:52 <BustyLoli-Chan> so how would I achieve that.....
 67 2013-11-29 01:41:55 <BustyLoli-Chan> I see
 68 2013-11-29 01:42:06 <sipa> and encourages unnecessary address reuse, which is bad for the privacy of the network as a whole
 69 2013-11-29 01:42:46 <BustyLoli-Chan> so then
 70 2013-11-29 01:43:11 <BustyLoli-Chan> how else do I have them enter a wallet address and send me money
 71 2013-11-29 01:43:29 <sipa> ?
 72 2013-11-29 01:43:46 <BustyLoli-Chan> so even if I make a web form
 73 2013-11-29 01:44:07 <BustyLoli-Chan> and tell them to enter their wallet address and then send K amount of money to bet
 74 2013-11-29 01:44:22 <BustyLoli-Chan> how will I know when K amount is recieved from that address?
 75 2013-11-29 01:44:40 <sipa> there is no 'from' address
 76 2013-11-29 01:44:47 <sipa> it does not exist in the protocol
 77 2013-11-29 01:44:59 <BustyLoli-Chan> but people have done it lol
 78 2013-11-29 01:45:10 <BustyLoli-Chan> even if it's bad practice
 79 2013-11-29 01:45:10 <sipa> yes, and it cripples the network
 80 2013-11-29 01:45:17 <BustyLoli-Chan> I would like to replicate this effect
 81 2013-11-29 01:45:33 <sipa> then please don't ask for advise here
 82 2013-11-29 01:45:53 <BustyLoli-Chan> if i can't do it without bad practice
 83 2013-11-29 01:46:02 <BustyLoli-Chan> then how would I do it with the proper practice
 84 2013-11-29 01:46:02 <sipa> you can
 85 2013-11-29 01:46:08 <sipa> and several sites do it right
 86 2013-11-29 01:46:32 <sipa> people visit your site, they enter a refund address
 87 2013-11-29 01:46:37 <BustyLoli-Chan> have them send me money and keep it in an account for them? and then gamble it and ask them where they want me to send it back to?
 88 2013-11-29 01:46:38 <shesek> BustyLoli-Chan, <sipa> yes, give each sender a different address
 89 2013-11-29 01:46:53 <sipa> you give them a fresh bet address associated with their session/refund address
 90 2013-11-29 01:47:07 <shesek> you give them a unique address, and associate that with the user information
 91 2013-11-29 01:47:19 <BustyLoli-Chan> there isn't any use information
 92 2013-11-29 01:47:29 <BustyLoli-Chan> it's suppose to be anonymous
 93 2013-11-29 01:47:33 <BustyLoli-Chan> *user
 94 2013-11-29 01:47:35 <[\\\]> 1) User wants to do a tx.  2) Your system generates a receiving address and you make a note of that. 3) When your system determines a tx with a sufficent number of confirmations from blocks exists, you process it as determine by your system. 4) Go back to 1.
 95 2013-11-29 01:47:37 <sipa> it can be anonymous sessions
 96 2013-11-29 01:47:39 <BustyLoli-Chan> ironically enough
 97 2013-11-29 01:47:48 <sipa> you don't need actual user data
 98 2013-11-29 01:48:09 <sipa> even better, just keep a balance in the session
 99 2013-11-29 01:48:15 <sipa> and give them a cash out button
100 2013-11-29 01:48:56 <BustyLoli-Chan> ^ how do I know when they've actually sent the money
101 2013-11-29 01:49:28 <[\\\]> you query your bitcoind
102 2013-11-29 01:49:35 <[\\\]> or have your bitcoind perform on tx
103 2013-11-29 01:49:50 <[\\\]> you should consult ./bitcoind help
104 2013-11-29 01:50:15 <sipa> or use any of the other wallet implementations that are perhaps easier to use than bitcoind
105 2013-11-29 01:50:21 <[\\\]> or that
106 2013-11-29 01:50:29 <BustyLoli-Chan> I have consulted bitcoind ./help
107 2013-11-29 01:50:34 <[\\\]> I'd say roll your own, but that's probably a bit beyond the current skill set
108 2013-11-29 01:52:49 <BustyLoli-Chan> my biggest concern with this is that my wallet is going to end up a giant nightmare
109 2013-11-29 01:52:59 <BustyLoli-Chan> with 5 billion addresses in it
110 2013-11-29 01:54:38 <tim`> if they're bothering you feel free to send me your bitcoins
111 2013-11-29 01:55:36 <[\\\]> lol
112 2013-11-29 01:56:15 <tim`> BustyLoli-Chan: you aren't the one that runs that loli website are you ?
113 2013-11-29 01:56:29 <BustyLoli-Chan> what loli website?
114 2013-11-29 01:58:04 <tim`> um it was on /r/bitcoin the other day
115 2013-11-29 01:58:22 <BustyLoli-Chan> uh... I guess it depends on what the site had
116 2013-11-29 01:58:36 <tim`> looking for link
117 2013-11-29 01:58:39 <tim`> austin tx based
118 2013-11-29 01:59:40 <BustyLoli-Chan> I'm not texas based... But go on, I'm curious lol
119 2013-11-29 01:59:56 <tim`> hold on im trying to find the link lol
120 2013-11-29 02:01:57 <tim`> http://www.reddit.com/r/Bitcoin/comments/1ril88/just_walked_a_reporter_from_time_magazine_through/
121 2013-11-29 02:02:01 <tim`> lollyphile
122 2013-11-29 02:02:03 <tim`> was the site
123 2013-11-29 02:03:04 <tim`> memorable because i had no idea such things existed until this article
124 2013-11-29 02:03:10 <BustyLoli-Chan> that's not me lol
125 2013-11-29 02:03:18 <BustyLoli-Chan> but this does give me domain name ideas
126 2013-11-29 02:15:11 <tim`> do you run a different store?
127 2013-11-29 02:23:01 <BustyLoli-Chan> no
128 2013-11-29 02:23:08 <BustyLoli-Chan> I'm trying to run a bitcoin RNG casino
129 2013-11-29 02:24:24 <Shishire> Getting some weird, reproducible errors with my bitcoin-qt wallet.dat file.  Is this the place to report them?
130 2013-11-29 02:25:38 <BlueMatt> Shishire: probably on github, but maybe here
131 2013-11-29 02:26:07 <BlueMatt> if you know its a bug -> github, if you think its a bug -> ???, if you dont really think its a bug but arent sure -> here, if you think its not a bug -> #bitcoin
132 2013-11-29 02:27:27 <Shishire> I'm getting an exception and a crash, but it's related to my wallet specifically.  Which is a problem because it's not like I can upload it so someone can take a look at it.
133 2013-11-29 02:33:01 <BlueMatt> is it encrypted/would you upload it to a dev?
134 2013-11-29 02:35:12 <Shishire> BlueMatt, it's temporarily unencrypted while I deal with trying to recover it, and I wouldn't be thrilled with the idea of uploading it to anyone.
135 2013-11-29 02:39:16 <BlueMatt> well, I meant bitcoin-encrypted, but, ok
136 2013-11-29 02:39:34 <BlueMatt> anywhoo...whats the exception?
137 2013-11-29 02:39:39 <BlueMatt> /debug.log
138 2013-11-29 02:40:55 <Shishire> EXCEPTION: St13runtime_error       CWallet::GenerateNewKey() : AddKey failed       C:\Program Files (x86)\Bitcoin\bitcoin-qt.exe in Runaway exception
139 2013-11-29 02:41:35 <phantomcircuit> Shishire, are you out of disk space
140 2013-11-29 02:41:50 <Shishire> Nowhere near.
141 2013-11-29 02:42:08 <Shishire> The file is also not read-only.
142 2013-11-29 02:42:55 <Shishire> And permissions don't appear to be out of whack
143 2013-11-29 02:43:30 <Shishire> Also, at the very end of the debug.log, I've got this: EnvShutdown exception: DB_RUNRECOVERY: Fatal error, run database recovery (-30974)
144 2013-11-29 02:44:12 <Shishire> The rest appears to be recieved getdata lines
145 2013-11-29 03:06:54 <BlueMatt> Shishire: can you run bdb tools on the wallet?
146 2013-11-29 03:09:35 <BustyLoli-Chan> holy crap... I didn't realize "accounts" could have multiple "address"ess....
147 2013-11-29 03:14:42 <phantomcircuit> BustyLoli-Chan, what are you using accounts for?
148 2013-11-29 03:35:30 <BustyLoli-Chan> well since there is no from
149 2013-11-29 03:35:43 <BustyLoli-Chan> everyone suggested I make multiple addresses to receive money from
150 2013-11-29 03:35:58 <BustyLoli-Chan> I'd like to keep all these addresses under one general account
151 2013-11-29 03:36:00 <phantomcircuit> yeah the suggestion is one per transaction
152 2013-11-29 05:00:44 <diki> this isnt funny
153 2013-11-29 05:00:57 <diki> why is my parser detecting more blocks than there are?
154 2013-11-29 05:01:10 <diki> I am currently at over 330k blocks
155 2013-11-29 05:01:23 <diki> Don't tell me it keeps orphans too?
156 2013-11-29 05:05:07 <diki> scratch that
157 2013-11-29 05:05:35 <kjj> yeah, pretty sure there haven't been 60k orphans
158 2013-11-29 05:08:40 <diki> hmm
159 2013-11-29 05:08:45 <phantomcircuit> diki, which parser?
160 2013-11-29 05:08:50 <diki> phantomcircuit:My own.
161 2013-11-29 05:08:58 <phantomcircuit> you're parsing the blk*.dat files?
162 2013-11-29 05:09:03 <diki> yeah
163 2013-11-29 05:09:11 <phantomcircuit> and you're checking for duplicates?
164 2013-11-29 05:09:14 <diki> but it was parsing blk00000.dat up to 400k blocks
165 2013-11-29 05:09:16 <diki> I am not
166 2013-11-29 05:09:17 <phantomcircuit> there could be partial blocks
167 2013-11-29 05:09:24 <phantomcircuit> multiple times
168 2013-11-29 05:09:35 <phantomcircuit> heh
169 2013-11-29 05:09:37 <diki> no wonder my blockchain is 13 gigabytes
170 2013-11-29 05:09:39 <diki> yet people say its 10
171 2013-11-29 05:09:41 <phantomcircuit> sounds like you have a bug more likely
172 2013-11-29 05:09:52 <phantomcircuit> diki, people are lazy and they round
173 2013-11-29 05:09:55 <kjj> did you read the source for the bootstrap file parser?
174 2013-11-29 05:09:57 <phantomcircuit> and/or dont know what it is
175 2013-11-29 05:10:09 <diki> kjj, no I implemented via the protocol specifications
176 2013-11-29 05:10:23 <phantomcircuit> diki, the easiest way is to split the entire file up using the magic value
177 2013-11-29 05:10:31 <phantomcircuit> it's very unlikely to appear in a block on it's own
178 2013-11-29 05:10:50 <diki> I am
179 2013-11-29 05:10:57 <diki> the first thing I do is read the 4 byte magic value
180 2013-11-29 05:11:09 <kjj> no, don't split the file by the magic value
181 2013-11-29 05:11:11 <diki> the program exits if it cant find it
182 2013-11-29 05:11:27 <diki> then split it by what?
183 2013-11-29 05:11:35 <kjj> read the parser in LoadExternalBlockFile in main.cpp
184 2013-11-29 05:11:41 <diki> http://james.lab6.com/2012/01/12/bitcoin-285-bytes-that-changed-the-world/#magicnetworkid
185 2013-11-29 05:11:49 <diki> "Notably, the magic network ID is not part of the block. It is used solely as a delimiter between blocks."
186 2013-11-29 05:12:28 <lianj> magic + length. 8 bytes, then read length which is the payload for the next block. then repeat
187 2013-11-29 05:12:34 <kjj> the correct way is to read the file, and only look for magic when you aren't already in a block
188 2013-11-29 05:12:56 <phantomcircuit> lianj, except the length can be wrong
189 2013-11-29 05:13:05 <phantomcircuit> those files can have partial blocks
190 2013-11-29 05:13:07 <kjj> you also need to verify that each block is valid.  the block files give no promise of validity
191 2013-11-29 05:13:20 <lianj> phantomcircuit: really? never happened for my bootstrap files
192 2013-11-29 05:13:32 <phantomcircuit> lianj, yeah, it's exceptionally unlikely
193 2013-11-29 05:13:35 <phantomcircuit> but it's possible
194 2013-11-29 05:13:36 <diki> my blockchain is from 2011 btw
195 2013-11-29 05:13:55 <kjj> and by valid, I don't mean you need to verify all of the transactions, just check that the length makes sense and the block meets minimum standards
196 2013-11-29 05:13:57 <phantomcircuit> diki, it's also possible that you're the only person to have ever been attacked with a diff=1 fork
197 2013-11-29 05:14:00 <phantomcircuit> but i doubt that
198 2013-11-29 05:14:30 <kjj> I've written a parser for the block files, and it works if you design it right
199 2013-11-29 05:14:46 <diki> kjj:Define "length makes sense"
200 2013-11-29 05:14:53 <kjj> the magic value is allowed to occur within a block
201 2013-11-29 05:15:21 <diki> well, I do believe that if something was wrong the program would quit
202 2013-11-29 05:15:57 <kjj> when we were working on the torrent, greg and I wrote our own parsers and came up with matching hashes for the canonical forms
203 2013-11-29 05:16:47 <diki> http://pastebin.com/YvrjjUC7
204 2013-11-29 05:16:47 <diki> this is the parser if you want to look
205 2013-11-29 05:18:01 <diki> I skip some values btw
206 2013-11-29 05:18:09 <phantomcircuit> kjj, LoadExternalBlockFile is basically doing what i suggested with the additional check of sanity checking the length
207 2013-11-29 05:18:11 <diki> I don't need some data, so I seek a bit forward
208 2013-11-29 05:19:36 <phantomcircuit> it's scanning for the magic value, reading the length value, and then processing it all if 80 <= length <= MAX_BLOCK_SIZE
209 2013-11-29 05:19:40 <diki> It is possible I have a bug, but I am not seeeing anythng
210 2013-11-29 05:20:35 <lianj> phantomcircuit: isn't the format broken then fix the payload length field is can sometimes be wrong. makes no sense
211 2013-11-29 05:20:42 <lianj> s/then/when
212 2013-11-29 05:21:24 <phantomcircuit> lianj, if the length is wrong that block will be rejected since the transactions will be gibberish
213 2013-11-29 05:21:49 <phantomcircuit> it's calling ProcessBlock()
214 2013-11-29 05:22:02 <phantomcircuit> and just ignores errors
215 2013-11-29 05:22:37 <lianj> so you can still do: loop{ m,l = fp.read(8).unpack("II"); payload = fp.read(l) }
216 2013-11-29 05:23:37 <phantomcircuit> the magic value isn't guaranteed to be aligned on an 8 byte boundary
217 2013-11-29 05:23:56 <phantomcircuit> but i guess that it would be very very unlikely not to be
218 2013-11-29 05:23:59 <diki> I think I see the problem
219 2013-11-29 05:24:05 <phantomcircuit> unless you have weird sector sizes or something
220 2013-11-29 05:24:31 <kjj> nothing jumping out as an obvious bug in your parser so far
221 2013-11-29 05:24:50 <lianj> every dat i parsed worked just fine with the loop above, but guess good to know then
222 2013-11-29 05:25:02 <kjj> your varint handling won't cover the 8 byte case that hasn't happened yet (and won't)
223 2013-11-29 05:25:04 <lianj> kjj: only makes my eyes bleed
224 2013-11-29 05:25:25 <diki> kjj:Well I think it didn't detect end of file
225 2013-11-29 05:25:39 <diki> the last 4 bytes in my blk00000.dat file were 0
226 2013-11-29 05:25:48 <diki> so I assumed that the parser would catch it
227 2013-11-29 05:25:58 <diki> will try again to see if it reappears
228 2013-11-29 05:26:12 <phantomcircuit> diki, in general the parser should assume the files are just lots of garbage with some blocks mixed in
229 2013-11-29 05:26:47 <kjj> in practice, my block files were clean as hell.  no garbage, no corrupt blocks, no gaps
230 2013-11-29 05:26:57 <kjj> but yeah, your parser should be defensive
231 2013-11-29 05:36:14 <kjj> since you don't handle eof, my guess is that fread(&magic_bytes) at the top leaves it unchanged
232 2013-11-29 05:37:36 <kjj> ditto all of the other freads into named variables.  most of your blocks are probably clones of the actual last block
233 2013-11-29 05:38:01 <diki> even though they should be "destroyed" on each loop?
234 2013-11-29 05:38:09 <kjj> destroyed?
235 2013-11-29 05:38:46 <kjj> fread copies from the source to the destination.  if the length copied is 0, the destination is unchanged
236 2013-11-29 05:38:54 <diki> http://en.wikipedia.org/wiki/Automatic_variable
237 2013-11-29 05:39:01 <diki> they should be what is known as automatic variables
238 2013-11-29 05:39:10 <diki> unless of course I am missing something
239 2013-11-29 05:39:45 <kjj> if they end up on the stack, the stack is unchanged in each iteration
240 2013-11-29 05:40:20 <phantomcircuit> diki, if you're not initializing them then their initial state is undefined
241 2013-11-29 05:40:40 <phantomcircuit> normally that means they're \x00 in memory because glibc zeros memory (as does the kernel)
242 2013-11-29 05:40:54 <phantomcircuit> however since it's stack memory and you're using exactly the same memory without reallocating
243 2013-11-29 05:41:03 <phantomcircuit> it's going to be initalized to whatever was there before
244 2013-11-29 05:41:09 <diki> alright, recompiled
245 2013-11-29 05:41:12 <diki> lets see if it goes anywhere
246 2013-11-29 05:42:15 <diki> Alright
247 2013-11-29 05:42:16 <diki> works now
248 2013-11-29 05:42:26 <diki> around block 188k it it went to the next file
249 2013-11-29 05:42:32 <kjj> sounds about right
250 2013-11-29 05:43:17 <kjj> woah.  has it really been 13 months since I wrote my parser?
251 2013-11-29 05:43:21 <diki> so can you clarify again what kind of sanity I should do?
252 2013-11-29 05:43:40 <diki> kjj:Are you the guy that claimed that his parser took 90 seconds to parse the blockchain?
253 2013-11-29 05:43:44 <diki> the one on google code?
254 2013-11-29 05:43:47 <kjj> ha!  no
255 2013-11-29 05:44:11 <kjj> mine is written in PHP.  I don't think I can make it through the first file in 50 seconds, much less the busy part later on
256 2013-11-29 05:44:30 <kjj> diki: failing out if you don't find magic should be pretty safe
257 2013-11-29 05:44:49 <diki> but phantomcircuit said something about length checks?
258 2013-11-29 05:45:12 <diki> I am not sure what "80 <= length <= MAX_BLOCK_SIZE" would mean
259 2013-11-29 05:46:35 <kjj> the block can't be shorter than 80 bytes because of the header
260 2013-11-29 05:46:35 <phantomcircuit> diki, the bitcoin client applies a number of tests to identify valid blocks in those files
261 2013-11-29 05:46:43 <phantomcircuit> probably more strenuous tests than you want to do
262 2013-11-29 05:46:48 <kjj> it also can't be longer than the maximum block size, which is 1 MB
263 2013-11-29 05:47:02 <kjj> actually, it might be 1 million bytes.  I should check that
264 2013-11-29 05:47:13 <phantomcircuit> it is 1 million bytes
265 2013-11-29 05:47:29 <kjj> lame
266 2013-11-29 05:48:03 <kjj> I think that means we can narrow down Satoshi's identity to a telecom worker or the employee of a hard drive manufacturer
267 2013-11-29 05:48:44 <phantomcircuit> lol
268 2013-11-29 05:49:09 <kjj> or, I guess Sony, because they came out with the abomination of the 1.44 MB floppy, where absolutely none of the units match up
269 2013-11-29 05:49:24 <null> with black friday coming up... is there a plot that shows time over block size?
270 2013-11-29 05:49:34 <null> more like block size over time
271 2013-11-29 05:49:52 <null> or are we still fine for some time?
272 2013-11-29 05:50:00 <kjj> blockchain.info/charts
273 2013-11-29 05:50:13 <swulf--> network's averaging about 1 tx/sec
274 2013-11-29 05:50:24 <swulf--> iirc, 1mb blocks will get hit with a ~7-8 tx/sec
275 2013-11-29 05:50:38 <kjj> I don't think they have a chart specific to block size
276 2013-11-29 05:51:05 <null> kjj: thanks. unfortunately they screwed up: https://blockchain.info/charts/avg-block-size (see y-tics :)
277 2013-11-29 05:51:10 <kjj> swulf--: that only applies to reasonably efficient blocks
278 2013-11-29 05:51:19 <swulf--> kjj: it's a generalized statement, sure
279 2013-11-29 05:51:59 <kjj> null: 2 week increments on the ticks.  what's the problem?
280 2013-11-29 05:52:15 <null> kjj: the y-axis
281 2013-11-29 05:52:27 <kjj> oh, that's X.
282 2013-11-29 05:52:29 <null> it just says 0. I have no idea where the 1MB limit is and where we currently are :)
283 2013-11-29 05:52:42 <diki> it is sad I cant skip the inputs and outputs
284 2013-11-29 05:52:48 <diki> they make the parser so slow
285 2013-11-29 05:52:49 <kjj> heh.  that's kinda funny
286 2013-11-29 05:53:07 <null> that's what you get for automating everything ;)
287 2013-11-29 05:53:18 <kjj> diki: you skip the length field.  if you read it, you can skip the txlist
288 2013-11-29 05:53:29 <null> well, the CSV file says ~0.1x MB
289 2013-11-29 05:53:34 <null> so I guess we're fine
290 2013-11-29 05:54:03 <kjj> oh, so the scale is accurate-ish?
291 2013-11-29 05:55:35 <diki> I see
292 2013-11-29 05:55:59 <diki> Well actually my goal is given an address, parse the chain and find the utxo
293 2013-11-29 05:56:10 <diki> in fact, I should export the utxos
294 2013-11-29 05:56:23 <kjj> in that case, yeah, you need to parse the txlist
295 2013-11-29 05:56:46 <diki> Sadly, I am not sure how exactly you figure out the "final balance as some call it" of the address
296 2013-11-29 05:57:06 <kjj> diki: the network knows no such concept
297 2013-11-29 05:57:30 <diki> I know, which is why I am wondering what to do.
298 2013-11-29 05:57:59 <kjj> basically, as you parse the transactions, you add all outputs to the UTXO set, then you remove the ones that get redeemed when they get redeemed in a future block
299 2013-11-29 05:58:12 <phantomcircuit> diki, there is no rational way to calculate that other than the total number of UTXO which pay to that address
300 2013-11-29 05:58:23 <kjj> find all of the ones that can be redeemed by a given key, and add them up, that is the balance
301 2013-11-29 05:59:13 <kjj> after you do it once, you really appreciate the node (or some random website) doing it for you
302 2013-11-29 05:59:39 <phantomcircuit> diki, the problem is that people really dont understand change addresses
303 2013-11-29 05:59:54 <diki> phantomcircuit:Well, you can include me too
304 2013-11-29 05:59:55 <phantomcircuit> so it scares them when their "address balance" changes but their bitcoin-qt balance doesn't
305 2013-11-29 06:00:07 <diki> that is to say
306 2013-11-29 06:00:18 <phantomcircuit> maybe the bitcoin-qt client should display the change addresses under the addresses tab
307 2013-11-29 06:00:23 <diki> According to people blockchain.info guesses the change address
308 2013-11-29 06:00:43 <phantomcircuit> diki, it does but it really has no way of knowing which is which
309 2013-11-29 06:00:53 <phantomcircuit> it's literally impossible unless the primary address has already been used
310 2013-11-29 06:00:54 <kjj> the node should not be showing change
311 2013-11-29 06:00:58 <phantomcircuit> and even then it's just a guess
312 2013-11-29 06:01:17 <kjj> the node has two modes, in normal mode, change addresses are abstracted away
313 2013-11-29 06:01:22 <phantomcircuit> kjj, why not? it scares people when they look at bc.i and they see a transfer to an address that's not under addresses
314 2013-11-29 06:01:24 <kjj> in raw mode, you are one your own
315 2013-11-29 06:01:44 <phantomcircuit> it would be really easy to just who change addresses with a label like "change"
316 2013-11-29 06:01:46 <diki> phantomcircuit:Never been scared about that.
317 2013-11-29 06:01:48 <kjj> phantomcircuit: I know they do.  but there is no help for them short of learning how it works
318 2013-11-29 06:02:03 <diki> I mean back when there was no blockchain.info
319 2013-11-29 06:02:10 <diki> we all relied on what the client told us
320 2013-11-29 06:02:16 <phantomcircuit> kjj, i can guarantee you that would help like 99% of them without actually understanding what was going on
321 2013-11-29 06:02:43 <phantomcircuit> i deal with this all the time even with people who understand most of bitcoin stuff
322 2013-11-29 06:03:18 <kjj> a visible change address would not help unless it was blinking red on the transaction itself
323 2013-11-29 06:04:34 <kjj> I really understand the scenario you are talking about.  it comes from metaphor shear between the reference client and the websites
324 2013-11-29 06:05:46 <phantomcircuit> kjj, i know but i think we could significantly reduce the confusion without changing the metaphor
325 2013-11-29 06:05:48 <kjj> the websites are in the wrong, in my opinion.  if blockchain.info wants to be more user friendly, it should put a note on the address page like "Wondering why the balance is zero?  The change ended up in address X or address Y"
326 2013-11-29 06:05:51 <phantomcircuit> by simple displaying the address
327 2013-11-29 06:06:14 <phantomcircuit> kjj, yeah and then they go look for that address in the client and cant find it
328 2013-11-29 06:06:20 <phantomcircuit> (which is what people do now!)
329 2013-11-29 06:06:23 <kjj> if you don't know what a change address is, showing it won't help.  and if you do know what it is, you don't panic wondering why your balance is now zero
330 2013-11-29 06:06:58 <phantomcircuit> kjj, i think it would move the problem from "ZOMG MY BITCOINZ" to "huh that's weird"
331 2013-11-29 06:07:02 <phantomcircuit> which is big
332 2013-11-29 06:07:17 <kjj> the reference client intentionally does not operate at that level by default
333 2013-11-29 06:07:32 <diki> phantomcircuit:I react like that when primedice is down and my balance is gone later on
334 2013-11-29 06:07:43 <phantomcircuit> diki, heh
335 2013-11-29 06:08:14 <diki> phantomcircuit:So what happened with those juicy 511 coins?
336 2013-11-29 06:08:28 <kjj> as far as the user is concerned, the reference client has a balance, and the details of that particular sausage is made is not important
337 2013-11-29 06:08:51 <kjj> er, add "how" in the appropraite place
338 2013-11-29 06:09:19 <phantomcircuit> kjj, i think that's naive in the assumption of how stupid the average user it
339 2013-11-29 06:09:23 <phantomcircuit> s/it/is/
340 2013-11-29 06:09:44 <phantomcircuit> or at least how content they are to just assume everything works perfectly
341 2013-11-29 06:10:23 <kjj> again, the websites are in the wrong for promoting the idea that addresses have balances
342 2013-11-29 06:11:07 <phantomcircuit> kjj, im not sure that "wrong" is exactly the right way of describing it
343 2013-11-29 06:11:39 <phantomcircuit> in many ways it's an abstraction that makes more sense, but it encourages address reuse which makes it less useful
344 2013-11-29 06:12:30 <Belxjander> phantomcircuit: I try to describe the address changing as a "security built-in"...
345 2013-11-29 06:12:53 <phantomcircuit> change absolutely 100% should be paid to a new address
346 2013-11-29 06:13:12 <phantomcircuit> (or even to multiple addresses in binary values above dust to make them harder to trace later)
347 2013-11-29 06:13:14 <diki> kjj:To be honest
348 2013-11-29 06:13:23 <diki> I am with the same mentality that addresses have a balance
349 2013-11-29 06:13:30 <diki> even if it's just utxos and whatnot
350 2013-11-29 06:14:03 <kjj> that's an inaccurate abstraction that causes you lots of pain
351 2013-11-29 06:14:36 <diki> trust me, it would cause me physical pain like a Vulcan's psyche xD
352 2013-11-29 06:14:45 <kjj> bitcoin is a ledger.  each line in the ledger destroys some previous line.
353 2013-11-29 06:14:49 <diki> if I tried to think otherwise
354 2013-11-29 06:15:27 <kjj> block explorers are technical tooks, and can be informative or educational
355 2013-11-29 06:15:31 <kjj> er, tools
356 2013-11-29 06:15:55 <kjj> but for the love of god, people should not be using them track balances of hot wallets
357 2013-11-29 06:44:51 <shesek> namecheap is having a $.98 domain sale for black friday in 15 minutes, if anyone's interested
358 2013-11-29 06:45:20 <shesek> it lasts for an hour, or until 300 are sold
359 2013-11-29 06:45:44 <Dagger2> so, for about 3 seconds then
360 2013-11-29 06:53:02 <shesek> heh, yeah, probably something like that :)
361 2013-11-29 06:53:27 <shesek> I hope to grab a few before they run out... I wonder if they limit the amount per account
362 2013-11-29 07:08:45 <maaku> how do you access the namecheap deal?
363 2013-11-29 07:13:38 <Bituser123> 
ACTION hello

364 2013-11-29 07:14:28 <shesek> maaku, it hasn't started yet for some reason
365 2013-11-29 07:14:50 <shesek> the countdown was at 5 minutes the last time I look at it, and when I got back it reseted back to an hour
366 2013-11-29 07:15:22 <shesek> they have an hourly promotion on their website, it changes to another deal every round hour
367 2013-11-29 07:15:46 <shesek> just go to the homepage, they have a big banner for that promotion
368 2013-11-29 07:16:31 <maaku> their page is getting hit hard.. i can't even get it to load :\
369 2013-11-29 09:00:35 <warren> toffoo: hey
370 2013-11-29 09:00:37 <warren> toffoo: new build
371 2013-11-29 09:00:50 <warren> toffoo: yesterday's build accidentally included the old patch too
372 2013-11-29 09:00:57 <warren> toffoo: https://bitcointalk.org/index.php?topic=337294.msg3718821#msg3718821
373 2013-11-29 09:01:03 <warren> toffoo: how were previous test result?
374 2013-11-29 09:21:34 <warren> we're having trouble finding MacOS testers to confirm the fix and unblock release of 0.8.6
375 2013-11-29 09:22:07 <chmod755> because nobody uses MacOS
376 2013-11-29 09:24:23 <Happzz> is setting a minimum tx fee of 0.00000001 instead of 0 going to do any good?
377 2013-11-29 09:25:42 <tommygunner> the txfee in the options is an optional fee
378 2013-11-29 09:25:46 <corpet> are you dudes getting rich in here?
379 2013-11-29 09:27:45 <toffoo> hi warren,
380 2013-11-29 09:27:46 <maaku> plenty of devs use macos
381 2013-11-29 09:27:54 <maaku> just not able to reliably reproduce this problem
382 2013-11-29 09:28:05 <toffoo> so far all is still fine with -OMG5
383 2013-11-29 09:28:21 <toffoo> I will go install the -OMG6 binary now,
384 2013-11-29 09:28:43 <warren> toffoo: one report of corruption with OMG5
385 2013-11-29 09:28:51 <warren> so a little confused
386 2013-11-29 09:28:56 <toffoo> that's interesting
387 2013-11-29 09:29:08 <tommygunner> i had no corruption for a while with the official client
388 2013-11-29 09:29:17 <tommygunner> then i downloaded OMG and a few days later, corrupted
389 2013-11-29 09:30:01 <toffoo> should I be safe installing -OMG6 right over -OMG5, or will I have to reindex from v0.7.2 again?
390 2013-11-29 09:31:44 <warren> tommygunner: which OMG?
391 2013-11-29 09:31:57 <warren> tommygunner: OMG5 was the first with the corruption fix
392 2013-11-29 09:32:15 <warren> toffoo: if you didn't corrupt just keep going with OMG6
393 2013-11-29 09:32:23 <toffoo> ok sounds good
394 2013-11-29 09:32:47 <tommygunner> i think it was omg3 or something
395 2013-11-29 09:33:05 <warren> tommygunner: OMG3 was the same as 0.8.5, lots of complaints of corruption
396 2013-11-29 09:33:15 <warren> it's random
397 2013-11-29 09:33:22 <warren> some people rarely/never see it
398 2013-11-29 09:33:27 <warren> some peopel see it every day
399 2013-11-29 09:33:44 <tommygunner> i had no problems with the official 0.8.5
400 2013-11-29 09:34:09 <warren> tommygunner: random is random
401 2013-11-29 09:34:19 <warren> tommygunner: one of the reasons 0.8.6 is delayed is to confirm this fix
402 2013-11-29 09:34:26 <warren> tommygunner: if the fix is confirmed, someone wins $20k
403 2013-11-29 09:34:49 <tommygunner> so someone submitted a fix?
404 2013-11-29 09:36:45 <warren> I hate dumb questions.
405 2013-11-29 09:37:07 <tommygunner> :P
406 2013-11-29 09:37:17 <tommygunner> it seems like its still a thing of chance
407 2013-11-29 09:38:08 <warren> You seem to be learning the meaning of random.
408 2013-11-29 09:42:16 <toffoo> warren I think in your OMG6 package you've got the exact same binary as OMG5
409 2013-11-29 09:42:25 <warren> ah crap
410 2013-11-29 09:42:27 <warren> 
ACTION looks

411 2013-11-29 09:42:54 <toffoo> might be getting late wherever you are?  time for a break   ;D
412 2013-11-29 09:44:15 <warren> I hate mac
413 2013-11-29 09:46:35 <warren> rebuilding
414 2013-11-29 09:47:34 <tommygunner> warren: sorry for wisecracking
415 2013-11-29 09:47:50 <tommygunner> but how do you know a random event doesnt occur anymore so you can pay out the bounty
416 2013-11-29 09:48:40 <warren> tommygunner: some users it happened frequently
417 2013-11-29 09:59:16 <warren> After launching a listening bitcoind on an IP address that has never done bitcoin before, how long would you expect it to take to have incoming connections?
418 2013-11-29 10:09:57 <warren> toffoo: http://download1.rpmfusion.org/~warren/bitcoin-0.8.5-OMG6/macosx/
419 2013-11-29 10:11:59 <warren> toffoo: in the future it will be common for mac builds to be uploaded without testing (like this)
420 2013-11-29 10:14:03 <toffoo> ok thanks warren, that was fast, I'll try this one and let you know how it goes.
421 2013-11-29 10:15:00 <warren> toffoo: I think restarting it after every new block might help to test it
422 2013-11-29 10:22:46 <swulf--> is there a convenient way to reduce the bandwidth requirements for bitcoind?
423 2013-11-29 10:23:18 <swulf--> nvm asking google
424 2013-11-29 10:24:34 <warren> swulf--: there's a script in contrib/ somewhere
425 2013-11-29 10:24:41 <warren> swulf--: for linux
426 2013-11-29 10:24:55 <swulf--> ah, thanks
427 2013-11-29 10:33:30 <madthanu> doof says his DB got corrupted after a power trip :/ now feeling bad I hadn't investigated my LevelDB system crash bugs for the bounty ... anyways
428 2013-11-29 10:58:32 <warren> toffoo: you there?
429 2013-11-29 11:03:46 <swulf--> is there something unusual about block 0000000000000006a5243b279078d42fd07aa87b6dd6efe0a37bab28d6c11ba9?
430 2013-11-29 11:12:59 <swulf--> yeah
431 2013-11-29 11:13:11 <swulf--> the inputscript used 0x4c for a piece of data less than 0x4c in size
432 2013-11-29 11:13:16 <swulf--> I suppose that's legal?? :P
433 2013-11-29 11:50:40 <toffoo> warren hi
434 2013-11-29 11:56:55 <warren> toffoo: hi
435 2013-11-29 11:57:12 <warren> toffoo: if you see corruption, save the chainstate/ directory, devs want that
436 2013-11-29 11:57:27 <toffoo> ok sure
437 2013-11-29 11:57:49 <toffoo> -OMG6 working fine so far
438 2013-11-29 11:58:09 <warren> toffoo: start and stop it a lot
439 2013-11-29 11:58:21 <toffoo> ok
440 2013-11-29 11:58:32 <warren> some sleep and wake up too during that
441 2013-11-29 11:58:44 <warren> not really sure what can make the old bug more liikely
442 2013-11-29 11:59:30 <toffoo> it usually happens right before I urgently need to send an important transaction    ;D
443 2013-11-29 11:59:43 <warren> toffoo: then do that =)
444 2013-11-29 11:59:57 <toffoo> hehe ok will do
445 2013-11-29 12:00:33 <toffoo> i tried all that on/off/sleep/reboot stuff with -OMG5 yesterday and couldn't phase it,
446 2013-11-29 12:00:51 <toffoo> I'll be doing the same with -OMG6 now today and will update here if anything interesting happens
447 2013-11-29 12:02:38 <warren> I *think* the main issue was stop and start
448 2013-11-29 12:05:41 <diki> so if the block chain file was mapped to memory(or however much you can afford to map) then would traversing it be faster?
449 2013-11-29 12:06:22 <diki> took me 10-15 minutes for the whole blockchain to be read(counting blocks for instance).
450 2013-11-29 13:01:05 <tommygunner> warren: OMG6 is still named Bitcoin-Qt.app :P
451 2013-11-29 13:01:21 <tommygunner> in case you are looking for another reason to re-do it
452 2013-11-29 13:01:22 <warren> tommygunner: does the about box say OMG6?
453 2013-11-29 13:01:27 <warren> tommygunner: no
454 2013-11-29 13:02:23 <tommygunner> Bitcoin-Qt version v0.8.5-OMG3-beta
455 2013-11-29 13:02:23 <tommygunner> $ Desktop/Bitcoin-Qt\ OMG.app/Contents/MacOS/Bitcoin-Qt --help
456 2013-11-29 13:02:40 <tommygunner> splash screen says OMG6-beta
457 2013-11-29 13:03:20 <tommygunner> time to let it rebuild i guess
458 2013-11-29 13:03:34 <warren> that doesnt look right
459 2013-11-29 13:03:35 <warren> I ran it
460 2013-11-29 13:03:36 <warren> it's fine
461 2013-11-29 13:04:07 <tommygunner> about screen says OMG6 too
462 2013-11-29 13:05:01 <warren> then it's OMG6
463 2013-11-29 13:05:09 <tommygunner> i wasnt questioning that
464 2013-11-29 13:05:25 <warren> 
ACTION sleep

465 2013-11-29 13:05:39 <tommygunner> n8
466 2013-11-29 13:08:10 <serialbandicoot> hi - I'm trying to use bitcoind sendrawtransaction and I get a hash returned, but it's never making it into the block chain. I'm trying on testnet. Has anyone got any suggestions. Please :)
467 2013-11-29 13:11:39 <Happzz> did you broadcast it?
468 2013-11-29 13:14:08 <serialbandicoot> how do you broadcast it? I thought by just running ./bitcoind send raw.. would broadcast it?
469 2013-11-29 13:24:52 <kjj> what's the txid?
470 2013-11-29 13:26:32 <serialbandicoot> ./bitcoind getrawtransaction de8c4a46345faa7e9f74a25ee3420db60aabab12e1316f875706c1dd06ca76c8
471 2013-11-29 13:26:59 <serialbandicoot> so it's entered the men pool
472 2013-11-29 13:29:38 <kjj> none of my nodes have seen it, so it isn't getting relayed
473 2013-11-29 13:29:48 <kjj> how current is your node?
474 2013-11-29 13:29:55 <kjj> (version)
475 2013-11-29 13:29:56 <serialbandicoot> full node
476 2013-11-29 13:30:24 <serialbandicoot> get info show "blocks" : 149332,
477 2013-11-29 13:30:49 <serialbandicoot> "version" : 89900,
478 2013-11-29 13:30:58 <serialbandicoot> build on mac from recent git pull
479 2013-11-29 13:31:49 <kjj> testnet or live?
480 2013-11-29 13:31:54 <serialbandicoot> testnet
481 2013-11-29 13:32:07 <kjj> ahh.  that explains why none of my nodes have seen your tx.  :)
482 2013-11-29 13:32:24 <serialbandicoot> appal - thought i mentioned earlier
483 2013-11-29 13:32:58 <kjj> yeah, you did.  I just didn't read enough of my scrollback
484 2013-11-29 13:33:45 <kjj> to answer your question, in general, sendrawtransaction is what you use to broadcast a completed tx
485 2013-11-29 13:34:24 <kjj> I don't currently have anything on testnet, so I'm not going to be much help diagnosing this specific problem
486 2013-11-29 13:35:15 <serialbandicoot> have you got any suggestions as to how I might be able to investigate myself?
487 2013-11-29 13:36:24 <serialbandicoot> the decoded hex looks fine
488 2013-11-29 13:36:53 <serialbandicoot> is there a way of broadcasting through another methods online perhaps
489 2013-11-29 13:37:14 <serialbandicoot> presumable I don;t need the address/priv etc in my wallet?
490 2013-11-29 13:37:23 <serialbandicoot> As long as the hex as been signed
491 2013-11-29 13:38:24 <Burritoh> serialbandicoot: yes. brainwallet.com/#tx is one. blockchain.info also has one, I'll get you a link.
492 2013-11-29 13:38:41 <swulf--> blockchain.info/pushtx
493 2013-11-29 13:38:44 <kjj> Burritoh: on testnet?
494 2013-11-29 13:38:45 <Burritoh> there
495 2013-11-29 13:38:49 <Burritoh> oh, on testnet, no
496 2013-11-29 13:38:51 <Burritoh> sorry, just joined
497 2013-11-29 13:39:02 <Burritoh> There might be one, I don't know of it.
498 2013-11-29 13:39:13 <serialbandicoot> for testnet
499 2013-11-29 13:40:34 <serialbandicoot> would using a pre-release of bitcoind cause the issue?
500 2013-11-29 13:43:29 <kjj> shouldn't, usually
501 2013-11-29 13:45:38 <kjj> oh, sweet.  the reboot button on the phone system's GUI doesn't ask for confirmation
502 2013-11-29 13:45:47 <serialbandicoot> So if I get a hash back from sendrawtransaction and decoderawtransaction was ok. I'm at a loss as to why it never made it onto the blockchain.
503 2013-11-29 13:45:52 <kjj> anyhow, there can be several reasons a tx doesn't make it into a block
504 2013-11-29 13:46:28 <serialbandicoot> please do tell :)
505 2013-11-29 13:46:34 <kjj> it may not be relayed to a miner.  the miner may not like it.  the miner doesn't think it is important enough
506 2013-11-29 13:47:33 <serialbandicoot> Interesting I put the fee at 0.005
507 2013-11-29 13:47:35 <kjj> if your node is current, it is unlikely that the transaction is invalid because of a spent input
508 2013-11-29 13:48:22 <kjj> as in, if your node is many blocks behind, it may think the transaction is valid because it doesn't know that one of the inputs has been spent in a block it doesn't know about yet
509 2013-11-29 13:48:43 <kjj> I don't use testnet much, so I don't know what tools are available for it
510 2013-11-29 13:49:42 <serialbandicoot> I'm presuming there is some mining on testnet.
511 2013-11-29 13:50:41 <serialbandicoot> If I send from the Bitcoin-Qt it works completely fine. So I'm guessing it was something to do with sendrawtransaction.
512 2013-11-29 13:53:33 <serialbandicoot> So it looks like I'm a little bit stuffed :(
513 2013-11-29 13:53:42 <kjj> hard to diagnose the problem without tools
514 2013-11-29 13:53:54 <kjj> I presume some tools are available, I just don't know them
515 2013-11-29 13:55:37 <serialbandicoot> is there a raw hex verifier?
516 2013-11-29 13:56:15 <kjj> blockchain.info has a tx decoder
517 2013-11-29 13:56:36 <serialbandicoot> :) tried that - all looks sounds.
518 2013-11-29 14:00:49 <swulf--> I've been doing a bunch of multisig and p2sh stuff lately, and one question has been bugging me.. curious if anyone has a good answer: why don't checkmultisig scripts use public key hashes instead of public keys directly?
519 2013-11-29 14:01:12 <serialbandicoot> thank kjj for the help anyway.
520 2013-11-29 14:02:18 <serialbandicoot> I created a question on bit coin.statckexhange see if anyone has any thoughts.
521 2013-11-29 14:04:13 <kjj> in p2sh, the pubkeys are hidden until the transaction is redeemed anyway
522 2013-11-29 14:04:28 <kjj> and the pubkey has to be published to verify the sig
523 2013-11-29 14:08:55 <TD> swulf--: addresses weren't originally intended to be so prominent, in the very first bitcoin release
524 2013-11-29 14:09:07 <TD> swulf--: that's why they don't have any kind of custom script form,even though that'd be more efficient
525 2013-11-29 14:09:09 <TD> etc
526 2013-11-29 14:09:29 <swulf--> TD: really? seems like the market picked a pretty effective choice though
527 2013-11-29 14:09:47 <swulf--> hiding the actual pubkeys has some advantages, no?
528 2013-11-29 14:11:09 <TD> not really?
529 2013-11-29 14:11:20 <TD> i mean, the point of addresses is they're 160 bits so they're short and can be typed by hand
530 2013-11-29 14:11:29 <TD> what's the advantage of hiding the pubkey?
531 2013-11-29 14:11:33 <swulf--> quantum factoring?
532 2013-11-29 14:11:50 <swulf--> i actually thought that was the main point of using hashed pubkeys
533 2013-11-29 14:11:54 <TD> no
534 2013-11-29 14:11:55 <TD> not at all
535 2013-11-29 14:12:07 <swulf--> i mean, it also reduces the data size
536 2013-11-29 14:12:11 <swulf--> which is a positive
537 2013-11-29 14:12:27 <TD> no
538 2013-11-29 14:12:35 <jpentland> Are there any good ongoing hardware-wallet projects at the moment?
539 2013-11-29 14:12:35 <TD> wrong again, sorry ;) it increases total data size in the block chain
540 2013-11-29 14:12:38 <kjj> yes, it is also safer.  and one of the arguments against reusing addresses
541 2013-11-29 14:12:47 <TD> jpentland: trezor?
542 2013-11-29 14:12:57 <swulf--> TD: only because the scriptSig doesn't extract pubkeys from signatures?
543 2013-11-29 14:13:36 <jpentland> TD, looks pretty cool
544 2013-11-29 14:13:53 <swulf--> definitely true that sig+pubkey+pubkeyhash is > sig+pubkey in size; but you can get rid of pubkey and do sig+pubkeyhash.. that would be smaller, no?
545 2013-11-29 14:14:07 <jpentland> I think securely storing bitcoins in a transferrable way really needs to be worked on
546 2013-11-29 14:14:09 <TD> swulf--: right.
547 2013-11-29 14:14:47 <kjj> swulf--: you can't verify the sig without the pubkey
548 2013-11-29 14:15:02 <swulf--> kjj: you can figure out the pubkey from a sig, I believe
549 2013-11-29 14:15:20 <swulf--> (and you can verify the hash of the pubkey)
550 2013-11-29 14:17:11 <kjj> hmm.  yeah, you can figure out the pubkey.  that's odd.  there must be some reason
551 2013-11-29 14:24:16 <TD> it's just the way the equations work out
552 2013-11-29 14:25:38 <kjj> no, I mean a reason why we include it
553 2013-11-29 14:26:00 <TD> because satoshi didn't know about key recovery
554 2013-11-29 14:26:16 <TD> his understanding of ECC wasn't deep. he knew it worked. that's it.
555 2013-11-29 14:26:28 <swulf--> TD: what, you saying Satoshi wasn't an all-knowing genius?
556 2013-11-29 14:26:38 <TD> i believe it was sipa who discovered you could recover the pubkey from the signature (with a couple of disambiguation bits)
557 2013-11-29 14:29:07 <topace> hey question, how can i get the latest block count from the bitcoind daemon itself? not what its synced up to (getblockcount, getinfo, etc)  but the actual height of the chain.
558 2013-11-29 14:29:23 <topace> i know it can do it because bitcoin-qt shows x of y syncing message
559 2013-11-29 14:29:28 <topace> i need to know "y" :)
560 2013-11-29 14:29:41 <kjj> topace: y comes from version messages from peers
561 2013-11-29 14:30:00 <topace> is there an rpc call that can report on that ?
562 2013-11-29 14:30:03 <swulf--> kjj: but peers could lie
563 2013-11-29 14:30:04 <kjj> no
564 2013-11-29 14:30:09 <topace> or do i have to grep the debug log
565 2013-11-29 14:30:17 <kjj> swulf--: exactly
566 2013-11-29 14:30:22 <kjj> topace: actually, getpeerinfo
567 2013-11-29 14:30:42 <topace> so if you trust a peer explicitly, you could rely on their block count?
568 2013-11-29 14:30:45 <kjj> that will show what each peer reported as their top of chain at the time they connected
569 2013-11-29 14:31:16 <kjj> meh.  getting fooled about the chain height isn't a big deal usually
570 2013-11-29 14:32:05 <topace> hmm so that shows their block chain height at the time they connect
571 2013-11-29 14:32:16 <topace> but if bitcoind has been running for a while, those could be well off
572 2013-11-29 14:32:21 <kjj> yup
573 2013-11-29 14:32:34 <Burritoh> Anyone know how Bitcoin-Qt can send an invalid transaction, which then become stuck? All other transactions are confirmed. This is related to a question in #bitcoin.
574 2013-11-29 14:32:40 <Burritoh> Is it just bad luck or something? or a bug?
575 2013-11-29 14:32:41 <kjj> but that is what the UI reports while it is downloading.  the number of blocks between what it knows and the highest value reported by a peer
576 2013-11-29 14:33:06 <kjj> Burritoh: invalid in what way?  and stuck how?
577 2013-11-29 14:33:21 <Burritoh> kjj: doesn't appear on the blockchain, not relayed by nodes, but standard fee paid
578 2013-11-29 14:33:49 <Burritoh> 7e5e70eed73e345bf679686e20a0a828c93b8987ec874112344f2308cc6e8ac0
579 2013-11-29 14:33:56 <Burritoh> ^ is the transaction
580 2013-11-29 14:34:40 <swulf--> I don't have it either
581 2013-11-29 14:34:50 <kjj> none of my nodes know it, nor does blockchain.info
582 2013-11-29 14:35:01 <swulf--> must have been bad and nobody will relay it :)
583 2013-11-29 14:35:04 <Burritoh> kjj: yes, that's the conundrum :<
584 2013-11-29 14:35:15 <swulf--> burritoh: getrawtransaction it and give us the tx
585 2013-11-29 14:35:38 <jpentland> If it was completely invalid would it just be discarded before reaching blockchain/other nodes?
586 2013-11-29 14:35:41 <kjj> I think there is a rounding bug that can make fees slightly too low
587 2013-11-29 14:37:57 <Burritoh> swulf--: in progress, this question is related to another person :)
588 2013-11-29 14:37:59 <TD> Burritoh: verson skew?
589 2013-11-29 14:38:09 <Burritoh> TD: nope, latest debian build
590 2013-11-29 14:38:22 <Burritoh> <bluesceada> help about says: "v0.8.5.0-gef14a26-beta"
591 2013-11-29 14:38:22 <TD> debian sucks, that doesn't mean anything. what *actual* version is it
592 2013-11-29 14:38:27 <TD> ok
593 2013-11-29 14:38:37 <TD> so that's not a debian build, i'd hope? given that it's claiming it's unreleased ...
594 2013-11-29 14:38:50 <swulf--> Ah.
595 2013-11-29 14:38:53 <Burritoh> It's probably from the PPA on Launchpad or something.
596 2013-11-29 14:39:26 <Burritoh> <bluesceada> http://pastebin.com/1v927RpD
597 2013-11-29 14:40:46 <kjj> need the hex, not the decode
598 2013-11-29 14:41:32 <bluesceada> hi, the transaction Burritoh must have posted some minutes ago is from me..
599 2013-11-29 14:42:01 <kjj> bluesceada: need the hex, not the decode
600 2013-11-29 14:42:32 <Burritoh> it's his first transaction
601 2013-11-29 14:43:05 <kjj> wait, just a normal send through the UI or sendtoaddress?
602 2013-11-29 14:43:12 <bluesceada> i used the UI
603 2013-11-29 14:43:14 <bluesceada> bitcoin-qt
604 2013-11-29 14:43:16 <bluesceada> from debian
605 2013-11-29 14:43:24 <bluesceada> previously I just received
606 2013-11-29 14:43:36 <bluesceada> this? http://pastebin.com/G9xsXNM0
607 2013-11-29 14:44:16 <bluesceada> kjj
608 2013-11-29 14:44:21 <Burritoh> bluesceada: type this in the console "getrawtransaction 7e5e70eed73e345bf679686e20a0a828c93b8987ec874112344f2308cc6e8ac0" - it should say a load of hex code.
609 2013-11-29 14:44:28 <kjj> I just sent it through one of my nodes.  no rjection so far
610 2013-11-29 14:44:38 <bluesceada> Burritoh: yeah already did, this is that: http://pastebin.com/G9xsXNM0
611 2013-11-29 14:44:49 <Burritoh> ah, thanks
612 2013-11-29 14:44:59 <kjj> so far, hasn't made it to any other nodes...
613 2013-11-29 14:45:08 <bluesceada> hm
614 2013-11-29 14:45:09 <swulf--> weird, i have a tx that hasn't propagated either
615 2013-11-29 14:45:17 <swulf--> kjj: you see a1a80866becc17d7add338354f42b03dd2ddafd2edf055b832194405d4ca65e2 anywhere?
616 2013-11-29 14:45:36 <Burritoh> It just appeared :)
617 2013-11-29 14:45:48 <Burritoh> bluesceada: it was sent
618 2013-11-29 14:45:49 <kjj> swulf--: no
619 2013-11-29 14:45:52 <bluesceada> hm ok
620 2013-11-29 14:45:56 <swulf--> hum..
621 2013-11-29 14:46:02 <bluesceada> Burritoh: thanks, so far I dont see a confirm here...
622 2013-11-29 14:46:55 <Burritoh> bluesceada: did you press the button in the coinbase dialogue to confirm that you've sent it?
623 2013-11-29 14:47:03 <bluesceada> ah i see it on blockhain.info now too
624 2013-11-29 14:47:04 <bluesceada> good
625 2013-11-29 14:47:09 <Burritoh> so it should work then
626 2013-11-29 14:47:13 <bluesceada> Burritoh: yeah I tried multiple times already
627 2013-11-29 14:47:31 <bluesceada> https://blockchain.info/tx/7e5e70eed73e345bf679686e20a0a828c93b8987ec874112344f2308cc6e8ac0
628 2013-11-29 14:48:10 <kjj> I'm guessing that the fees are slightly too low for relay by the majority of nodes
629 2013-11-29 14:48:15 <Burritoh> bluesceada: how many nodes are you connected to? There should be eight if you don't have a port opened in your router.
630 2013-11-29 14:48:42 <Burritoh> (mouse-over the bars (like cell phone reception symbol) bottom right to see how many nodes)
631 2013-11-29 14:49:00 <bluesceada> yeah 8 ...
632 2013-11-29 14:49:34 <Burritoh> kjj: I didn't know transaction fee was accounted for when deciding to relay
633 2013-11-29 14:49:40 <Burritoh> only when deciding to prioritise for mining
634 2013-11-29 14:49:40 <kjj> ok, so if I recall, there is a rounding bug in the fee calculation on some versions
635 2013-11-29 14:49:48 <Burritoh> ahh..
636 2013-11-29 14:49:58 <Burritoh> so it was a bug + bad luck :)
637 2013-11-29 14:50:03 <bluesceada> i didnt forward a port in my "router" (ugly combination rather, because provider enforces it's own modem<->router combination that is quite limited...)
638 2013-11-29 14:50:04 <kjj> yes, recent versions will not relay a tx that they wouldn't mine
639 2013-11-29 14:50:55 <kjj> and by now, the majority of nodes are using that policy
640 2013-11-29 14:51:05 <bluesceada> so, this would have never went through usually?
641 2013-11-29 14:51:21 <kjj> it would have when the priority was high enough
642 2013-11-29 14:51:34 <Burritoh> So, later?
643 2013-11-29 14:51:35 <kjj> your wallet keeps trying forever, until it lands in a block
644 2013-11-29 14:51:59 <kjj> and priority is based on age.  so eventually, it would become eligible for free inclusion, and nodes will relay it
645 2013-11-29 14:52:06 <bluesceada> (sorry I didn't fully read about all bitcoin details so far...)
646 2013-11-29 14:52:06 <Burritoh> Neat.
647 2013-11-29 14:52:39 <bluesceada> but ok sounds reasonable, but in the end a higher transaction fee should probably have been paid?
648 2013-11-29 14:53:03 <Burritoh> It's a rounding error, which means yes, but the client didn't know that
649 2013-11-29 14:53:05 <kjj> yes
650 2013-11-29 14:53:39 <kjj> so, the node calculates the fee it thinks it needs, but rounds it.  other nodes don't round when making the relay decision
651 2013-11-29 14:53:53 <bluesceada> even if percentage wise it was already 0,27% of the btc amount i transfered hmh
652 2013-11-29 14:53:57 <kjj> so you can end up with fees that are almost, but not quite, enough
653 2013-11-29 14:54:08 <bluesceada> uh ok
654 2013-11-29 14:54:09 <kjj> percentages don't matter.  size matters
655 2013-11-29 14:54:19 <kjj> and in this case, size isn't a factor either
656 2013-11-29 14:55:25 <kjj> I'm pretty sure gavin fixed the rounding problem, for later versions
657 2013-11-29 14:55:29 <bluesceada> hm I still dont see a confirmation here
658 2013-11-29 14:55:44 <Burritoh> bluesceada: coinbase still should accept it
659 2013-11-29 14:55:51 <kjj> but as I'm thinking about it right now, maybe a better option would be to use something other than a hard cutoff for relaying
660 2013-11-29 14:56:03 <bluesceada> kjj ok .. but this is rounding of my peers, so I can't directly do anything about it, right?
661 2013-11-29 14:56:05 <kjj> it should confirm soon
662 2013-11-29 14:56:07 <Burritoh> takes about ten minutes for one confirmation, but HIB's Coinbase checkout has accepted it for me at 0 conf.
663 2013-11-29 14:56:48 <kjj> bluesceada: well, assuming the problem is what I think it is (and it may not be it exactly), the rounding is happening in your node
664 2013-11-29 14:57:01 <bluesceada> umm ok
665 2013-11-29 14:57:12 <bluesceada> i can also try the git version or something ...
666 2013-11-29 14:57:14 <Burritoh> When your node decides to set the transaction fee.
667 2013-11-29 14:57:22 <kjj> update the next time a release comes out
668 2013-11-29 14:57:35 <bluesceada> ok then maybe debian packages are updated anyway
669 2013-11-29 14:57:49 <Burritoh> 0.8.5 is the latest, there is no later
670 2013-11-29 14:58:08 <bluesceada> Burritoh: yeah, but git versions ..
671 2013-11-29 14:58:39 <Burritoh> You could try that, but I wouldn't risk the instability with my money
672 2013-11-29 14:58:58 <bluesceada> kjj: so thanks for putting the transaction through one of your nodes!
673 2013-11-29 14:59:27 <kjj> no problem.  by the way, blockchain.info has a page where you can paste the hex in and relay it there
674 2013-11-29 14:59:36 <kjj> https://blockchain.info/pushtx
675 2013-11-29 14:59:37 <bluesceada> oh ok