1 2013-08-18 01:30:48 <rubino123> I am having trouble using the python-jsonrpc to work with bitcoind
2 2013-08-18 01:31:12 <rubino123> I am getting a connection refused error
3 2013-08-18 01:32:06 <rubino123> I checked bitcoin.conf and it looks ok: just dummy settings for rpcuser and rpcpassword
4 2013-08-18 01:32:10 <rubino123> defualt ip
5 2013-08-18 13:59:55 <hardfalcon> hi everyone :)
6 2013-08-18 14:04:32 <hardfalcon> I'd be willing to write a patch for bitcoin-qt to make it use the hardware accelerated padlock engine of my via nano CPU so I'm not sitting here with 10-15 hours of 100% CPU load just for resyncing with the hive when I haven't started bitcoin-qt for a few weeks. But TBH I'm not exactly sure where to start - would it be enough to make sure that openssl uses the hardware acceleration and then simply recompile the vanilla bitcoin-qt sou
7 2013-08-18 14:05:01 <Luke-Jr> I don't think padlock will accelerate things much
8 2013-08-18 14:05:14 <nanotube> hardfalcon: fwiw, your msg got cut off at 'bitcoin-qt sou'
9 2013-08-18 14:05:27 <hardfalcon> oh, thx
10 2013-08-18 14:05:27 <Luke-Jr> but you could look at BFGMiner's VIA padlock CPU miner code
11 2013-08-18 14:05:34 <hardfalcon> * bitcoin-qt source code, or do I have to patch the bitcoin-qt source code by itself?
12 2013-08-18 14:05:42 <sipa> i'm not sure any of the CPU intensive parts of chain validation can be accelerated
13 2013-08-18 14:05:58 <sipa> well, an OpenCL full ECDSA implementation would
14 2013-08-18 14:06:05 <Luke-Jr> the only chance padlock will help significantly, is if it does ECDSA yeah
15 2013-08-18 14:06:28 <sipa> chain validation is not the same thing as mining
16 2013-08-18 14:06:32 <Luke-Jr> sipa: padlock is VIA's x86 extensions for SHA256 and some other things (not sure what it includes)
17 2013-08-18 14:06:34 <hardfalcon> Luke-Jr: I'm pretty sure that CPU speed is the limiting factor on my machine because the CPU is dead slow by itself, I have a 50mbit/s VDSL2 line and the harddisk definitely provides the data faster than the CPU can hash it
18 2013-08-18 14:06:34 <sipa> it's a very different and much more complex thing
19 2013-08-18 14:06:50 <Luke-Jr> hardfalcon: verification isn't hashing.
20 2013-08-18 14:07:10 <Luke-Jr> there's some TINY subset of verification that involves checking the hashes
21 2013-08-18 14:07:13 <sipa> it needs to verify ECDSA signatures, which is relatively slow
22 2013-08-18 14:07:19 <sipa> and very slow compared to SHA256
23 2013-08-18 14:07:22 <hardfalcon> oh ok
24 2013-08-18 14:07:34 <hardfalcon> well the via CPU has some capability to speed that up as well IIRC
25 2013-08-18 14:07:47 <hardfalcon> the padlock engine does also feature a HW accelerated montgomery multiplicator
26 2013-08-18 14:07:48 <sipa> yes and no
27 2013-08-18 14:07:53 <sipa> hmmm
28 2013-08-18 14:08:11 <hardfalcon> (something like "square and multiply" in silicon if I understand correctly)
29 2013-08-18 14:09:03 <sipa> i haven't seen any references to that in the openssl source code
30 2013-08-18 14:09:15 <hardfalcon> but ECC is tricky, gotta admit I don't have any experience with *that* :/
31 2013-08-18 14:09:25 <Luke-Jr> http://referaat.cs.utwente.nl/conference/14/paper/7244/speeding-up-ec-cryptography-on-embedded-hardware.pdf
32 2013-08-18 14:10:12 <sipa> hardfalcon: in any case, there is certainly potential for speeding that up
33 2013-08-18 14:10:43 <hardfalcon> Luke-Jr: thx for the link, that's an interesting paper :)
34 2013-08-18 14:10:52 <sipa> hardfalcon: i wrote a (software) implementation of ECDSA specifically for secp256k1, and on 64-bit CPU's it results in a ~6 fold speedup over OpenSSL
35 2013-08-18 14:11:11 <hardfalcon> sipa: what version of openssl?
36 2013-08-18 14:11:36 <hardfalcon> AFAIK their padlock support is broken on x86_64
37 2013-08-18 14:11:45 <shesek> does anyone know what's the status of bitcoinjs-lib? is it abandon?
38 2013-08-18 14:11:57 <Luke-Jr> ???
39 2013-08-18 14:11:58 <sipa> hardfalcon: oh sure, it's purely x86_64
40 2013-08-18 14:12:09 <Luke-Jr> does a padlock x86_64 CPU exist?
41 2013-08-18 14:12:09 <sipa> hardfalcon: both openssl and my code
42 2013-08-18 14:12:16 <hardfalcon> yes
43 2013-08-18 14:12:30 <hardfalcon> I've got one and I'm using it as I'm chatting with you ;)
44 2013-08-18 14:12:35 <hardfalcon> even a dualcore
45 2013-08-18 14:12:43 <hardfalcon> via nano x2, 1.2 ghz
46 2013-08-18 14:12:57 <Luke-Jr> hmm
47 2013-08-18 14:13:01 <sipa> i do an ECDSA validation in 300k CPU cycles or so (on a i7-2670QM)
48 2013-08-18 14:13:11 <hardfalcon> comes even with VMX (they licensed the vanderpool technology from intel)
49 2013-08-18 14:13:30 <hardfalcon> but of course that is dead slow as well, it's just 1.2ghz
50 2013-08-18 14:17:51 <hardfalcon> sipa: I gotta admit I don't have any comparison figures for that
51 2013-08-18 14:19:25 <michagogo> So the other day, I was wondering if Wireshark understood Bitcoin
52 2013-08-18 14:19:46 <sipa> michagogo: someone once started writing a wireshark recognization script for it, or whatever it's called
53 2013-08-18 14:19:51 <sipa> i can't remember whether he completed it
54 2013-08-18 14:19:54 <michagogo> After a while of Googling (after opening it and seeing it apparently didn't)...
55 2013-08-18 14:20:26 <michagogo> Turns out that a bitcoin dissector actually does come with it -- just not in the older version I had
56 2013-08-18 14:21:04 <sipa> ha
57 2013-08-18 14:22:04 <michagogo> And the googling didn't even turn that up -- I was looking for a plugin and it took me a while to check what the latest version was
58 2013-08-18 14:22:15 <michagogo> or rather, took me a while to think of checking
59 2013-08-18 14:23:37 <Luke-Jr> neat, it does everything except disassemble scripts
60 2013-08-18 14:24:01 <michagogo> Huh.
61 2013-08-18 14:24:48 <michagogo> Should [bitcoin protocol -> inventory message -> inventory vector -> data hash] be the TXID of a transaction?
62 2013-08-18 14:25:32 <sipa> if it's a tx being announced
63 2013-08-18 14:25:35 <sipa> it can also be a block hash
64 2013-08-18 14:25:40 <michagogo> Yeah, it's a tx
65 2013-08-18 14:25:44 <sipa> it can be
66 2013-08-18 14:25:58 <michagogo> (I set up wireshark to listen on port 18333 and sent myself some testcoins)
67 2013-08-18 14:26:43 <michagogo> Hmm.
68 2013-08-18 14:27:13 <michagogo> I wonder what's going wrong here? http://i.imgur.com/q2pFevO.png
69 2013-08-18 14:27:52 <michagogo> Also, apparently my transaction's change of a block hash was exactly what a testnet miner needed to solve a block -- it confirmed in under 2 seconds
70 2013-08-18 14:28:05 <michagogo> The txid is f8f98e476e313e9ac0830de0da14e95bbc3985052396f445a75abf991856eda4
71 2013-08-18 14:28:05 <sipa> is something wrong?
72 2013-08-18 14:28:12 <michagogo> I'm not seeing that there
73 2013-08-18 14:28:13 <sipa> ah, byteswapped
74 2013-08-18 14:28:17 <michagogo> ...what
75 2013-08-18 14:28:20 <michagogo> Oh.
76 2013-08-18 14:28:24 <michagogo> Gahhhhh.
77 2013-08-18 14:28:50 <michagogo> Bitcoin-qt byteswaps its data?
78 2013-08-18 14:29:00 <sipa> yes and no
79 2013-08-18 14:29:19 <sipa> its interprets byte arrays as little-endian encoded integers
80 2013-08-18 14:29:57 <michagogo> That's right-to-left?
81 2013-08-18 14:29:57 <sipa> and if you print that number for human consumption, you put the most significant digits first
82 2013-08-18 14:30:01 <sipa> but internally, nothing is swapped
83 2013-08-18 14:30:09 <michagogo> I see.
84 2013-08-18 14:30:36 <michagogo> So it gets transmitted backwards, but when the software displays it it puts it back in the right order?
85 2013-08-18 14:30:50 <michagogo> And WS is showing it the way it's being transmitted...
86 2013-08-18 14:30:51 <michagogo> :-/
87 2013-08-18 14:31:23 <sipa> i'd rather say it's displayed backwards
88 2013-08-18 14:31:24 <sipa> :)
89 2013-08-18 14:31:35 <sipa> but that's s philosophical discussion
90 2013-08-18 14:31:40 <michagogo> ACTION still doesn't understand why little vs big endian is a thing
91 2013-08-18 14:32:04 <sipa> well humans use big endian
92 2013-08-18 14:32:09 <sipa> and some computers use little endian
93 2013-08-18 14:32:15 <sipa> it's got to cause problems somewhere :)
94 2013-08-18 14:32:43 <michagogo> [19:32:09] <sipa> and some computers use little endian
95 2013-08-18 14:32:51 <hardfalcon> well you could use ARM to solve that problem ^^
96 2013-08-18 14:32:51 <michagogo> Right, that's the part I don't understand
97 2013-08-18 14:33:25 <sipa> michagogo: it's very convenient that you can use a pointer to 32-bit int as a pointer to 64-bit int and vice verse
98 2013-08-18 14:33:37 <sipa> on big-endian, you need to add/subtract an offset
99 2013-08-18 14:52:47 <hardfalcon> Luke-Jr: the conclusion of that paper is very interesting as well, because apparently they also had problems with the padlock engine on 64 bit, just like the openssl people
100 2013-08-18 15:08:14 <michagogo> Just to make sure I'm not making a stupid mistake here... A txid is always 64 hex digits, right?
101 2013-08-18 15:08:48 <lianj> yes
102 2013-08-18 15:09:47 <michagogo> k
103 2013-08-18 15:25:21 <michagogo> ...okay, that didn't go as well as I'd hoped
104 2013-08-18 15:25:39 <michagogo> I guess I shouldn't have expected it to.
105 2013-08-18 15:26:21 <michagogo> I think I've found (one of) blockchain.info's node(s), based on their site listing how long they've been connected to me
106 2013-08-18 15:26:58 <michagogo> I tried creating a raw transaction (just spending bitcoins back to myself) and using bc.i's pushtx to confirm that it's them
107 2013-08-18 15:27:57 <michagogo> I guess, in hindsight, I shouldn't have expected bc.i to be the first to send a pushtx'd transaction to every one of the ~875 nodes they're connected to
108 2013-08-18 15:29:20 <sipa> why not?
109 2013-08-18 15:32:07 <michagogo> sipa: Because they can't do it simultaneously
110 2013-08-18 15:32:56 <michagogo> It probably didn't take more than a second or two to send to the 875 nodes, but in that time it's been spreading from those nodes as well
111 2013-08-18 15:33:23 <sipa> right
112 2013-08-18 15:33:47 <michagogo> (was that some kind of test?)
113 2013-08-18 15:34:22 <sipa> no
114 2013-08-18 15:34:35 <sipa> though there's way to make it propagate more evenly, i guess
115 2013-08-18 15:35:40 <michagogo> ACTION guesses
116 2013-08-18 15:35:40 <michagogo> Send invs to everyone, then get the getdatas from everyone, and then send tx to everyone?
117 2013-08-18 15:35:51 <sipa> i mean having several outgoing nodes
118 2013-08-18 15:36:07 <sipa> and send the pushtx simultaneously to all
119 2013-08-18 15:39:00 <michagogo> Ah
120 2013-08-18 15:39:14 <michagogo> I mean, for all I know that's what they do
121 2013-08-18 15:45:44 <i2pRelay> <toran> hello
122 2013-08-18 15:46:26 <i2pRelay> <toran> ?nicks
123 2013-08-18 15:47:58 <i2pRelay> <toran> let's say your neighborhood wants to repave its roads
124 2013-08-18 15:48:16 <i2pRelay> <toran> it sets up a bitcoin address, and neighbors donate to it
125 2013-08-18 15:48:38 <i2pRelay> <toran> finally, someone comes along to pave the road and would now like to claim the money
126 2013-08-18 15:49:13 <i2pRelay> <toran> five or so neighbors are randomly selected to verify the road was in fact paved well
127 2013-08-18 15:49:32 <i2pRelay> <toran> then the construction company is given the money
128 2013-08-18 15:50:07 <i2pRelay> <toran> without using trusted parties and only rpc calls, what is the best way to handle the donation address in bitcoin?
129 2013-08-18 15:50:57 <i2pRelay> <toran> i was thinking about multisigaddresses, but it is not clear who would own the private keys
130 2013-08-18 15:51:07 <Luke-Jr> you need trusted parties..
131 2013-08-18 15:51:08 <sipa> private keys are private
132 2013-08-18 15:51:19 <i2pRelay> <toran> i mean, why make five random people the road paving kings of the whole world?
133 2013-08-18 15:51:36 <sipa> they're only the road paving kings of one street
134 2013-08-18 15:51:51 <i2pRelay> <toran> why do you need trusted parties?
135 2013-08-18 15:52:05 <sipa> scalability
136 2013-08-18 15:52:35 <i2pRelay> <toran> can you say more?
137 2013-08-18 15:53:11 <sipa> how will you tell the protocol who was selected to be the five neighbors who are even allowed to do the validation?
138 2013-08-18 15:53:23 <sipa> how will you even decide that
139 2013-08-18 15:53:26 <sipa> and how will you agree on it?
140 2013-08-18 15:53:33 <sipa> that's not something the protocol can do for you
141 2013-08-18 15:54:01 <michagogo> toran: You want to ask the people who will be authorized to jointly release the funds for public keys
142 2013-08-18 15:54:12 <michagogo> Use those public keys to create a multisig address
143 2013-08-18 15:54:18 <michagogo> Everyone pays into that multisig address
144 2013-08-18 15:54:32 <sipa> you can have 5 keys from those neighbors, build a multisig address from it, have everyone donate to that, and have them release it to the construction company
145 2013-08-18 15:54:35 <sipa> that's all easy
146 2013-08-18 15:54:50 <michagogo> And then m of the n privkeys you use need to sign
147 2013-08-18 15:54:54 <sipa> but that only works when you have those verifiers identified and people trust them
148 2013-08-18 15:55:00 <michagogo> (or was it the other way around)>
149 2013-08-18 15:56:06 <i2pRelay> <toran> sipa, i was asking about the addresses, not the random selection
150 2013-08-18 15:56:33 <sipa> so what's the problem?
151 2013-08-18 15:56:39 <sipa> everyone has his own private key
152 2013-08-18 15:56:48 <sipa> you construct a multisig address from the selected verifiers
153 2013-08-18 15:56:56 <sipa> and have people pay to that
154 2013-08-18 15:59:00 <michagogo> sipa: Found a way around the endianness problem
155 2013-08-18 15:59:19 <nsh> did you superglue the ends together?
156 2013-08-18 15:59:21 <michagogo> Using this line of ruby code: Clipboard.copy(Clipboard.paste.scan(/\\h\\h/).reverse.join(":"))
157 2013-08-18 15:59:34 <michagogo> (using the 'clipboard' rubygem)
158 2013-08-18 16:00:08 <sipa> what does the clipboard have to do with anything?
159 2013-08-18 16:00:18 <sipa> i'd suggest changing the dissector to flip the bytes :)
160 2013-08-18 16:01:16 <michagogo> sipa: I think the dissector is compiled into the software, though :-/
161 2013-08-18 16:01:34 <michagogo> ACTION doesn't want to get in to the source and trying to get it to compile
162 2013-08-18 16:01:38 <sipa> and the source cannot be changed? :p
163 2013-08-18 16:01:58 <michagogo> ACTION doesn't want to get in to the source and trying to get it to compile
164 2013-08-18 16:02:14 <sipa> ok
165 2013-08-18 16:02:33 <michagogo> Anyway, it's an easy way to transform the txid into the format wireshark wants it
166 2013-08-18 16:02:53 <michagogo> Both in the right order, and with : separators
167 2013-08-18 16:06:06 <Luke-Jr> yay gentoo
168 2013-08-18 16:07:28 <michagogo> Lol
169 2013-08-18 16:07:36 <michagogo> Accidentally did rm wallet.dat
170 2013-08-18 16:07:41 <michagogo> instead of rm debug.log
171 2013-08-18 16:07:54 <sipa> testnet?
172 2013-08-18 16:08:01 <michagogo> Fortunately it was on my patched testnet mining node