1 2012-02-23 00:00:22 <wladston> kinlo: just finished to sync here with testnet, got the coins, thanks a lot man :)
  2 2012-02-23 00:18:42 <BlueMatt> uhh...why is bitcoin-qt.exe on wine+tmpfs downloading quicker than Ive ever seen bitcoin-qt on linux+tmpfs download???
  3 2012-02-23 00:19:44 <sipa> My guess: VirtualLock() not implemented
  4 2012-02-23 00:19:50 <BlueMatt> heh, probably
  5 2012-02-23 00:21:52 <sipa> Also: bitcoin only requests the latest block from the first connection made
  6 2012-02-23 00:22:08 <BlueMatt> always downloading from localhost
  7 2012-02-23 00:22:32 <sipa> BlueMatt: https://github.com/bitcoin/bitcoin/pull/883 :p
  8 2012-02-23 00:22:45 <sipa> But if a node with more blocks connects to the network himself, nobody will request those from him...
  9 2012-02-23 00:22:50 <BlueMatt> 75% in 6 minutes...
 10 2012-02-23 00:22:57 <sipa> (Just realized that during a test with roconnor)
 11 2012-02-23 00:23:18 <BlueMatt> oh, thats odd...
 12 2012-02-23 00:23:36 <BlueMatt> I could have sword we request blockchain tip from every new connection...
 13 2012-02-23 00:23:49 <sipa> Nope, only the first one.
 14 2012-02-23 00:24:05 <sipa> That's usually enough to do an initial sync; newly found blocks are announces anyway.
 15 2012-02-23 00:24:06 <BlueMatt> damn, should be easy to fix though
 16 2012-02-23 00:29:52 <BlueMatt> well, ok its not much faster, but I do think it is slightly faster...which is just odd
 17 2012-02-23 00:30:19 <sipa> Remember, WINE is not an emulator :p
 18 2012-02-23 00:30:56 <BlueMatt> yes, but bitcoin-qt.exe is i386, not amd64 like bitcoin-qt on linux is...
 19 2012-02-23 00:31:13 <sipa> amd64 is far from necessarily faster
 20 2012-02-23 00:31:22 <BlueMatt> true, but it shouldnt be slower...
 21 2012-02-23 00:31:43 <BlueMatt> (or if it is, gcc needs some work...)
 22 2012-02-23 00:32:30 <sipa> It sure can be slower; higher code size means less code fits in the CPU's caches during execution.
 23 2012-02-23 00:32:59 <sipa> On the other hand, more and larger registers means some algorithms need less interaction with cache.
 24 2012-02-23 00:33:01 <BlueMatt> it sure can be, but if its ending up slower, gcc should be just using i386 instructions...
 25 2012-02-23 00:33:10 <sipa> Eh, no...
 26 2012-02-23 00:33:25 <sipa> The entire process is either 32-bit or 64-bit
 27 2012-02-23 00:34:16 <luke-jr> LOL
 28 2012-02-23 00:34:53 <luke-jr> BlueMatt: x86 != everything else ;)
 29 2012-02-23 00:35:07 <BlueMatt> that comment was just sad...
 30 2012-02-23 00:35:53 <BlueMatt> ...doesnt even make sense
 31 2012-02-23 00:36:38 <luke-jr> BlueMatt: other architectures support mixing 32-bit and 64-bit, but not x86
 32 2012-02-23 00:36:39 <sipa> I am very glad it is that way; now we have at least some hope of ever dumping all x86's compatibility modes
 33 2012-02-23 00:36:58 <BlueMatt> sipa: keep dreaming
 34 2012-02-23 00:37:02 <luke-jr> sipa: hahaha
 35 2012-02-23 00:37:03 <sipa> Yeah, I know...
 36 2012-02-23 00:37:09 <luke-jr> doesn't x86 still boot in 16-bit mode?
 37 2012-02-23 00:37:12 <BlueMatt> yep
 38 2012-02-23 00:37:13 <sipa> Yes.
 39 2012-02-23 00:37:18 <sipa> 8-bit mode even, no?
 40 2012-02-23 00:37:22 <luke-jr> >_<
 41 2012-02-23 00:37:26 <BlueMatt> thought it was 16, but maybe...
 42 2012-02-23 00:37:40 <luke-jr> sipa: I'd much rather dump x86 entirely
 43 2012-02-23 00:37:47 <sipa> luke-jr: ACK
 44 2012-02-23 00:37:54 <BlueMatt> luke-jr: for?
 45 2012-02-23 00:38:03 <luke-jr> if only Intel wasn't such jerks with keeping the microcode stuff closed, someone could port another arch to their CPUs :/
 46 2012-02-23 00:38:10 <BlueMatt> agreed, but, what for?
 47 2012-02-23 00:38:10 <luke-jr> BlueMatt: *anything* but x86&
 48 2012-02-23 00:38:33 <luke-jr> performance, for a start? sane instructions to look at when disassembling?
 49 2012-02-23 00:38:50 <BlueMatt> well, yea, it needs dumped, but what, for arm?
 50 2012-02-23 00:38:52 <Diablo-D3> luke-jr: not true
 51 2012-02-23 00:38:58 <sipa> x86 is a high-level architecture that is very very far from how it currently is actually executed
 52 2012-02-23 00:39:03 <Diablo-D3> the x86 decoder is not written in microcode
 53 2012-02-23 00:39:06 <Diablo-D3> it uses dedicated hardware
 54 2012-02-23 00:39:15 <Diablo-D3> what you COULD do, however, is use the native microarch as your arch
 55 2012-02-23 00:39:16 <luke-jr> BlueMatt: SPARC
 56 2012-02-23 00:39:23 <Diablo-D3> AMD allows this on very select CPUs
 57 2012-02-23 00:39:32 <Diablo-D3> its really fucking fast
 58 2012-02-23 00:39:39 <Diablo-D3> requires a board that has a firmware that can do it though
 59 2012-02-23 00:39:39 <luke-jr> Diablo-D3: I don't think the native microarch can run normal code
 60 2012-02-23 00:39:44 <Diablo-D3> luke-jr: it can
 61 2012-02-23 00:39:51 <Diablo-D3> on k8s and up, theres even a gcc patchset for it
 62 2012-02-23 00:39:53 <pingdrive> luke-jr, if only Intel wasn't such jerks with keeping the microcode stuff closed, someone could port another arch to their CPUs :/
 63 2012-02-23 00:39:58 <pingdrive> this makes no sense
 64 2012-02-23 00:40:12 <pingdrive> do you know how cpu works?
 65 2012-02-23 00:40:16 <luke-jr> it's tempting to paste this link to someone I don't like: http://91.222.39.58:8080/realsolid_logs.txt (DO NOT CLICK)
 66 2012-02-23 00:40:18 <Diablo-D3> pingdrive: he doesnt, and I just pwned him
 67 2012-02-23 00:40:39 <pingdrive> oh werd
 68 2012-02-23 00:40:40 <luke-jr> pingdrive: obviously not, because Intel won't release specs
 69 2012-02-23 00:40:42 <Diablo-D3> luke-jr: why no click? last measure?
 70 2012-02-23 00:40:51 <BlueMatt> luke-jr: thats like putting up a big red button and only putting "DO NOT PUSH" on it
 71 2012-02-23 00:40:57 <BlueMatt> luke-jr: you know everyone is gonna push it
 72 2012-02-23 00:41:15 <luke-jr> Diablo-D3: it's rigged to a DDoS
 73 2012-02-23 00:42:14 <Diablo-D3> so if I vist it on caspar, it will end up with you in prison?
 74 2012-02-23 00:42:28 <luke-jr> me? no
 75 2012-02-23 00:44:09 <dub> I clicked the other link (thanks gmaxwell), didnt notice any ddos
 76 2012-02-23 00:44:18 <BlueMatt> sipa: ohhhh, its progress bar was off because its only connected to one node (so 100% is highest checkpoint, not others peer's highest block)
 77 2012-02-23 00:44:55 <sipa> Haha.
 78 2012-02-23 00:46:22 <BlueMatt> (also, we need another checkpoint, its been quite a while)
 79 2012-02-23 00:47:28 <sipa> 168000 was a nice number
 80 2012-02-23 00:47:32 <sipa> ;;bc,blocks
 81 2012-02-23 00:47:33 <gribble> 168025
 82 2012-02-23 00:47:45 <sipa> (though it should be 100 deep)
 83 2012-02-23 00:47:56 <BlueMatt> it will easily be by the time we release 0.6
 84 2012-02-23 00:48:17 <BlueMatt> well, I was going to test the non-debug binary to compare its speed with the debug one, but the non-debug one crashed just sitting there downloading blocks (and guess what, its backtrace was useless :) )
 85 2012-02-23 00:56:42 <luke-jr> BlueMatt: eh, debug binary? O.o
 86 2012-02-23 00:56:52 <BlueMatt> luke-jr: read logs
 87 2012-02-23 00:56:54 <luke-jr> BlueMatt: does Windows not support split debug info like Linux?
 88 2012-02-23 00:56:58 <BlueMatt> luke-jr: read logs
 89 2012-02-23 00:57:01 <luke-jr> which part?
 90 2012-02-23 00:57:12 <BlueMatt> everything after <BlueMatt> wumpus: ping
 91 2012-02-23 00:58:40 <luke-jr> hrm
 92 2012-02-23 00:58:49 <luke-jr> why doesn't -g work?
 93 2012-02-23 00:59:12 <BlueMatt> nfc, Im assuming qmake puts some strips in the Makefile, but I cant figure out where and how to skip it
 94 2012-02-23 00:59:28 <BlueMatt> (again google turns up a useful...nothing)
 95 2012-02-23 00:59:50 <sipa> BlueMatt: i change the 'STRIP := strip' to 'STRIP := true' in the generated Makefile manually if I need debug binaries
 96 2012-02-23 00:59:59 <sipa> Didn't know a better way :)
 97 2012-02-23 01:00:00 <luke-jr> ah
 98 2012-02-23 01:00:14 <BlueMatt> sipa: tried it, also $(STRIP) is never called
 99 2012-02-23 01:00:22 <luke-jr> I thought you meant it literally didn't do anything in gdb :p
