1 2013-05-12 00:08:50 <flound1129> are txid's guaranteed unique?
2 2013-05-12 00:09:31 <lianj> yes-ish. not guaranteed though
3 2013-05-12 00:09:40 <flound1129> ok
4 2013-05-12 00:09:53 <flound1129> is there a way to get the block number for a generate/immature transaction?
5 2013-05-12 00:10:17 <lianj> what do you mean?
6 2013-05-12 00:10:25 <flound1129> well
7 2013-05-12 00:10:50 <flound1129> if my pool finds a block
8 2013-05-12 00:11:00 <flound1129> I have the block number in the shares db
9 2013-05-12 00:11:05 <flound1129> but no way to match it up with txid
10 2013-05-12 00:11:27 <denisx> sounds like pushpoold
11 2013-05-12 00:12:38 <flound1129> stratum
12 2013-05-12 00:14:36 <flound1129> and the solution logged in the shares table doesn't match the one in the transaction
13 2013-05-12 00:22:09 <luke-jr_> lianj: actually, unspent txids are guaranteed to be unique
14 2013-05-12 00:22:25 <luke-jr_> flound1129: note, however, that the same transaction may change txids
15 2013-05-12 00:26:02 <NxTitle> Luke-Jr: cool, didn't know that - what guarantees them to be unique?
16 2013-05-12 00:26:27 <NxTitle> or is it just so improbable as to not happen in practice?
17 2013-05-12 00:26:40 <cjd> id == sha256 of the transaction
18 2013-05-12 00:27:13 <Luke-Jr> NxTitle: it's super-improbable, but also there is a protocol rule that the same txids cannot enter the UTXO more than once
19 2013-05-12 00:27:13 <NxTitle> cjd: I know that much, but how is that guaranteed to be unique?
20 2013-05-12 00:27:35 <NxTitle> Luke-Jr: ah, I see - so if it collides, none of the other nodes will accept it?
21 2013-05-12 00:27:57 <cjd> if you can make sha256 collisions then bitcoin has some other issues
22 2013-05-12 00:28:04 <cjd> not to mention the rest of the world
23 2013-05-12 00:28:05 <SomeoneWeird> so does the rest of the world
24 2013-05-12 00:28:06 <NxTitle> cjd: I mean unintentoinally
25 2013-05-12 00:28:07 <SomeoneWeird> lol
26 2013-05-12 00:28:23 <NxTitle> obviously it's super improbable
27 2013-05-12 00:28:24 <Luke-Jr> NxTitle: it won't be mined, at least
28 2013-05-12 00:28:26 <lianj> cjd: there are 4 blocks that share the same coinbase tx. legacy mess
29 2013-05-12 00:28:30 <denisx> cjd: if you can make sha256 collisions then the whole world has a problem
30 2013-05-12 00:28:31 <NxTitle> Luke-Jr: ah, okay
31 2013-05-12 00:28:37 <SomeoneWeird> denisx, yep
32 2013-05-12 00:28:57 <denisx> oh, I'm late, I see...
33 2013-05-12 00:28:57 <NxTitle> interesting
34 2013-05-12 00:29:32 <cjd> lianj: yeah, I remember when that was discovered.. one of those "I'm not sure if this is bad but I don't like it" things
35 2013-05-12 00:30:09 <Luke-Jr> denisx: Still waiting on a resolution to the copyright issues in your contributions. This is holding up my releases??? Can I just relicense these as GPLv3? A yes here will do.
36 2013-05-12 00:30:29 <cjd> xD
37 2013-05-12 00:30:40 <SomeoneWeird> >.<
38 2013-05-12 00:30:50 <cjd> Luke-Jr: https://github.com/cjdelisle/fixlicense
39 2013-05-12 00:31:33 <Luke-Jr> cjd: ????
40 2013-05-12 00:31:39 <SomeoneWeird> lmfao
41 2013-05-12 00:32:07 <denisx> Luke-Jr: peter decides that
42 2013-05-12 00:32:43 <Luke-Jr> denisx: ok, thanks
43 2013-05-12 00:34:41 <flound1129> luke-jr_: can a generate transaction change its id?
44 2013-05-12 00:34:49 <flound1129> and why would that happen?
45 2013-05-12 00:34:56 <Luke-Jr> flound1129: not once it's mined
46 2013-05-12 00:34:59 <flound1129> ok
47 2013-05-12 00:35:03 <Luke-Jr> in fact, no transaction can change id once its mined
48 2013-05-12 00:35:04 <flound1129> thanks
49 2013-05-12 00:35:12 <flound1129> ok good
50 2013-05-12 00:35:13 <Luke-Jr> short of a reorganziation
51 2013-05-12 00:35:32 <flound1129> so I can definitely make the txid field unique in the db
52 2013-05-12 00:35:42 <Luke-Jr> should be safe
53 2013-05-12 00:35:53 <Luke-Jr> not guaranteed, though, unless you're certain to never spent it
54 2013-05-12 00:36:04 <Luke-Jr> once it's spent, it's legal to reuse the txid
55 2013-05-12 00:36:18 <Luke-Jr> but still, so improbable, I wouldn't worry about that
56 2013-05-12 00:36:34 <flound1129> but it probably wouldn't show up as a txid on another mined block
57 2013-05-12 00:36:37 <flound1129> or definitely wouldn't?
58 2013-05-12 00:37:19 <Luke-Jr> flound1129: it *cannot* until you spend it. once you spend it, it *can*, but it's much less likely than the entire universe imploding tomorrow
59 2013-05-12 00:37:39 <cjd> flound1129: http://crypto.stackexchange.com/a/1172 this might put it in perspective
60 2013-05-12 00:39:26 <SomeoneWeird> hahahaahhaah
61 2013-05-12 01:26:30 <ngc0202> Is there any good tutorials on making raw transactions?
62 2013-05-12 01:26:40 <ngc0202> Are*
63 2013-05-12 06:31:22 <Jhong> hey everyone, am I right in thinking for most merchants using bitcoind, "setaccount" is a bit of a security risk ?
64 2013-05-12 06:32:01 <Jhong> an attacker could listen for inbound transactions, and set the account to their own. No need to decrypt wallet
65 2013-05-12 06:33:29 <Jhong> this is assuming the attacker already owns your web server or database -- but the whole point of double encryption is to guard agains tthis scenario
66 2013-05-12 06:34:54 <tholenst> What is double encryption in bitcointd, and why should it protected against this scenario?
67 2013-05-12 06:35:56 <cjd> ACTION blinks -- for a moment I thought I was watching jeopardy
68 2013-05-12 06:36:25 <tholenst> Did I win? :)
69 2013-05-12 06:36:38 <cjd> sure, why not :)
70 2013-05-12 06:36:59 <Jhong> @tholenst: Sorry, wallet passphrase
71 2013-05-12 06:37:49 <Jhong> I imagine most exchanges/merchants manually type the passphrase to prevent anyone who owns their server from being able to withdraw
72 2013-05-12 06:38:07 <cjd> well sorta
73 2013-05-12 06:38:09 <Jhong> but the weakest link is deposits
74 2013-05-12 06:38:22 <cjd> anyone serious in the business is using an offline cold storage wallet
75 2013-05-12 06:38:37 <Jhong> yes sure, you would use that too
76 2013-05-12 06:38:49 <cjd> payments go directly to it
77 2013-05-12 06:39:05 <Jhong> but most deposits are automated right?
78 2013-05-12 06:39:36 <cjd> getting keys from it while it remains offline is the tricky part
79 2013-05-12 06:39:44 <Jhong> a web server communicating with bitcoind and asking for inbound transactions or account balances, and using bitcoind to tie them to users via accounts
80 2013-05-12 06:40:04 <cjd> /nod
81 2013-05-12 06:40:40 <cjd> could always ask bitcoind for 9000 keys and then dish them out over time while using another bitcoind to determine which of those keys has been paid
82 2013-05-12 06:40:55 <Jhong> I guess my point is that you can't trust inbound account status reported from bitcoind any more than you can trust your own database
83 2013-05-12 06:41:00 <cjd> but that doesn't answer your question
84 2013-05-12 06:41:54 <sipa> Jhong: if an attacker gets access to RPC, you're screwed anyway
85 2013-05-12 06:42:08 <Jhong> In my case I have my web servers/db server, etc -- they're VPSes. But the Bitcoind server is in my own basement, locked down etc
86 2013-05-12 06:42:31 <Jhong> I'm thinking I should patch out setaccount
87 2013-05-12 06:42:38 <cjd> it seems like an edge case since it doesn't allow attackers to get old money, just to intercept payments
88 2013-05-12 06:42:42 <tholenst> yeah but what if he rewrites the program which *uses* bitcoind
89 2013-05-12 06:42:50 <sipa> Jhong: and sendtoaddress?
90 2013-05-12 06:42:51 <cjd> and they can do that by altering the pay-to addr on your website
91 2013-05-12 06:43:01 <Jhong> yes that's true
92 2013-05-12 06:43:03 <sipa> Jhong: and move?
93 2013-05-12 06:43:12 <tholenst> i think you need to assume the server is uncorrupted anyhow
94 2013-05-12 06:43:20 <sipa> yes
95 2013-05-12 06:43:29 <Jhong> move is OK if you monitor transactions rather than balances
96 2013-05-12 06:43:31 <tholenst> (what if he installs a keylogger)
97 2013-05-12 06:43:36 <sipa> if you need remote access to bitcoind, you need a proxy to filter out commands
98 2013-05-12 06:48:55 <Jhong> I guess it doesn't matter -- if someone has access to the database, they can set balances at will anyway
99 2013-05-12 06:51:59 <ByronZED> Rippln Mobile Apps Social Gamification - http://www.rippln.by/get-started/
100 2013-05-12 06:52:53 <coingenuity> god, stupid client
101 2013-05-12 08:12:58 <warren> sipa: hi. are there currently any known drawbacks to secp256k1?
102 2013-05-12 08:14:03 <whiskers75> How do I get difficulty inside of GetBlockValue()
103 2013-05-12 08:15:03 <sipa> warren: compared to?
104 2013-05-12 08:16:20 <warren> sipa: openssl
105 2013-05-12 08:17:01 <sipa> warren: beside not being tested, not afaik
106 2013-05-12 08:17:36 <warren> sipa: I'm using it in local test builds for Fedora/RHEL for both bitcoin and litecoin. No real tx or mining. Seems OK so far.
107 2013-05-12 08:18:01 <warren> testnet seems ok
108 2013-05-12 08:19:16 <warren> sipa: I've been using it mostly as means to avoid Ubuntu. Haven't distributed any test builds to anyone yet. I'll wait until you think it's ready for wider testing.
109 2013-05-12 08:29:10 <warren> sipa: are you uncomfortable with me giving Fedora/RHEL users test builds using it? I can lock it to testnet only at first, if you want.
110 2013-05-12 08:29:26 <sipa> warren: yes, i'd prefer that
111 2013-05-12 08:49:19 <warren> Where in the code is the block size soft limit defined? I'm looking at the defaults that changed over time.
112 2013-05-12 09:02:53 <ghash> guys was it a bad idea to downlod the blockchain with 0.8.2?
113 2013-05-12 09:03:05 <ghash> I'm getting a lot of orphan blocks I see in debug.log
114 2013-05-12 09:05:35 <sipa> known problem, but not worse than other versions
115 2013-05-12 09:06:45 <Luke-Jr> ghash: it'll recover on its own
116 2013-05-12 09:15:03 <ghash> ok, thx
117 2013-05-12 09:35:19 <MoALTz> how expensive (in runtime) is the signature algorithm (ECDSA) compared to any of the other cryptographic operations?
118 2013-05-12 09:36:05 <sipa> Very.
119 2013-05-12 09:37:57 <sipa> In the time you do one signature verification, you can calculate ~1000 double-SHA256 hashes
120 2013-05-12 09:38:13 <edcba> why the question ?
121 2013-05-12 09:38:19 <sipa> (order of magnitude, i may be a factor N off)
122 2013-05-12 09:40:25 <MoALTz> edcba: looking at blockchain designs and seeing if it's worth using something other than a signature algorithm (not possible for secure transactions that fully done on a single block, but might be possible with pre-commitment over more than one block)
123 2013-05-12 09:41:01 <sipa> other than a signature algorithm? what else would you use?
124 2013-05-12 09:42:45 <MoALTz> sipa: under something like p2sh the sender commits the receiver to have a script with a certain hash. if the receiver commits what their transaction will look like on one block (using a hash), and then 6+ blocks down reveals the contents of the block then it's unlikely that someone could reverse it
125 2013-05-12 09:43:22 <MoALTz> many downsides. i'll look at it more
126 2013-05-12 09:44:07 <sipa> like 'any miner can trivially steal any output being spent' ?
127 2013-05-12 09:44:11 <MoALTz> yes
128 2013-05-12 09:44:19 <MoALTz> erm that's what this scheme would avoid
129 2013-05-12 09:44:41 <MoALTz> if you don't do precommitment nor a signature then stealing is easy
130 2013-05-12 09:46:36 <MoALTz> but if you don't use a signature then you must commit the blockchain to accepting only your transaction via a precommitment ("my transactiion will have hash H"). the big downside is that then transactions take an hour or more (you have to wait until it's computationally infesible to redo the blocks since the precommitment). and it opens up the possiblity of spamming the blockchains with useless hashes (precommitments that a
131 2013-05-12 09:46:36 <MoALTz> re never fulfilled)
132 2013-05-12 09:48:46 <sipa> i don't think it's possible to know the hash of the spending transaction in advance
133 2013-05-12 09:49:08 <sipa> as the spending transaction contains the hash of the one being spent
134 2013-05-12 09:49:19 <sipa> so you get a dependency loop in trying to find the hashes
135 2013-05-12 09:49:58 <sipa> ah, you don't mean to have the hash of the spending transaction in the creating transaction; right
136 2013-05-12 09:50:09 <sipa> that'd be a very different structure from what we have now, though...
137 2013-05-12 09:50:17 <sipa> as you need a way to put non-transaction in the chain
138 2013-05-12 09:51:26 <rdponticelli> It looks like there's some bug on the qt changes in 0.8.2rc1...
139 2013-05-12 09:51:37 <sipa> rdponticelli: elaborate (or post an issue)
140 2013-05-12 09:52:10 <rdponticelli> On a small environment on a vm, the rc never gets to fill the qt windows...
141 2013-05-12 09:52:20 <rdponticelli> 0.8.1 works fine
142 2013-05-12 09:52:37 <rdponticelli> I'm trying to find more...
143 2013-05-12 09:53:01 <rdponticelli> Oh, and you can't stop it
144 2013-05-12 09:53:10 <sipa> anything in debug.log?
145 2013-05-12 09:53:24 <rdponticelli> getinfo works, asking to stop on rpc works, but it never stops
146 2013-05-12 09:53:45 <rdponticelli> I'm looking
147 2013-05-12 09:54:33 <rdponticelli> bitcoind 0.8.2rc1 also works fine
148 2013-05-12 09:54:56 <sipa> so RPC is functional, it's just the GUI that looks stuck?
149 2013-05-12 09:57:19 <rdponticelli> Yes, rpc works
150 2013-05-12 09:57:39 <rdponticelli> The gui never finishes starting
151 2013-05-12 09:57:46 <sipa> file a bug, please
152 2013-05-12 09:57:51 <rdponticelli> debug.log looks fine
153 2013-05-12 09:57:57 <rdponticelli> Yeah, I'll do
154 2013-05-12 10:49:34 <ghash> what can I do if the bitcoind blockchain download is stuck?
155 2013-05-12 10:50:08 <ghash> wait..this evolved into another question
156 2013-05-12 10:50:18 <ghash> why did bitcoind crash? debug.log doesnt give any output regarding that
157 2013-05-12 10:54:31 <ezdiy> gdb ./bitcoind
158 2013-05-12 10:54:32 <ezdiy> r
159 2013-05-12 10:54:33 <ezdiy> b
160 2013-05-12 10:54:34 <ezdiy> :)
161 2013-05-12 10:54:36 <ezdiy> and pastebin
162 2013-05-12 10:57:01 <ghash> wut
163 2013-05-12 10:57:05 <ghash> I've started it again
164 2013-05-12 10:57:07 <ghash> and its running fine
165 2013-05-12 10:57:10 <ghash> isnt there any log?
166 2013-05-12 10:57:17 <sipa> yes, debug.log
167 2013-05-12 10:57:19 <tumak> not for segfaults
168 2013-05-12 10:57:31 <sipa> the log may give a hint about what happened
169 2013-05-12 10:57:45 <ghash> well the last line was about a received block
170 2013-05-12 10:57:47 <ghash> that was all
171 2013-05-12 10:57:51 <ezdiy> never seen bitcoind segfault
172 2013-05-12 10:57:55 <ezdiy> most likely faulty hw
173 2013-05-12 10:58:00 <ghash> uh?
174 2013-05-12 10:58:08 <ghash> its running on a vps from bitvps.com
175 2013-05-12 10:58:11 <ezdiy> as bitcoind can be pretty resource intensive thus likely to catch bitflip bugs
176 2013-05-12 10:58:15 <ezdiy> lol vps
177 2013-05-12 10:58:26 <ezdiy> most likely oom kill
178 2013-05-12 10:58:27 <ezdiy> dmesg
179 2013-05-12 10:58:32 <ghash> https://www.bitvps.com/kvm-vps > KVM 4
180 2013-05-12 10:58:37 <ghash> that spec not enough?
181 2013-05-12 10:58:51 <ezdiy> i'm surprised it even runs in kvm
182 2013-05-12 10:58:58 <ghash> lol
183 2013-05-12 10:59:02 <ezdiy> please use xen, or at most openvz instances
184 2013-05-12 10:59:29 <ghash> ok I'm pretty new to all this stuff
185 2013-05-12 10:59:39 <ezdiy> you get what you pay for
186 2013-05-12 10:59:55 <ezdiy> uh, $25
187 2013-05-12 11:00:05 <ezdiy> so overpriced lol
188 2013-05-12 11:00:30 <ezdiy> ghash: 128M vps is worth like $5-$10 tops
189 2013-05-12 11:00:37 <ghash> yea, so, if I get the dedicated ("starter"), 2x 3.4ghz, 8gb ram, is that enough?
190 2013-05-12 11:00:42 <ezdiy> nah
191 2013-05-12 11:00:47 <ezdiy> at least 1gb memory
192 2013-05-12 11:00:49 <ezdiy> no overcommit
193 2013-05-12 11:01:00 <ezdiy> didnt realize bitvps is such a ripoff :(
194 2013-05-12 11:01:05 <ghash> :|
195 2013-05-12 11:01:20 <ghash> so, the OpenVZ 3 (2cores, 1gb ram) is enough?
196 2013-05-12 11:01:29 <ezdiy> yup, that should be fair for bitcoind
197 2013-05-12 11:01:52 <ezdiy> maybe 512m but thats kinda pushing it
198 2013-05-12 11:02:32 <sipa> 512 is maybe enough on 32-bit and if not serving many connections
199 2013-05-12 11:02:33 <ezdiy> oh, its quarterly price
200 2013-05-12 11:02:35 <ezdiy> thats fine then
201 2013-05-12 11:02:41 <sipa> otherwise i'd go for at least 1024
202 2013-05-12 11:02:45 <ezdiy> yep
203 2013-05-12 11:03:21 <ghash> okay, thank you guys, I'll take care of that
204 2013-05-12 11:03:32 <ghash> is there any way of going around the blockchain download?
205 2013-05-12 11:03:38 <ezdiy> yeah
206 2013-05-12 11:03:40 <ezdiy> just scp it there
207 2013-05-12 11:03:54 <ezdiy> torrenting on a vps is excercise in pain if there are bw quotas
208 2013-05-12 11:04:04 <ghash> yea... you mean I'll connect via SCP onto the server and upload the blockchain?
209 2013-05-12 11:04:11 <ezdiy> yup
210 2013-05-12 11:04:22 <ezdiy> assuming you have a place to upload from
211 2013-05-12 11:04:30 <ghash> http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/
212 2013-05-12 11:04:43 <ghash> couldnt I just get the 170000.zip and extract it?
213 2013-05-12 11:05:10 <ezdiy> look at the date
214 2013-05-12 11:05:15 <ezdiy> blockchain is 6gb now
215 2013-05-12 11:05:37 <ezdiy> ghash: if you have decent bw quota, just torrent it on vps
216 2013-05-12 11:05:48 <ezdiy> dunno how bitvps handles this
217 2013-05-12 11:05:57 <ezdiy> but incoming data shouldnt be counted
218 2013-05-12 11:06:08 <ezdiy> the torrent is very well seeded so it'll be probably ok
219 2013-05-12 11:08:09 <ghash> okay I'll if I am capable of setting up torrent at the openVZ etc...
220 2013-05-12 11:08:12 <ghash> see*
221 2013-05-12 11:08:18 <ghash> thanks so far!
222 2013-05-12 11:08:41 <ezdiy> ghash: avoid kvm next time, there are some specific uses for it but usually its not worth it :(
223 2013-05-12 11:08:57 <ghash> okay thx
224 2013-05-12 11:09:02 <ghash> for me it just sounded fancier
225 2013-05-12 11:09:04 <ghash> :D
226 2013-05-12 11:09:13 <Belxjander> ezdiy: KVM is only really useful if you virtualize locally (as in use a VM on the same machine)
227 2013-05-12 11:09:23 <Belxjander> otherwise I wouldn't really rely on it
228 2013-05-12 11:09:30 <ezdiy> Belxjander: ack
229 2013-05-12 11:09:40 <ezdiy> qemu gdb stub ftw
230 2013-05-12 11:09:44 <ezdiy> other than that, its useless
231 2013-05-12 11:09:47 <Belxjander> qemu-kvm ?
232 2013-05-12 11:09:57 <ezdiy> kvm is qemu :)
233 2013-05-12 11:10:10 <ezdiy> kvm is just vt-d acceleration for it
234 2013-05-12 11:10:13 <Belxjander> ezdiy: not exactly... kvm is a support module for virtualization within the linux kernel
235 2013-05-12 11:10:21 <Belxjander> qemu is just one VM toolkit that makes use of it
236 2013-05-12 11:10:23 <ezdiy> as i said, vt-x/vt-d acceleration
237 2013-05-12 11:10:28 <Belxjander> VirtualBox also uses the kvm module when present
238 2013-05-12 11:10:45 <ezdiy> but most of it is not necessary, or even hindering for debugging
239 2013-05-12 13:28:11 <nsh> Integer factorization and Discrete Logarithm problem are neither in P nor NP-complete
240 2013-05-12 13:28:17 <nsh> http://arxiv.org/abs/1207.2171
241 2013-05-12 13:28:41 <nsh> ctions to the existence of pseudorandom functions. )
242 2013-05-12 13:28:41 <nsh> (Later versions of this paper carry the title "Relationship between circuit complexity and symmetry". The paper shows that by interpreting a Boolean circuit as a graph, the small number of graph automorphisms and the large number of subgraph automorphisms in the circuit establishes the exponential circuit lower bound for NP-complete problems. As this strategy violates the largeness condition in Natural proof, this result shows that P!=NP without any contradi
243 2013-05-12 13:29:04 <nsh> ACTION frowns
244 2013-05-12 13:55:06 <Corndawg> Hypothetically: Is it possible to make fork off Bitcoin code to make a curency that only allows certain miners to get money? Like miners that had a certain priv key... or sub key derived from that priv key?
245 2013-05-12 13:56:04 <Corndawg> so if a Govt wanted to centralize a cryptocurrency they could do that (scary thought I know)? And they would then control the mining supply
246 2013-05-12 13:56:36 <Corndawg> but still get the benefits of nearly impossible to counterfit
247 2013-05-12 13:57:18 <BlueMatt> yes, in fact a few altcoins do something along those lines
248 2013-05-12 14:06:22 <Corndawg> that's prob whats going ot happen in a few years then... if the Euro breaks up some Scandanavian country will start that
249 2013-05-12 14:07:07 <Corndawg> not long before all countries move to that... too tempting to take away cash (truely untraceable transactions + easy counterfiting)
250 2013-05-12 14:07:18 <Corndawg> scary
251 2013-05-12 14:09:42 <franl> Why would a nation state need the "crypto" part of cryptocurrency if all transactions pass through a central state-operated clearinghouse?
252 2013-05-12 14:10:06 <MoALTz> speaking of new currencies for countries, i find it somewhat ironic that low generation times (e.g. chncoin) would actually fix generation to a geographic region of high connectivity and high hash rate. reason: by the time a block has reached a miner on the other side of the world a new block will have likely been found
253 2013-05-12 14:10:47 <MoALTz> metastable i mean - there is a chance that it would flip between dense computational+connective regions
254 2013-05-12 14:11:05 <marijnfs> hello, im trying to implement the script system in golang
255 2013-05-12 14:11:12 <marijnfs> where can i find example scripts to test it on?
256 2013-05-12 14:13:12 <franl> marijnfs, just thought of this: extract real scripts from the blockchain.
257 2013-05-12 14:13:25 <michagogo> Look up [[Script]] on the wiki
258 2013-05-12 14:14:03 <franl> https://en.bitcoin.it/wiki/Script
259 2013-05-12 14:14:07 <marijnfs> not a bad idea;)
260 2013-05-12 14:18:36 <BlueMatt> Corndawg: heh, yea...keep dreaming...or something
261 2013-05-12 14:19:10 <BlueMatt> marijnfs: at a bare minimum, the data-driven test-cases in bitcoind and all of the testnet scripts should be run
262 2013-05-12 14:19:39 <franl> Is the block height of the next re-target known in advance of the re-target?
263 2013-05-12 14:19:57 <michagogo> Yes
264 2013-05-12 14:20:00 <michagogo> Every 2016 blocks
265 2013-05-12 14:21:12 <franl> michagogo, thx
266 2013-05-12 14:23:21 <BlueMatt> Corndawg: note that both the data-driven script and data-driven tx tests are important for testing script processing
267 2013-05-12 14:25:05 <BlueMatt> ehh, marijnfs ^
268 2013-05-12 14:27:30 <franl> When it's time to re-target, is the computation of the new target determined entirely from the 2016 most recent blocks in the blockchain?
269 2013-05-12 14:28:23 <ThomasV> franl: and the previous difficulty
270 2013-05-12 14:28:33 <franl> ThomasV, ah, yes. Thx.
271 2013-05-12 14:31:39 <franl> So if, due to network latency, different miners each believe they've published the 2016th block at the current difficulty, they will computer different values for the next target. That's fixed once they all see the consensus on the ture 2016th block, right?
272 2013-05-12 14:31:53 <franl> *compute
273 2013-05-12 14:32:41 <franl> I'm trying the understand the boundary conditions that exist at re-target time.
274 2013-05-12 14:36:31 <BlueMatt> franl: yes
275 2013-05-12 14:36:51 <BlueMatt> while you're at it...wanna write test-cases to exercise those conditions?
276 2013-05-12 14:37:22 <nimdAHK_> one boundary is the 3-hour limit
277 2013-05-12 14:37:29 <nimdAHK_> the network has to be synced within 3 hours
278 2013-05-12 14:38:05 <nimdAHK_> you'll see "out of order" blocks in the chain, but never more than 3 hours apart
279 2013-05-12 14:39:08 <BlueMatt> what?
280 2013-05-12 14:39:25 <franl> nimdAHK_, where's that 3 hour value come from? Do miners do something every 18 block to cause that synchronization to happen?
281 2013-05-12 14:39:41 <nimdAHK_> no
282 2013-05-12 14:39:54 <nimdAHK_> but the node rejects blocks that are too out of sync
283 2013-05-12 14:40:09 <nimdAHK_> let me find the relevant source
284 2013-05-12 14:40:12 <franl> nimdAHK_, ok. Thx.
285 2013-05-12 14:40:26 <michagogo> nimdAHK_: Erm, but that would mean that if there were the equivalent of a netsplit for over 3 hours, we'd have a fork
286 2013-05-12 14:40:33 <BlueMatt> as someone who's been developing bitcoin for years, Im very interested to know where this 3 hour limit comes from...
287 2013-05-12 14:40:33 <nimdAHK_> michagogo: true
288 2013-05-12 14:40:48 <michagogo> Personally I find that unlikely
289 2013-05-12 14:40:53 <michagogo> Are you able to back it up?
290 2013-05-12 14:40:54 <nimdAHK_> BlueMatt: as someone who has not been developing bitcoin, I'm open to being wrong
291 2013-05-12 14:41:00 <franl> It seems to be a code-enforced consensus, not a crypto-enforced one.
292 2013-05-12 14:41:03 <nimdAHK_> I'm looking in the source right now
293 2013-05-12 14:41:06 <nimdAHK_> just give me a moment
294 2013-05-12 14:41:09 <BlueMatt> ACTION has been wrong before, but Ive never heard of any 3-hour limit
295 2013-05-12 14:41:18 <nimdAHK_> ACTION is almost always wrong
296 2013-05-12 14:41:26 <franl> BlueMatt, me too. It's always "longest blockchain wins".
297 2013-05-12 14:41:29 <BlueMatt> there is the 2-hour offset limit, but its really not quite what you're describing
298 2013-05-12 14:41:37 <vrs> nsh: found http://www.win.tue.nl/~gwoegi/P-versus-NP.htm after some cursory research
299 2013-05-12 14:42:09 <BlueMatt> (nodes reject blocks which have timestamps >2 hours in the future when they hear of the blocks)
300 2013-05-12 14:42:25 <nimdAHK_> hrm
301 2013-05-12 14:43:06 <BlueMatt> also, there is no way to get blocks "out of order" since each blocks has the previous block in its header...
302 2013-05-12 14:43:13 <franl> nimdAHK_, even if it's in the _code_ of every miner, no crypto algorithm enforces it, right?
303 2013-05-12 14:43:25 <BlueMatt> franl: ehhh...thats equivalent
304 2013-05-12 14:43:35 <nimdAHK_> BlueMatt: that's not what I meant, exactly
305 2013-05-12 14:43:35 <nsh> vrs, looking, thanks
306 2013-05-12 14:43:45 <franl> BlueMatt, until a majority of miners start doing it differently.
307 2013-05-12 14:43:54 <nimdAHK_> I can show you two blocks where the previous one has the later timestamp
308 2013-05-12 14:44:09 <BlueMatt> nimdAHK_: ahh, yes well there is no rule on consecutive timestamps
309 2013-05-12 14:44:22 <nimdAHK_> that is what I meant
310 2013-05-12 14:44:33 <franl> Right, the "previous block hash" is what creates the total ordering.
311 2013-05-12 14:44:50 <nimdAHK_> ok, I'm probably wrong about the 3 hours, but give me a moment
312 2013-05-12 14:45:07 <BlueMatt> franl: no, if some miners start doing it differently, they can get forked off the chain because they are arbitrarily redefining their own network rules
313 2013-05-12 14:45:37 <BlueMatt> there are /very/ few rules which miners could chose to change or tweak on their own
314 2013-05-12 14:45:40 <franl> BlueMatt, yes. And they have the majority hashpower, their rules win because they create the longest blockchain.
315 2013-05-12 14:45:44 <BlueMatt> no
316 2013-05-12 14:45:56 <nimdAHK_> I'm with BlueMatt on this one
317 2013-05-12 14:45:59 <BlueMatt> the vast, vast majority of rules are enforced by /everyone/ not just miners
318 2013-05-12 14:46:16 <nimdAHK_> miners merely choose the transaction ordering
319 2013-05-12 14:46:20 <BlueMatt> if a miner makes a block that is invalid, everyone else just ignores it, doesnt matter if it has a vaild hash or not
320 2013-05-12 14:46:21 <nimdAHK_> and inclusion
321 2013-05-12 14:46:27 <franl> How does a non-miner enforce anything about the blockchain?
322 2013-05-12 14:46:36 <BlueMatt> it ignores blocks which are invalid
323 2013-05-12 14:46:41 <michagogo> franl: By ignoring anything that doesn't meet the rules it chooses to follow
324 2013-05-12 14:46:56 <BlueMatt> doesnt matter if it has an incorrect hash or its transactions arent valid, its the same invalid
325 2013-05-12 14:47:24 <BlueMatt> (note that some clients, ie SPV clients, dont actually do very much verification, but those are still the vast minority on the network)
326 2013-05-12 14:47:37 <franl> BlueMatt, sure, where "invalid" == "mathematically unacceptable". But if it breaks some non-crypto-enforced concept of validity, then that's just a network-wide agreement, which can change if the majority decides.
327 2013-05-12 14:47:47 <nimdAHK_> nope
328 2013-05-12 14:47:51 <michagogo> franl: Even if 90% of hashpower changes the rules, unless users also change *their* rules they'll ignore the 90%
329 2013-05-12 14:48:28 <franl> michagogo, ok, I see that. Disenfranchising the majority of clients causes you to be rejected.
330 2013-05-12 14:48:37 <michagogo> franl: Yeah
331 2013-05-12 14:48:40 <BlueMatt> Im not sure what you mean by crypto-enforced, crypto is just a program, as are all the other block validity rules
332 2013-05-12 14:48:41 <nimdAHK_> franl: see page 3 of bitcoin.pdf
333 2013-05-12 14:49:23 <nimdAHK_> non-mining nodes can reject blocks
334 2013-05-12 14:50:15 <franl> BlueMatt, hmm. I see now that it all comes down to the code. Code that deviates from the agreed algorithms (crypto or not), ends up marginalized and unable to participate in the shared consensus that is the accepted blockchain.
335 2013-05-12 14:50:31 <BlueMatt> franl: exactly
336 2013-05-12 14:50:56 <BlueMatt> now to confuse you more, there are some things that can be changed by majority-network-consensus (not miners)
337 2013-05-12 14:51:01 <BlueMatt> ie soft-fork things
338 2013-05-12 14:51:09 <BlueMatt> realistically, those are changed at ie 90% consensus
339 2013-05-12 14:51:10 <franl> Like how the March 2013 force was resolved?
340 2013-05-12 14:51:14 <franl> *fork
341 2013-05-12 14:51:22 <BlueMatt> see: the block v2 height-in-coinbase stuff
342 2013-05-12 14:51:22 <michagogo> franl: No, that was by getting miners to downgrade
343 2013-05-12 14:51:54 <franl> OK, I missed your "not miners" bit.
344 2013-05-12 14:52:39 <franl> So where do the majority of miner and client developers communicate with each other about such things? Is there a mailing list?
345 2013-05-12 14:52:45 <BlueMatt> well, it requires miner participation and is calculated as miner-majority, but its enforced by the network
346 2013-05-12 14:53:01 <BlueMatt> here/Bitcoin-Development ml
347 2013-05-12 14:53:13 <franl> Thx
348 2013-05-12 14:53:18 <michagogo> franl: In the case of the March hardfork, IIRC, gavin sent out a network alert
349 2013-05-12 14:53:55 <BlueMatt> that, among other things
350 2013-05-12 14:54:06 <BlueMatt> ie emails to relevant parties
351 2013-05-12 14:54:54 <nimdAHK_> especially pools
352 2013-05-12 14:55:02 <BlueMatt> yes
353 2013-05-12 14:55:43 <BlueMatt> wat?
354 2013-05-12 14:56:52 <nimdAHK_> the March fork was a software disagreement due to database problems. If miners hadn't downgraded, everyone else would have needed to upgrade.
355 2013-05-12 14:56:58 <nimdAHK_> lol, backup gribble
356 2013-05-12 14:57:30 <BlueMatt> yea, sorry I was wat'ing at gribble, not the marchfork
357 2013-05-12 14:57:48 <nimdAHK> what happened to normal gribble?
358 2013-05-12 14:58:08 <nimdAHK> seems rather difficult to DoS an IRC bot
359 2013-05-12 14:58:24 <BlueMatt> not really
360 2013-05-12 14:58:46 <nimdAHK> you'd have to get around the network's own rate limiting
361 2013-05-12 14:59:05 <nimdAHK> so it would need to be very asymetrical
362 2013-05-12 14:59:09 <BlueMatt> well, ok, have to DDoS, not DoS
363 2013-05-12 14:59:55 <nimdAHK> I wonder what the most intensive operation gribble performs is
364 2013-05-12 15:01:35 <fiat500> i thought the ddos targeted the host the bot was on directly
365 2013-05-12 15:01:47 <BlueMatt> well, you can do that too
366 2013-05-12 15:02:03 <Optimo> if I was an evil arbitrager I would definitely prey on newbs to this room
367 2013-05-12 15:02:04 <fiat500> cuz the webserver is down too
368 2013-05-12 15:02:14 <fiat500> Optimo: wrong room
369 2013-05-12 15:02:19 <Optimo> oh shit
370 2013-05-12 15:02:23 <Optimo> sorry
371 2013-05-12 15:02:54 <Optimo> I meant -otc of course. the IQ in this room tends to be higher
372 2013-05-12 15:03:00 <fiat500> lol
373 2013-05-12 15:03:08 <fiat500> not anymore now that im here
374 2013-05-12 15:03:37 <Optimo> a word of warning, probably everywhere but inside your head, that's a girl's car
375 2013-05-12 15:04:13 <fiat500> Optimo: the fiat is a reference to the currency term, not the vehicle make
376 2013-05-12 15:04:25 <nimdAHK> fiat500: it would make sense to separate the web interface and the bot
377 2013-05-12 15:04:37 <Optimo> fiat500: you're not clever
378 2013-05-12 15:04:42 <nimdAHK> then a hostmask on the bot would make even a DDoS tricky
379 2013-05-12 15:04:52 <diki> wtf
380 2013-05-12 15:05:02 <diki> Bitcoin-Qt using over 90% of my CPU?
381 2013-05-12 15:05:07 <fiat500> nimdAHK: is it really that critical? anyway i dont run these things, you should ask OneFixt :)
382 2013-05-12 15:05:14 <BlueMatt> diki: importing blocks?
383 2013-05-12 15:05:19 <diki> syncing, yes
384 2013-05-12 15:05:26 <nimdAHK> fiat500: gribble runs the whole bitcoin-otc
385 2013-05-12 15:05:27 <diki> but it's never used that much of my CPU resources
386 2013-05-12 15:05:30 <BlueMatt> ok...then why would it not use 90% cpu
387 2013-05-12 15:05:44 <OneFixt> fiat500: nanotube runs gribble
388 2013-05-12 15:05:53 <fiat500> my bad
389 2013-05-12 15:05:56 <OneFixt> np
390 2013-05-12 15:06:09 <backupgribble> Forget the snack, just send me some bitcoins at 1MgD6rah5zUgEGYZnNmdpnXMaDR3itKYzU :)
391 2013-05-12 15:06:09 <OneFixt> ;;botsnack
392 2013-05-12 15:06:17 <OneFixt> maybe if gribble is fed well he'll stay up more? =)
393 2013-05-12 15:06:26 <fiat500> shakedown
394 2013-05-12 15:10:52 <devurandom> Hello!
395 2013-05-12 15:10:57 <BlueMatt> hi
396 2013-05-12 15:11:26 <franl> hi devurandom. How's your entropy?
397 2013-05-12 15:11:36 <devurandom> Quite good today, thanks!
398 2013-05-12 15:13:22 <devurandom> condition. So I went to a 1 element queue, which get-template tries to fill the whole time (timeouting after expires/4, so the template stays fresh). But I fear that might waste more bw than necessary.
399 2013-05-12 15:13:22 <devurandom> Do you have a tip how to design the get-template thread for GBT miner in Python 3.2? Once I had a needtmpl event, which the make-work thread set when it found that the current template would last less than 10s. The get-template thread would then wakeup, fetch a template and stuff it into the queue so it was ready when make-work needs it. But that created quite a few more requests for templates than necessary, due to the inherent race
400 2013-05-12 15:17:50 <franl> I don't know that code, so I can't help, but ... a miner written in Python? Is the hashing code also Python?
401 2013-05-12 15:19:17 <devurandom> No, it just produces work for stuff running on dedicated hardware.
402 2013-05-12 15:19:24 <franl> Ah
403 2013-05-12 15:23:34 <backupgribble> I have not seen foqmrctz.
404 2013-05-12 15:23:34 <sharktopuz> !seen foqmrctz
405 2013-05-12 15:25:54 <Eremes> guys is it possible to send 100 BTC without fees ?
406 2013-05-12 15:26:25 <BlueMatt> umm...yes?
407 2013-05-12 15:26:34 <BlueMatt> but seriously, why are you asking this on #bitcoin-dev ?
408 2013-05-12 15:26:43 <Julius129> you can test it by sending the 100 BTC to me
409 2013-05-12 15:27:51 <Eremes> BlueMatt: mind asking where should i ask then ?
410 2013-05-12 15:28:01 <BlueMatt> #bitcoin
411 2013-05-12 15:28:26 <Eremes> BlueMatt: ok
412 2013-05-12 15:30:32 <franl> Anyone who has 100 BTC to send shouldn't be worried about the fee. :)
413 2013-05-12 15:31:15 <franl> Deep pockets and short arms.
414 2013-05-12 15:40:52 <k9quaint> wow, BlueMatt has the touch
415 2013-05-12 15:41:22 <BlueMatt> ?
416 2013-05-12 15:42:10 <k9quaint> you made a person leave bitcoin-dev just by asking nicely
417 2013-05-12 15:43:08 <BlueMatt> most people arent trying to be a dick by coming here for support, they just read somewhere that #bitcoin-dev will answer questions and come here...
418 2013-05-12 15:54:23 <nimdAHK> why do people not read the topic?
419 2013-05-12 15:54:47 <sipa> because it requires effort
420 2013-05-12 15:55:13 <nimdAHK> so does joining the channel :(
421 2013-05-12 16:08:52 <The_Fly> lol
422 2013-05-12 16:20:58 <grau> sipa: changed bop BIP32 to additive. It is self consistent, but do you have any test vectors?
423 2013-05-12 16:25:10 <ardeay_> ;;ticker
424 2013-05-12 16:25:12 <backupgribble> BTCUSD ticker | Best bid: 114.49000, Best ask: 115.72741, Bid-ask spread: 1.23741, Last trade: 115.72420, 24 hour volume: 25944.82101161, 24 hour low: 112.40000, 24 hour high: 117.47000, 24 hour vwap: 114.49139
425 2013-05-12 16:26:41 <sipa> grau: great, i don't have any right now, but i intend to 'finalize' bip32 by the conference, and publish test vectors then
426 2013-05-12 16:28:05 <grau> sipa: you mean finalize before or on the conference?
427 2013-05-12 16:29:00 <grau> I have built this into the product. It would be really handy to have some test vectors in beforehand.
428 2013-05-12 16:29:51 <sipa> i'll try to have vectors before, but no promises
429 2013-05-12 16:31:09 <grau> Worse case I will have a rebook function later.
430 2013-05-12 16:31:20 <TheLordOfTime> when's the next release of bitcoin-qt
431 2013-05-12 16:31:29 <TheLordOfTime> and how "absolutely required" is it (I have 0.8.1)
432 2013-05-12 16:31:37 <sipa> 0.8.1 is fine
433 2013-05-12 16:31:52 <sipa> 0.8.2rc1 is just made available, feel free to test if you like
434 2013-05-12 16:32:13 <TheLordOfTime> 0.8.2-rc1 still pulls the entire set of blocks since the dawn of time, right?
435 2013-05-12 16:32:16 <CaptainBlaze> hey guys, thought this might be a question for bitcoin-dev, is there anyway the processing power used to hash and verify the block chain could be shared out to help "good" causes?
436 2013-05-12 16:32:22 <CaptainBlaze> for example seti
437 2013-05-12 16:32:22 <TheLordOfTime> ... damn it, I keep using debian-style version strings!
438 2013-05-12 16:32:24 <TheLordOfTime> ACTION facedesks
439 2013-05-12 16:32:38 <sipa> TheLordOfTime: it's harder than it looks
440 2013-05-12 16:32:44 <sipa> eh, CaptainBlaze
441 2013-05-12 16:32:47 <sipa> TheLordOfTime: yes
442 2013-05-12 16:33:03 <TheLordOfTime> sipa, yeah, i'll test some other time, i don't want to risk my active wallets :P
443 2013-05-12 16:33:13 <sipa> of course
444 2013-05-12 16:33:20 <michagogo> TheLordOfTime: Just `cp wallet.dat wallet.dat.bak`
445 2013-05-12 16:33:23 <CaptainBlaze> erm not sure how to break down what i am trying to say.
446 2013-05-12 16:33:28 <TheLordOfTime> michagogo, you assume linux.
447 2013-05-12 16:33:35 <TheLordOfTime> michagogo, 'tis windows the bitcoin wallet's on
448 2013-05-12 16:33:36 <michagogo> Or, `mv wallet.dat wallet.dat.bak` or equivalent
449 2013-05-12 16:33:37 <TheLordOfTime> and without ssh.
450 2013-05-12 16:33:48 <michagogo> TheLordOfTime: You get my point
451 2013-05-12 16:33:52 <michagogo> Make a backup copy
452 2013-05-12 16:33:53 <TheLordOfTime> ACTION has to remote-desktop in after jumping through a couple VPNs.
453 2013-05-12 16:34:02 <TheLordOfTime> michagogo, true, i plan to tonight
454 2013-05-12 16:34:03 <TheLordOfTime> :)
455 2013-05-12 16:34:15 <sipa> CaptainBlaze: it's perfectly clear what you mean (i think), and you're far from the first person to suggest it
456 2013-05-12 16:34:28 <sipa> but the answer is that it's far harder than it looks
457 2013-05-12 16:34:32 <CaptainBlaze> sipa, ah ok, is there a forum discussion on it somewhere?
458 2013-05-12 16:34:48 <sipa> CaptainBlaze: i'm sure you'll find a few hundred threads about it
459 2013-05-12 16:34:56 <CaptainBlaze> haha, ok.
460 2013-05-12 16:35:03 <CaptainBlaze> I will have a look outside of this forum.
461 2013-05-12 16:35:19 <CaptainBlaze> I am guessing it's a question best read about in depth.
462 2013-05-12 16:35:25 <CaptainBlaze> and not quickly answered in a short summation?
463 2013-05-12 16:43:22 <CaptainBlaze> Can't seem to find anything on bitcointalk, could you point me towards any other forums that might contain this topic? Or a thread if you have a more accurate link?
464 2013-05-12 16:46:20 <ali1234> does anyone know why some altcoins wallet import format decodes to 38 bytes instead of 37?
465 2013-05-12 16:46:52 <ali1234> bitcoins is byte:networkID, 32xbyte:key, 4xbyte:checksum
466 2013-05-12 16:47:16 <ali1234> the altcoins appear to be sing byte:networkID, byte:0x01, ...
467 2013-05-12 16:48:17 <BlueMatt> CaptainBlaze: essentially it boils down to: you have to use something that can be verified easily (without a central authority) and takes lots of effort to solve
468 2013-05-12 16:48:42 <BlueMatt> CaptainBlaze: if you can do that securely, then you should be able to replace the pow algorithm
469 2013-05-12 16:50:43 <CaptainBlaze> ah i see BlueMatt.
470 2013-05-12 16:50:44 <lianj> ali1234: maybe you mean compressed wtf uncompressed addresses?
471 2013-05-12 16:50:53 <lianj> s/wtf/vs/
472 2013-05-12 16:50:58 <lianj> strange typo
473 2013-05-12 16:51:08 <ali1234> hmm, maybe
474 2013-05-12 16:51:16 <ali1234> but wait why would compressed be bigger?
475 2013-05-12 16:51:33 <lianj> because it has a 'is compressed' flag
476 2013-05-12 16:51:54 <ali1234> well
477 2013-05-12 16:52:01 <ali1234> look at these two b58 strings
478 2013-05-12 16:52:16 <ali1234> N6DE37A57qq4dnfS1JL9VTHtHdoxmv5ZHZiWWYwT4iuuP1TRcskt
479 2013-05-12 16:52:28 <ali1234> 5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ
480 2013-05-12 16:52:43 <ali1234> second one is the example from https://en.bitcoin.it/wiki/Wallet_import_format
481 2013-05-12 16:54:02 <ali1234> first one decodes to 0x8e 0x01 <32 bytes> <4 bytes checksum>
482 2013-05-12 16:54:35 <ali1234> i don't see how that 0x01 can represent "compressed" as the key might start with 0x01...
483 2013-05-12 16:55:45 <lianj> ali1234: first one is compressed, second one not
484 2013-05-12 16:55:53 <lianj> http://paste.mhanne.net/p/41cf7b8ad907f33092906d1ec79e43c0801e5150?hl=text
485 2013-05-12 16:56:37 <lianj> itst the 0x01 before the checksum
486 2013-05-12 16:56:51 <BlueMatt> CaptainBlaze: oh, and it also has to take as input, something securely covering the data in the block (ie the hash of the header or the header contents itself or whatever)
487 2013-05-12 16:57:01 <ali1234> lianj: how can it be?
488 2013-05-12 16:57:42 <ali1234> also you're right
489 2013-05-12 16:57:55 <ali1234> net,key,x,checksum = struct.unpack('>B32sB4s', raw) is my code
490 2013-05-12 16:58:34 <ali1234> but in that case, how do you spot the difference between compressed and a checksum that just happens to start with 0x01?
491 2013-05-12 17:00:46 <MoALTz> you also need to vary the parameters of the useful PoW function for it to continue being useful. and you need to pick ones that cannot be cheated with bogus results (cheating and getting useful results is fine)
492 2013-05-12 17:04:35 <MoALTz> i strongly suspect that you can turn a deterministic stochastic (RNG seeded; i recommend hash(previous block + miner's choice + nonce)) simulation into a PoW. gromacs (a molecular simulator used in folding@home) or other physics ones might be nice
493 2013-05-12 17:19:10 <The_Fly> https://www.youtube.com/watch?v=_G-K7-QOaA4
494 2013-05-12 17:36:28 <nsh> people who have videos shot in front of their array of armaments...
495 2013-05-12 17:37:09 <The_Fly> i know, lol
496 2013-05-12 17:37:33 <The_Fly> "i was wrong about bitcoin, but i will still end you if you disagree with me"
497 2013-05-12 17:39:22 <ali1234> that guy looks like gabe newell got lyposuction
498 2013-05-12 17:45:47 <The_Fly> maybe he 3d printed those guns
499 2013-05-12 17:46:36 <BlueMatt> MoALTz: yes, I would not be surprised if something like gromacs could be turned into a pow, would take some serious work though
500 2013-05-12 17:48:11 <lianj> ali1234: the length
501 2013-05-12 17:48:33 <ali1234> lianj: so if length != 37 it is compressed?
502 2013-05-12 17:48:48 <sipa> ali1234: what altcoin is that?
503 2013-05-12 17:48:56 <ali1234> what if compressing it reduced the length by 1 byte?
504 2013-05-12 17:49:04 <ali1234> then it would be compressed and 37 bytes long
505 2013-05-12 17:49:09 <ali1234> sipa: it's feathercoin
506 2013-05-12 17:49:15 <sipa> ali1234: and compression is not a property of private key, but of _public_ keys
507 2013-05-12 17:49:31 <lianj> what sipa said
508 2013-05-12 17:49:35 <ali1234> sipa: i never really believed it was compressed :)
509 2013-05-12 17:49:35 <sipa> it's just that the private key needs a marker to know whether to construct the corresponding compressed or uncompressed pubkey
510 2013-05-12 17:49:59 <ali1234> hmm
511 2013-05-12 17:50:23 <ali1234> i see
512 2013-05-12 17:50:29 <ali1234> so it really is just an extra flag
513 2013-05-12 17:50:57 <sipa> and in bitcoin, [0x80] [32-byte privkey] [4-byte checksum] for uncompressed ones, and [0x80] [32-byte privkey] [0x01] [4-byte checksum] for compressed one
514 2013-05-12 17:51:09 <sipa> for other coins, go ask them
515 2013-05-12 17:51:16 <ali1234> sipa: you'll probably find this amusing. today someone made "gamecoin" with same genesis block and rules compatible with feathercoin. their blockchain now begins with 6600 feathercoin blocks then a hard fork
516 2013-05-12 17:51:56 <ali1234> so i made a tool to convert the privatekeys so people can get their feather/gamecoins and double spend them and posted it on the forum
517 2013-05-12 17:52:41 <ali1234> i'm not 100% sure that actually works?
518 2013-05-12 18:03:19 <tumak> MoALTz: there is a paper on the forum somewhere on how to exploit PoW for monte carlo simulations
519 2013-05-12 18:03:27 <tumak> it has some really rough corners, but might be nice indeed
520 2013-05-12 18:13:49 <Julius129> how can i detect dust and penalize people that deposit dust?
521 2013-05-12 18:16:14 <nsh> nanotube, do you want gribble rehosted over tor/sasl?
522 2013-05-12 20:27:23 <ali1234> given txid and vout, can i tell if it is unspent if it isn't in my wallet, without scanning the entire block chain?
523 2013-05-12 20:39:08 <diki> lol
524 2013-05-12 20:39:15 <diki> 300gbit DDoS
525 2013-05-12 20:41:59 <nsh> ?
526 2013-05-12 23:49:24 <Neozonz> Disc|Aga|is there a command to exit bitcoind?
527 2013-05-12 23:49:44 <rdponticelli> Neozonz|Disc|Aga: bitcoind stop?