1 2014-03-17 00:02:12 <lechuga_> CheckDavid: you could use bitcoind
2 2014-03-17 00:04:14 <lechuga_> importprivkey / getaddressesbyaccount
3 2014-03-17 00:05:43 <CheckDavid> Oh...
4 2014-03-17 00:06:12 <CheckDavid> You mean I test a key in my script and in another generator?
5 2014-03-17 00:06:43 <CheckDavid> And see if they match ?
6 2014-03-17 00:07:03 <lechuga_> i mean try to get bitcoind to import a privkey you create
7 2014-03-17 00:07:13 <CheckDavid> Oh
8 2014-03-17 00:07:15 <lechuga_> and then see if it does and if it will spit out the same address you calculate
9 2014-03-17 00:07:26 <CheckDavid> Is there bitcoinf for android?
10 2014-03-17 00:07:38 <CheckDavid> *bitcoind
11 2014-03-17 00:07:51 <sipa> why do you need a android version to test?
12 2014-03-17 00:08:13 <CheckDavid> sipa: cuz I'm poor and thats all I have
13 2014-03-17 00:08:47 <sipa> you're developing python scripts on android?
14 2014-03-17 00:08:53 <CheckDavid> Yes
15 2014-03-17 00:09:22 <sipa> ok
16 2014-03-17 00:09:33 <CheckDavid> I am not competing with Microsoft :)
17 2014-03-17 00:09:42 <CheckDavid> Just doing some basic scripting
18 2014-03-17 00:10:43 <CheckDavid> Look what I found
19 2014-03-17 00:10:46 <CheckDavid> http://gobittest.appspot.com/Address
20 2014-03-17 00:11:02 <CheckDavid> I guess I could cross test using this
21 2014-03-17 00:11:12 <Imbue> CheckDavid: that's the link i tried to show you the other day via wiki
22 2014-03-17 00:11:34 <Imbue> it is a useful tool but bear in mind addresses are submitted to server so it is not good to use for mission critical
23 2014-03-17 00:11:50 <sipa> it doesn't support compressed pubkeys
24 2014-03-17 00:12:45 <CheckDavid> Imbue: you tried but didn't @
25 2014-03-17 00:13:33 <Imbue> it is on the 'technical background of ver 1 addresses' page
26 2014-03-17 00:13:35 <Imbue> hehe
27 2014-03-17 00:14:07 <CheckDavid> Imbue: yes
28 2014-03-17 00:14:12 <lechuga_> you can run bitcoind on a raspberry pi
29 2014-03-17 00:14:18 <lechuga_> those are what
30 2014-03-17 00:14:19 <lechuga_> $40?
31 2014-03-17 00:14:31 <lechuga_> you dont need to sync the blockchain
32 2014-03-17 00:14:48 <Imbue> well if you want it just for testing it feels like there should be sort of emulator you can use
33 2014-03-17 00:14:58 <CheckDavid> Yeah. Just want to year address generation
34 2014-03-17 00:15:05 <Imbue> providing you don't care about speed and your android machine is less than 3 years old or whatever
35 2014-03-17 00:15:10 <CheckDavid> *test
36 2014-03-17 00:15:35 <CheckDavid> Imbue: my android is a beast
37 2014-03-17 00:18:21 <CheckDavid> In which format is the private key in that website?
38 2014-03-17 00:18:25 <CheckDavid> Hex?
39 2014-03-17 00:20:22 <CheckDavid> Well. Apparently it works :D
40 2014-03-17 00:20:35 <TheCleanGame> hehehe
41 2014-03-17 00:21:20 <CheckDavid> If anyone would like to peer review be my guest :p
42 2014-03-17 00:21:34 <CheckDavid> And thanks to dims for compiling it
43 2014-03-17 00:30:54 <CheckDavid> Why were WIFs created? Compactness?
44 2014-03-17 00:33:17 <dims> CheckDavid, nice!
45 2014-03-17 00:33:30 <CheckDavid> :D
46 2014-03-17 00:33:43 <mbelshe> does anyone have any good stats on average time of a transaction from insertion into the p2p network to first confirmation? obviously it will depend on the transaction; but it seems like this could be a great area of research?
47 2014-03-17 00:33:45 <dims> you can cross verify against http://brainwallet.org/
48 2014-03-17 00:36:06 <Cylta> mbelshe: greatly depends on size of transaction and fee
49 2014-03-17 00:36:18 <ne0futur> mbelshe: 10-20 mins for the first conf most of the time
50 2014-03-17 00:36:32 <ne0futur> not always
51 2014-03-17 00:36:55 <mbelshe> yeah, i know the basic theory. i was wondering if anyone had done any research of actual times and analyzed it.
52 2014-03-17 00:38:26 <Cylta> is electrum safe?
53 2014-03-17 00:39:25 <CheckDavid> Ths
54 2014-03-17 00:39:35 <CheckDavid> Thanks dims
55 2014-03-17 00:40:53 <Imbue> Cylta: it leaks a bit of information about addresses under your control, that's all i can think of right now
56 2014-03-17 00:41:24 <Imbue> as far as i am aware anyway. i don't think it uses a bloom filter or anything similar when synchronizing
57 2014-03-17 00:42:30 <Cylta> Imbue: okay, I will keep that in mind. Does not sounds critical. Is it open source\checked? (I mean, what is they have a backdoor?.. who is author?)
58 2014-03-17 00:43:00 <Imbue> i think it's 100% python so you can check if you wish
59 2014-03-17 00:43:26 <Imbue> as to 'is it audited', no idea
60 2014-03-17 00:44:25 <Cylta> Imbue: is there any other lightweight client, better than electrum?
61 2014-03-17 00:45:06 <mbelshe> (selfishly, bitgo.com!
62 2014-03-17 00:45:08 <Imbue> only one i've tried is android wallet
63 2014-03-17 00:45:32 <Imbue> i prefer it because it's p2p spv instead of 'proprietary'
64 2014-03-17 00:45:50 <Imbue> but electrum is (designed to be) more secure unless android wallet has improved somewhat since my last use
65 2014-03-17 00:53:22 <BlueMatt> sipa: oooo fun
66 2014-03-17 00:54:35 <BlueMatt> gmaxwell: it does that sometimes when its replaying chain or something
67 2014-03-17 00:54:36 <Cylta> mbelshe does it have api?
68 2014-03-17 00:54:40 <BlueMatt> gmaxwell: but that should be incredibly rare
69 2014-03-17 00:54:45 <BlueMatt> sipa: I blame gavinandresen
70 2014-03-17 00:54:56 <BlueMatt> gavinandresen: usually fixes pull-tester these days :(
71 2014-03-17 00:55:49 <mbelshe> @cylta, yes, but i'm changing it.... if you're looking for an api right now, i don't quite have it yet. 2 weeks
72 2014-03-17 00:56:28 <mbelshe> anyone have tips for a transaction that seems like it should be going through, but is sitting unconfirmed for hours? (not a fee issue, not small issue, etc)
73 2014-03-17 00:56:44 <mbelshe> here it is: https://blockchain.info/tx/ea95e2b5d90c41ef83ab2695964b1767526d0311b4760fa1a0b51e3bb7c2d84f
74 2014-03-17 00:57:09 <Cylta> mbelshe: fee issue
75 2014-03-17 00:57:48 <mbelshe> really? it has a fee on it of 0.0001?
76 2014-03-17 00:58:10 <Cylta> mbelshe: not sure about current normal fee, but recently it was 0.0005 btc per kb. you have 0.0001 for 0.8 kb
77 2014-03-17 00:59:01 <mbelshe> hrm; i thought it was 0.0001 per kb. that would explain it if i have that wrong.
78 2014-03-17 01:01:09 <mbelshe> latest source shows nMinTxFee at 10000
79 2014-03-17 01:02:17 <Imbue> it is .0001 per kb for relaying
80 2014-03-17 01:02:28 <emowataji> mbelshe: I had a 0.0001 fee transaction that took almost 48 hours to confirm recently
81 2014-03-17 01:02:33 <Imbue> miners inclusion policy may differ
82 2014-03-17 01:05:09 <lechuga_> that txn isnt standard is it
83 2014-03-17 01:05:18 <lechuga_> OP_HASH160 3dc660ed8e4053b3404389e92cc6723f993b1a05 OP_EQUAL
84 2014-03-17 01:06:25 <mbelshe> it is standard. blockchain.info is confused about how to parse a P2SH signature block
85 2014-03-17 01:06:35 <lechuga_> ic
86 2014-03-17 01:06:54 <mbelshe> i guess it could just be miners are expecting greater than 0.0001. But as I read the code, the fee is correct.
87 2014-03-17 01:11:44 <Imbue> annoying that blockchain don't have a raw tx function
88 2014-03-17 01:11:54 <Imbue> not in my mempool so i can't decode it
89 2014-03-17 01:13:08 <Imbue> bc.i that is. i need to be strict on my mental replacement here. damn domain squatters.
90 2014-03-17 01:13:48 <lechuga_> fee seems correct to me
91 2014-03-17 01:18:05 <lechuga_> mbelshe: have you tried sending it directly ot a miner?
92 2014-03-17 01:18:22 <mbelshe> yes
93 2014-03-17 01:18:54 <mbelshe> @imbue - i can send it to you
94 2014-03-17 01:19:06 <Luke-Jr> Imbue: they do
95 2014-03-17 01:19:10 <lianj> mbelshe: do you have the hex? seems like no node except bc.i has seen it
96 2014-03-17 01:19:51 <Imbue> Luke-Jr: how is it accessed? could be that I am missing it with js disabled
97 2014-03-17 01:20:07 <Luke-Jr> https://blockchain.info/tx/ea95e2b5d90c41ef83ab2695964b1767526d0311b4760fa1a0b51e3bb7c2d84f?format=hex
98 2014-03-17 01:20:19 <lianj> ah nie
99 2014-03-17 01:20:21 <Imbue> magic
100 2014-03-17 01:20:21 <mbelshe> good ptr, thx lukejr
101 2014-03-17 01:20:22 <lianj> *c
102 2014-03-17 01:20:34 <Imbue> thanks
103 2014-03-17 01:21:28 <lechuga_> oh thats cool
104 2014-03-17 01:30:04 <mbelshe> @imbue - did you see anything fishy in there?
105 2014-03-17 01:30:29 <Imbue> mbelshe: i am no expert; just wanted to have a look
106 2014-03-17 01:30:44 <Cylta> how much ram does the bitcoind or electrum need?
107 2014-03-17 01:31:02 <Imbue> bitcoind seems happy with it but then given that you relayed it fine, that makes sense
108 2014-03-17 01:31:11 <lechuga_> are the inputs both 2-of-3 p2sh multisig?
109 2014-03-17 01:31:17 <mbelshe> yes
110 2014-03-17 01:45:19 <lechuga_> my bitcoind rejects it
111 2014-03-17 01:45:42 <lechuga_> it looks eligius does too
112 2014-03-17 01:59:59 <lechuga_> nm it accepted it now
113 2014-03-17 02:01:00 <Luke-Jr> lechuga_: how's libblkmaker coming? :P
114 2014-03-17 02:02:44 <mbelshe> lechuga_: thx for checking.
115 2014-03-17 02:06:36 <lechuga_> weird i sne ti tonce with no error then i get an error about it being nonstd
116 2014-03-17 02:06:40 <lechuga_> sent it*
117 2014-03-17 02:06:54 <lechuga_> Luke-Jr: this week was pretty crazy due to job interview
118 2014-03-17 02:07:01 <lechuga_> should have plenty of time this week
119 2014-03-17 02:07:25 <Luke-Jr> lechuga_: I thought you already have a job with <â¦>
120 2014-03-17 02:08:34 <lechuga_> sort of
121 2014-03-17 02:08:39 <lechuga_> ;)
122 2014-03-17 02:09:47 <sipa> ACTION is curious now
123 2014-03-17 02:17:31 <super3> hello all
124 2014-03-17 02:34:00 <mbelshe> well that tx finally went through
125 2014-03-17 02:34:20 <lechuga_> yeah i didnt get a chance to figure out why my node was rejecting it
126 2014-03-17 02:34:27 <lechuga_> prior to it getting into a block
127 2014-03-17 02:34:35 <mbelshe> i think i'm doing something incorrectly. but i can't figure out what it is.
128 2014-03-17 02:34:47 <mbelshe> i debugged with bitcoind; its definitely go enough fee and its definitely standard.
129 2014-03-17 02:35:04 <mbelshe> i think the TX rejected was just because it was already in the mempool
130 2014-03-17 02:35:10 <mbelshe> but it still took forever.
131 2014-03-17 02:36:04 <lechuga_> i had debugging printfs in there which seemed to indicate it was nonstd
132 2014-03-17 02:36:15 <dhill> lechuga_: i pasted you
133 2014-03-17 02:37:08 <lechuga_> ah i wasnt sure what that meant
134 2014-03-17 02:38:49 <lechuga_> i really need a tool that dumps serialized scripts to human readable ascii
135 2014-03-17 02:38:55 <lechuga_> surely such a thing exists
136 2014-03-17 02:39:35 <lianj> http://webbtc.com/tx/ea95e2b5d90c41ef83ab2695964b1767526d0311b4760fa1a0b51e3bb7c2d84f 'run script'
137 2014-03-17 02:39:41 <lianj> looks normal
138 2014-03-17 02:39:57 <dhill> 22:01:51 2014-03-16 [DBG] RPCS: Rejected transaction ea95e2b5d90c41ef83ab2695964b1767526d0311b4760fa1a0b51e3bb7c2d84f: transaction
139 2014-03-17 02:39:57 <dhill> ea95e2b5d90c41ef83ab2695964b1767526d0311b4760fa1a0b51e3bb7c2d84f has a non-standard input: transaction input #0 expects 3 inputs, but referenced
140 2014-03-17 02:39:57 <dhill> output script only provides 4
141 2014-03-17 02:40:00 <dhill> is what i got
142 2014-03-17 02:41:42 <lechuga_> oh cool @ webbtc
143 2014-03-17 02:41:47 <mbelshe> thanks dhill - looking at that
144 2014-03-17 02:41:52 <lechuga_> thats exactly what ive been looking for
145 2014-03-17 02:42:31 <lechuga_> i think i saw that erferenced in your ruby library but ignored it :)
146 2014-03-17 02:42:33 <lechuga_> referenced
147 2014-03-17 02:43:05 <mbelshe> webbtc.com is awesome!
148 2014-03-17 02:43:30 <lechuga_> would it differentiate pushdata from pushdata2?
149 2014-03-17 02:44:29 <lianj> in the debug output, no. but if its a handcrafted use of OP_PUSHDATAs you would see it
150 2014-03-17 02:46:08 <lianj> script wise i think the tx is just fine
151 2014-03-17 02:46:42 <mbelshe> dhill: what program gave you that output?
152 2014-03-17 02:46:57 <dhill> btcd
153 2014-03-17 02:47:12 <lechuga_> handcrafted meaning non-canonical?
154 2014-03-17 02:48:09 <lianj> meaning for example pushdata2 where the data fits in pushdata
155 2014-03-17 02:48:14 <lechuga_> right
156 2014-03-17 02:48:16 <lechuga_> k
157 2014-03-17 02:49:28 <mbelshe> dhill: any chance that is an old version of bitcoind?
158 2014-03-17 02:50:05 <mbelshe> dhill: or i that actually the btcd (written in go)?
159 2014-03-17 02:50:20 <mbelshe> err - /i/is
160 2014-03-17 02:50:29 <dhill> go
161 2014-03-17 02:51:58 <mbelshe> ok. I'll look into it. The error seems like it might be a btcd-ism. The text reads funny: "expects 3 inputs, but referenced output only provides 4".
162 2014-03-17 02:52:12 <mbelshe> maybe the "only" should be removed.
163 2014-03-17 02:52:16 <mbelshe> i'll check the source
164 2014-03-17 02:53:09 <mbelshe> heh. ok:
165 2014-03-17 02:53:29 <dhill> yea, only should be removed
166 2014-03-17 02:53:52 <dhill> reads funny
167 2014-03-17 02:54:58 <mbelshe> does btcd support p2sh?
168 2014-03-17 02:58:06 <dhill> btcd does
169 2014-03-17 03:03:26 <CodeShark> is OP_PUSHDATA2 big or small endian?
170 2014-03-17 03:03:41 <mbelshe> well, there is a bug in bitcoind; you're supposed to push an OP_0 in your CHECKMULTISIG scripts; it appears that btcd doesn't like this.
171 2014-03-17 03:04:09 <lechuga_> btcd needs the same bug :)
172 2014-03-17 03:04:12 <CodeShark> looking in script.h, I see insert(end(), (unsigned char*)&nSize, (unsigned char*)&nSize + sizeof(nSize));
173 2014-03-17 03:04:16 <mbelshe> i believe littleendian
174 2014-03-17 03:04:29 <CodeShark> doesn't the serialization of nSize here depend on the platform endianness?
175 2014-03-17 03:05:41 <CodeShark> shouldn't we be doing explicit bitshifts and masks?
176 2014-03-17 03:07:30 <CodeShark> nSize is an unsigned short (which presumably is a 16 bit integer on our target platforms, even though C++ doesn't dictate a standard)
177 2014-03-17 03:07:42 <mbelshe> codeshark: it reads that way to me too.
178 2014-03-17 03:07:49 <CodeShark> seems like we should be using a uint16_t
179 2014-03-17 03:07:56 <CodeShark> and doing explicit bitshifts
180 2014-03-17 03:08:02 <CodeShark> to make sure we're portable
181 2014-03-17 03:09:25 <mbelshe> i think i read somewhere that bitcoind only works on little endian machines.
182 2014-03-17 03:09:34 <mbelshe> (not that this is a good thing)
183 2014-03-17 03:09:50 <CodeShark> I'
184 2014-03-17 03:10:01 <mbelshe> maybe satoshi worked for intel.
185 2014-03-17 03:10:03 <CodeShark> I've only built it for Intel architectures
186 2014-03-17 03:10:20 <CodeShark> but it seems like it would cost us very little to make the code not care about architecture endianness
187 2014-03-17 03:10:23 <davec> in regards to the OP_0 on multisig, btcd does pop that extra argument
188 2014-03-17 03:10:35 <lechuga_> the orig impl was windows-only i believe
189 2014-03-17 03:11:09 <CodeShark> it's silly to use architecture-specific code unless we're talking about to-the-metal optimizations which would have different architecture-specific implementaitons
190 2014-03-17 03:11:26 <CodeShark> and this is not one of those instances :)
191 2014-03-17 03:11:48 <CodeShark> script serialization is hardly a runtime bottleneck in bitcoind :)
192 2014-03-17 03:12:25 <sipa> CodeShark: yeah, bitcoind should absolutely move to neutral-endianness
193 2014-03-17 03:12:45 <sipa> CodeShark: the problem is that testing that requires access to different platforms
194 2014-03-17 03:12:53 <sipa> and someone who cares
195 2014-03-17 03:13:20 <lechuga_> what popular architectures are big endian anymore
196 2014-03-17 03:13:47 <sipa> none
197 2014-03-17 03:14:03 <CodeShark> what about type widths?
198 2014-03-17 03:14:03 <copumpkin> ARM has the option of being both, but is typically LE
199 2014-03-17 03:14:05 <mbelshe> davec: i'm trying to figure out why btcd didn't like ea95e2b5d90c41ef83ab2695964b1767526d0311b4760fa1a0b51e3bb7c2d84f...
200 2014-03-17 03:14:11 <CodeShark> there's also the issue of an unsigned short being 16 bits
201 2014-03-17 03:14:27 <copumpkin> powerpc is big endian though
202 2014-03-17 03:14:31 <copumpkin> and it's not impossible to find
203 2014-03-17 03:15:00 <CodeShark> I mean, we might as well hardcode 2 instead of sizeof(nSize) :)
204 2014-03-17 03:15:20 <sipa> CodeShark: don't know any popular architecture that doesn't have short=2 int=4
205 2014-03-17 03:15:37 <sipa> anyway, not disagreeing with you at all
206 2014-03-17 03:15:46 <davec> mbelshe: have you updated to the latest version? I ask because that was in block 290938, and I'm currently at 290943
207 2014-03-17 03:15:49 <sipa> just saying that trying to fix it isn't all that trivial
208 2014-03-17 03:17:01 <mbelshe> davec: oh - yes - i'm aware it finally got picked up. dhill found that it was getting rejected in btcd with this error:
209 2014-03-17 03:17:13 <mbelshe> 22:01:51 2014-03-16 [DBG] RPCS: Rejected transaction ea95e2b5d90c41ef83ab2695964b1767526d0311b4760fa1a0b51e3bb7c2d84f: transaction
210 2014-03-17 03:17:27 <mbelshe> ea95e2b5d90c41ef83ab2695964b1767526d0311b4760fa1a0b51e3bb7c2d84f has a non-standard input: transaction input #0 expects 3 inputs, but referenced
211 2014-03-17 03:17:34 <mbelshe> output script only provides 4
212 2014-03-17 03:17:52 <mbelshe> i was speculating (from casually looking at the btcd source) - that the OP_0 is tripping it up
213 2014-03-17 03:18:04 <dhill> bitcoind 0.8.5 rejected it as well i believe
214 2014-03-17 03:18:17 <mbelshe> i was looking here: https://github.com/conformal/btcd/blob/master/mempool.go
215 2014-03-17 03:18:18 <sipa> seems it is taken into account for validity, but not for standardness
216 2014-03-17 03:18:22 <sipa> dhill: really?
217 2014-03-17 03:18:42 <davec> I'll take a look, but there is a difference between non-standard and invalid
218 2014-03-17 03:18:43 <dhill> yea, TX Rejected i think
219 2014-03-17 03:18:47 <dhill> let me take a second look
220 2014-03-17 03:18:58 <dhill> hoopefully debug.log as it still
221 2014-03-17 03:18:59 <davec> miners can and do accept non-standard txns if the fee is high enough
222 2014-03-17 03:19:01 <davec> that is what happened here
223 2014-03-17 03:19:01 <sipa> dhill: most likely because it's already in the mempool
224 2014-03-17 03:19:28 <sipa> oh
225 2014-03-17 03:19:35 <sipa> ignore me
226 2014-03-17 03:19:51 <mbelshe> so i don't think this is a non-standard tx tho.
227 2014-03-17 03:20:53 <davec> I'll dig into it, but I'm basing this on the fact that error message is specifically in regards to non-standard, then it was mined into a block and passed the consensus checks with no issues (i.e valid, but non-standard).
228 2014-03-17 03:21:05 <davec> will report back in a few after I disasm the p2sh
229 2014-03-17 03:22:06 <mbelshe> here is a pretty good view: http://webbtc.com/script/ea95e2b5d90c41ef83ab2695964b1767526d0311b4760fa1a0b51e3bb7c2d84f:0
230 2014-03-17 03:22:18 <mbelshe> thanks for looking at it, davec
231 2014-03-17 03:24:42 <sipa> looks standard 2-of-3 p2sh to me
232 2014-03-17 03:25:04 <davec> agreed
233 2014-03-17 03:33:19 <lechuga_> 0x48 immediately follows OP_0
234 2014-03-17 03:34:10 <lechuga_> oh nm
235 2014-03-17 03:35:56 <lechuga_> is that normal that its not using pushdata1
236 2014-03-17 03:38:07 <lechuga_>
237 2014-03-17 03:38:07 <lechuga_> yes it is :)_
238 2014-03-17 03:40:02 <davec> found it - thanks for the heads up
239 2014-03-17 03:42:52 <CodeShark> ah, the limitation in number of pubkeys in a multisig is actually in main.cpp, not script.cpp
240 2014-03-17 03:43:09 <CodeShark> if (txin.scriptSig.size() > 500) { reason = "scriptsig-size"; return false; }
241 2014-03-17 03:43:38 <CodeShark> the comment above it is incorrect, though
242 2014-03-17 03:43:52 <CodeShark> it assumes ~65 byte pubkeys when most of us are using 33 byte pubkeys
243 2014-03-17 03:43:58 <CodeShark> so 3-of-5 transactions still work fine
244 2014-03-17 03:44:31 <mbelshe> codeshark: there is a patch pending - i think from peter todd that would greatly increase that limit too
245 2014-03-17 03:44:38 <mbelshe> i don't know the status of the patch tho
246 2014-03-17 03:44:43 <davec> to 15-of-15 iirc
247 2014-03-17 03:44:45 <Luke-Jr> CodeShark: no, that's just IsStandard
248 2014-03-17 03:45:15 <CodeShark> IsStandardTx in main.cpp
249 2014-03-17 03:45:27 <Luke-Jr> right, that's not a protocol rule
250 2014-03-17 03:45:30 <Luke-Jr> static const unsigned int MAX_SCRIPT_ELEMENT_SIZE = 520; // bytes
251 2014-03-17 03:45:33 <Luke-Jr> ^ real limit
252 2014-03-17 03:45:35 <Luke-Jr> src/script.h
253 2014-03-17 03:45:45 <CodeShark> right, it's not a protocol rule
254 2014-03-17 03:45:55 <CodeShark> but this still means bitcoind won't relay it :p
255 2014-03-17 03:46:13 <Luke-Jr> ACTION shrugs
256 2014-03-17 03:46:53 <CodeShark> ERROR: CTxMemPool::accept() : nonstandard transaction: scriptsig-size
257 2014-03-17 03:46:59 <mbelshe> luke-jr: do you have advice for folks that want to more than 500b multisigs? i've been like codeshark - just assuming that if not standard, it isn't going to fly. i know eligius will take it still, but it seems like a problem? it sounds like you see it differently?
258 2014-03-17 03:47:50 <Luke-Jr> mbelshe: I don't see it as a problem.
259 2014-03-17 03:48:02 <Luke-Jr> 520 bytes is the hard limit anyway
260 2014-03-17 03:48:06 <Luke-Jr> so 500 isn't that constraining
261 2014-03-17 03:48:12 <CodeShark> 520 for a script element!
262 2014-03-17 03:48:14 <CodeShark> not for the entire script
263 2014-03-17 03:48:24 <CodeShark> hmm
264 2014-03-17 03:48:26 <Luke-Jr> CodeShark: the entire script, in P2SH
265 2014-03-17 03:48:32 <CodeShark> yeah, hmmm
266 2014-03-17 03:48:36 <CodeShark> well, this is a problem, then
267 2014-03-17 03:48:40 <CodeShark> because people want more than 3-of-4
268 2014-03-17 03:48:43 <CodeShark> because people want more than 3-of-3
269 2014-03-17 03:48:44 <CodeShark> or whateer
270 2014-03-17 03:48:45 <gmaxwell> 500b is a whole lot of keys in any case, the signatures a pretty large at that point.
271 2014-03-17 03:48:53 <Luke-Jr> CodeShark: 500 is M-of-15
272 2014-03-17 03:48:57 <gmaxwell> CodeShark: dude you can have like of-15 in 520 bytes.
273 2014-03-17 03:49:18 <CodeShark> ok, right - the problem here is that the 500 includes the signatures
274 2014-03-17 03:49:23 <CodeShark> it's not just the p2sh redeemscript
275 2014-03-17 03:49:38 <Luke-Jr> CodeShark: if you're concerned about IsStandard, it will reject N over 3 anyway
276 2014-03-17 03:49:43 <CodeShark> no it won't
277 2014-03-17 03:49:49 <CodeShark> doesn't check input scripts
278 2014-03-17 03:49:53 <Luke-Jr> â¦
279 2014-03-17 03:49:56 <CodeShark> I've done 3-of-5 with no problem
280 2014-03-17 03:51:07 <gmaxwell> In any case, petertodd's pull expands all the IsStandard stuff.
281 2014-03-17 03:51:45 <CodeShark> how soon before petertodd's pull gets into release?
282 2014-03-17 03:51:58 <sipa> that's not relevant
283 2014-03-17 03:52:10 <sipa> you can do 19-of-15 p2sh right now i think
284 2014-03-17 03:52:16 <sipa> *10-of-15
285 2014-03-17 03:52:28 <CodeShark> as long as enough nodes on the network will relay it it isn't a problem
286 2014-03-17 03:52:36 <sipa> all will
287 2014-03-17 03:53:06 <Luke-Jr> not the spend
288 2014-03-17 03:54:27 <CodeShark> let's say ~71 bytes per signature * 5 signatures, that means 355 bytes just for the signatures. then 33 per pubkey * 8 pubkeys is another 264 bytes
289 2014-03-17 03:54:38 <CodeShark> so a 5-of-8 exceeds this 500 byte limit
290 2014-03-17 03:55:04 <Luke-Jr> CodeShark: that's on spend, not receive
291 2014-03-17 03:55:16 <CodeShark> that's all I care about
292 2014-03-17 03:55:29 <CodeShark> of course on receive the sender doesn't even care what's in the redeemscript
293 2014-03-17 03:55:37 <CodeShark> it's just a 20 byte hash
294 2014-03-17 03:55:47 <mbelshe> codeshark: your math matches mine
295 2014-03-17 03:56:41 <CodeShark> if we were talking about a limit on script elements, 500 wouldn't be a problem since we only need a few more bytes than 355 for the redeemscript
296 2014-03-17 03:56:48 <CodeShark> but this is a limit on the entire input script
297 2014-03-17 03:56:52 <CodeShark> including signatures
298 2014-03-17 04:00:09 <uiop> does sizeof m-of-n script grow exponentially or is there a single opcode that (with params (m,n)) that encodes it? (/me doesn't recall)
299 2014-03-17 04:01:29 <CodeShark> it grows linearly
300 2014-03-17 04:02:29 <CodeShark> O(71*m + 33*n)
301 2014-03-17 04:02:59 <gmaxwell> you're not counting the pushes.
302 2014-03-17 04:03:14 <CodeShark> well, big O here
303 2014-03-17 04:03:52 <gmaxwell> I mean the numbers are just actually more like 75, 34. Thats all.
304 2014-03-17 04:03:56 <CodeShark> right
305 2014-03-17 04:10:50 <uiop> ah, nice
306 2014-03-17 04:22:14 <uiop> oh, right. i was picturing powerset-ish thing, but it's not
307 2014-03-17 04:25:02 <sipa> uiop: it's avoided by requiring the signatures to be in the same order as the public keys
308 2014-03-17 04:25:18 <sipa> so you don't need to check all orderings/subsets
309 2014-03-17 04:32:33 <justanotheruser> sipa: thats still O(mn) right?
310 2014-03-17 04:32:41 <sipa> no
311 2014-03-17 04:32:45 <sipa> O(m+n)
312 2014-03-17 04:33:44 <justanotheruser> I see. Not sure what I was thinking (well I was thinking check every combo)
313 2014-03-17 04:34:08 <CodeShark> and since m <= n, we can just write O(2n)
314 2014-03-17 04:34:16 <CodeShark> or O(n) :)
315 2014-03-17 04:35:20 <CodeShark> even if it allowed for arbitrary signature permutations, that would only be time O(n^2)
316 2014-03-17 04:36:31 <CodeShark> in the worst case it would have to try each pair of (signature, pubkey)
317 2014-03-17 04:37:00 <gmaxwell> which would be pretty awful, fortunately we don't do that.
318 2014-03-17 04:37:34 <gmaxwell> a single of-15 would basically blow the ecdsa budget for a block. :P
319 2014-03-17 04:38:30 <CodeShark> I've been giving my parser even more help by keeping a zero-length placeholder for each missing signature
320 2014-03-17 04:39:01 <CodeShark> at least in edit mode
321 2014-03-17 04:39:11 <CodeShark> the zero-length placeholders are stripped off for broadcast
322 2014-03-17 04:40:48 <CodeShark> then we know exactly which pubkeys to test
323 2014-03-17 04:41:21 <justanotheruser> What is the most expensive op_code?
324 2014-03-17 04:41:25 <justanotheruser> opcode
325 2014-03-17 04:44:06 <gmaxwell> op_checksig with high N.
326 2014-03-17 04:47:01 <sipa> op_checkmultisigverify
327 2014-03-17 05:00:34 <gmaxwell> er thats what I meant by OP_CHECKSIG. :P
328 2014-03-17 05:20:20 <fnesse> longshot here: but has anyone had any success with cpp_int bignum types? specifically uint1024_t?
329 2014-03-17 06:30:26 <coinnabis> the db dumps are pretty clear
330 2014-03-17 06:31:26 <coinnabis> the number of btc Luke-Jr bought on mtgox, minus the number of btc sold, is 2,819... over the account lifetime... ignoring whatever profit he took from trading, that's a balance of at least $1.8 mil USD in bitcoins
331 2014-03-17 06:31:40 <coinnabis> which is great. bravo...
332 2014-03-17 06:31:53 <Luke-Jr> coinnabis: are you *trying* to get banned?
333 2014-03-17 06:34:09 <coinnabis> Luke-Jr: you've done great things for bitcoin. it's ok that people know you've earned millions from your involvement with it. why you're playing the part of a pauper who's just happy to be a bitcoin supporter is beyond me. the info is all out there. no need to be coy
334 2014-03-17 06:35:05 <justanotheruser> coinnabis: Are you with the media or something, why do you care so much about money?
335 2014-03-17 06:35:29 <Ademan> username sounds more like a silkroad reject
336 2014-03-17 06:36:34 <venzen> coming here and baiting a developer... some agenda for sure... snake
337 2014-03-17 06:43:25 <koriander22> hi devs...
338 2014-03-17 06:44:13 <koriander22> can anyone tell me how the system handles a fork in the blockchain
339 2014-03-17 06:44:31 <Luke-Jr> koriander22: elaborate?
340 2014-03-17 06:47:52 <koriander22> elaborate! or elaborate?
341 2014-03-17 06:49:35 <koriander22> well, 2 blocks are found the same time, so we got a fork. How fast will the system rekognize the fork ?
342 2014-03-17 06:50:06 <Luke-Jr> next blcok
343 2014-03-17 06:52:10 <koriander22> what happens with the transactions on the invalid branch? Are they all invalid then?
344 2014-03-17 06:52:25 <justanotheruser> koriander22: they are re-added to the mempool
345 2014-03-17 06:53:05 <koriander22> so they will be addet to the next valid block ?
346 2014-03-17 06:53:20 <Ademan> they will be available to be added to a future block
347 2014-03-17 06:53:52 <koriander22> k, thx
348 2014-03-17 06:55:04 <koriander22> did we ever seen a fork in the btc system ?
349 2014-03-17 06:55:24 <Ademan> yep
350 2014-03-17 06:55:45 <Luke-Jr> koriander22: it's a regular occurance
351 2014-03-17 06:56:04 <jcorgan> maybe every 2-3 days it seems
352 2014-03-17 06:56:10 <Ademan> Luke-Jr: longer than a block or two?
353 2014-03-17 06:56:15 <Luke-Jr> Ademan: not usually
354 2014-03-17 06:56:57 <jcorgan> https://blockchain.info/charts/n-orphaned-blocks
355 2014-03-17 06:57:24 <koriander22> nice tool...
356 2014-03-17 06:57:26 <jcorgan> wait, that's number of orphans, not fork length
357 2014-03-17 06:59:15 <koriander22> Luke-Jr: What was the max lenght of a fork?
358 2014-03-17 06:59:24 <Luke-Jr> koriander22: 80 or 90 blocks I think
359 2014-03-17 06:59:25 <ququ> hi
360 2014-03-17 07:00:04 <ququ> how to use lockunspent unlock?
361 2014-03-17 07:00:11 <jcorgan> Luke-Jr: o.O? I thought the length 26 fork last year was the largest
362 2014-03-17 07:00:16 <ququ> when I use it ,I get a error
363 2014-03-17 07:00:19 <koriander22> Luke-Jr: Wow, this are a lot of invalid transactions
364 2014-03-17 07:01:18 <Luke-Jr> jcorgan: that wasn't even a real fork
365 2014-03-17 07:01:23 <justanotheruser> jcorgan: were there any real tx in that?
366 2014-03-17 07:01:30 <Luke-Jr> koriander22: block forks != invalid transactions
367 2014-03-17 07:01:56 <Luke-Jr> looks like only 53 blocks actually
368 2014-03-17 07:02:03 <Luke-Jr> https://en.bitcoin.it/wiki/CVEs#CVE-2010-5139
369 2014-03-17 07:02:26 <jcorgan> oh, that one, before my time
370 2014-03-17 07:02:42 <koriander22> Luke-Jr: i know, but as statet befor, all thos transactions has to go back in mempool and append to the next valid block right ?
371 2014-03-17 07:02:50 <Luke-Jr> right
372 2014-03-17 07:03:18 <ququ> hi luke ,can you tell me how to use lockunspent unlock? please?
373 2014-03-17 07:03:19 <jcorgan> koriander22: they go back into the mempool, but whether they go into the *next* block is entirely up to miners
374 2014-03-17 07:05:12 <koriander22> Luke-Jr: So i wonder, how can get an invalid branch that lenght? I thought broadcast's take a few seconds to make a new block public and find a new block takes nearly always a few mins
375 2014-03-17 07:05:38 <Luke-Jr> it's random
376 2014-03-17 07:07:28 <koriander22> thx for helping me and answer my questions...
377 2014-03-17 07:16:50 <Ademan> dang, 53 blocks
378 2014-03-17 07:17:26 <justanotheruser> Ademan: The only people that lost money from it were miners. I believe they either had a bug, or didn't upgrade
379 2014-03-17 07:18:37 <Ademan> wow, patched the code to kill a block, that truly was a different era
380 2014-03-17 07:51:39 <ququ> -.-
381 2014-03-17 08:44:11 <chichov> Can anyone help with two inconsistencies I've found?
382 2014-03-17 08:45:05 <Luke-Jr> chichov: ?
383 2014-03-17 08:45:19 <chichov> 1) In OP_CHECKSIG (see https://en.bitcoin.it/w/images/en/7/70/Bitcoin_OpCheckSig_InDetail.png) it states that the script is copied from the last OP_CODESEP, whereas it depicts that it's from the second last OP_CODESEP
384 2014-03-17 08:46:48 <chichov> 2) In the sighash unit tests (sighash_test.cpp) the OP_CODESEP's are (if I understand it correctly) simply removed from the referenced public key script, which is different again from what stands in the wiki.
385 2014-03-17 08:48:35 <chichov> can anyone resolve this problem?
386 2014-03-17 08:48:50 <Luke-Jr> feel free to
387 2014-03-17 08:49:00 <Luke-Jr> as a rule, the code is correct
388 2014-03-17 08:49:49 <Luke-Jr> (if you find the code has definitely changed behaviour since 0.8.1, privately contact the security mailing list with detailed explanation)
389 2014-03-17 09:18:47 <chichov> Luke-Jr: if I'd have the time I'd have done it myself
390 2014-03-17 09:18:59 <chichov> however, since I don't I'm asking around here.
391 2014-03-17 09:32:46 <vondra> ;; prevdiff
392 2014-03-17 09:32:49 <gribble> 3815723798.81
393 2014-03-17 09:47:15 <airbreather> sheesh... almost time to shut off my BFL 5GH/s unit for inefficiency >.<
394 2014-03-17 09:53:00 <venzen> it's hot season (mid summer) so hot and dry most days - only thundershowers now and again... today is very dry... the other season is wet seaton - 6 months of monsoon rains
395 2014-03-17 09:54:11 <venzen> today is about 35 or 40 - i' not sure... maybe it's 30 and my measure of hot is out :)
396 2014-03-17 09:54:21 <venzen> sorry wrong window
397 2014-03-17 14:27:17 <disident> hello, someone know how to fix glibbest build on maverick ? https://github.com/bitcoin/bitcoin/issues/3228
398 2014-03-17 14:38:08 <venzen> hehe :) man's work!
399 2014-03-17 14:40:10 <venzen> disident: you mean Ubuntu 10.10?
400 2014-03-17 14:40:27 <disident> venzen: Mac OS X 10.9
401 2014-03-17 14:43:56 <venzen> disident: ok, sorry can't help
402 2014-03-17 15:12:22 <heipa> hey
403 2014-03-17 15:12:55 <heipa> is there some easy way to convert 52 chars long priv key into its 51 char equivalent?
404 2014-03-17 15:13:38 <michagogo> cloud|heipa: Could you elaborate and/or provide an example?
405 2014-03-17 15:15:08 <heipa> when I issue dumpprivkey it gives 52 lenght private key aka private key of compressed address, in brief I want to see how those online wallet sites work and derive 130 hex public key
406 2014-03-17 15:15:16 <heipa> via 51 chars private key :)
407 2014-03-17 15:16:40 <heipa> to get private key associated with uncompressed public key via compressed wallet address private key
408 2014-03-17 15:17:48 <kjj> first, you need to understand different key formats
409 2014-03-17 15:19:04 <kjj> the private key is just 256 bits, but it can be encoded in different ways, and it can carry different metadata
410 2014-03-17 15:19:57 <sipa> from bitcoin's perspective tge comptessed and uncompressed one are completely separate
411 2014-03-17 15:20:16 <kjj> dumpprivkey exports the key in WIF format, which is base58 encoded, and carrying metadata about the pubkey that *should* be generated to match it
412 2014-03-17 15:20:20 <sipa> as thry have different private keys, different public keys, different addresses
413 2014-03-17 15:22:09 <kjj> as Sipa is saying, bitcoin considers the private key itself, along with the metadata, to be an atomic whole
414 2014-03-17 15:22:39 <heipa> sipa so say I have an address in the wallet, I have WIF compressed key, is there so way to derive an uncompressed WIF private key?
415 2014-03-17 15:23:24 <sipa> yes, but it is pointless
416 2014-03-17 15:23:33 <kjj> just unpack the WIF, remove the compression flag, then repack. but this is almost certainly not a useful operation and does something you probably don't intend to do
417 2014-03-17 15:24:26 <heipa> well I was curious how to derive 130 chars hex public address from wallet address
418 2014-03-17 15:24:28 <kjj> the only time it would be useful is if you had engraved the private key in stone or something and wanted to generate a second address using it.
419 2014-03-17 15:24:34 <heipa> and how keys are working with each other
420 2014-03-17 15:24:40 <heipa> lol
421 2014-03-17 15:24:53 <heipa> lolol
422 2014-03-17 15:25:44 <kjj> to derive the pubkey, you just unpack the WIF, multiply G by the private key, and then encode the pubkey into whatever format you need it in (paying attention to metadata from the WIF as you do)
423 2014-03-17 15:27:18 <kjj> https://bitcointalk.org/index.php?topic=129652.5
424 2014-03-17 15:27:49 <kjj> https://bitcointalk.org/index.php?topic=205490.0
425 2014-03-17 15:27:54 <sipa> heipa: private key -> public key -> address
426 2014-03-17 15:28:01 <sipa> both steps are irreversible
427 2014-03-17 15:28:15 <sipa> you cannot compute the pubkey from an address
428 2014-03-17 15:28:47 <sipa> and if the address is for a compressed key, its pubkey is 66 characters hex, not 130
429 2014-03-17 15:29:19 <heipa> yes
430 2014-03-17 15:29:24 <heipa> as per https://www.bitaddress.org/bitaddress.org-v2.8.1-SHA1-a6e63f2712851710255a27fa0f22ef7833c2cd07.html
431 2014-03-17 15:29:36 <sipa> (33 bytes instead of 65)
432 2014-03-17 15:30:28 <heipa> sipa so how to unpack compressed keys at all?
433 2014-03-17 15:30:43 <sipa> you don't
434 2014-03-17 15:30:54 <sipa> they are just smaller keys
435 2014-03-17 15:31:09 <heipa> yes I realise that
436 2014-03-17 15:31:30 <sipa> from a crypto point of view, they are a more efficient encoding for the samwe mathemathical point
437 2014-03-17 15:31:41 <heipa> yes save chain space
438 2014-03-17 15:31:50 <sipa> but unless you are writing crypto code (don't!)
439 2014-03-17 15:31:59 <sipa> you don't care about thast
440 2014-03-17 15:32:18 <sipa> from bitcoin's persepctive these are just 33 byte pubkeys instead of 65 byte ones
441 2014-03-17 15:32:26 <heipa> its nice to know how things work
442 2014-03-17 15:33:02 <heipa> as it allows fuller understanding of entire code :)
443 2014-03-17 15:33:19 <kjj> actually, it really doesn't
444 2014-03-17 15:33:31 <heipa> how come?
445 2014-03-17 15:33:33 <thermoman> is this wanted?
446 2014-03-17 15:33:35 <thermoman> bitcoin-0.9.0rc3-linux.tar.gz contains bitcoin-0.9.0rc3-linux/src/bitcoin-0.9.0.tar.gz
447 2014-03-17 15:33:37 <kjj> bitcoin treats most of this stuff as black box operations done by openssl
448 2014-03-17 15:33:38 <thermoman> unpacking bitcoin-0.9.0.tar.gz each and every file is timestamped Jun 1 2013
449 2014-03-17 15:33:51 <sipa> bitcoin never 'unpacks' them
450 2014-03-17 15:34:25 <kjj> behind the scenes, we understand how openssl is treating them, but as far as bitcoin is concerned, they are just different strings of data
451 2014-03-17 15:34:47 <heipa> I see so its kinda like http://kjur.github.io/jsrsasign/sample-ecdsa.html ? :D
452 2014-03-17 15:38:02 <thermoman> configure: error: Could not link against boost_thread !
453 2014-03-17 15:38:06 <thermoman> what's the problem here?
454 2014-03-17 15:38:20 <thermoman> ii libboost-thread1.42-dev 1.42.0-4 portable C++ multi-threading
455 2014-03-17 15:38:24 <thermoman> ii libboost-thread1.42.0 1.42.0-4 portable C++ multi-threading
456 2014-03-17 15:38:49 <heipa> which OS?
457 2014-03-17 15:38:54 <thermoman> # Debian Squeeze
458 2014-03-17 15:39:07 <heipa> maybe install 1.55?
459 2014-03-17 15:39:20 <heipa> well check makefile also
460 2014-03-17 15:39:35 <heipa> which file could not link?
461 2014-03-17 15:40:33 <thermoman> conftest.cpp:32:28: error: boost/chrono.hpp: No such file or directory
462 2014-03-17 15:40:41 <heipa> sipa ok bitcoin got some code to work with opensll with it
463 2014-03-17 15:40:59 <thermoman> configure:10946: checking whether the Boost::Chrono library is available
464 2014-03-17 15:40:59 <thermoman> configure:10970: g++ -c -g -O2 -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -Wstack-protector -fstack-protector-all -fPIE -DBOOST_SPIRIT_THREADSAFE -DHAVE_BUILD_INFO -D__STDC_FORMAT_MACROS -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include conftest.cpp >&5
465 2014-03-17 15:42:28 <heipa> sudo apt-get install build-essential libssl-dev libdb-dev libdb++-dev libboost-all-dev git have u done that? :D
466 2014-03-17 15:42:53 <heipa> well apart git which is probably already installed
467 2014-03-17 15:43:30 <thermoman> i don't have all libboost dev packages installed
468 2014-03-17 15:43:36 <thermoman> seems i missed one
469 2014-03-17 15:43:37 <heipa> so install
470 2014-03-17 15:43:45 <heipa> :)
471 2014-03-17 15:44:11 <heipa> sipa so how those online bitcoin address sites can display all wallets format? :)
472 2014-03-17 15:45:30 <kjj> remember the chain he mentioned? if you start on the left side of it, it is easy to move right. if you start on the right, it is impossible to move left
473 2014-03-17 15:46:09 <heipa> oki got it
474 2014-03-17 15:46:21 <heipa> have to make private key -> then public key -> then address
475 2014-03-17 15:46:46 <heipa> from secret to open to compact open a bit like genesis :D
476 2014-03-17 15:47:46 <kjj> right. if you give an address, it *might* be able to find a pubkey in the blockchain, if that address has already been used to sign a transaction. otherwise, it can't do anything with the address other than reformat it into hex or swahili or something
477 2014-03-17 15:50:49 <heipa> kjj give address means like grep kinda? some way u speficify address as a string and search chain? :)
478 2014-03-17 15:50:57 <dhill> anyone have 2304c60c0d9f4da31af9804e85c3e1520ddcf4d2496269b6ed72d33b18b17e03 in their mempool?
479 2014-03-17 15:52:19 <kjj> dhill: no (three nodes, remote networks)
480 2014-03-17 15:52:43 <Apocalyptic> dhill, confirmed no
481 2014-03-17 15:52:52 <dhill> danke
482 2014-03-17 15:53:01 <kjj> heipa: they would need to have a database backing the site. searching the blockchain in raw form would be slow
483 2014-03-17 15:53:57 <heipa> yes like mariadb can be fast
484 2014-03-17 15:55:39 <michagogo> cloud|dhill: I also do not have it
485 2014-03-17 15:55:40 <heipa> what will happen if someone send some other coins that use same encoding to bitcoin address already cointaining some bitcoins? like kinda spam? :)
486 2014-03-17 15:56:10 <michagogo> cloud|heipa: I'm not sure I understand the question
487 2014-03-17 15:56:11 <heipa> well since its private key it could in theory manage many things
488 2014-03-17 15:56:11 <kjj> free money
489 2014-03-17 15:56:33 <michagogo> cloud|Bitcoin software is unaware of other coins
490 2014-03-17 15:56:39 <michagogo> cloud|and vice versa
491 2014-03-17 16:02:29 <helo> it's aware in other ways :D
492 2014-03-17 16:02:59 <heipa> helo? lol
493 2014-03-17 16:03:28 <helo> ACTION returns from whence he came
494 2014-03-17 16:03:39 <heipa> means here u are now
495 2014-03-17 16:03:48 <heipa> :P
496 2014-03-17 16:08:44 <heipa> Unless you are computing EC multiply, SHA-256 and RIPEMD-160 with pen and paper, you are going to need tools either way. lol
497 2014-03-17 16:08:52 <heipa> kjj just read u comments
498 2014-03-17 16:12:42 <ConvivialMatt> any explanation on these 30% fee transactions happening?
499 2014-03-17 16:12:44 <ConvivialMatt> https://blockchain.info/address/1JSJUGcaQX8ZLV8K6zk6cXykhNdivqn2p8
500 2014-03-17 16:13:18 <disident> Someone know how to build bitcoin-qt on Mac OS Maverick ? can't fix that : https://github.com/bitcoin/bitcoin/issues/3228
501 2014-03-17 16:13:20 <disident> thanks
502 2014-03-17 16:17:35 <hearn> ConvivialMatt: probably legit. that's a huge tx
503 2014-03-17 16:17:39 <hearn> 53kb
504 2014-03-17 16:22:01 <michagogo> cloud|disident: IIRC gavinandresen and cfields are our resident Mac users
505 2014-03-17 16:22:27 <disident> michagogo|cloud: thanks
506 2014-03-17 16:22:30 <hearn> disident: i had that problem too. try uninstalling and reinstalling the dependencies
507 2014-03-17 16:22:35 <hearn> i use brew and it worked for me
508 2014-03-17 16:22:36 <thermoman> does bitcoind compile and run fine with libdb5.1?
509 2014-03-17 16:22:44 <michagogo> cloud|thermoman: yep
510 2014-03-17 16:22:48 <thermoman> justupgrading from debian squeeze zu wheezy
511 2014-03-17 16:22:54 <disident> hearn: ok going to try that
512 2014-03-17 16:22:56 <michagogo> cloud|thermoman: But one important thing to note
513 2014-03-17 16:23:02 <gavinandresen> disident: rebuilding homebrew boost worked for me with OSX 10.8 and XCode 5.1
514 2014-03-17 16:23:12 <michagogo> cloud|BDB 5.1 is not backwards-compatible with 4.8
515 2014-03-17 16:23:12 <thermoman> michagogo|cloud: yes?