100 2012-02-23 01:00:24 <luke-jr> gcc*
101 2012-02-23 01:01:19 <sipa> BlueMatt: Hmm, right.
102 2012-02-23 01:01:20 <BlueMatt> Ill probably look more into it later, but afaict gcc is ignoring -g
103 2012-02-23 01:02:07 <pingdrive> which file in ./bitcoin directory contains the data displayed on blockexplorer?
104 2012-02-23 01:02:11 <sipa> Isn't some degree of debugging debug?
105 2012-02-23 01:02:13 <sipa> *default
106 2012-02-23 01:02:23 <BlueMatt> pingdrive: blk*
107 2012-02-23 01:02:35 <BlueMatt> sipa: not afaict (strip does nothing on the default release binaries)
108 2012-02-23 01:02:59 <luke-jr> BlueMatt: try
109 2012-02-23 01:03:01 <luke-jr> QMAKE_CXXFLAGS_RELEASE = $$QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO
110 2012-02-23 01:03:03 <luke-jr> QMAKE_LFLAGS_RELEASE = $$QMAKE_LFLAGS_RELEASE_WITH_DEBUGINFO
111 2012-02-23 01:03:16 <BlueMatt> hmm, that looks promising...
112 2012-02-23 01:03:32 <pingdrive> okay there are two files
113 2012-02-23 01:03:41 <pingdrive> which one contains difficulties for blocks
114 2012-02-23 01:03:45 <sipa> pingdrive: both
115 2012-02-23 01:04:30 <sipa> pingdrive: blk0001.dat contains the blocks themselves, blkindex.dat contains metadata about all blocks and transactions (in particular which ones are already spent, and where in blk0001.dat they reside)
116 2012-02-23 01:04:51 <sipa> But the difficulty is both part of the blocks themselves and part of the metadata.
117 2012-02-23 01:05:01 <pingdrive> i need to pull all difficulties for all block ever
118 2012-02-23 01:05:06 <pingdrive> blocks*
119 2012-02-23 01:05:34 <sipa> 0.6.0's getblock RPC call is probably the easiest way to get those.
120 2012-02-23 01:05:53 <pingdrive> ummm
121 2012-02-23 01:05:59 <pingdrive> what does that mean?>
122 2012-02-23 01:08:00 <sipa> https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)
123 2012-02-23 01:08:24 <pingdrive> its never easy
124 2012-02-23 01:08:27 <pingdrive> grr
125 2012-02-23 01:08:47 <sipa> ?
126 2012-02-23 01:09:12 <pingdrive> always gotta do work before you do work
127 2012-02-23 01:09:41 <sipa> :)
128 2012-02-23 01:14:06 <pingdrive> i know people post on bitcoin forums asking for work, but most stuff i can do myself, i just cant figure out when do i involve people and pay thme
129 2012-02-23 01:14:28 <BlueMatt> luke-jr: RELEASE_WITH_DEBUGINFO is exactly the same as debug afaict...
130 2012-02-23 01:14:29 <BlueMatt> :(
131 2012-02-23 01:14:39 <BlueMatt> (links to debug qt libraries, etc)
132 2012-02-23 01:14:45 <luke-jr> :/
133 2012-02-23 01:16:32 <BlueMatt> so, in other words, it looks like qt recommends releasing stripped debug binaries...
134 2012-02-23 01:17:43 <BlueMatt> Im gonna go do some more benchmarking between the two, and if its all good, Ill pull request that
135 2012-02-23 01:18:12 <luke-jr> BlueMatt: Qt debug has asserts all over the place
136 2012-02-23 01:18:24 <luke-jr> is this problem Win32-specific, or Linux too?
137 2012-02-23 01:18:32 <BlueMatt> so? if it doesnt effect performance much, who cares?
138 2012-02-23 01:18:35 <BlueMatt> its win32-specific
139 2012-02-23 01:19:02 <BlueMatt> (and it shouldnt, assuming all those asserts are only in gui threads and dont touch blockchain download)
140 2012-02-23 01:23:14 <BlueMatt> luke-jr: for some backward-ass reason, building on linux with CONFIG = debug links against the RELEASE versions of libqt, not the debug ones...
141 2012-02-23 01:25:49 <luke-jr> <.<
142 2012-02-23 01:25:59 <BlueMatt> maybe ubuntu/debian fucked with qmake, but...
143 2012-02-23 01:45:39 <nanotube> sipa: maybe. shoot me a link to your crawler db again? :)
144 2012-02-23 02:08:08 <BlueMatt> nevermind, stripped version linked against debug qt libs has measurably worse performance...
145 2012-02-23 02:10:06 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 887 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/887>
146 2012-02-23 02:46:05 <BlueMatt> omfg...
147 2012-02-23 02:46:11 <BlueMatt> OMFG
148 2012-02-23 02:46:18 <luke-jr> &
149 2012-02-23 02:46:26 <BlueMatt> so that measurably worse performance of the debug version, guess what?
150 2012-02-23 02:46:33 <BlueMatt> cblockstore has always been built in debugmode
151 2012-02-23 02:46:43 <BlueMatt> so...there is no damn performance issue
152 2012-02-23 02:46:58 <BlueMatt> in fact, its slightly faster
153 2012-02-23 02:47:08 <luke-jr> LOL
154 2012-02-23 02:47:11 <luke-jr> nice
155 2012-02-23 02:47:13 <BlueMatt> FML
156 2012-02-23 02:47:30 <luke-jr> BlueMatt++ for improving performance accidentally
157 2012-02-23 02:47:57 <BlueMatt> no, the slightly faster part is (im 99% sure) just the moving of wallet rescan to a separate thread
158 2012-02-23 02:48:05 <luke-jr> lol
159 2012-02-23 02:48:19 <luke-jr> oh well, still
160 2012-02-23 02:48:20 <BlueMatt> though maybe there is more Ill probably do some more benchmarking later
161 2012-02-23 02:48:24 <BlueMatt> but either way
162 2012-02-23 02:48:30 <luke-jr> BlueMatt++ for writing hidden-bug-free code <.<
163 2012-02-23 02:48:56 <BlueMatt> BlueMatt-- for taking this damn long to figure out the issue
164 2012-02-23 02:49:05 <BlueMatt> I guess I come out with 0?
165 2012-02-23 02:49:21 <luke-jr> BlueMatt: don't be so hard on yourself
166 2012-02-23 02:49:42 <luke-jr> I'm just as much to blame
167 2012-02-23 02:49:48 <luke-jr> I should have noticed it didn't impact next-test
168 2012-02-23 02:49:56 <k9quaint> bluematt: worse, it turns out you are not the real bluematt, just a pointer to the real one
169 2012-02-23 02:50:13 <BlueMatt> luke-jr: well its a pita to test because its slight enough that you have to download plenty of blocks to figure it out...
170 2012-02-23 02:50:16 <k9quaint> and now that you have been incremented, we lost you in a page swap :(
171 2012-02-23 03:21:02 <BlueMatt> the perf difference on cblockstore is about 5%, probably +/- something like 2%
172 2012-02-23 03:21:15 <BlueMatt> so not much, but measureable
173 2012-02-23 03:21:27 <BlueMatt> measurable*
174 2012-02-23 03:23:31 <luke-jr> BlueMatt: but favourable?
175 2012-02-23 03:24:26 <BlueMatt> yea
176 2012-02-23 03:24:54 <BlueMatt> Ill publish some hard numbers once Ive run the test a couple times
177 2012-02-23 03:27:09 <BlueMatt> odd, it looks like actually less than 50% of that diff is due to the scanning of blocks for wallet txes without blocking block download
178 2012-02-23 03:30:26 <BlueMatt_> yay, also back to the really weird computer lockups :)
179 2012-02-23 03:30:28 <BlueMatt_> :(
180 2012-02-23 03:45:03 <luke-jr> BlueMatt_: maybe try Linux 3.2
181 2012-02-23 03:45:18 <luke-jr> at least nested VT-x seemed unstable with 3.1
182 2012-02-23 03:45:28 <BlueMatt_> Im not even using vt-x
183 2012-02-23 03:45:32 <luke-jr> gitian
184 2012-02-23 03:45:38 <BlueMatt> Im not using gitian
185 2012-02-23 03:45:46 <BlueMatt> literally the only thing running is bitcoin-qt
186 2012-02-23 03:45:50 <luke-jr> O.o
187 2012-02-23 03:45:52 <BlueMatt> (2 of them exchanging blocks)
188 2012-02-23 03:45:55 <BlueMatt> (on tmpfs's)
189 2012-02-23 03:45:59 <luke-jr> hmm
190 2012-02-23 03:46:05 <luke-jr> memtest said OK?
191 2012-02-23 03:47:17 <BlueMatt> yea
192 2012-02-23 03:47:35 <BlueMatt> I should do a straight cpu stresstest too, just havnt had time yet...
193 2012-02-23 09:12:41 <xenland> How do I send Bitcoins through RPC with a precision of 8 decimal points?
194 2012-02-23 09:12:53 <sipa> ?
195 2012-02-23 09:12:57 <xenland> I'll have to compile my own client I'm thinking right?
196 2012-02-23 09:13:05 <sipa> No.
197 2012-02-23 09:13:38 <sipa> sendtoaccount address 1.23456789
198 2012-02-23 09:13:45 <xenland> Well my problem is when i use the bitcoin-php library I sendtoaddress() and it constantly rounds to a the .01 decminal place
199 2012-02-23 09:13:49 <sipa> eh, sendtoaddress
200 2012-02-23 09:14:04 <sipa> Which bitcoin version?
201 2012-02-23 09:14:27 <xenland> 5.1 or 5.2 i can't remember let me check
202 2012-02-23 09:14:45 <sipa> It should never round.
203 2012-02-23 09:15:23 <sipa> Maybe a bug in the library?
204 2012-02-23 09:18:06 <xenland> I looked in the library functions/classes it dosen't do any rounding or anything to the value although in their documentation it explains that it will round to the nearest thousandth
205 2012-02-23 09:18:15 <xenland> so I assumed it was the bitcoin client
206 2012-02-23 09:18:39 <xenland> im going to try through command line and see if it rounds
207 2012-02-23 09:20:49 <xenland> It was becuase i wasn't taking into account for transaction fees
208 2012-02-23 09:47:28 <swulf--> curious..i'm still learning how bitcoin works internally, but one thing i can't figure out is the timestamps in a block header.. how are those verified to be correct?  couldn't a client just put garbage in as a date?
209 2012-02-23 09:49:49 <sipa> they must not be: lower than the median of the past 11 blocks, and not be more than 2 hours in the future
210 2012-02-23 09:50:14 <swulf--> !
211 2012-02-23 09:50:16 <swulf--> so clever
212 2012-02-23 09:52:34 <swulf--> since a block can have a timestamp 2 hours in the future, does it matter that a subsequent block has a timestamp less than the previous?
213 2012-02-23 10:00:01 <Graet> no
214 2012-02-23 10:14:28 <badluck> upgrade your shizzles
215 2012-02-23 10:17:45 <sipa> ?
216 2012-02-23 10:25:10 <badluck> broctothorpe
217 2012-02-23 10:30:34 <gribble> New news from bitcoinrss: jonassmedegaard opened issue 888 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/888>
218 2012-02-23 11:03:43 <vegard> public keys are not uniformly distributed, are they?
219 2012-02-23 11:04:09 <Diablo-D3> vegard: "yes"
220 2012-02-23 11:04:25 <Diablo-D3> but the algo selected was not selected based on it being uniformly distributed or not
221 2012-02-23 11:04:41 <Diablo-D3> it just happens that cryptographically strong algos tend to score highly on that
222 2012-02-23 11:05:14 <vegard> examining the public keys embedded in the block chain, I find that they are highly non-uniform
223 2012-02-23 11:05:46 <Diablo-D3> how many keys is that, though?
224 2012-02-23 11:05:58 <Diablo-D3> you cant do uniformity tests unless you have several million keys
225 2012-02-23 11:08:16 <vegard> I find that 26.7% of the bits are fixed to either 0 or 1
226 2012-02-23 11:09:01 <vegard> for example: bit 911, 919, 927, 935, and 943 of the pubkey are always fixed to 0
227 2012-02-23 11:09:50 <vegard> that looks like a stride of 8.. but I don't think I have a bug in my program, because you can grab any pubkey off blockexplorer and verify it easily
228 2012-02-23 11:10:04 <vegard> for example, I grabbed the key 0x041d90591be2f1c02ad6f8a5bc60bb2fac335d9433657623fc4f9e270dee012c790e2cd2f83d10a60f9cf5d16b009e10e6847dd696a16e34ad8aec73747775804d off the latest block
229 2012-02-23 11:10:11 <Diablo-D3> bring it up with gmaxwell
230 2012-02-23 11:10:44 <sipa> vegard: no reason it needs to be uniform
231 2012-02-23 11:10:52 <Diablo-D3> also, that too
232 2012-02-23 11:11:06 <vegard> so they're not supposed to be, right?
233 2012-02-23 11:11:17 <Diablo-D3> vegard: thats not true either
234 2012-02-23 11:11:17 <vegard> (that was my original question)
235 2012-02-23 11:11:19 <sipa> also, they are only 512 bits wide
236 2012-02-23 11:11:34 <badluck> theres a checksum embedded in the address
237 2012-02-23 11:11:34 <vegard> O.o
238 2012-02-23 11:11:46 <Diablo-D3> heh, could explain the weirdity
239 2012-02-23 11:12:15 <sipa> vegard: disregard the 0x04 at the start, that is just serialization
240 2012-02-23 11:12:15 <ThomasV> address != pubkey
241 2012-02-23 11:12:41 <sipa> after that there are 128 hex characters
242 2012-02-23 11:13:15 <vegard> nvm
243 2012-02-23 11:13:19 <vegard> I found the bug
244 2012-02-23 11:13:27 <Diablo-D3> vegard: when in doubt, doubt your code
245 2012-02-23 11:13:44 <vegard> still, my original question holds: are they supposed to be uniformly random or not? :-P
246 2012-02-23 11:13:57 <Diablo-D3> vegard: neither.
247 2012-02-23 11:13:59 <sipa> i'd say no
248 2012-02-23 11:14:03 <Diablo-D3> its a factor that doesnt matter
249 2012-02-23 11:14:17 <Diablo-D3> infact, uniformly random is a misnomer
250 2012-02-23 11:14:24 <Diablo-D3> if something is uniformly random, its not random
251 2012-02-23 11:14:37 <sipa> Diablo-D3: it is
252 2012-02-23 11:14:44 <Diablo-D3> sipa: yet its not
253 2012-02-23 11:14:58 <Diablo-D3> any truly random number god would still have clumps of shit
254 2012-02-23 11:15:10 <vegard> not in the long run
255 2012-02-23 11:15:13 <sipa> uniformly random means that each possibility is equally likely
256 2012-02-23 11:15:26 <Diablo-D3> sipa: yes, but it doesnt mean every possibility HAS equally happened
257 2012-02-23 11:15:36 <Diablo-D3> this is why you need a significant number of results from the search space
258 2012-02-23 11:15:42 <sipa> that doesn't mean local clustering is forbidden
259 2012-02-23 11:15:54 <Diablo-D3> hes only looking at pubkeys in the chain
260 2012-02-23 11:15:59 <Diablo-D3> which is a smidgen of all possible keys
261 2012-02-23 11:16:07 <sipa> irrelevant
262 2012-02-23 11:16:31 <sipa> he is making an observation based on a limited sample
263 2012-02-23 11:16:39 <Diablo-D3> badly performed science is never irrelevant
264 2012-02-23 11:17:00 <Diablo-D3> yeah, but you have to ask yourself is the sample statistically valid
265 2012-02-23 11:17:08 <sipa> but that may allow him to derive statistical information about the population
266 2012-02-23 11:17:10 <vegard> the bad science here was using the ascii string instead of the binary string :-P
267 2012-02-23 11:17:19 <Diablo-D3> vegard: that too.
268 2012-02-23 11:17:21 <sipa> LOL
269 2012-02-23 11:17:36 <Diablo-D3> infact, no wonder you think its not random
270 2012-02-23 11:18:10 <Diablo-D3> sipa: yes, but he cant derive if its uniform or not
271 2012-02-23 11:18:32 <Diablo-D3> 2**512 is like 13 brazillion or something
272 2012-02-23 11:18:49 <sipa> vegard: anyway, there is a simple mathematical relation that holds for all valid pubkrys, so they are definitely not truly uniformly distributed
273 2012-02-23 11:19:22 <vegard> Diablo-D3: if one of the bits of the pubkey is not uniformly distributed, the whole pubkey cannot be uniformly distributed
274 2012-02-23 11:19:44 <Diablo-D3> vegard: thats not true
275 2012-02-23 11:19:46 <vegard> (this is not true the other way, though)
276 2012-02-23 11:19:49 <Diablo-D3> they actually have a scale for that.
277 2012-02-23 11:20:16 <Diablo-D3> Ive seen it mentioned in papers
278 2012-02-23 11:20:37 <badluck> well it should be uniformly distribtued among all possible keys.. but the bitpattern doesnt have to be
279 2012-02-23 11:21:39 <Diablo-D3> anyhow, I said strong crypto algos perform good on distribution
280 2012-02-23 11:21:51 <Diablo-D3> there are non-cyrpto algos that perform better
281 2012-02-23 11:23:11 <Diablo-D3> its not perfectly uniform, but its clearly in the good enough territory
282 2012-02-23 11:27:20 <sipa> Diablo-D3: sure, perfect hash functions can be better than cryptographic hashes for some purposes
283 2012-02-23 11:27:49 <sipa> but the public key construction is not a hash function at all
284 2012-02-23 11:28:15 <sipa> all it claims is being hard to revert to the private key
285 2012-02-23 11:28:58 <Diablo-D3> hrm
286 2012-02-23 11:29:08 <vegard> ok, so now using the binary values, it does indeed appear that each bit is approximately uniformly distributed
287 2012-02-23 11:29:27 <Diablo-D3> anyhow, Im going to bed
288 2012-02-23 11:29:32 <Diablo-D3> night all
289 2012-02-23 11:30:02 <vegard> night!
290 2012-02-23 11:30:59 <sipa> vegard: maybe it is not uniform antmore for combinations of bits
291 2012-02-23 11:31:26 <vegard> maybe.
292 2012-02-23 11:34:14 <badluck> ecc keyspace is around half the key size
293 2012-02-23 11:38:57 <archo43> whats a perfect hash function?
294 2012-02-23 11:39:16 <badluck> a collision-free one
295 2012-02-23 11:40:50 <edcba> that's not an hash anymore then
296 2012-02-23 11:41:07 <badluck> yes it is. a perfect one
297 2012-02-23 11:41:34 <edcba> you can't reduce an infinite set of element to a finite one without collisions :)
298 2012-02-23 11:41:54 <edcba> unless perfect means impossible :p
299 2012-02-23 11:42:11 <sipa> perfect hash functions are defined for finite sets
300 2012-02-23 11:42:14 <badluck> yes, the set of elements has to be finite, of course
301 2012-02-23 11:42:49 <sipa> and cryptographic hash functions cannot be perfect, as they would leak information
302 2012-02-23 11:44:14 <badluck> http://cmph.sourceforge.net/
303 2012-02-23 12:33:47 <archo43> i agree
304 2012-02-23 12:33:59 <archo43> the size of the hash of a perfect function must equal its inputs
305 2012-02-23 12:39:11 <vegard> that's not true
306 2012-02-23 12:39:26 <vegard> the number of bits of output could be larger than the number of bits of input
307 2012-02-23 12:51:02 <sipa> archo43: you're talking about a minimal perfect hash
308 2012-02-23 14:08:54 <swulf--> why are the upper (lower?) 8 bytes of the block sha256 hash all zero?  kind of weird to me that a hash function has such a common occurrence of zeros
309 2012-02-23 14:09:36 <swulf--> sorry... 6 bytes?
310 2012-02-23 14:09:56 <swulf--> or is it that they aren't, just that those blocks in bitcoin have to be all zero in order to meet the target?
311 2012-02-23 14:10:01 <Zarutian> swulf--: you familiar with the concept of hashcash?
312 2012-02-23 14:10:09 <slush> https://en.bitcoin.it/wiki/Proof_of_work
313 2012-02-23 14:10:15 <slush> swulf--: ^
314 2012-02-23 14:10:25 <swulf--> i understand the proof of work concept
315 2012-02-23 14:10:39 <slush> then what you don't understand ? :-)
316 2012-02-23 14:10:41 <swulf--> am i correct in stating that the only reason why the hash is full of leading zeros is because the target hash is full of leading zeros?
317 2012-02-23 14:10:57 <swulf--> s/target hash/target
318 2012-02-23 14:11:01 <slush> yes
319 2012-02-23 14:11:03 <swulf--> ok:)
320 2012-02-23 14:11:04 <swulf--> thanks
321 2012-02-23 14:12:20 <swulf--> any reason why the header of each block compresses the target to 4 bytes? why not just send the full 32 byte target?  extra 28 bytes on a header isn't that big of a deal, is it?
322 2012-02-23 14:13:01 <sipa> Headers are 80 bytes now; 28 bytes extra is relevant :)
323 2012-02-23 14:13:24 <pasa> tuum ganish budunga deh heh...ganish budunga ga deh he
324 2012-02-23 14:14:14 <swulf--> :)
325 2012-02-23 14:52:13 <ThomasV> !seen piuk
326 2012-02-23 14:52:14 <gribble> piuk was last seen in #bitcoin-dev 3 weeks, 3 days, 18 hours, 53 minutes, and 4 seconds ago: <piuk> ignore that - my mistake
327 2012-02-23 14:59:15 <kokjo> hi!
328 2012-02-23 15:00:07 <kokjo> is it possible to harvest fees multiple times by including the same transaction multiple blocks?
329 2012-02-23 15:00:49 <luke-jr> no
330 2012-02-23 15:00:55 <luke-jr> the same transaction is not valid twice
331 2012-02-23 15:01:01 <kokjo> and what does the satoshi client do, about block with already comfirmed transactions?
332 2012-02-23 15:01:19 <sipa> kokjo: it will reject them
333 2012-02-23 15:01:28 <sipa> as is required by the network rules
334 2012-02-23 15:01:29 <kokjo> are you sure?
335 2012-02-23 15:01:36 <riush> https://en.bitcoin.it/wiki/Protocol_rules
336 2012-02-23 15:01:36 <sipa> postive
337 2012-02-23 15:01:58 <kokjo> thanks!
338 2012-02-23 15:03:47 <riush> kokjo: block messages, 16.1.5, should cover your case
339 2012-02-23 15:04:53 <kokjo> yes but if that transaction, does have the same hash, would it be possible to hit a glitch?
340 2012-02-23 15:05:29 <edcba> that won't happen
341 2012-02-23 15:05:40 <gmaxwell> having a different transaction with the same hash isn't the same thing as having the same transaction twice.
342 2012-02-23 15:05:59 <riush> well, bugs are always possible, but i would expect the client looking in its database, seeing 'already got that' and ignoring it
343 2012-02-23 15:06:13 <gmaxwell> edcba: well, there is a way that it can be caused to happen, but we're in the process of making that impossible.
344 2012-02-23 15:06:16 <sipa> first, such transactions will not be accepted into the memory pool
345 2012-02-23 15:06:37 <sipa> second, if they were in a block a second time, that would mean spending its inputs twice
346 2012-02-23 15:06:45 <sipa> which is most certainly forbibbed
347 2012-02-23 15:06:52 <kokjo> sipa: could a rough miner do it?
348 2012-02-23 15:07:04 <sipa> kokjo: yes, but his blocks would be ignored by everyone else
349 2012-02-23 15:07:12 <sipa> because such a block is not valid
350 2012-02-23 15:08:40 <kokjo> fine, thanks!
351 2012-02-23 15:08:46 <gmaxwell> Exactly as a 'miner' could produce a 'block' that was nothing but the word 'spam' repeated over and over again 'spamspamspamspam...' of course, all other nodes would just drop it and would blacklist peers trying to tell them about it.
352 2012-02-23 15:09:20 <kokjo> going to look though the code, to find out where the magic happens :)
353 2012-02-23 15:09:45 <kokjo> thanks for your help. :)
354 2012-02-23 15:25:54 <jrmithdobbs> you could coinbase to a script that was spamspamspamspamspam and burns the coins though
355 2012-02-23 15:26:21 <jrmithdobbs> but why
356 2012-02-23 15:43:52 <gribble> sirius was last seen in #bitcoin-dev 23 weeks, 5 days, 8 hours, 44 minutes, and 37 seconds ago: <sirius> The forum is being relocated and should be up some time today. There was an exploit that allowed to upload javascript as a smiley and embed it. The database should be safe.
357 2012-02-23 15:43:52 <jgarzik> !seen sirius
358 2012-02-23 15:44:00 <jgarzik> hrm
359 2012-02-23 15:44:12 <gribble> theymos was last seen in #bitcoin-dev 3 days, 16 hours, 14 minutes, and 24 seconds ago: <theymos> gmaxwell: Thanks. I will add it.
360 2012-02-23 15:44:12 <jgarzik> !seen theymos
361 2012-02-23 16:39:03 <swulf--> where in the code is the difficulty (the one that occurs ever 2016) adjustment made?
362 2012-02-23 16:39:09 <swulf--> every*
363 2012-02-23 16:41:52 <gavinandresen> main.cpp GetNextWorkRequired.  If I recall correctly
364 2012-02-23 16:42:14 <BlueMatt> gmaxwell sipa: cblockstore performance issues resolved :)
365 2012-02-23 16:42:22 <BlueMatt> (turns out there never were any performance issues)
366 2012-02-23 16:42:26 <swulf--> is it GetNextWorkR... oh :)
367 2012-02-23 16:42:30 <swulf--> foudn it just as you said that
368 2012-02-23 16:42:39 <swulf--> thanks
369 2012-02-23 16:43:48 <jrmithdobbs> ThomasV: i sent those sidsecurity guys an email seeing what it takes to get a devkit/etc, no response yet :(
370 2012-02-23 16:43:55 <jrmithdobbs> err nidsecurity
371 2012-02-23 16:44:03 <ThomasV> when?
372 2012-02-23 16:44:10 <jrmithdobbs> earlier this morning
373 2012-02-23 16:44:18 <jrmithdobbs> it's still early in CA we'll see ;p
374 2012-02-23 16:44:25 <ThomasV> I think they are in switwerland, no?
375 2012-02-23 16:45:33 <ThomasV> http://www.nidsecurity.com/about/about.html
376 2012-02-23 16:46:17 <ThomasV> oh they have offices in LA too
377 2012-02-23 16:51:59 <ThomasV> jrmithdobbs: I also compiled a list of references on the wiki: https://en.bitcoin.it/wiki/Smart_card_wallet One of them is an implementation of ECDSA on a smart card
378 2012-02-23 16:54:02 <ThomasV> jrmithdobbs: if you are serious about doing it, I suggest to start with standard smart cards; dev kits are cheap for those
379 2012-02-23 17:07:43 <btc_novice> Are the bitcoin.conf and command line options meant to be interchangeable?
380 2012-02-23 17:07:50 <btc_novice> I would have thought yes....
381 2012-02-23 17:08:43 <btc_novice> For example, the "testnet" flag-- on the command line it must be -testnet, and in the conf file, it must be testnet=1
382 2012-02-23 17:09:10 <XMPPwocky> yu-[
383 2012-02-23 17:09:13 <XMPPwocky> yup
384 2012-02-23 17:12:29 <btc_novice> XMPPwocky: so they are not meant to be interchangeable?
385 2012-02-23 17:12:57 <XMPPwocky> they are interchangable
386 2012-02-23 17:13:46 <btc_novice> But in practice, they are not interchangeable.
387 2012-02-23 17:14:15 <btc_novice> the conf file requires testnet=1 to use the testnet.
388 2012-02-23 17:14:28 <XMPPwocky> read util.h
389 2012-02-23 17:14:29 <btc_novice> if you just put testnet in the conf file, it throws an exception.
390 2012-02-23 17:14:48 <XMPPwocky> the syntax is not interchangable
391 2012-02-23 17:15:24 <XMPPwocky> the meaning is (except for those that affect the findingm of the configcfiole)
392 2012-02-23 17:16:02 <btc_novice> That's fine, but consistency would be nice. For example, the min flag does not behave the same as the testnet flag between command line and conf file.
393 2012-02-23 17:16:21 <XMPPwocky> read util.h
394 2012-02-23 17:16:31 <btc_novice> I will
395 2012-02-23 17:23:24 <btc_novice> test
396 2012-02-23 17:23:59 <BlueMatt_> ???
397 2012-02-23 17:24:25 <gavinandresen> btc_novice: -testnet=1 on the command line works
398 2012-02-23 17:24:37 <gavinandresen> (as does -testnet=0)
399 2012-02-23 17:25:17 <btc_novice> Thanks gavinadresen. I guess what bothers me is that "min" in the conf file works (no value), but "testnet" does not.
400 2012-02-23 17:25:34 <btc_novice> seems it should be consistent, that's all.
401 2012-02-23 17:26:50 <btc_novice> *gavinandresen, oops :)
402 2012-02-23 17:27:57 <gavinandresen> oops?  just min in the bitcoin.conf doesn't do what you thought it did?
403 2012-02-23 17:30:27 <btc_novice> gavinandresen: oops because I spelled your last name wrong. o_O. just min in the bitcoin.conf file does what I thought it would do, but just testnet in bitcoin.conf throws an exception.  It needs to be testnet=0 or testnet=1 to work.
404 2012-02-23 17:30:50 <btc_novice> I expected just testnet in the file to work like -testnet on the command line does.
405 2012-02-23 17:31:01 <gavinandresen> file an issue
406 2012-02-23 17:31:30 <btc_novice> Ok, I will.
407 2012-02-23 17:31:35 <btc_novice> Thanks.
408 2012-02-23 17:34:21 <gavinandresen> gmaxwell sipa : I just pushed a new checkpoint, at block 168,000
409 2012-02-23 17:34:47 <captain^k> thats a big deal
410 2012-02-23 17:35:02 <captain^k> thank you :)
411 2012-02-23 17:35:37 <badluck> checkpoint logged
412 2012-02-23 17:38:54 <badluck> of course there is a way to prune all that block log
413 2012-02-23 17:39:50 <badluck> allow the client to accept any blockchain of equal or greater hash difficulty that compresses all the current balances into one initialization block
414 2012-02-23 17:40:41 <gmaxwell> badluck: May I suggest you spend some time trying to implement some ideas like that?
415 2012-02-23 17:40:46 <badluck> the compressified one would just be one notch higher in the precedence, as long as it meets those conditions - of being a faithful continuation of the prime chain and at least X blocks went by
416 2012-02-23 17:41:09 <badluck> gmaxwell: yes ill research it some more
417 2012-02-23 17:41:37 <gmaxwell> Suggesting it is fine and all but I could spew out ideas like that about as fast as I can type. Proving their security and implementing them is the hard part and you'd learn about what can and can't work in the process.
418 2012-02-23 17:41:58 <badluck> gmaxwell: your aversion to discussing change is well known
419 2012-02-23 17:42:27 <badluck> i know your sensors prefer change of incremental magnitude <= heuristic_threshold
420 2012-02-23 17:42:36 <badluck> hehe j/k bro
421 2012-02-23 17:43:13 <wumpus> sigh, indeed
422 2012-02-23 17:43:51 <gmaxwell> I did that because he's that many-named troll who was "doxing" coingenuity and wasting a bunch of time I didn't realize who he was until his 'well known' comment caused me to go look.
423 2012-02-23 17:51:17 <captain^k> well spotted :)
424 2012-02-23 18:03:14 <luke-jr> gavinandresen: should I expect getalltxns+getblock_full in 0.6 or 0.7?
425 2012-02-23 18:03:34 <luke-jr> (or is that still undecided?)
426 2012-02-23 18:03:39 <gavinandresen> no 0.6
427 2012-02-23 18:03:46 <gavinandresen> err, not 0.6
428 2012-02-23 18:03:55 <gavinandresen> 0.6 should be considered feature-frozen
429 2012-02-23 18:05:13 <luke-jr> ok, I wasn't sure if those counted as bugfixes to the new getblock feature or not
430 2012-02-23 18:05:25 <luke-jr> since it's mostly useless otherwise
431 2012-02-23 18:06:14 <luke-jr> (not arguing, just explaining why I asked :p)
432 2012-02-23 18:06:29 <gavinandresen> I used the new getblock feature just this morning to make sure the timestamps around block 168,000 were reasonable
433 2012-02-23 18:06:57 <jrmithdobbs> hrm, this is recent: cc1plus: warning: -Wformat-security ignored without -Wformat [-Wformat-security]
434 2012-02-23 18:07:07 <jrmithdobbs> want to fix makefile.unix? ;p
435 2012-02-23 18:08:59 <luke-jr> http://pastebin.com/EB0MnGdx <-- wtf is this conflict O.O
436 2012-02-23 18:09:59 <luke-jr> never seen a conflict as scary looking as that&
437 2012-02-23 18:13:28 <jrmithdobbs> 2012-02-23_19:12:11.38585 trying connection 31.147.181.34:8333 lastseen=-0.1hrs lasttry=-369451.2hrs
438 2012-02-23 18:13:31 <jrmithdobbs> um what
439 2012-02-23 18:14:42 <jrmithdobbs> was there time changes that makes my addr.dat nonsensical or something?
440 2012-02-23 18:15:08 <jrmithdobbs> just upgraded from .5.0.2 (iirc) to HEAD
441 2012-02-23 18:15:19 <gmaxwell> Last try being a crazy value just means you've never tried it
442 2012-02-23 18:17:18 <jrmithdobbs> ok, just never noticed
443 2012-02-23 18:17:25 <jrmithdobbs> teach me to read logs
444 2012-02-23 18:20:08 <swulf--> a bit off topic, but wondering if anyone's interested: i'm trying to devise a strategy for proof of work that maintains these constraints: 1) each solution takes roughly the same amount of time regardless of computing power (i.e., problem gets harder), 2) each *node* has a different difficulty so that it takes me the same time as it does you with different amounts of computing power, and 3) is still verifiable via a distributed net
445 2012-02-23 18:20:20 <swulf--> figure bitcoin guys are the best to ask, all things considered..
446 2012-02-23 18:20:36 <bulletbill> question about tx with same hash (generation in block 91812 & 91842) (http://blockchain.info/tx-index/144116/d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599)
447 2012-02-23 18:20:37 <bulletbill> i'm assuming the first generation in 91812 would be valid and the second one would be 'lost'. my question is: what does the client do currently when it sees this? is this something that is checked now and prevented?
448 2012-02-23 18:21:13 <swulf--> weird that there's a collision in blocks that are so close
449 2012-02-23 18:22:33 <bulletbill> wierd that there is a collision at all. this has been discussed on the forum. though no resolution. if i'm writing a payment system, what do i do when i see this? hoping gavinandresen/jgarzik/etc can shed some light
450 2012-02-23 18:23:13 <swulf--> its kinda interesting that the recipient is the same address,too
451 2012-02-23 18:23:16 <sipa> live-updated list of reachable nodes: http://bitcoin.sipa.be/seeds.txt
452 2012-02-23 18:23:43 <luke-jr> bulletbill: the current behaviour is exploitable; in the future, blocks will be required to include their height to prevent collisions
453 2012-02-23 18:23:47 <swulf--> sipa: no column headers :(
454 2012-02-23 18:23:53 <sipa> swulf--: tabs
455 2012-02-23 18:23:56 <sipa> oh
456 2012-02-23 18:23:58 <sipa> second
457 2012-02-23 18:24:11 <swulf--> sipa: what do the #s mean
458 2012-02-23 18:24:14 <luke-jr> bulletbill: basically, right now you want to consider the 1st one valid *until* the 2nd one; then that one becomes valid
459 2012-02-23 18:24:17 <swulf--> 99.99% of what? :)
460 2012-02-23 18:24:29 <jrmithdobbs> 100.00% 100.00% 99.97% 99.67%   99.66%  60000 "/Satoshi:0.6.0/"
461 2012-02-23 18:24:43 <swulf--> guessing the 32400 is the port number
462 2012-02-23 18:24:56 <swulf--> nope, nvm
463 2012-02-23 18:25:02 <swulf--> ports with the ip, as it should be
464 2012-02-23 18:26:45 <jrmithdobbs> sipa: that's pretty damned real time considering i had just upgraded that node less than 30 min ago
465 2012-02-23 18:27:20 <bulletbill> luke-jr: interesting. so i see the first, and credit the user 50btc. the user now does whatever they want with that money. there is no chance of loss for me, right? essentially, the second time the transaction appears it can't be a 25btc credit (thereby making me lose 25 if the user already withdrew)...
466 2012-02-23 18:27:38 <sipa> jrmithdobbs: my crawler visits the entire network in approximately 20 minutes
467 2012-02-23 18:27:55 <sipa> (20000 nodes)
468 2012-02-23 18:27:57 <jrmithdobbs> sipa: what are the values?
469 2012-02-23 18:28:08 <swulf--> sipa, this list isn't for all connected clients right?
470 2012-02-23 18:28:18 <jrmithdobbs> swulf--: all connectable
471 2012-02-23 18:28:32 <sipa> the crawlers bans nodes if they are persistently bad
472 2012-02-23 18:28:43 <swulf--> ah, so even though i'm connected, it may be that i'm behind a firewall and thats why i'm not on this list?
473 2012-02-23 18:29:04 <sipa> the percentages are availability in exponential windows with time factors 2 hours, 8 hours, 1 day, 1 week, 1 month
474 2012-02-23 18:29:13 <luke-jr> bulletbill: there is chance of loss
475 2012-02-23 18:29:15 <sipa> swulf--: indeed
476 2012-02-23 18:29:47 <sipa> though the 1-month was only enabled today, and the numbers were copies from the 1 weeks stats
477 2012-02-23 18:30:13 <bulletbill> luke-jr: crap.
478 2012-02-23 18:30:33 <gavinandresen> luke-jr: loss how?  The person who created the dup coinbase will lose coins....
479 2012-02-23 18:30:47 <luke-jr> gavinandresen: that's loss&
480 2012-02-23 18:30:57 <gavinandresen> but bulletbill doesn't care about that
481 2012-02-23 18:31:02 <luke-jr> bulletbill: in practical terms, I think if you ignore the 2nd one, you're safe
482 2012-02-23 18:31:23 <luke-jr> not 100% sure tho
483 2012-02-23 18:31:33 <jrmithdobbs> sipa: wondering what's making the 1week/month stat on that node so low
484 2012-02-23 18:31:46 <jrmithdobbs> sipa: since i know bitcoind hasn't even been restarted in the last month until just a minute ago ;p
485 2012-02-23 18:31:50 <luke-jr> bulletbill: actually, when you see the 2nd one, you'll want to restart the 100 block count
486 2012-02-23 18:31:54 <gavinandresen> to answer bulletbill's original question: the satoshi code will overwrite the second un-spent duplicate transaction, so the first one becomes un-spendable
487 2012-02-23 18:32:09 <sipa> jrmithdobbs: maybe its connect slots were full?
488 2012-02-23 18:32:25 <jrmithdobbs> sipa: oh good point, they do fill up occassionally even at 512
489 2012-02-23 18:32:30 <luke-jr> bulletbill: if that 2nd block gets orphaned, the entire network is in trouble, tho
490 2012-02-23 18:33:03 <gavinandresen> bulletbill: ... and we're going to make duplicate coinbases illegal soon, to avoid possible exploits that could happen if they are partially spent and involved in complicated blockchain re-organizations
491 2012-02-23 18:33:10 <jrmithdobbs> sipa: your aggregator isn't doing any dns ptr lookups where you might be trying to hit an ipv6 address you can't route to, right? ;p
492 2012-02-23 18:33:26 <sipa> jrmithdobbs: no IPv6 support for now
493 2012-02-23 18:33:36 <jrmithdobbs> sipa: eg ptr then AAAA record giving you the ipv6 which bitcoin isn't listening on
494 2012-02-23 18:33:54 <jrmithdobbs> (i've been having ipv6 issues on the host)
495 2012-02-23 18:34:01 <sipa> jrmithdobbs: all addresses come from bitcoin's addr packets
496 2012-02-23 18:34:09 <sipa> there is no dns lookup involved
497 2012-02-23 18:34:19 <jrmithdobbs> k
498 2012-02-23 18:34:26 <jrmithdobbs> pretty cool
499 2012-02-23 18:34:30 <bulletbill> gavinandresen: luke-jr: thanks for response. this one particular instance is a generation, so not too worried about that. what i am worried is about a send from A -> B that exhibits the same behavior (e.g. 40btc the first time and then 20btc the second time. invalidating the first send). or is that an entirely different problem?
500 2012-02-23 18:35:22 <gavinandresen> bulletbill: the only way to get non-generation duplication transaction ids is to spend two generation duplicate transaction ids
501 2012-02-23 18:35:22 <luke-jr> bulletbill: if the send is different, the hash will also be different
502 2012-02-23 18:36:08 <bulletbill> lol. good. that's comforting.
503 2012-02-23 18:36:15 <gavinandresen> bulletbill: ... and spend exactly the same number of coins to the same address both times (with the only input being the duplicate coinbase)
504 2012-02-23 18:36:53 <jrmithdobbs> barring any preimage attacks on sha2*
505 2012-02-23 18:36:55 <sipa> using the same PRNG when creating the signatures
506 2012-02-23 18:37:03 <gavinandresen> right, all that too
507 2012-02-23 18:37:05 <sipa> as ECDSA signatures are not deterministic
508 2012-02-23 18:37:16 <luke-jr> sipa: they could be made to be so, no?
509 2012-02-23 18:37:19 <sipa> luke-jr: yes
510 2012-02-23 18:37:39 <sipa> Ed25519 has a construction for making them deterministic
511 2012-02-23 18:38:02 <luke-jr> anyhow, Eligius now supports *for testing only* getmemorypool, currently renamed to test_getmemorypool
512 2012-02-23 18:38:19 <luke-jr> including submitting shares (currently must be unmodified except ntime/nonce)
513 2012-02-23 18:38:50 <sipa> so you could connect a p2pool node to it?
514 2012-02-23 18:39:00 <luke-jr> sipa: unlikely, as p2pool modifies the coinbase txn
515 2012-02-23 18:39:18 <luke-jr> with some hacking, you could probably make it workable
516 2012-02-23 18:39:29 <luke-jr> it would mine on Eligius, not p2pool, of course
517 2012-02-23 18:39:49 <bulletbill> gavinandresen: so basically, the net effect would be that the same amount of coins get delivered regardless, jsut that the coins are now 'newer' :)
518 2012-02-23 18:40:13 <jrmithdobbs> bulletbill: assuming all of the above, yes
519 2012-02-23 18:40:46 <luke-jr> basically
520 2012-02-23 18:40:51 <bulletbill> so, i'm not really seeing any attack vector here, right?
521 2012-02-23 18:41:07 <bulletbill> other than annoyance of revolving coin
522 2012-02-23 18:41:13 <jrmithdobbs> not that I can think of
523 2012-02-23 18:41:31 <luke-jr> bulletbill: well, if the new txn gets orphaned, about half of the entire bitcoin network breaks, and opens a can of worms; until we fix it
524 2012-02-23 18:41:35 <jrmithdobbs> sipa: Ed25519 is pretty cool stuff
525 2012-02-23 18:41:45 <sipa> jrmithdobbs: definitely
526 2012-02-23 18:41:50 <gmaxwell> jrmithdobbs: can't do key recovery without a minor modification though.
527 2012-02-23 18:42:03 <jrmithdobbs> sipa: i wish someone would supply some libc patches for dnscurve already
528 2012-02-23 18:42:19 <sipa> gmaxwell: but with only some minor modification it *can* do key recovery
529 2012-02-23 18:42:25 <gmaxwell> The place where the public key is included in the hash of the message needs to either be replaced with the address ... or the public key need to be omitted.
530 2012-02-23 18:42:26 <sipa> gmaxwell: formulate things positively :p
531 2012-02-23 18:42:28 <jrmithdobbs> gmaxwell: i'm not sure that's a bad thing any how
532 2012-02-23 18:42:38 <bulletbill> luke-jr: that is in the case where there are transactions further down in the chain that use that one as prevout
533 2012-02-23 18:42:41 <bulletbill> ?
534 2012-02-23 18:42:51 <gmaxwell> jrmithdobbs: well in our usage key recover is super-useful. For some applications its not.
535 2012-02-23 18:42:54 <luke-jr> bulletbill: ?
536 2012-02-23 18:42:58 <jrmithdobbs> gmaxwell: oh you mean for use in bitcoin, nm
537 2012-02-23 18:42:59 <jrmithdobbs> haha
538 2012-02-23 18:43:17 <sipa> Bitcoin 2.0 :)
539 2012-02-23 18:43:52 <bulletbill> luke-jr: well, if the new txn gets orphaned, only subsequent txs that rely on it would break? or am i missing something?
540 2012-02-23 18:54:41 <quilla> lol ive registered gmaxwell on some notorious child porn sites with his real name and info and a prepaid card. using his laurel tree ln address in herndon, va. when the registrations are dumped, theyll be looking for him like pete townsend. lmao hahah
541 2012-02-23 18:54:46 <quilla> lo-to-the-ol
542 2012-02-23 18:54:47 <quilla> haha
543 2012-02-23 18:54:49 <quilla> l8r
544 2012-02-23 19:07:40 <jrmithdobbs> err whoa
545 2012-02-23 19:07:42 <jrmithdobbs> http://t.co/58XT7xbS
546 2012-02-23 19:08:01 <jrmithdobbs> HMAC proof flawed =/
547 2012-02-23 19:10:53 <armariables> are bitcoin releases signed?
548 2012-02-23 19:11:00 <luke-jr> usually
549 2012-02-23 19:11:16 <luke-jr> we use an experimental program called gitian to do release builds
550 2012-02-23 19:11:25 <armariables> I'm having trouble finding a .sig for 0.5.2 win32 .exe
551 2012-02-23 19:11:29 <luke-jr> it allows multiple independent parties to build the code themselves and get the same output
552 2012-02-23 19:11:50 <luke-jr> http://luke.dashjr.org/programs/bitcoin/files/bitcoin-0.5.2/SHA256SUMS.asc
553 2012-02-23 19:11:51 <armariables> hmmm..
554 2012-02-23 19:12:25 <luke-jr> https://github.com/bitcoin/gitian.sigs/tree/master/0.5.2-win32 too for .sig I guess
555 2012-02-23 19:17:17 <armariables> luke-jr: you are outside of my web of trust, 0x665fc11dd53e9583 is you, I assume?
556 2012-02-23 19:17:27 <goxxed> wow
557 2012-02-23 19:18:22 <luke-jr> armariables: yes
558 2012-02-23 19:18:43 <luke-jr> armariables: note that IRC is not a secure medium for verifying identity
559 2012-02-23 19:19:07 <armariables> luke-jr: understood, but it adds to the barriers needed for forge a release
560 2012-02-23 19:19:18 <armariables> to forge
561 2012-02-23 19:20:13 <goxxed> people are getting g0oxxed]
562 2012-02-23 19:20:31 <armariables> luke-jr: not adding any any trust to your key, just importing it
563 2012-02-23 19:26:53 <armariables> woot! my download looks legit
564 2012-02-23 19:27:00 <armariables> luke-jr: thanks for everything you do
565 2012-02-23 19:30:16 <gribble> New news from bitcoinrss: gavinandresen opened issue 889 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/889>
566 2012-02-23 19:30:35 <goxxed> thx gavinandresen
567 2012-02-23 19:40:26 <gribble> New news from bitcoinrss: gavinandresen opened pull request 890 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/890>
568 2012-02-23 19:51:49 <coingenuity> ;;more copumpkin
569 2012-02-23 19:51:49 <gribble> itemprop="image" content="/images/google_favicon_128.png"><title>Google</title><script>window.google={kEI:"taZGT_2yMIvbiQLliMn_CA",getEI:function(a){var d;while(a&&!(a.getAttribute&&(d=a.getAttribute("eid"))))a=a.parentNode;return d||google.kEI},https:function(){return (11 more messages)
570 2012-02-23 19:51:57 <copumpkin> oh
571 2012-02-23 19:52:00 <copumpkin> I see
572 2012-02-23 19:52:12 <coingenuity> apologies to observers, that was a demonstration :(
573 2012-02-23 20:21:23 <libcoin> Considering buying some plane tickets - anyone who knows if BitCon 2012 will be, and if so if it will be in San Antonio or Calif ?
574 2012-02-23 20:21:37 <Tuxavant_> i vote for las vegas
575 2012-02-23 20:24:03 <libcoin> well, I guess you mean you bet it will be in Las Vegas...
576 2012-02-23 20:31:05 <luke-jr> I vote for Tampa.
577 2012-02-23 20:31:16 <luke-jr> lots of Bitcoiners near Tampa <.<
578 2012-02-23 20:32:46 <copumpkin> luke-jr: will you shoot me if I show up? :(
579 2012-02-23 20:32:55 <copumpkin> cause I'd prefer not to get shot
580 2012-02-23 20:32:56 <luke-jr> copumpkin: if you attack me
581 2012-02-23 20:33:02 <copumpkin> wasn't planning on it
582 2012-02-23 20:33:05 <luke-jr> good
583 2012-02-23 20:33:09 <luke-jr> I'd hate to have to shoot someone
584 2012-02-23 20:33:19 <copumpkin> sounds like we have a deal then
585 2012-02-23 20:33:28 <sipa> Can I join that deal?
586 2012-02-23 20:33:38 <luke-jr> I'd just hate it more, to have to shoot someone and not be able to ;)
587 2012-02-23 20:33:43 <luke-jr> sipa: :D
588 2012-02-23 20:33:46 <libcoin> It is announced as in San Antonio in March 17-18, but info from the conference people is not that clear
589 2012-02-23 20:35:27 <luke-jr> that soon? :/
590 2012-02-23 20:38:54 <sipa> A bit too pricy for me to get there, I'm afraid.
591 2012-02-23 20:46:27 <jgarzik> sipa: so, hosts at the top of seeds.txt have best uptime?
592 2012-02-23 21:00:40 <sipa> jgarzik: yes
593 2012-02-23 21:07:34 <jrmithdobbs> sipa: you sure it's sorting right?
594 2012-02-23 21:07:43 <sipa> yes
595 2012-02-23 21:07:45 <jrmithdobbs> 204.62.14.161:8333      100.00% 99.73%  99.50%  99.67%  99.66%  50100 ""
596 2012-02-23 21:07:57 <sipa> it's sorted on the value of the fifth number
597 2012-02-23 21:08:10 <jrmithdobbs> so it is
598 2012-02-23 21:08:38 <jrmithdobbs> i'm surprised my node is in the first 100
599 2012-02-23 21:27:36 <andrew_wmf> the san antonio conference does not inspire confidence
600 2012-02-23 21:33:56 <libcoin> andrew_wmf: agree - I think I'll skip it :/
601 2012-02-23 21:34:32 <andrew_wmf> yeah, don't get me wrong i'd be willing to fly there if something happened but
602 2012-02-23 21:34:59 <andrew_wmf> it doesnt look like it is going to happen unless at starbucks
603 2012-02-23 21:35:04 <libcoin> same here, but it is in 3 week and there is no program, and radio silence from the organizers
604 2012-02-23 21:36:06 <libcoin> and latest at the forum there were a suggestion to move it to San Francisco the 3rd... again too short notice
605 2012-02-23 21:36:26 <andrew_wmf> ^ lol
606 2012-02-23 21:36:59 <andrew_wmf> sf meetups have had 10-20 people in previous months
607 2012-02-23 21:37:58 <libcoin> nice, but it still takes a little more to organize a workshop/conference
608 2012-02-23 21:42:48 <helo> announcement a month in advance would be nice to allow better air rates
609 2012-02-23 21:43:36 <libcoin> Yup
610 2012-02-23 22:05:44 <luke-jr> [Thursday, February 23, 2012] [5:51:26 PM] <ljrbot> Txn d0f4df70fa179395c076ead51b01b77cc7b5803a5190415c991c3c5dc419281f: 1JF5A4MG87HXs8tknMxvAWQkrWHYqkKS33 0.09745 BTC, 3NUy5bPEnQ9kom3mWYcQ1CVa1qYTSPW14N 0.00001 BTC
611 2012-02-23 22:05:53 <luke-jr> ^ P2SH now supported by #bitcoin-watch :D
612 2012-02-23 22:06:30 <luke-jr> (don't send to that address, I'll be destroying it soon)