1 2013-08-28 00:01:53 <gmaxwell> :P
  2 2013-08-28 00:15:07 <TheLordOfTime> ;;op
  3 2013-08-28 01:08:23 <hydromet> gavinandresen: I have clang 3.3 via macports installed just fine, and I attempted to use qmake the way you suggested (my paths are somewhat different) ... so I didn't get any errors but it did not appear to build, for example:
  4 2013-08-28 01:08:44 <hydromet> Project MESSAGE: Building with UPNP support
  5 2013-08-28 01:08:52 <hydromet> Removed plural forms as the target language has less forms.
  6 2013-08-28 01:08:59 <hydromet> If this sounds wrong, possibly the target language is not set or recognized.
  7 2013-08-28 01:09:07 <hydromet> the last two lines are merely:
  8 2013-08-28 01:09:13 <hydromet> Project WARNING: No .qmake.cache is present. This significantly slows down qmake with this makespec.
  9 2013-08-28 01:09:20 <hydromet> Project WARNING: Call 'cache()' in the top-level project file to rectify this problem.
 10 2013-08-28 01:09:45 <hydromet> maybe I need to start fresh and clone again from GitHub?
 11 2013-08-28 01:12:57 <hydromet> gavinandresen: oops, I forgot to tack on "&& make"
 12 2013-08-28 01:13:07 <hydromet> once  added && make, then I got this error at the end:
 13 2013-08-28 01:13:24 <hydromet> protoc --cpp_out=build --proto_path=src/qt --proto_path=src/qt src/qt/paymentrequest.proto
 14 2013-08-28 01:13:30 <hydromet> make: protoc: No such file or directory
 15 2013-08-28 01:13:37 <hydromet> make: *** [build/paymentrequest.pb.h] Error 1
 16 2013-08-28 01:13:38 <hydromet> sigh
 17 2013-08-28 01:19:13 <CodeShark> you need the protocol buffer compiler?
 18 2013-08-28 01:19:14 <CodeShark> https://code.google.com/p/protobuf/downloads/list
 19 2013-08-28 01:20:03 <CodeShark> there's a macports package
 20 2013-08-28 01:20:16 <CodeShark> protobuf-cpp or something like that
 21 2013-08-28 01:22:27 <hydromet> CodeShark: thanks - the weird thing is that an earlier version of bitcoin didn't seem to need this (I had previously easily built Bitcoin-Qt using Qt Creator per the ReadMe docs)
 22 2013-08-28 01:22:32 <hydromet> so something has changed?
 23 2013-08-28 01:25:35 <hydromet> CodeShark: indeed there is a MacPorts port named "protobuf-cpp"
 24 2013-08-28 01:25:37 <hydromet> https://trac.macports.org/browser/trunk/dports/devel/protobuf-cpp/Portfile
 25 2013-08-28 01:25:46 <bizoro> hydromet: they now use protobuf... so you can export your wallet to another client if you want
 26 2013-08-28 01:25:46 <hydromet> I wonder if Gavin has this installed on his Mac
 27 2013-08-28 01:26:03 <CodeShark> which branch are you trying to build?
 28 2013-08-28 01:26:17 <hydromet> bizoro: that's great to know! This makes sense then.
 29 2013-08-28 01:26:30 <hydromet> CodeShark: master
 30 2013-08-28 01:26:35 <bizoro> hydromet: I mean... I don't know, probably x.x
 31 2013-08-28 01:27:20 <hydromet> bizoro: well, probabilistically this is a change that may have been made since I last built bitcoin qt over 1 month ago
 32 2013-08-28 01:27:28 <hydromet> a lot can probably change in 1 month
 33 2013-08-28 01:27:34 <hydromet> with a fast moving project like bitcoin
 34 2013-08-28 01:28:06 <CodeShark> it's for the payment protocol, not for wallet exports
 35 2013-08-28 01:40:12 <CodeShark> hydromet: specifically, https://en.bitcoin.it/wiki/BIP_0070
 36 2013-08-28 01:41:41 <hydromet> CodeShark: excellent, thank!
 37 2013-08-28 01:42:01 <Diablo-D3> [11:25:36] <hydromet> CodeShark: indeed there is a MacPorts port named "protobuf-cpp"
 38 2013-08-28 01:42:08 <Diablo-D3> people dont use macports anymore though
 39 2013-08-28 01:42:16 <Diablo-D3> so Im not sure why you care
 40 2013-08-28 01:42:35 <CodeShark> Diablo-D3: hydromet was specifically talking about using macports earlier
 41 2013-08-28 01:42:36 <hydromet> Diablo-D3: I humbly disagree ... gavinandresen: uses MacPorts
 42 2013-08-28 01:42:51 <Diablo-D3> gavin needs to switch to homebrew like everyone else then
 43 2013-08-28 01:42:57 <Diablo-D3> macports and that other one are basically dead now
 44 2013-08-28 01:42:58 <rethaw> can you troll a snark?
 45 2013-08-28 01:43:04 <CodeShark> lol
 46 2013-08-28 01:43:10 <CodeShark> anyhow, enough bikeshedding
 47 2013-08-28 01:43:11 <hydromet> Diablo-D3: I have looked at homebrew
 48 2013-08-28 01:43:13 <rethaw> ya fink
 49 2013-08-28 01:43:18 <rethaw> it's homebrew or bust...
 50 2013-08-28 01:43:40 <Diablo-D3> homebrew is the only reason I didnt install linux on my new mac
 51 2013-08-28 01:43:40 <hydromet> fink is ancient as well
 52 2013-08-28 01:43:56 <Diablo-D3> last time I tried osx full time, osx was a slow pile of shit that needed to die
 53 2013-08-28 01:44:01 <Diablo-D3> and macports and fink didnt help it any
 54 2013-08-28 01:44:06 <rethaw> osx is a great host for linux vm
 55 2013-08-28 01:44:09 <Diablo-D3> seriously, all the software I wnated to use wernt in either
 56 2013-08-28 01:44:12 <hydromet> Diablo-D3: glad homebrew worked out for you
 57 2013-08-28 01:44:31 <Diablo-D3> rethaw: I wanted osx to test software on
 58 2013-08-28 01:44:38 <Diablo-D3> but now Im not targeting languages that need that anymore
 59 2013-08-28 01:44:41 <Diablo-D3> so w/e
 60 2013-08-28 01:44:52 <rethaw> by the way, thanks Diablo-D3 I found a block on an imac using your miner
 61 2013-08-28 01:45:10 <CodeShark> anyhow, I don't particularly care which package manager you use or if you use a package manager - build protoc from source for all I care. point is protoc is necessary because of BIP0070
 62 2013-08-28 01:45:10 <Diablo-D3> if I switch, Im going to wait until one of the wayland desktop environments get hidpi mode
 63 2013-08-28 01:45:23 <Diablo-D3> CodeShark: /me shrugs
 64 2013-08-28 01:45:23 <hydromet> but we should be careful - there are plenty of "mere mortals" who run Windows and OS X - if you want more adoption of Bitcoin, you can't thumb noses at them
 65 2013-08-28 01:45:34 <Diablo-D3> yes I can thumb my noses at them
 66 2013-08-28 01:45:36 <Diablo-D3> I do it all the time
 67 2013-08-28 01:46:13 <hydromet> Diablo-D3: well then the "mere mortals" will thumb their noses back and not use Bitcoin and it will remain a niche that never gets enough uptake
 68 2013-08-28 01:46:26 <Diablo-D3> yes, and then they will never be as awesome as I am
 69 2013-08-28 01:46:33 <hydromet> ok whatever
 70 2013-08-28 01:49:02 <rethaw> bitcoind and bitcoin-qt are more about perfecting the protocol and less about adoption
 71 2013-08-28 01:49:28 <CodeShark> more like proof-of-concept than perfecting :p
 72 2013-08-28 01:49:37 <rethaw> although a lot of hard work has gone into the qt client
 73 2013-08-28 01:50:00 <rethaw> adoption is about electrum, blockchain.info, mobile apps, payment processors
 74 2013-08-28 01:50:28 <gavinandresen> yes, mere mortals might use OSX and Windows, but the Unwashed Masses all use cell phones and tablets.
 75 2013-08-28 01:51:14 <rethaw> if that
 76 2013-08-28 02:07:45 <hydromet> gavinandresen: its safe to assume you have protocol buffers (dare I ask, as a macport) installed on your Mac as part of your dev environment?
 77 2013-08-28 02:08:52 <CodeShark> hydromet: given that BIP0070 uses protobuf and is gavin's baby, I think it's more than a safe assumption :p
 78 2013-08-28 02:09:18 <hydromet> CodeShark: ah!
 79 2013-08-28 02:09:53 <gavinandresen> hydromet: yes, see doc/readme-qt.md  I use the protobuf-cpp macports port
 80 2013-08-28 02:29:48 <hydromet> CodeShark: and gavinandresen: a huge thank you for pointing out the protocol buffers dependency ... I diffed the doc/readme-qt.md from my current clone of master v.s. from over a month ago (18 July 2013) and protobuf-cpp is definitely a new addition
 81 2013-08-28 02:30:23 <gavinandresen> yes, I pulled it just a few days ago.
 82 2013-08-28 02:30:37 <hydromet> which make sense since BIP0070 draft published was end of July 2013
 83 2013-08-28 02:31:06 <hydromet> these are exciting times learning about bitcoin!
 84 2013-08-28 03:04:36 <andkore> man, #bitcoin-tech really needs to get more active
 85 2013-08-28 03:05:03 <andkore> I'd love to have a place to talk about bitcoin development. that is, not development OF bitcoin, but development involving/using bitcoin
 86 2013-08-28 05:03:32 <toffoo> so far so good with 0.8.4rc2 on my troublesome MacBookPro  ??? more tomorrow, goodnight!
 87 2013-08-28 05:04:20 <hydromet> toffoo: sorry I was away for a while, I didn't realize you are having problems with your MacBook Pro (I have one too, maybe I can help you)
 88 2013-08-28 05:05:18 <toffoo> hydromet what version of bitcoin-qt are you running on yours?
 89 2013-08-28 05:09:19 <hydromet> toffoo: Bitcoin version v0.8.2-313-gbb7d0fc-beta
 90 2013-08-28 05:18:57 <sipa> wow, we have 313 changes since 0.8.2 already
 91 2013-08-28 05:45:56 <Krellan> sipa: thanks for your comments on my ping patch.  I further refined it, getting rid of debug/printf bloat.  https://github.com/bitcoin/bitcoin/pull/2937
 92 2013-08-28 05:47:05 <sipa> you use Yoda conditions!
 93 2013-08-28 05:47:08 <hydromet> sipa: CodeShark: gavinandresen: thank you collectively for your help! I have successfully made and am now running Bitcoin-Qt on my MacBook
 94 2013-08-28 05:48:08 <hydromet> protocol buffers cpp was very key to this, as was the workaround Gavin suggested with regard to using the command line with qmake and make (instead of using Qt Creator)
 95 2013-08-28 05:48:29 <CodeShark> glad to know it's working for you, hydromet
 96 2013-08-28 05:56:05 <Krellan> yes, 0 == n, avoids chance of typo nasty bug 0 = n
 97 2013-08-28 05:57:25 <sipa> yes, i had heard about that style and the reasoning for it, but never saw anyone actually use iy
 98 2013-08-28 05:57:56 <gmaxwell> = vs == bugs is something I've basically never run into.
 99 2013-08-28 05:58:17 <gmaxwell> it helps that modern compilers warn on a number of places where this might happen.
