1 2012-09-17 00:10:43 <Luke-Jr> sipa: wumpus: BlueMatt: ping
 2 2012-09-17 01:40:43 <arij> i want to use this but i cant figure out how to get it to work does some one want to help me? https://bitcointalk.org/index.php?topic=109831.0
 3 2012-09-17 01:48:18 <kjj_> I'd ask in that thread
 4 2012-09-17 02:08:40 <sipa> Luke-Jr: ?
 5 2012-09-17 02:09:08 <Luke-Jr> sipa: can you do gitians of stable rc3s? :p
 6 2012-09-17 02:10:31 <Luke-Jr> maybe when you get back
 7 2012-09-17 10:15:21 <daedeloth> alright guys, http://home.catlab.be/bitcoin/ => try it, feedback it, break it. Everything is implemented except the last step (= sending you the credits) but that part will be implemented soon and will process all "old" transfers as well. Let me know what you think :)
 8 2012-09-17 10:15:48 <daedeloth> *credits = bitcoins :)
 9 2012-09-17 10:18:51 <kreal> v1 :)
10 2012-09-17 10:19:03 <daedeloth> yea :p
11 2012-09-17 11:47:49 <otimm> would it be a stupid idea to hardcode the requirements for a new checksum block into the source instead of a hand choosen list? and let the nodes vote for a new checksum block by themself? the "hash of all checksum blocks" would then be another metric of the nework. if it changes, a new checksum block is added to the list. new nodes can request the list and check if the checksum matches.
12 2012-09-17 11:49:47 <gmaxwell> otimm: Yes it would be a bad idea.
13 2012-09-17 11:49:56 <gmaxwell> otimm: it would undermine the security model entirely.
14 2012-09-17 11:50:00 <otimm> oh, great, i am good at those >)
15 2012-09-17 11:51:21 <gmaxwell> Bitcoin is not a democracy. The only voting in the system is on the order of transactions... and thats because there was no other way known to accomplish it. Each complete bitcoin node fully validates the rules of the system on its own.
16 2012-09-17 11:53:08 <gmaxwell> as for what you suggest, either it does nothing because you reorg off it??? e.g. you get a second longer chain which disagrees with a checksum but it's longer so you accept it??? or it risks creating mutually exclusive hard forks because different nodes heard of different chains in different orders and accept different checksums.
17 2012-09-17 11:57:13 <sipa> i wonder what the security implications would be of using a check-sigs-in-last-5000-blocks rule for example, ibstead of after the last checksum, in reverse-headers fetch?
18 2012-09-17 11:59:59 <gavinandresen> I'm going to tag and push 0.7.0 final now, unless I hear howls of protest ....
19 2012-09-17 12:03:40 <gmaxwell> sipa: I'm sort of doubtful that the gain is worth thinking about or arguing about the security of it.
20 2012-09-17 12:04:08 <gavinandresen> * [new tag]         v0.7.0 -> v0.7.0
21 2012-09-17 12:04:30 <gmaxwell> sipa: would certantly be better off if you could process notifications of rule violations. Then even getting a big reorg wouldn't let you get away with stealing coins.
22 2012-09-17 12:06:52 <gmaxwell> sipa: better, e.g. to get sig checking in async enough and just run them behind. and when it's sufficiently deep in the chain you let them go completely async.
23 2012-09-17 12:22:09 <sipa> gmaxwell: that does seem safer indeed
24 2012-09-17 12:22:37 <Diablo-D3> sipa, gmaxwell...
25 2012-09-17 12:22:54 <Diablo-D3> how is it I enter your interesting conversations in the middle like every time?
26 2012-09-17 12:23:16 <sipa> gmaxwell: btw, my guess why i only see a 2.5x speedup with parallel sig checking: my i7 cpu clocks down when multiple cores are busy
27 2012-09-17 12:23:28 <gmaxwell> sipa: AH!
28 2012-09-17 12:23:46 <Diablo-D3> lol turbocore
29 2012-09-17 12:23:49 <Diablo-D3> I hate that feature
30 2012-09-17 12:23:59 <Diablo-D3> it penalizes you for having well written parallel code
31 2012-09-17 12:24:16 <sipa> it's very useful in general, but very inconvenient for benchmarks
32 2012-09-17 12:24:31 <Diablo-D3> you can turn that off at runtime I believe, I dont think you have to reboot to bios to do it
33 2012-09-17 12:24:49 <Diablo-D3> 
ACTION doesnt have a cpu with that

34 2012-09-17 12:25:37 <Diablo-D3> sipa: btw, cant you do sig checking in opencl?
35 2012-09-17 12:26:07 <sipa> i'll add some cmdline options to select the number of threads and where to start sigchecking, and ask some others to benchmark too :)
36 2012-09-17 12:26:55 <sipa> Diablo-D3: should be possible, but i'm not sure whether someone already implemented ec multiplication in opencl
37 2012-09-17 12:27:10 <sipa> vanitygen only does ec additions on the gpu
38 2012-09-17 12:27:48 <Diablo-D3> wonder why
39 2012-09-17 12:27:56 <Diablo-D3> ec is only integer right?
40 2012-09-17 12:28:12 <sipa> though i do expect something in the order of 50000 sigchecks/s on a high-end cpu
41 2012-09-17 12:28:28 <sipa> wwhich i*gpu
42 2012-09-17 12:28:31 <sipa> eh
43 2012-09-17 12:28:32 <Diablo-D3> wtf
44 2012-09-17 12:28:34 <sipa> *gpu
45 2012-09-17 12:44:18 <gavinandresen> sipa wumpus BlueMatt Luke-Jr : are y'all able to gitian build 0.7.0 final today?  I just pushed my sigs...  (and gmaxwell: are you gitian-capable ?)
46 2012-09-17 12:48:53 <BlueMatt> gavinandresen: ack, building (not sure if my win32's will match this time, but I kinda doubt it)
47 2012-09-17 12:49:39 <gavinandresen> BlueMatt: what should I say about the ppa in the release announcement?  How quickly is that updated/available ?
48 2012-09-17 12:49:48 <BlueMatt> gavinandresen: will push that today too
49 2012-09-17 12:50:12 <BlueMatt> "if you are currently using the ppa, there should be an update available with the rest of your system updates within a few hours"
50 2012-09-17 12:57:08 <gavinandresen> BlueMatt: I modified the info about the ppa from the 0.6 release:  see README.txt at https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.0/
51 2012-09-17 13:05:15 <BlueMatt> gavinandresen: I still find the "How to upgrade" section unclear wrt the ppa
52 2012-09-17 13:05:37 <BlueMatt> gavinandresen: seems like ppa users may have to -detachdb, which is wrong
53 2012-09-17 13:08:11 <gavinandresen> BlueMatt: I'm torn between wanting to keep the how-to-upgrade simple for the 95% of users who just upgrade from the last release and adding more info for the 5% who do something weird (like switch from ppa to the .tar.gz ....)
54 2012-09-17 13:09:03 <gavinandresen> BlueMatt: Maybe the right thing to do is one paragraph for the 95% case, then a very short sentence saying "If you have trouble, see <link>."
55 2012-09-17 13:09:18 <gavinandresen> ... where <link> has all the gory details.
56 2012-09-17 13:18:59 <kjj_> odd.  was/is there a bug with the "version message" log lines?
57 2012-09-17 13:25:47 <BlueMatt> gavinandresen: Id just say add (for example, if you were using an Ubuntu PPA version, and are switching to the binary releases)
58 2012-09-17 13:26:15 <BlueMatt> to make it clear
59 2012-09-17 13:26:59 <gavinandresen> BlueMatt: OK
60 2012-09-17 13:28:40 <gavinandresen> BlueMatt: readme updated
61 2012-09-17 13:31:14 <BlueMatt> gavinandresen: thanks
62 2012-09-17 13:45:54 <BlueMatt> gavinandresen: my linux sigs pushed, win32 didnt match (again) there's something up with my system thats making it not match, Ill look into it some other time
63 2012-09-17 13:46:17 <gavinandresen> BlueMatt: great, thanks.
64 2012-09-17 13:48:44 <BlueMatt> does anyone other than me build with -j4 or something other than default?
65 2012-09-17 13:52:40 <gavinandresen> BlueMatt: I gitian build following doc/release-process.txt exactly
66 2012-09-17 13:53:31 <gavinandresen> BlueMatt: I could try gitian-building -j4... how would I do that?
67 2012-09-17 13:54:41 <kjj_> is it normal for the port number in the "send version message" debug line to be 1 higher than the actual port number?
68 2012-09-17 14:00:50 <Eliel> https://twitter.com/SDLerner/status/247725013975834624 is this something that's known about?
69 2012-09-17 14:01:55 <Diablo-D3> Eliel: I doubt there is one
70 2012-09-17 14:02:17 <Diablo-D3> many people have tried, none have succeeded
71 2012-09-17 14:03:34 <kjj_> I'm pretty sure he's actually found several security problems already.
72 2012-09-17 14:07:39 <gmaxwell> kjj_: He's been pretty helpful with node dos attacks. I take issue with calling every way you can flood a node off a "security problem"
73 2012-09-17 14:07:45 <gmaxwell> It's abnormal to do so.
74 2012-09-17 14:08:09 <kjj_> heh.  I agree.  I don't really see DOS potential as a huge threat either
75 2012-09-17 14:08:22 <gmaxwell> Well there are different kinds of dosses.
76 2012-09-17 14:09:57 <gmaxwell> It's just the general problem with language. A buffer overflow causing arbitrary code execution is what I think most people think of when they hear security, which is not at all the same thing.
77 2012-09-17 14:11:04 <gmaxwell> A DOS that takes O(~1) effort to blow up all the nodes is not the same as a DOS where the attacker must do as much work as the victims.
78 2012-09-17 14:11:07 <gmaxwell> etc.
79 2012-09-17 14:11:53 <otimm> apple releasing a new iphone is also kind of an ddos attack to many websites ;)
80 2012-09-17 14:12:29 <gmaxwell> It's also complicated by the fashion of security people to selfpromote the everlasting shit out of themselves. Why is a DOS attack of a boring kind more important than fixing a crasher? Or a more serious DOS more important than a data corruption bug?
81 2012-09-17 14:12:41 <phantomcircuit> gmaxwell, too be fair there are probably a few dos attacks which would work against the network
82 2012-09-17 14:13:06 <phantomcircuit> all the ones i've come up with at this point require significant work by the attacker, but they would still get an out sized result
83 2012-09-17 14:13:17 <gmaxwell> phantomcircuit: Sure, and we've been closing them diligently for the last year.
84 2012-09-17 14:13:48 <phantomcircuit> yeah i think most of them are well covered at this point
85 2012-09-17 14:14:06 <gmaxwell> Some remain and are more fundimental and a bit harder to fix.
86 2012-09-17 14:14:49 <gmaxwell> E.g. what happens if I have a 100,000 node botnet and make them all bitcoin listeners that do nothing? They accept connections, they rumor their own adresses (and no others), and then they just sit around.
87 2012-09-17 14:14:58 <phantomcircuit> i can think of at least one which is probably not even possible to fix but is more a matter of there simply needing to be more nodes
88 2012-09-17 14:15:52 <phantomcircuit> gmaxwell, i haven't looked at it closelt but i suspect gavins DOS thing would end up flagging them as being naughty if you had at least one real connection
89 2012-09-17 14:15:57 <gmaxwell> Say there are 15k good listeners.. 100k drones.  1/3 chance you pick 8 peers and they're all bad.
90 2012-09-17 14:16:02 <phantomcircuit> would take a bit more investigating though
91 2012-09-17 14:16:20 <gmaxwell> phantomcircuit: nah, no way to tell that they're naughty. They act normal, but they're quiet.
92 2012-09-17 14:16:28 <gmaxwell> They don't send you bad data.. just no good data.
93 2012-09-17 14:16:44 <phantomcircuit> gmaxwell, well that's in itself suspicious after a certain point
94 2012-09-17 14:16:51 <phantomcircuit> given the amount of activity on the real network
95 2012-09-17 14:17:17 <phantomcircuit> given that every connection you have should issue you an INV for each transaction the others send
96 2012-09-17 14:17:25 <gmaxwell> phantomcircuit: yea, but thats very dangerous to code in tests for... the network gets quiet for too long once and everyone bans everyone else! hurrah!
97 2012-09-17 14:17:26 <phantomcircuit> you could reasonably well identify bad nodes
98 2012-09-17 14:17:28 <gmaxwell> :P