100 2013-08-28 05:58:52 <CodeShark> I think C/C++ developers tend to be particularly aware of this type of issue and are generally pretty vigilant about it
101 2013-08-28 05:59:08 <gmaxwell> Makes sense.
102 2013-08-28 05:59:51 <CodeShark> it's somewhat unfortunate that a bunch of other programming languages had to inherit this
103 2013-08-28 06:01:08 <CodeShark> on the other hand, languages like pascal tried really hard to make it nearly impossible to make this mistake - and it didn't catch on as much
104 2013-08-28 06:03:52 <CodeShark> for better or worse, C syntax still reigns supreme amongst imperative languages
105 2013-08-28 06:08:19 <sipa> Krellan: what is nPingNonceQueued for?
106 2013-08-28 06:08:26 <sipa> it seems unused
107 2013-08-28 06:09:22 <sipa> ah, it's sort of a cached nonce
108 2013-08-28 06:11:37 <sipa> Krellan: would it make sense to report max(lastpingtime, now-lastpingsent) in the getpeerinfo rpc?
109 2013-08-28 06:12:39 <sipa> so max(dPingTime,dPingWait)
110 2013-08-28 06:14:09 <sipa> what widely-deployed alt implementation is that, which doesn't reply with the right nonce?
111 2013-08-28 06:19:31 <Krellan> sipa: I'm trying to figure that out myself.
112 2013-08-28 06:19:53 <Krellan> was hoping someone else would know.
113 2013-08-28 06:20:16 <Krellan> As for syntax, I wish they would use := for assignment and == for comparison, that seems to be the best.
114 2013-08-28 06:21:12 <Krellan> sipa: nPingNonceQueued is the nonce that will be sent out next.  It's precomputed so that I only need to take 8 random bytes no matter how many nodes there are.
115 2013-08-28 06:21:22 <Krellan> Avoid draining the random entropy that way.
116 2013-08-28 06:21:45 <sipa> you could just use the non-crypto RNG
117 2013-08-28 06:21:48 <Krellan> sipa: Funny you mention that, I actually had it coded up just like that, in a draft.
118 2013-08-28 06:23:15 <Krellan> reporting max(pingtime,pingwait) = caller can't tell if there is still a ping outstanding or not.
119 2013-08-28 06:24:31 <Krellan> plus, starting a new ping would suddenly make the ping times go down, if pingwait had become larger than pingtime.
120 2013-08-28 06:27:34 <CodeShark> going over this list of languages (http://en.wikipedia.org/wiki/List_of_programming_languages_by_category#Imperative_languages), it seems from that list only algol, pascal/object pascal, ada, and modula adopted the := assignment operator. BASIC, C, C++, COBOL, FORTRAN, Java, Lua, MATLAB, Perl, PHP, Python, Ruby, and Rust all use =
121 2013-08-28 06:28:29 <CodeShark> Mathematica uses both. := is delayed evaluation
122 2013-08-28 06:28:53 <CodeShark> anyhow, this isn't the comparative language channel :p
123 2013-08-28 06:29:58 <warren> CodeShark: hi, regarding ""RPC method for explicitly banning nodes or removing a ban.", will you have an opportunity to fix what sipa asked for?
124 2013-08-28 06:30:09 <warren> CodeShark: I can ask one of our devs to help if you're busy.
125 2013-08-28 06:30:18 <CodeShark> let me take a look
126 2013-08-28 06:31:19 <sipa> Krellan: i think over time it may be useful to do more pings, like every few minutes or even less
127 2013-08-28 06:31:27 <Krellan> agreed
128 2013-08-28 06:31:33 <sipa> Krellan: and then reporting an average ping time and a last ping time
129 2013-08-28 06:32:02 <sipa> the last ping time could take an ongoing one into account
130 2013-08-28 06:32:07 <sipa> while the average wouldn't
131 2013-08-28 06:32:28 <sipa> so i wonder if we can do something for now to remain rpc-conpatible with that
132 2013-08-28 06:32:38 <Krellan> an interesting idea
133 2013-08-28 06:32:55 <sipa> (i'm not suggesting you do all that now)
134 2013-08-28 06:33:40 <Krellan> with "pingwait" i'm already dangerously close to overengineering it as it is.
135 2013-08-28 06:33:44 <sipa> hehe
136 2013-08-28 06:34:08 <sipa> no worries, i'm not afraid of overengineering
137 2013-08-28 06:34:15 <sipa> (ever saw addrman.h?)
138 2013-08-28 06:34:20 <Krellan> interesting how we both had thought of the max(pingtime,pingwait) idea, i had that running for a while, it gave me confusing results.
139 2013-08-28 06:35:11 <Krellan> peeked at addrman.h, makes sense to me
140 2013-08-28 06:36:06 <Krellan> I thought about keeping all outstanding nonces in a map and then looking them up whenever a pong came in.  That would solve the problem of overlapping nonces more cleanly.
141 2013-08-28 06:36:18 <sipa> meh :)
142 2013-08-28 06:36:48 <Krellan> and i'm still intrigued about why a client woudl send a pong of zero.  maybe it's only sending a 32-bit number (there was a similar bug in ping a while ago)?
143 2013-08-28 06:37:11 <sipa> yes, but that was discovered shortly after merging
144 2013-08-28 06:37:25 <sipa> i don't think there was actually a release with that problem
145 2013-08-28 06:38:19 <sipa> you can print pbode->strSubVer or what it's called
146 2013-08-28 06:38:33 <sipa> should tell you what codebase is sending it
147 2013-08-28 06:41:06 <Krellan> I just added that, actually
148 2013-08-28 06:41:24 <Krellan> printf("This jerk just sent me a pong nonce of zero: %s\\n", pfrom->strSubVer.c_str());
149 2013-08-28 06:41:50 <Krellan> :)
150 2013-08-28 06:42:25 <gmaxwell> I'd like to solicit some shed-painting of this approach: http://people.xiph.org/~greg/encourage_sweeping.patch
151 2013-08-28 06:43:02 <gmaxwell> (one issue with the patch as it is now is that it lowers both the wallet behavior and the relay behavior at the same time, so it might result in some stuck txn if not deployed with rapid uptake... but that could be fixed)
152 2013-08-28 06:43:12 <Krellan> To my surprise it's Satoshi:0.8.99 and it's fairly common.  7 of my 18 nodes (I just restarted bitcoind) do it.
153 2013-08-28 06:44:25 <warren> ok great, I have my team helping to review jgarzik's nowallet patch
154 2013-08-28 06:44:35 <gmaxwell> sipa: So I changed my thinking from an earlier idea for encouraging sweeping to one that strictly makes the additional (cheap) inputs free. The reason for this is that I think if there is any more incentive than that it will encourage people to make _extra_ txouts in order to gobble up their credit later.
155 2013-08-28 06:45:21 <Krellan> You misspelled "disincentivizing" ):
156 2013-08-28 06:45:46 <gmaxwell> e.g. under my prior patch if you had??? say 10 inputs such that your 'size' would have been negative, it would be in your interest to add extra outputs 'for free' to balance that out which you could redeem later.
157 2013-08-28 06:46:50 <sipa> Krellan: wut? :o
158 2013-08-28 06:46:51 <gmaxwell> and the reason for the maximum of 109 bytes of credit for the signature here is so that it doesn't make weird data-storage transactions cheaper.
159 2013-08-28 06:48:34 <sipa> Krellan: so some patch in git head broke ping responses?
160 2013-08-28 06:49:10 <gmaxwell> Krellan: what?! ... or there is some busted node type claiming to be 0.8.99. :(
161 2013-08-28 06:50:04 <Krellan> It's a 64-bit number (8 bytes).
162 2013-08-28 06:50:14 <sipa> yes
163 2013-08-28 06:50:31 <sipa> but your 0.8.99 peers answer with 0?
164 2013-08-28 06:50:49 <Krellan> all 00's.  Wireshark helpful.
165 2013-08-28 06:51:21 <Krellan> although "pong" is unknown command, it still picks apart the command packet.  Payload checksum 7ef0ca62 is correct.
166 2013-08-28 06:52:20 <gmaxwell> I don't see how.. if your peers ping you do you also respond stupidly?
167 2013-08-28 06:52:54 <Krellan> nope, ping nonce gets echoed in pong nonce (that is unchanged).
168 2013-08-28 06:53:04 <sipa> weird weird
169 2013-08-28 06:53:07 <Krellan> very.
170 2013-08-28 06:53:13 <Krellan> it's not just one node, it's widespread.
171 2013-08-28 06:53:29 <gmaxwell> sounds like an attack, to be honest.
172 2013-08-28 06:53:45 <gmaxwell> not the pings themselves, but someone running software which isn't 0.8.99 claiming to be 0.8.99
173 2013-08-28 06:53:53 <sipa> we need to figure that out before adding code that depends on thay broken behaviour...
174 2013-08-28 06:54:09 <Krellan> yes, that scuttles my attempt to use version to distinguish who's sending the zero pong nonces.
175 2013-08-28 06:54:53 <sipa> i'll add code to my node to track that as well
176 2013-08-28 06:55:11 <Krellan> I was running code earlier that just dropped the pong if nonce was zero.  Got discouraged by a good chunk of my peers having unmeasurable ping times then.
177 2013-08-28 06:55:23 <Krellan> sipa: thanks.
178 2013-08-28 06:56:01 <sipa> discouraged as in human lack of motivation... not block discouragement i hope
179 2013-08-28 06:56:18 <Krellan> :)
180 2013-08-28 06:56:55 <sipa> i take that as a yes
181 2013-08-28 06:57:32 <Krellan> I still wonder where the broken behavior (pong nonce all 00's) comes from.  whatever it is, it's widely deployed.  I looked through history briefly and could only find a few changes to ping over time and none to pong.
182 2013-08-28 07:02:04 <CodeShark> do you have any specific IP addresses of hosts exhibiting this behavior?
183 2013-08-28 07:02:16 <Krellan> sipa: Curious to know what you find, if you also see it happening in your client: send good ping out, get ping nonce zero back.
184 2013-08-28 07:02:29 <Krellan> hmm let me pull some addresses
185 2013-08-28 07:04:54 <CodeShark> hmm, the protocol specification document https://en.bitcoin.it/wiki/Protocol_specification#ping mentions a nonce in the ping message but doesn't talk about the ping message format other than suggesting there's a nonce field somewhere
186 2013-08-28 07:05:50 <gmaxwell> CodeShark: what crazy idea made you think that page was useful?
187 2013-08-28 07:06:03 <CodeShark> gmaxwell: it was THE page I used to implement a bitcoin node
188 2013-08-28 07:06:12 <CodeShark> it was the MOST useful page EVER that I found on bitcoin
189 2013-08-28 07:06:13 <CodeShark> EVER
190 2013-08-28 07:06:14 <gmaxwell> It's been full of lies historically. Your punishment for reading it is to fix them as you find them.
191 2013-08-28 07:06:55 <gmaxwell> oh sorry, its the rules page thats full of lies.
192 2013-08-28 07:07:21 <gmaxwell> that one might be okay as far as I know.
193 2013-08-28 07:07:47 <CodeShark> it's had a few minor warts here and there but has been by far the best reference on the bitcoin protocol I've found
194 2013-08-28 07:09:18 <CodeShark> whenever any developer asks me where to look for information about bitcoin I point them to this and satoshi's paper first
195 2013-08-28 07:10:40 <gmaxwell> CodeShark: I was confusing it with the rules page, which is basically stuffed full of omitted rules.
196 2013-08-28 07:10:50 <CodeShark> anyhow, what's the message format for a ping message? a header + a 64 bit nonce?
197 2013-08-28 07:11:04 <CodeShark> I'll add it to the document
198 2013-08-28 07:11:20 <Krellan> CodeShark: 91.121.58.230:60406 5.9.203.20:44514 5.9.30.207:52886 144.76.70.73:19492 46.4.64.21:21221 5.9.245.121:18615 = nodes that do that
199 2013-08-28 07:11:26 <Krellan> cool
200 2013-08-28 07:11:27 <CodeShark> Krellan: thanks
201 2013-08-28 07:11:37 <Krellan> ping has 8-byte payload (nonce)
202 2013-08-28 07:11:39 <gmaxwell> Krellan: interesting, they are all nodes connecting to you?
203 2013-08-28 07:11:43 <Krellan> pong has 8-byte payload (nonce)
204 2013-08-28 07:11:45 <Krellan> Yes.
205 2013-08-28 07:12:05 <Krellan> and I already throw out unsolicited pongs so it's not that.
206 2013-08-28 07:12:23 <Krellan> ping *had* buggy 4-byte payload of all zeroes once.
207 2013-08-28 07:12:37 <gmaxwell> I notice that three are in the same russian data center.
208 2013-08-28 07:12:52 <Krellan> Da.
209 2013-08-28 07:13:26 <gmaxwell> and all of them but the first one are the same hosting company.
210 2013-08-28 07:13:36 <Krellan> who maintains the Wireshark dissector for bitcoin? be good to fix that as well same time, to decode pong.
211 2013-08-28 07:14:07 <gmaxwell> Krellan: sounds like you do.
212 2013-08-28 07:15:21 <phantomcircuit> lol
213 2013-08-28 07:17:12 <CodeShark> ok, document updated
214 2013-08-28 07:23:54 <CodeShark> gmaxwell: agreed on the rules page - the validation pseudo-flowcharts in particular
215 2013-08-28 07:25:45 <Krellan> hehe
216 2013-08-28 07:25:53 <Krellan> will be another fun project
217 2013-08-28 07:26:06 <Krellan> figure out the guts of wireshark
218 2013-08-28 07:29:04 <CodeShark> gmaxwell: I think the rules document should be less bitcoind-centric (i.e. "Add to wallet if mine") and instead focus on what constitutes a valid block and what constitutes a valid transaction from a purely network rules perspective (ignoring implementation specific rules or optimizations)
219 2013-08-28 07:29:58 <CodeShark> a separate document could mention implementation-specific rules or optimizations
220 2013-08-28 07:30:40 <Krellan> Nite all, I'll let bitcoind run more overnight and see if it finds any other versions that send back pong nonce of all 00's.
221 2013-08-28 07:30:42 <CodeShark> concepts like transaction pools and wallets are entirely separate from the p2p protocol rules themselves
222 2013-08-28 07:31:06 <CodeShark> nite, Krellan
223 2013-08-28 07:31:42 <gmaxwell> CodeShark: I think the rules document is actually not a documentation of bitcoind' but actually of genjix's node code, and thats partially why its been wrong historically.
224 2013-08-28 07:32:29 <Krellan> nite nite, i'll dream of finding a block
225 2013-08-28 07:34:40 <gmaxwell> Find one for me too!
226 2013-08-28 07:35:30 <CodeShark> gmaxwell: hmm, more the reason to draw this distinction :)
227 2013-08-28 07:36:20 <CodeShark> rather than an algorithmic pseudocode definition, perhaps it would be better to present a more mathematical definition
228 2013-08-28 07:37:20 <CodeShark> and instead just use algorithmic pseudocode as a possible example, but not as the official "spec"
229 2013-08-28 07:37:43 <gmaxwell> CodeShark: I had an idea before to go through the code and instrument every protocol rule with macros that in the normal case complied exactly to the current code, but could also be used to assign IDs and enumerate all the rules and their conditional relationships.
230 2013-08-28 07:38:12 <gmaxwell> You could then clean up that output and get a spec, and also be able to easily relate the spec to the code.
231 2013-08-28 07:38:44 <gmaxwell> You could then spot check alternative implementations by simply grepping for all the IDs, assuming they noted in the code where each rule was implemented.
232 2013-08-28 07:39:00 <gmaxwell> And you could test your tests by some instrumention to break indivigual rules.
233 2013-08-28 07:39:13 <gmaxwell> e.g. a GTLT becomes at GT... do your tests fail?
234 2013-08-28 07:39:30 <gmaxwell> but it's a lot of work and it would add a lot of noise to the codebase.
235 2013-08-28 07:40:42 <gmaxwell> and might just be better done as part of an effort to extract all the rules into a standalone.c file sutiable for implementation in a cryptographic proof system.
236 2013-08-28 07:41:31 <CodeShark> yeah, it sounds a bit complicated - also, there should be different categories for the rules. for instance, proof-of-work block header validation belongs in a more fundamental category than, say, "nonstandard transactions" or fees
237 2013-08-28 07:41:47 <gmaxwell> oh " "nonstandard transactions" or fees" are not protocol rules.
238 2013-08-28 07:41:53 <gmaxwell> They're just implementation behaviors.
239 2013-08-28 07:41:57 <CodeShark> right
240 2013-08-28 07:42:06 <gmaxwell> By protocol rules I mean the stuff that all full nodes must implement the same or doomsday happens. :P
241 2013-08-28 07:42:32 <CodeShark> well, block header proof-of-work validation also belongs in a more fundamental category than, say, MAX_BLOCK_SIZE
242 2013-08-28 07:42:39 <gmaxwell> No it doesn't.
243 2013-08-28 07:42:47 <CodeShark> the latter is subject to change
244 2013-08-28 07:42:59 <gmaxwell> It's a hardforking rule that all nodes must agree on exactly.
245 2013-08-28 07:43:14 <CodeShark> but it's still subject to change
246 2013-08-28 07:43:25 <CodeShark> much moreso than pow validation rules
247 2013-08-28 07:44:03 <gmaxwell> I don't think it is. I mean, sure, anything is subject to change if there is a necessity to do so. The hardforking rules are only mostly a suicide pact.
248 2013-08-28 07:44:23 <gmaxwell> But changing them has exactly the same technical consequences and needs the same deployment strategy.
249 2013-08-28 07:45:33 <CodeShark> also, headers-only and headers-first implementations might not even check MAX_BLOCK_SIZE upon initial sync
250 2013-08-28 07:46:10 <gmaxwell> sure, they also don't check that scriptpubkeys are under 10kbytes...
251 2013-08-28 07:46:46 <gmaxwell> or ecdsa signatures on transactions, or maximum checksig operations, or the that the coinbase isn't inflating the currency supply or...
252 2013-08-28 07:46:51 <CodeShark> they could check that selectively for transactions they care about - point is, rules for accepting transactions might be different from rules for full validation and relay
253 2013-08-28 07:47:16 <CodeShark> and pow validation seems like the minimal check that any node should be making
254 2013-08-28 07:47:45 <gmaxwell> CodeShark: sure, the rules have multiple entry points: the things you can validate with just a header, the things you can validate with just a utxo set and a mempool, and then the block validation which is the sum of these and some extra stuff.
255 2013-08-28 07:47:59 <CodeShark> exactly
256 2013-08-28 07:48:23 <gmaxwell> (actually two kinds of header checks, stateless ones and stateful ones)
257 2013-08-28 07:48:41 <CodeShark> I'm not saying that these other things aren't also important - perhaps I shouldn't have used the term "fundamental"
258 2013-08-28 07:49:24 <CodeShark> from a practical standpoint, I think what you just said is the key - different rules require different contexts for validation and not all nodes necessarily will be performing all the checks all the time
259 2013-08-28 07:51:03 <gmaxwell> Mostly I only give a shit about full nodes. If your SPV node or whatever implements a test wrong ... I cry for it??? but it won't bugger the global consensus.  Obviously it's prudent to set things up to be easily reuable, and even a full node wants to do some tests early for anti-dos reasons... but I think the concerns of non-network nodes are an order of magnitude less.
260 2013-08-28 07:51:39 <CodeShark> gmaxwell: even for a full node there are some interesting possibilities - like headers-first sync and gradual transitioning to full node
261 2013-08-28 07:53:31 <CodeShark> then there are also ideas like what you brought up yesterday as far as relaying prior to full validation to reduce latency (or other such potential optimizations)
262 2013-08-28 07:54:36 <gmaxwell> CodeShark: luke implemented it last year, it didn't help at the time, because of the blocking nature of bitcoin's networking. perhaps in the future.
263 2013-08-28 07:55:24 <CodeShark> gmaxwell: I was just using it as an example - there could be other possibilities where not applying all the rules up front makes the most sense even for a full node
264 2013-08-28 07:55:35 <gmaxwell> CodeShark: in any case, those entry points are simple enough.  I'm actually becoming hopefully that we can eliminate the need to ever have the gradual transition model.
265 2013-08-28 07:56:11 <CodeShark> sure, we just need a way to hash the utxo state into block headers :)
266 2013-08-28 07:56:16 <gmaxwell> no.
267 2013-08-28 07:56:20 <gmaxwell> gah wtf.
268 2013-08-28 07:56:33 <gmaxwell> That would be a severe reduction in the security model to just trust that.
269 2013-08-28 07:56:57 <gmaxwell> using SCIP to recieve proof-of-validation of a utxo, however, wouldn't be.
270 2013-08-28 07:57:27 <CodeShark> ok, then that :)
271 2013-08-28 07:57:33 <gmaxwell> :P
272 2013-08-28 07:59:17 <gmaxwell> in any case, doing that would imply some structural changes where you reorganize the code so that you have a validation part (well really, three of them), and a part that prepares inputs for them and gives them their input and they do no IO and return a pass/fail.
273 2013-08-28 07:59:31 <CodeShark> in practice, we really only need a few full validation nodes that are well-connected that will raise a stink if anyone starts accepting blocks/txs that break the rules
274 2013-08-28 07:59:34 <gmaxwell> and the idea is that everything outside of them is 'untrusted' and they enforce all the rules.
275 2013-08-28 08:00:06 <CodeShark> a few full validation nodes that are well-connected and not in collusion with each other
276 2013-08-28 08:00:23 <phantomcircuit> CodeShark, that last part is lol impossibro
277 2013-08-28 08:00:43 <gmaxwell> CodeShark: I don't agree. Once the consensus has gone the wrong way it cannot be fixed without permitting the risk of double spends. Besides thats just really offensive to the security model in bitcoin.
278 2013-08-28 08:01:12 <phantomcircuit> CodeShark, you have offended the security model
279 2013-08-28 08:01:22 <CodeShark> once consensus has gone the wrong way the network has broken
280 2013-08-28 08:01:23 <gmaxwell> You cannot tell when parties are in collusion when they are anonymous and self selecting. And you cannot achieve satoshi's vision of correcting the problem with so much trust in money when you go making magical trusted nodes.
281 2013-08-28 08:01:25 <phantomcircuit> gmaxwell, puzzling choice of words but i like it
282 2013-08-28 08:02:06 <gmaxwell> CodeShark: and there were double spends, :( and next time people will be even more prepared to exploit a divergence.
283 2013-08-28 08:02:14 <CodeShark> anyone can still run a full node in principle - and most entities dealing in large quantities of money will most likely want to run a few of their own
284 2013-08-28 08:02:51 <CodeShark> but for most users it's simply not practical to expect them all to be running full validation nodes - at least not without some significant breakthroughs in cryptography, hardware, and protocol improvements
285 2013-08-28 08:02:51 <gmaxwell> moreover, actually applying the rules is not fundimentally expensive.
286 2013-08-28 08:03:25 <gmaxwell> CodeShark: I think you've mistaken bitcoin for visa my friend.
287 2013-08-28 08:03:45 <CodeShark> it's already too expensive to validate the entire block chain for MOST typical users
288 2013-08-28 08:03:59 <gmaxwell> Moreover, commercial operators would be the last parties you'd expect to be running full nodes. The protection they care about is not one that detecting errors other people do not detect can provide.
289 2013-08-28 08:04:17 <gmaxwell> CodeShark: What the heck are you talking about?
290 2013-08-28 08:04:27 <CodeShark> if an error goes undetected, the network has broken and all coins are at risk of becoming worthless
291 2013-08-28 08:04:40 <gmaxwell> CodeShark: yea, sounds like a great problem for someone else to solve.
292 2013-08-28 08:04:55 <CodeShark> point is anyone who has sufficient stake in the network'
293 2013-08-28 08:05:05 <CodeShark> has incentive to run a full validation node
294 2013-08-28 08:05:20 <gmaxwell> CodeShark: Yes, like all the users, who are the ones who actually care about preventing inflation??? businesses demonstrably do not.
295 2013-08-28 08:05:22 <CodeShark> most casual consumers do not
296 2013-08-28 08:05:42 <gmaxwell> CodeShark: but lets wind back a bit here, you made a claim that I think is nuts "< CodeShark> it's already too expensive to validate the entire block chain for MOST typical users"
297 2013-08-28 08:05:47 <gmaxwell> What are you talking about there?
298 2013-08-28 08:06:04 <CodeShark> initial sync time on handheld devices is too long for most people to sit through
299 2013-08-28 08:06:16 <CodeShark> and requires a significant amount of storage
300 2013-08-28 08:06:29 <CodeShark> hard disks are cheap but flash media is still relatively expensive
301 2013-08-28 08:06:33 <gmaxwell> It currently requires about 300 mbytes of storage to run a full validation node.
302 2013-08-28 08:06:50 <gmaxwell> And you can, if you want, move the sync into the background.
303 2013-08-28 08:07:10 <CodeShark> the only people currently doing that are technogeeks
304 2013-08-28 08:07:53 <gmaxwell> (and with a SCIP proof for a faithful utxo set, the sync could be eliminated entirely, but thats probably a couple years out)
305 2013-08-28 08:08:04 <CodeShark> and I expect that to remain the case for the time being barring any significant breakthroughs in cryptography and/or hardware
306 2013-08-28 08:08:38 <gmaxwell> CodeShark: Please stop. You are lowering my opinion of you substantially. You do not have to be right all the time, and arguing a moronic point just makes you look like a moron.
307 2013-08-28 08:08:54 <gmaxwell> It doesn't take a "breakthroughs in cryptography and/or hardware" to move a task into the background.
308 2013-08-28 08:09:12 <gmaxwell> It doesn't take a "breakthroughs in cryptography and/or hardware" to have the process simply not save old blocks to disk.
309 2013-08-28 08:09:30 <CodeShark> gmaxwell: from a purely theoretical/technical standpoint I agree with you - from a real-world deployment standpoint, there are some significant hurdles
310 2013-08-28 08:10:23 <gmaxwell> the existing node software works fine if you just type ~/.bitcoin/blocks/*000??.dat ... (until a peer tries to pull the old chain from you, since we don't yet have service bits to indicate that you don't have the blocks)
311 2013-08-28 08:11:18 <CodeShark> again you're talking about something which only a small percentage of the actual population even understands
312 2013-08-28 08:11:22 <gmaxwell> CodeShark: Your commentary was on "too expensive" not "unfashionable"  ... not that I'm advocating FVNs on phones (bandwidth is the concern), but it's not fundimentally expensive, and on a desktop its trivial.
313 2013-08-28 08:11:41 <CodeShark> I'm talking about practical real-world deployment and mass adoption
314 2013-08-28 08:11:48 <CodeShark> not just a hobby project of a few technogeeks
315 2013-08-28 08:11:55 <gmaxwell> CodeShark: what does that have to do with anything? I'm not expecting the actual population to ever know or care about it.
316 2013-08-28 08:12:35 <gmaxwell> CodeShark: don't say "too expensive" when you really mean "because someone hasn't yet written the 10 line patch to bitcoind to make it easier for storage limited devices"
317 2013-08-28 08:14:09 <gmaxwell> CodeShark: yes, and I'm talking about preserving something which is pratically worth having.  If you demove the users running verifiying nodes in favor of a few large trusted validators??? for want of people to write 10 line patches!???  then you invalidate Satoshi's whole purpose for bulding bitcoin:
318 2013-08-28 08:14:14 <gmaxwell> "
319 2013-08-28 08:14:17 <gmaxwell> The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let ...
320 2013-08-28 08:14:23 <gmaxwell> ... identity thieves drain our accounts."
321 2013-08-28 08:14:40 <gmaxwell> Because we're back to trusting some big 'banks' but they're just with another name, and hyper subject to regulation by whatever random misguided power wants to dork with them.
322 2013-08-28 08:15:10 <CodeShark> the big bank analogy only really holds if there's a huge barrier to entry for anyone who wants to perform full validation
323 2013-08-28 08:15:29 <CodeShark> and the barrier to entry is NOT huge - there can still be a significant number of people, organizations, and businesses running such nodes
324 2013-08-28 08:15:31 <gmaxwell> And if it were fundimentally necessary, if it couldn't be made to work for people at all, even with thousands of lines of code??? I might agree with you. But to risk the whole purpose of the system to grow deployment at the expense of writing a modest amount of code? I don't buy it.
325 2013-08-28 08:16:14 <gmaxwell> CodeShark: you yourself are arguing that it was already prohibitively costly.   There is no _profit_ you get from doing it, already our full nodes dwindle.  If it isn't a default expirence what makes you think people will do it?
326 2013-08-28 08:16:39 <CodeShark> it's mostly a matter of risk management for any sufficiently invested party
327 2013-08-28 08:16:43 <CodeShark> not profit
328 2013-08-28 08:16:51 <gmaxwell> I say they'll do it because it'll be made as cheap as possible, and made so you can contribute at multiple levels.
329 2013-08-28 08:17:04 <CodeShark> point is it isn't necessary for every last smartphone and tablet user to be running a full validation node in order for bitcoin to function
330 2013-08-28 08:17:07 <gmaxwell> But if few enough people do it it's _risky_ to do so (see for example coinbase keep forking themselves with their implementation)
331 2013-08-28 08:17:38 <gmaxwell> The thing a business wants is not bitcoin,  they want bitcoin-bank to give them cryptographically signed blocks and an insurance policy that no txn in a signed block will be reversed no matter what.
332 2013-08-28 08:18:16 <CodeShark> if a block chain is accepted that grossly breaks the rules, the entire network's credibility flies out the window
333 2013-08-28 08:18:21 <gmaxwell> CodeShark: and sure, I'm not proposing that smartphones and tablets do??? but they certantly could. And they also could do partial validation, and fraud proof generation and processing, and that probably makes a lot of sense.
334 2013-08-28 08:19:17 <gmaxwell> CodeShark: hah. No. I don't agree. Not once it's widely used. The USD's credibility didn't go out the window when the government removed metallic backing or made any of other countless economic changes that broke the prior rules.
335 2013-08-28 08:19:28 <CodeShark> it is certainly in my interest to run a full validation node (in fact, I run several) just because I want to know about any potential fundamental problems with the network - I don't run full validation nodes on all my devices and probably never will
336 2013-08-28 08:19:45 <gmaxwell> it would remove the _point_ of bitcoin??? making it just a really inefficient way to accomplish a fiat payment system??? but it wouldn't stop people from using it.
337 2013-08-28 08:20:34 <gmaxwell> and I've repeadily said that I'm not proposing that every device do it (partial validation and fraud proofs, perhaps is another matter)
338 2013-08-28 08:20:50 <CodeShark> so then where was it that we were disagreeing?
339 2013-08-28 08:21:02 <CodeShark> perhaps it was on the connotation of "few"
340 2013-08-28 08:21:18 <CodeShark> by "few" I didn't mean an oligopoly of full validators
341 2013-08-28 08:21:46 <CodeShark> I meant a significant number but still a minority of the total number of devices that interface the bitcoin network
342 2013-08-28 08:22:01 <gmaxwell> I don't follow how any model where there isn't a very large number doesn't rapidly reduce to an oligopoly of full validators. If it doesn't make sense for you to do it, why does it make sense for anyone else?
343 2013-08-28 08:22:11 <gmaxwell> okay. That could still agree with me.
344 2013-08-28 08:22:27 <CodeShark> it DOES make sense for me to run full nodes - I already said I run several
345 2013-08-28 08:22:50 <CodeShark> but none on handheld devices
346 2013-08-28 08:22:51 <gmaxwell> I think I believed you were saying that few or no individuals would, and that you also described it as very expensive, which it's not.
347 2013-08-28 08:23:30 <CodeShark> running a full node on a dedicated server is cheap - running it on a tablet is considerably more expensive
348 2013-08-28 08:23:46 <gmaxwell> and on a handheld device you can run a partial verifying node with ~no extra cost, once we make a few softforking protocol changes.  (A partial verifying node only checks a random subset of a block: but it can catch any rule violation that happens in that random subset)
349 2013-08-28 08:24:23 <gmaxwell> (and if you couple partial verifying nodes with fraud proofs there don't really need to be any full verifying nodes, really??? though it would make sense to still have some)
350 2013-08-28 08:24:44 <Scrat> gmaxwell: but it will only work while the app is opened
351 2013-08-28 08:24:54 <Scrat> due to battery constraints
352 2013-08-28 08:24:56 <gmaxwell> Scrat: sure. Fortunately there is more than one user.
353 2013-08-28 08:25:26 <gmaxwell> Scrat: for a handheld device you'd actually make use of the fact that the bloom filters select too much data, to perform your random selection for you.
354 2013-08-28 08:26:49 <gmaxwell> Scrat: the idea is that each device checks a small fraction of the block, ??? while its online??? and if  it finds something wrong it broadcasts a fraud proof that tells everyone else where to go look and find the badness.
355 2013-08-28 08:27:12 <CodeShark> note: running it on a dedicated server is only cheap for me because I already have other uses for dedicated servers
356 2013-08-28 08:27:32 <phantomcircuit> CodeShark, cookie crisps
357 2013-08-28 08:27:33 <CodeShark> so I already have the IT investments
358 2013-08-28 08:27:43 <gmaxwell> So long as there are many devices doing this, the probablity of getting away with breaking the rules is negligible.
359 2013-08-28 08:28:46 <CodeShark> for most people, running a full node is probably far more expensive than it is for me - I don't expect most of them to do so. I certainly believe there should be at least sufficient devices doing full validation so that it is extremely difficult to break the rules and get away with it.
360 2013-08-28 08:28:50 <gmaxwell> CodeShark: yes, that why I think things like PVN is important, I really don't think we can trust people to run full nodes in any great quantity if its too expensive.  And once few enough people to, it will start becoming safer to just use the biggest ones since they're least likely to lose the consensus, right or wrong.
361 2013-08-28 08:30:02 <gmaxwell> (we already see this to some extent: electrum is very likely _pratically_ safer than multibit, because electrum servers are run by known-through-you-can-choke, while multibit just connects to a couple public nodes and will believe all kinds of BS)
362 2013-08-28 08:30:19 <gmaxwell> s/through/throat/
363 2013-08-28 08:30:39 <CodeShark> which brings up another important point - where is the actual weakest link in trust?
364 2013-08-28 08:31:07 <gmaxwell> well trust against what?  preventing inflation long term is not the same threat as .. say, stealing your coins.
365 2013-08-28 08:32:17 <gmaxwell> For the latter we'd probably all be best off -connect= a node run by google, since their capacity to pay out damages due to misconduct is basically unbounded. :P .. and if we all connect a single node we could all be immune to double spends. :P
366 2013-08-28 08:32:38 <gmaxwell> But if we want to prevent censorship or inflation, thats not at all a good model.
367 2013-08-28 08:32:47 <CodeShark> fiat currencies aren't going anywhere anytime soon - bitcoin will likely be used mainly for speculation and money transmission and not so much for pricing in the foreseeable future
368 2013-08-28 08:33:32 <gmaxwell> Indeed, fiat currencies aren't going anywhere: which is why I think it's important to work to preserve bitcoin's unique value... it's a piss poor replacement for VISA+USD technically, politically, otoh....
369 2013-08-28 08:34:56 <gmaxwell> omg huge fee in mempool
370 2013-08-28 08:35:01 <gmaxwell> please p2pool find this block!
371 2013-08-28 08:35:21 <gmaxwell> Current block value: 225.0891 BTC Expected time to block: 12.6 hours
372 2013-08-28 08:35:43 <gmaxwell> ... bet some crap pool that doesn't pay fees to miners gets it. :-/
373 2013-08-28 08:35:44 <CodeShark> 12.6 hours?
374 2013-08-28 08:35:53 <gmaxwell> CodeShark: yes, for p2pool.
375 2013-08-28 08:35:59 <CodeShark> oh, just p2pool
376 2013-08-28 08:42:52 <CodeShark> anyhow, calling it a night - later, gmaxwell
377 2013-08-28 08:42:53 <Scrat> isnt it good if a pool finds it? then the poor guy fucking around with raw transactions might get his btc back :p
378 2013-08-28 08:45:57 <gmaxwell> boo.
379 2013-08-28 08:46:10 <Graet> asicminer
380 2013-08-28 08:46:13 <gmaxwell> Scrat: only if that actually happens.
381 2013-08-28 08:46:26 <gmaxwell> most of the time it hasn't.
382 2013-08-28 08:46:45 <gmaxwell> asicminer got it.
383 2013-08-28 08:47:40 <gmaxwell> it wasn't even a single big transaction
384 2013-08-28 08:47:47 <gmaxwell> it's loads of txn with 1 btc fees it looks like.
385 2013-08-28 08:48:04 <gmaxwell> oh I'm wrong.
386 2013-08-28 08:48:24 <gmaxwell> http://blockchain.info/tx/4ed20e0768124bc67dc684d57941be1482ccdaa45dadb64be12afba8c8554537
387 2013-08-28 08:48:31 <gmaxwell> oh fun, that looks like a coinjoin transaction.
388 2013-08-28 08:48:53 <gmaxwell> I wonder if that was done with genjix's tool.
389 2013-08-28 08:55:49 <Diablo-D3> a what?
390 2013-08-28 08:56:55 <CodeShark> an expensive test!
391 2013-08-28 08:59:42 <CodeShark> the fee calculation (change output) seems to be off by like 5 or 6 orders of magnitude :)
392 2013-08-28 09:01:12 <sipa> 200 BTC fee? :o
393 2013-08-28 09:01:41 <winbtc_moarrr> oh damn, why did i forget that stupid decimal point!
394 2013-08-28 09:02:13 <gmaxwell> it looks like someone computed the fee as the last input minus the outputs rather than all the inputs minus all the outputs.
395 2013-08-28 09:02:27 <gmaxwell> er computed the change.
396 2013-08-28 09:02:57 <sipa> or it's a coinjoin tx, but the second party replaced the outputs rather than added
397 2013-08-28 09:03:45 <CodeShark> I believe all the inputs come from the same source
398 2013-08-28 09:04:02 <CodeShark> so most likely it's just a single person running a test
399 2013-08-28 09:04:04 <gmaxwell> it does, might have been someone expirementing with a coinjoin tool... as it does look a lot like a coinjoin txn.
400 2013-08-28 09:04:05 <sipa> ok
401 2013-08-28 09:04:19 <gmaxwell> I don't see any change handling code in genjix's tool.
402 2013-08-28 09:05:43 <CodeShark> I never run initial tests on mainnet with these amounts - but then again, whoever did this might have a LOT more coins than I do
403 2013-08-28 09:06:10 <sipa> "I do not always test on mainnet, but when I do, I do it with huge amounts."
404 2013-08-28 09:06:13 <gmaxwell> well, might not be CJ txn...
405 2013-08-28 09:06:58 <gmaxwell> CodeShark: this was the worlds second public CJish transaction: https://blockchain.info/tx/69d9d66aae4812b6cf156f32267b773fb2118db696bb847ebd3454a198b59fbd
406 2013-08-28 09:07:20 <CodeShark> sipa, reference to this guy? http://en.wikipedia.org/wiki/File:Jonathan_Goldsmith_2009.jpg
407 2013-08-28 09:07:48 <sipa> i had no idea what his real name was, but yes
408 2013-08-28 09:07:51 <CodeShark> http://upload.wikimedia.org/wikipedia/commons/2/2a/Jonathan_Goldsmith_2009.jpg
409 2013-08-28 09:08:01 <gmaxwell> I had no idea what his name was either!
410 2013-08-28 09:08:14 <CodeShark> yeah, he's a jewish guy from new york :)
411 2013-08-28 09:08:28 <CodeShark> pretty funny he's been cast in that role
412 2013-08-28 09:11:07 <CodeShark> I think the most I've ever lost in mainnet from a bug in my code is like 5 btc
413 2013-08-28 09:11:30 <sipa> i have no idea how many BTC i jad on mybitcoin...
414 2013-08-28 09:11:32 <CodeShark> but this was back when bitcoin was < $10
415 2013-08-28 09:11:32 <sipa> maybe a few
416 2013-08-28 09:13:25 <gmaxwell> wow, I've never lost bitcoin.
417 2013-08-28 09:13:42 <gmaxwell> I lost namecoin due to a SSD electronics failure.
418 2013-08-28 09:13:46 <gmaxwell> like a few thousand.
419 2013-08-28 09:13:55 <gmaxwell> (well maybe only a thousand don't recall now)
420 2013-08-28 09:15:05 <CodeShark> change miscalculations are at the top of my list of things to watch for because bitcoin is extremely unforgiving about that
421 2013-08-28 09:15:58 <CodeShark> the 5 btc or whatever I lost were also due to a change miscalculation
422 2013-08-28 09:27:54 <CodeShark> alright, this time for real - goodnight, guys
423 2013-08-28 09:28:10 <sipa> nite
424 2013-08-28 09:35:19 <gmaxwell> I got ahold of friedcat and he said they'll refund if the sender can provide them signatures on all the inputs.
425 2013-08-28 09:35:33 <warren> wow
426 2013-08-28 09:35:54 <gmaxwell> Graet has refunded a jumbo fee before too.
427 2013-08-28 09:35:58 <gmaxwell> (IIRC)
428 2013-08-28 09:37:02 <warren> I lost Bitcoin due to not believing it would survive from early 2010.  I gave away my Bitcoins so as not to have an abandoned, deleted wallet pollute the UTXO set forever.
429 2013-08-28 09:37:15 <warren> Shows how smart I was.
430 2013-08-28 09:37:55 <gmaxwell> oh :( well now that you mention that.
431 2013-08-28 09:38:07 <gmaxwell> I'm reasonably sure I lost an unknown amount of coin from 2009.
432 2013-08-28 09:38:16 <gmaxwell> (I think at least 500, perhaps just that perhaps lots more0
433 2013-08-28 09:38:23 <gmaxwell> but I wasn't counting that. :P
434 2013-08-28 09:38:29 <warren> =)
435 2013-08-28 09:40:26 <Graet> gmaxwell, btcguild did - no-one ever came forward to claim lost coins on our one so we did a "bonus payout" to miners
436 2013-08-28 09:41:33 <gmaxwell> Graet: ah, I know eligius got one (40 btc?) and also had no one (but scammers!) come forward.
437 2013-08-28 09:41:36 <sipa> but imho, if you're mining and not immediately selling, you're just speculating
438 2013-08-28 09:41:36 <sipa> it's tempting to say "damn, if only i had kept those 2000 BTC i mined in 2010"
439 2013-08-28 09:42:40 <gmaxwell> sipa: it's exactly the same as saying "damn, I wish I ate one less cheeseburger in 2010 and used the $5 to but 1000 BTC!"
440 2013-08-28 09:42:40 <Graet> good on friedcat if he does - his shareholders are getting excited already ;)
441 2013-08-28 09:42:53 <sipa> gmaxwell: yup
442 2013-08-28 09:42:56 <gmaxwell> Graet: still requires the owner showing up.
443 2013-08-28 09:43:03 <Graet> yep
444 2013-08-28 09:43:22 <warren> Early 2010 I read the Satoshi paper, found it plausible, but I thought the government would make examples out of people rather than risk Snow Crash happening.
445 2013-08-28 09:43:55 <gmaxwell> warren: weird, I saw bitcoin on some mailing list but never saw the paper.
446 2013-08-28 09:44:15 <gmaxwell> I misunderstood how it worked and thought the consensus was just counting peers and that the pow was just for the lottery.
447 2013-08-28 09:44:33 <gmaxwell> And since that was trivially insecure, I figured it would just be a novelity, and perhaps useful as some antispam stuff.
448 2013-08-28 09:44:54 <warren> irony, antispam is the only thing Bitcoin doesn't do.
449 2013-08-28 09:45:02 <gmaxwell> I'd played with hal's RPOW stuff, so I mostly thought of it as RPOW with some weak p2p thing instead of the ibmcryptocard.
450 2013-08-28 09:45:44 <gmaxwell> I started it up, in wine in a vnc session and forgot about it.. didn't keep running it because I knew no one else using it and had nothing to use it for, and it was pita.
451 2013-08-28 09:46:08 <warren> yeah, it caused my laptop to overheat and kill itself
452 2013-08-28 09:46:34 <gmaxwell> Didn't notice bitcoin again until the end of 2010 when I had some gpus that were idle (a customer had bought them for me because I coded some gpgpu crypto stuff for them) and I was looking for fun computational tasks to use them on..
453 2013-08-28 09:46:52 <warren> (it still does ... same laptop... I can't sync the bitcoin blockchain on this thing without underclocking and locking it to a single core.
454 2013-08-28 09:47:10 <gmaxwell> "holy shit? this still exists <reads paper> Oh crap, this could actually work! <reads source code> <buys more gpus>"
455 2013-08-28 09:47:51 <warren> I didn't look at Bitcoin again until February 2013 when I had to choose a topic to research and present for Internet Law & Policy class.
456 2013-08-28 09:48:08 <warren> Needless to say, I found it uninteresting and I moved on quickly. =P
457 2013-08-28 09:48:26 <gmaxwell> warren: we talked about a bunch in 2011 in an irc channel you were in, so no excuses.
458 2013-08-28 09:48:40 <warren> I know, I just wasn't paying attention.
459 2013-08-28 10:46:14 <jouke> Would it be hard to disable the broadcasting-solution of a node? I would like to use the wallet-functions of bitcoind and I would like to keep it up to date with the blokchain, but I would not want it to broadcast transactions automatically.
460 2013-08-28 10:46:42 <Luke-Jr> leech
461 2013-08-28 10:47:07 <jouke> Luke-Jr: I would let it connect to only a few nodes of my own.
462 2013-08-28 10:47:08 <sipa> you mean just broadcasting, not relaying?
463 2013-08-28 10:47:24 <jouke> sipa: if that distinction could be made, yes.
464 2013-08-28 10:47:31 <sipa> jouke: yes, they are separate
465 2013-08-28 10:47:55 <sipa> jouke: it should be easy to disable, i think
466 2013-08-28 11:17:39 <_dr> good job on improving initial sync; seems to be a bit faster than a few months ago
467 2013-08-28 11:18:26 <_dr> still annoying as f. though :)
468 2013-08-28 11:19:38 <sipa> more improvements to come
469 2013-08-28 11:29:17 <runeks> Thinking about that 200 BTC fee transaction... it could actually be a way to mix coins.
470 2013-08-28 11:29:59 <runeks> Step 1: Pre-mine a block. Step 2: Include your transaction in that block (don't publish it). Result: you now have transferred 200 BTC as fees to another address, and no one will suspect anything.
471 2013-08-28 11:30:15 <Luke-Jr> runeks: except everyone will suspect it
472 2013-08-28 11:30:26 <Luke-Jr> runeks: and an ambitious miner can try to take it
473 2013-08-28 11:30:26 <sipa> also, step 2 goes before step 1 :)
474 2013-08-28 11:30:28 <runeks> Luke-Jr: Did you suspect it?
475 2013-08-28 11:30:34 <Luke-Jr> runeks: if I knew about it
476 2013-08-28 11:30:41 <Cusipzzz> cut a deal with the pool in advance, easy game
477 2013-08-28 11:30:50 <Luke-Jr> not so easy, no
478 2013-08-28 11:30:55 <runeks> sipa: Oh yeah, good point :)
479 2013-08-28 11:31:05 <Luke-Jr> you've just incentivized btcguild grabbing the fee by orphaning the block
480 2013-08-28 11:31:28 <runeks> Luke-Jr: How would you take it? There's no reason to publish the transaction.
481 2013-08-28 11:31:37 <Luke-Jr> runeks: you have to publish it with your block
482 2013-08-28 11:31:41 <jgarzik> 
ACTION decides RPC raw needs a 'getchangeaddress'

483 2013-08-28 11:31:51 <Luke-Jr> so I see it, put it in my own block, and try to orphan you
484 2013-08-28 11:31:55 <jgarzik> change seems to be one issue poorly handled by RPC
485 2013-08-28 11:31:56 <jgarzik> right now
486 2013-08-28 11:32:16 <Luke-Jr> jgarzik: isn't a change address defined as one not in the address book, but used?
487 2013-08-28 11:32:27 <sipa> yup
488 2013-08-28 11:32:28 <runeks> Luke-Jr: Right. That makes sense. Doesn't make sense for ~1 BTC in fees as they usually are. But mining for 200 BTC creates a different incentive.
489 2013-08-28 11:32:32 <jgarzik> "mine but not in address book"
490 2013-08-28 11:32:33 <jgarzik> yes
491 2013-08-28 11:33:51 <runeks> Actually, without doing the math, I think it would be profitable for most miners to try to include the transaction in their own block and orphan the existing block.
492 2013-08-28 11:34:20 <runeks> The chance of succeeding isn't great, but your reward is 8x what you would normally get (200 BTC vs 25 BTC)
493 2013-08-28 11:34:29 <runeks> Actually 225 BTC vs 25 BTC
494 2013-08-28 11:39:51 <Luke-Jr> 225 can be split among 8 different miners collaborating on it
495 2013-08-28 11:39:57 <Luke-Jr> that's easily 51%
496 2013-08-28 12:05:45 <runeks> Luke-Jr: But if the chance of that block being ignored is 50% then it's not profitable (on average). 50% chance you'll not earn anything, 50% chance you'll earn 28.5 BTC (225 BTC divided by 8)
497 2013-08-28 12:06:09 <Luke-Jr> runeks: with 8 people, the chance of it being ignores is near 0
498 2013-08-28 12:06:20 <Luke-Jr> assuming the 8 people are the biggest pools
499 2013-08-28 12:06:44 <runeks> Luke-Jr: It depends on what their network share is. They need to find two blocks in a row so that their chain becomes the longest.
500 2013-08-28 12:06:47 <kinlo> there are less then 20 pools....
501 2013-08-28 12:07:25 <kinlo> the top 3 pools already have > 51%
502 2013-08-28 12:07:40 <runeks> If someone publishes a block, and you publish a block that conflicts with it, the odds are against you. You need to extend your own chain, because everyone else will work on the block they received first (or will they work on the block with the highest POW?).
503 2013-08-28 12:08:11 <kinlo> you are correct, they mine on the block they received first
504 2013-08-28 12:09:03 <kinlo> the POW is only used to see if it matches D or not.  Nowhere in the code is the POW used for anything else, either it matches or not, how high or low the POW is doesn't matter
505 2013-08-28 12:09:13 <runeks> But with a potential 225 BTC reward, this disadvantage can be outweighed by having a substantial share of the network.
506 2013-08-28 12:09:19 <runeks> kinlo: Are you sure?
507 2013-08-28 12:09:24 <kinlo> runeks: yes.
508 2013-08-28 12:09:55 <sipa> kinlo: POW != hash
509 2013-08-28 12:10:08 <kinlo> eh, right, change POW to hash
510 2013-08-28 12:10:13 <sipa> the PoW of a block is the inverse of its target
511 2013-08-28 12:10:20 <runeks> kinlo: Then why does debug.log mention "log2_work"? As far as I know this is the cumulative work done on  a chain. And the one with the most work done wins.
512 2013-08-28 12:10:22 <runeks> 2013-08-26 23:46:06 SetBestChain: new best=00000000000000124e24e8031f20d322a2df0c9e57988e7a4a770853c45fb48c  height=254397  log2_work=71.460905  tx=22780611  date=2013-08-26 23:45:45 progress=0.999997
513 2013-08-28 12:10:24 <sipa> and the block is valid or not
514 2013-08-28 12:10:36 <sipa> one of the requirements for which is that the hash is belong the target
515 2013-08-28 12:10:44 <sipa> *below
516 2013-08-28 12:11:02 <kinlo> POW = you prooved you did work.  The hash value is irrelevant,e ither it matches D and the POW is confirmed, or it does not match and you didn't proove your work.
517 2013-08-28 12:11:29 <sipa> the important part is that the amount of work you're doing is determined before you start working
518 2013-08-28 12:11:31 <kinlo> matches -> that your hash value is below the difficulty
519 2013-08-28 12:12:08 <runeks> kinlo: That makes sense. So then the log2_work would just be determined by the difficulty; not by whatever hash you happen to find that is below the target.
520 2013-08-28 12:12:33 <runeks> sipa: How is the log2_work figure calculated? Is it calculated from the actualy block hashes, or just from the target of the valid blocks?
521 2013-08-28 12:12:38 <kinlo> runeks: the longest chain is indeed measured byt the total sum of all D's of those blocks, not by the hashes that were found
522 2013-08-28 12:12:41 <sipa> runeks: kinlo is right
523 2013-08-28 12:12:48 <sipa> runeks: only the difficulty matters, not the hash
524 2013-08-28 12:12:51 <runeks> Cool. Good to know.
525 2013-08-28 12:13:15 <sipa> you would have extreme variance if you used the actual hash, and difficulties wouldn't be linear
526 2013-08-28 12:13:28 <sipa> it's not technically wrong though, just much less useful
527 2013-08-28 12:13:48 <kinlo> runeks: which makes sense.  Imagine I'm so lucky to find a block with an incredible POW, the hash is really really low.  Then my block will yield a "longer" chain, while it might not be
528 2013-08-28 12:14:09 <kinlo> if you'd measure chain lenght in actual hashes instead of D's
529 2013-08-28 12:14:13 <runeks> kinlo: Yeah that's a good point. A shorter chain could actually be chosen rather than a longer one.
530 2013-08-28 12:14:31 <sipa> the difficulty requirements just selects a particular subset of blocks to be valid
531 2013-08-28 12:14:45 <sipa> the amount of work you have to do is how small that set is
532 2013-08-28 12:15:12 <runeks> sipa: Yeah, and it doesn't make sense to judge by the actual hash, as we know everyone publish blocks that are less than target.
533 2013-08-28 12:15:39 <sipa> well, you could build a system that used actual hash values
534 2013-08-28 12:15:49 <sipa> but it would end up being much much more of a lottery
535 2013-08-28 12:15:56 <sipa> and the difficulty/work calculations would be harder
536 2013-08-28 12:16:15 <kinlo> sipa: I dont think it would work...  it would be too easy to split the chain
537 2013-08-28 12:16:23 <runeks> sipa: I was just contemplating that. Could we envision a system without a target? The chain with most work just wins. And miners decide for themeselves which chain they like. This would also entail no fixed block time.
538 2013-08-28 12:16:32 <sipa> runeks: log2_work is log2(sum(for each block: 2^256 / block.target))
539 2013-08-28 12:16:50 <sipa> runeks: you need to define work
540 2013-08-28 12:17:06 <sipa> runeks: you can do that without a fixed target, or you could use the actual hash
541 2013-08-28 12:17:11 <runeks> sipa: Work is 1/block.hash
542 2013-08-28 12:17:11 <sipa> the latter would be a really bad idea
543 2013-08-28 12:17:30 <sipa> no, work should be 1/target, but there's no problem in letting miners choose their own target
544 2013-08-28 12:17:35 <helo> the goal is to come to distributed consensus routinely and predictably
545 2013-08-28 12:17:42 <sipa> you need to set the amount of work before doing the work
546 2013-08-28 12:18:19 <runeks> sipa: It's not obvious to me why that would be the case.
547 2013-08-28 12:18:28 <sipa> it would be a lottery
548 2013-08-28 12:18:52 <sipa> if you find a hash that happens to be 1000 times smaller than others (which would happen every week), you can reorg hundreds of blocks
549 2013-08-28 12:18:54 <runeks> I mean, we could set a minimum difficulty of 1 like Bitcoin already has.
550 2013-08-28 12:19:23 <sipa> but before you reason further about this: why does bitcoin have a predetermined difficulty?
551 2013-08-28 12:19:39 <runeks> sipa: Do you have proof of that? Can you point a block out whose hash is 1000 times less than the target?
552 2013-08-28 12:19:53 <runeks> sipa: To rate-limit new blocks founds.
553 2013-08-28 12:19:58 <runeks> *found
554 2013-08-28 12:20:02 <sipa> runeks: i'm sure about it, without looking
555 2013-08-28 12:20:44 <runeks> sipa: But the question is how many blocks that would revert. After all, the factor 1000 would compete against the *sum* work of the previous blocks.
556 2013-08-28 12:20:50 <runeks> I guess I could write a script that figures that out.
557 2013-08-28 12:22:21 <_dr> is there a good way to list the utxo using the reference client? or maybe a tool that does that using my local copy of the blockchain?
558 2013-08-28 12:22:31 <runeks> sipa: But let's say you do find a hash that is 1000 times smaller. You would have to, beforehand, start from an early block, thus giving yourself a disadvantage from the beginning.
559 2013-08-28 12:22:54 <sipa> runeks: sure, it's not necessarily an attack
560 2013-08-28 12:22:57 <runeks> So you're at a disadvantage compared to everyone else who starts with the latest block
561 2013-08-28 12:23:10 <sipa> runeks: i'm just saying that you can get lucky and get a block that is unfair to compete against
562 2013-08-28 12:23:17 <sipa> resulting in worse convergence behaviour
563 2013-08-28 12:23:30 <sipa> though i'm sure it would mean that some attacks become easier to
564 2013-08-28 12:24:07 <runeks> sipa: What do you mean "unfair to compete against"? Rational miners wouldn't compete against, they would work with, ie. extend that chain.
565 2013-08-28 12:24:33 <runeks> Sounds like a fun experiment to me.
566 2013-08-28 12:24:59 <sipa> write a network simulator with miners and random latencies between them, using such a PoW valuation function
567 2013-08-28 12:25:04 <sipa> and see what happens :)
568 2013-08-28 12:25:35 <runeks> I should do that.
569 2013-08-28 12:27:42 <runeks> It would be fun to see which blocks would make sense to publish. Would be interested to see if there's an incentive to spam the network with low difficulty blocks. Just thinking about it now I don't see why you wouldn't publish a block as long as it's more than the minimum difficulty.
570 2013-08-28 12:27:50 <runeks> Might require some modifications.
571 2013-08-28 14:10:20 <petertodd> Smallest block ever, 95 bytes: 00000000000000189ad9b20ed103ac14ca5c08ecfb0f5a0f538e4678f4535c46
572 2013-08-28 14:10:58 <petertodd> Largest block, 998,053 bytes: 000000000000023d9a3ee2714f4365b2d312700ba113af23084104319133c6c0
573 2013-08-28 14:11:14 <sipa> 95??
574 2013-08-28 14:11:24 <sipa> that's not possible
575 2013-08-28 14:11:36 <sipa> oh, or is it excluding the header?
576 2013-08-28 14:11:43 <petertodd> Yeah
577 2013-08-28 14:11:56 <petertodd> 95 bytes of transactions
578 2013-08-28 14:12:08 <sipa> so 176 in total, i guess
579 2013-08-28 14:12:18 <petertodd> Yeah
580 2013-08-28 14:12:38 <petertodd> Having said that, 95 bytes total would be possible too you know if you left the scriptPubKey empty.
581 2013-08-28 14:13:03 <sipa> no
582 2013-08-28 14:13:08 <petertodd> Only restriction is the block height in coinbase, and how you need extraNonce in practice.
583 2013-08-28 14:13:49 <petertodd> Er, right, not 95 bytes, um... 153 bytes?
584 2013-08-28 14:13:49 <sipa> the txin already requires 36 bytes + script
585 2013-08-28 14:15:41 <petertodd> Anyway, the other interesting thing is that the largest block ever included what may be the largest transaction ever too, 465,554 bytes: 659135664894e50040830edb516a76f704fd2be409ecd8d1ea9916c002ab28a2
586 2013-08-28 14:18:25 <petertodd> And, code to produce this with the new python-bitcoinlib RPC support:
587 2013-08-28 14:18:31 <petertodd> import bitcoin.rpc
588 2013-08-28 14:18:46 <petertodd> proxy = bitcoin.rpc.Proxy() # grabs user.pass from ~/.bitcoin/bitcoin.conf automatically
589 2013-08-28 14:18:57 <petertodd> sizes = [(proxy.getblock(proxy.getblockhash(i))['size'],i) for i in range(proxy.getblockcount())]
590 2013-08-28 14:19:12 <petertodd> sorted(sizes,key=lambda x: x[0])
591 2013-08-28 14:20:04 <petertodd> Still working on making bitcoin.rpc.Proxy() automatically serialize/deserialize JSON to bitcoin.core instances in my 'pythonize' branch.
592 2013-08-28 14:28:16 <Luke-Jr> crap
593 2013-08-28 14:28:24 <Luke-Jr> made a CNAME for dns seed instead of NS
594 2013-08-28 14:28:41 <Luke-Jr> 
ACTION fixed

595 2013-08-28 14:28:43 <petertodd> lol, I made that mistake too :/
596 2013-08-28 14:29:06 <michagogo> Lol?
597 2013-08-28 14:29:10 <michagogo> 
ACTION checks logs

598 2013-08-28 14:29:16 <Luke-Jr> there we go, dnsseed.bitcoin.dashjr.org back online
599 2013-08-28 14:29:38 <michagogo> BTW, any #bitcoin ops around?
600 2013-08-28 14:29:46 <petertodd> Luke-Jr: weird, it's only returning feathercoin nodes
601 2013-08-28 14:29:59 <Luke-Jr> ???
602 2013-08-28 14:30:08 <petertodd> hehe
603 2013-08-28 14:30:24 <michagogo> The logs link in #bitcoin is broken -- it sends you to the logs from May
604 2013-08-28 14:30:39 <petertodd> didn't know there was #bitcoin logs
605 2013-08-28 14:30:42 <michagogo> Yeah
606 2013-08-28 14:31:19 <michagogo> the topic here points to bitcoinstats.com, which redirects to http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/08
607 2013-08-28 14:31:26 <michagogo> (with the month being the current one)
608 2013-08-28 14:31:45 <michagogo> The topic there points to http://bit.ly/1082HNz, which redirects to http://bitcoinstats.com/irc/bitcoin/logs/2013/05
609 2013-08-28 14:32:16 <petertodd> weird, because there are more recent logs: http://bitcoinstats.com/irc/bitcoin/logs/2013/08
610 2013-08-28 14:32:31 <michagogo> petertodd: I know, that's my point
611 2013-08-28 14:32:59 <michagogo> It should be a pointer to http://bitcoinstats.com/irc/bitcoin/logs/
612 2013-08-28 14:33:04 <petertodd> yeah
613 2013-08-28 14:33:07 <michagogo> Which goes to the current month
614 2013-08-28 14:36:55 <petertodd> Funny how right after gmaxwell launches the coinjoin bounty there's a rash of articles talking about how public and non-anonymous Bitcoin is... http://www.wired.co.uk/news/archive/2013-08/28/bitcoin-anonymity http://www.pcworld.com/article/2047608/bitcoin-offers-privacy-as-long-as-you-dont-cash-out-or-spend-it.html
615 2013-08-28 15:22:12 <sipa> gmaxwell: aaaaand it's on /.
616 2013-08-28 15:23:34 <gmaxwell> "oh shit, publish the paper before they fix it!"
617 2013-08-28 15:24:54 <_ingsoc> Haters make you famous, gmaxwell. :D
618 2013-08-28 15:39:36 <EasyAt> gmaxwell: "As I write this people with unknown motivations are raining down tiny little payments on old addresses" is there a post about this?
619 2013-08-28 15:41:25 <gmaxwell> EasyAt: there have been a couple here and there.
620 2013-08-28 15:42:21 <EasyAt> gmaxwell: okay, I'll search.  Is there a nice keyword that could help narrow it down
621 2013-08-28 15:53:16 <jgarzik> https://plus.google.com/105424721218711536033/posts/feNSPqJDC7r
622 2013-08-28 15:53:44 <jgarzik> I am often reminded of this quote, when people ask me about the possibility of key collisions and cracking bit coins and such
623 2013-08-28 15:54:06 <jgarzik> it's just? interesting? how a lot of people reason in the face of absurdly large numbers
624 2013-08-28 15:54:30 <jgarzik> but hey, people waste money on the Powerball lottery every day, so what do I know?
625 2013-08-28 15:57:52 <gmaxwell> jgarzik: good quote!
626 2013-08-28 15:58:13 <michagogo> jgarzik: Any ETA on the bootstrap.dat update?
627 2013-08-28 15:59:51 <jgarzik> michagogo, um, keep nagging me about it ;p
628 2013-08-28 16:00:00 <michagogo> 
ACTION nags jgarzik

629 2013-08-28 16:00:08 <jgarzik> pynode broke, so I need to redo it in C
630 2013-08-28 16:00:19 <michagogo> Oh, on the march fork?
631 2013-08-28 16:00:29 <jgarzik> no, more recently
632 2013-08-28 16:00:29 <michagogo> Or something else?
633 2013-08-28 16:00:35 <jgarzik> block #245xxx somewhere
634 2013-08-28 16:00:44 <michagogo> Do you know what caused it?
635 2013-08-28 16:00:57 <jgarzik> if I did, it would have already been fixed and torrent posted ;p
636 2013-08-28 16:01:57 <michagogo> [21:00:07] <jgarzik> pynode broke, so I need to redo it in C
637 2013-08-28 16:01:57 <michagogo> ...like https://bitcointalk.org/index.php?topic=145386.msg1544885#msg1544885 ?
638 2013-08-28 16:02:08 <sipa> jgarzik: just cat blk*.dat >bootstrap.dat ?
639 2013-08-28 16:02:25 <sipa> (after a fresh load-from-network, so there are no reorgs in there)
640 2013-08-28 16:02:42 <jgarzik> sipa, not easily reproducible by third parties, due to padding
641 2013-08-28 16:03:10 <gmaxwell> trimming the padding would be pretty easy.
642 2013-08-28 16:03:22 <jgarzik> sipa, and I want a "give me a linearized block chain, with no reorgs" tool for this and other purposes anyway
643 2013-08-28 16:03:27 <sipa> if you exclude the last blk.dat file, there is no padding
644 2013-08-28 16:03:39 <gmaxwell> sipa: oh do we trim the padding already?
645 2013-08-28 16:03:41 <jgarzik> sipa, have to stop at a specific block
646 2013-08-28 16:03:42 <sipa> yes
647 2013-08-28 16:03:45 <sipa> jgarzik: i'll write you an RPC for that :p
648 2013-08-28 16:03:49 <michagogo> ...or just use https://gist.github.com/dooglus/5002764
649 2013-08-28 16:03:55 <sipa> gmaxwell: yes
650 2013-08-28 16:04:01 <sipa> since 0.8.1 afaik
651 2013-08-28 16:04:05 <gmaxwell> But yea, grabbing the linearized tool is good.
652 2013-08-28 16:04:11 <jgarzik> meh, an RPC should not dump a 8GB file
653 2013-08-28 16:04:12 <gmaxwell> sipa: my memory seems to stink these days.
654 2013-08-28 16:04:17 <jgarzik> that is more for a tool
655 2013-08-28 16:04:21 <gmaxwell> jgarzik: rpc would give you a byte offset to stop at.
656 2013-08-28 16:04:37 <sipa> jgarzik: it can spawn a background thread to build the file
657 2013-08-28 16:04:42 <jgarzik> gmaxwell, too hacky.  I still don't like to depend on a fresh download.
658 2013-08-28 16:04:50 <jgarzik> that's annoying for? me
659 2013-08-28 16:04:56 <jgarzik> and easy to write a smarter tool
660 2013-08-28 16:05:08 <michagogo> (what's wrong with https://gist.github.com/dooglus/5002764 ?)
661 2013-08-28 16:05:18 <jgarzik> sipa, I don't like RPCs that write to the local filesystem
662 2013-08-28 16:05:21 <gmaxwell> hopefully headers first mostly obsoletes this. :P
663 2013-08-28 16:05:45 <michagogo> jgarzik: That's any of several wallet RPCc...
664 2013-08-28 16:05:48 <michagogo> RPCs*
665 2013-08-28 16:05:58 <jgarzik> michagogo, I mean directly, like the wallet backup RPC
666 2013-08-28 16:06:03 <jgarzik> michagogo, indirect is fine
667 2013-08-28 16:06:27 <jgarzik> modifying the wallet through abstract RPC interface is the purpose of the wallet RPCs
668 2013-08-28 16:06:49 <jgarzik> interacting directly with the local filesystem breaks the nice json-rpc api abstraction / illusion
669 2013-08-28 16:07:15 <michagogo> (do people have some kind of script that drops messages that contain a string that's part of https://gist.github.com/dooglus/5002764 ?)
670 2013-08-28 16:07:22 <jgarzik> OTOH, an http rest "GET /rest/block/all-through-25000" that returns an 8GB bytestream would be OK
671 2013-08-28 16:07:25 <jgarzik> rather than a tool
672 2013-08-28 16:07:43 <sipa> michagogo: didn't know about it, but i'm very unfamiliar with the armory codebase
673 2013-08-28 16:08:02 <jgarzik> 
ACTION switches topics

674 2013-08-28 16:08:14 <michagogo> sipa: Well, if it works... :-P
675 2013-08-28 16:08:24 <jgarzik> our signmessage/verifymessage stuff should handle the multibit "BITCOIN SIGNED MESSAGE" PGP-like wrapper
676 2013-08-28 16:08:41 <sipa> also, a 10-line python script could call getblock <hash> false repeatedly, convert the hex to binary, and prepend the 8-byte header to each
677 2013-08-28 16:09:05 <jgarzik> sipa, that's a reasonable solution, if annoyingly slow
678 2013-08-28 16:09:26 <michagogo> (also, getblock <hash> false gives an error)
679 2013-08-28 16:09:27 <sipa> it'll be faster than doing a reload from network + cat blk*.dat :D
680 2013-08-28 16:09:37 <jgarzik> sipa, would need to get an in-order list of block hashes somehow
681 2013-08-28 16:09:50 <gmaxwell> getblockhash
682 2013-08-28 16:09:50 <jgarzik> sipa, requires a reverse-traverse, I think
683 2013-08-28 16:10:05 <sipa> jgarzik: yes, sure?
684 2013-08-28 16:10:16 <sipa> well, no
685 2013-08-28 16:10:26 <jgarzik> no, gmaxwell is right
686 2013-08-28 16:10:27 <sipa> just iterate 0 to N, getblock $(getblockhash N)
687 2013-08-28 16:10:30 <jgarzik> yes
688 2013-08-28 16:10:36 <sipa> anyway
689 2013-08-28 16:10:46 <sipa> my memory fails me, as getblock X false doesn't seem to exist
690 2013-08-28 16:11:00 <michagogo> Maybe it does in HEAD? Idk
691 2013-08-28 16:11:11 <jgarzik> sipa, we had this discussion last week, where I thought get-hex-encoded-raw-block did not exist, and you showed that it did
692 2013-08-28 16:11:14 <jgarzik> so it's there, somewhere ;p
693 2013-08-28 16:11:41 <sipa> seems it was added in head, indeed
694 2013-08-28 16:11:54 <sipa> apparently i had 0.8.something checked out
695 2013-08-28 16:12:33 <michagogo> Have any gitian builders not built 0.8.4rc2 yet?
696 2013-08-28 16:13:04 <sipa> yes yes me
697 2013-08-28 16:13:12 <michagogo> If so, do they want to? (I set up an IFTTT recipe to email me when there's a new commit on gitian.sigs)
698 2013-08-28 16:13:23 <michagogo> (since I couldn't find an RSS feed for bitcoin tags)
699 2013-08-28 16:16:10 <michagogo> (and if a new release is tagged when my computer is off, I'd like to know in advance of booting because I need to boot into my Ubuntu external HD)
700 2013-08-28 16:25:02 <jgarzik> wallet question,
701 2013-08-28 16:25:07 <jgarzik> keypool reserve 94
702 2013-08-28 16:25:10 <jgarzik> keypool return 94
703 2013-08-28 16:25:21 <jgarzik> does that mean the reservekey was returned unused?
704 2013-08-28 16:35:07 <sipa> jgarzik: yes
705 2013-08-28 16:42:59 <sipa> jgarzik: you'll need to call Keep or something like that on the reservekey
706 2013-08-28 16:43:05 <sipa> otherwise it's returned at destruct
707 2013-08-28 16:45:59 <petertodd> jgarzik: I'll bet you you could do a quick bootstrap.dat creator with bitcoin-pythonlib now that I've added RPC support...