1 2012-08-24 00:04:57 <BlueMatt> Luke-Jr: is there a reason there is a change on gitian-win32.yml with (apparently) no change?
2 2012-08-24 00:05:07 <Luke-Jr> BlueMatt: 1_47 to 1_49
3 2012-08-24 00:05:17 <Luke-Jr> two instances of it IIRC
4 2012-08-24 00:05:23 <BlueMatt> does that still build?
5 2012-08-24 00:05:28 <BlueMatt> or does it need it?
6 2012-08-24 00:05:34 <Luke-Jr> it does after the change. it doesn't build at all right now.
7 2012-08-24 00:06:22 <BlueMatt> iirc BOOST_INTERPROCESS_HAS_WINDOWS_KERNEL_BOOTTIME was broken < 1.49
8 2012-08-24 00:06:49 <Luke-Jr> hmm
9 2012-08-24 00:07:21 <Luke-Jr> so we should do #if defined(WIN32) && BOOST_VERSION == 104900 ?
10 2012-08-24 00:07:25 <BlueMatt> also, Im not a big fan of doing it that way - too easy to mess up later, and its possible something else in boost includes interprocess/... and messes it up (maybe not in current version...)
11 2012-08-24 00:07:52 <BlueMatt> I have no problem moving it out of the gitian build file, but I still prefer to patch boost directly
12 2012-08-24 00:08:00 <BlueMatt> maybe add a .patch and make gitian apply it?
13 2012-08-24 00:08:03 <gmaxwell> Make a boost version wrapper?
14 2012-08-24 00:08:08 <Luke-Jr> BlueMatt: how does that work for native buidls?
15 2012-08-24 00:08:13 <gmaxwell> BlueMatt: hows that help someone who is using a system provided boost?
16 2012-08-24 00:08:15 <Luke-Jr> gmaxwell: that sounds ok
17 2012-08-24 00:08:26 <BlueMatt> gmaxwell: no one uses a system provided boost to build for win32
18 2012-08-24 00:08:37 <Luke-Jr> BlueMatt: everyone building on win32 does afaik
19 2012-08-24 00:08:40 <BlueMatt> Luke-Jr: for native builds, it doesnt work, but I just fell like its more likely to break as-is
20 2012-08-24 00:08:52 <BlueMatt> Luke-Jr: you still have to build it yourself, it doesnt come with anything
21 2012-08-24 00:08:59 <Luke-Jr> gmaxwell: #include "boost_ipc_workaround.h" ?
22 2012-08-24 00:09:08 <gmaxwell> BlueMatt: and I would, if I ever bothered to do my own windows builds (fedora mingw has boost)
23 2012-08-24 00:09:18 <gmaxwell> Luke-Jr: the problem is that IPC could be added in a file without adding that. :(
24 2012-08-24 00:09:27 <BlueMatt> gmaxwell: oh, thats right, I did know that...
25 2012-08-24 00:09:48 <gmaxwell> (though it also has _current_ boost, so it's not an issue there, I guess)
26 2012-08-24 00:10:06 <gmaxwell> but in general, we should avoid patching boost if we can, and it seems like we can here.
27 2012-08-24 00:10:09 <Luke-Jr> gmaxwell: Diapolo said current boost adds yet another library for IPC
28 2012-08-24 00:10:41 <BlueMatt> alright, lets just upgrade to boost 1.51
29 2012-08-24 00:10:56 <BlueMatt> Luke-Jr: no big deal, we probably already build it anyway
30 2012-08-24 00:11:07 <Luke-Jr> BlueMatt: more to break/test/etc
31 2012-08-24 00:11:09 <BlueMatt> (btw, I believe we can cut down the number of libs we build when we build boost by...a ton)
32 2012-08-24 00:11:10 <Luke-Jr> ACTION shrugs
33 2012-08-24 00:11:21 <BlueMatt> better than patching boost in the first place
34 2012-08-24 00:11:28 <BlueMatt> (though that patch is really very harmless)
35 2012-08-24 00:11:58 <Luke-Jr> updating to 1.50+ sounds like more work that I really wanted to put into it tho
36 2012-08-24 00:14:10 <gmaxwell> Luke-Jr: can you figure out how this hunk fell out of the pack when you split up the pull? https://github.com/bitcoin/bitcoin/pull/898#issuecomment-7980120
37 2012-08-24 00:15:02 <Luke-Jr> gmaxwell: the original pull was one big giant commit with everything, so I had to pretty much re-patch it by hand. it's possible I simply missed it :/
38 2012-08-24 00:15:07 <gmaxwell> (and in particular, why are the unit tests passing without that change?)
39 2012-08-24 00:15:11 <gmaxwell> hm.
40 2012-08-24 00:15:36 <BlueMatt> now that we have those ProcessBlock unit tests, can we add a real chain?
41 2012-08-24 00:15:47 <Luke-Jr> BlueMatt: ?
42 2012-08-24 00:16:05 <BlueMatt> I thought we now did unit tests that ran ProcessBlock with a memory-backed bdb?
43 2012-08-24 00:16:09 <Luke-Jr> yes
44 2012-08-24 00:16:13 <BlueMatt> can we add a real test chain import to the test cases
45 2012-08-24 00:16:19 <Luke-Jr> it does???
46 2012-08-24 00:16:30 <BlueMatt> ie one that exercises things like MAX_BLOCK_SIZE MAX_BLOCK_SIGOPS, etc, etc, etc
47 2012-08-24 00:16:35 <Luke-Jr> o
48 2012-08-24 00:16:43 <Luke-Jr> yeah, I'm pretty sure it does that
49 2012-08-24 00:17:27 <BlueMatt> I see one instance of ProcessBlock in src/test
50 2012-08-24 00:17:48 <BlueMatt> (its in a loop, but the block is essentially constant)
51 2012-08-24 00:18:42 <BlueMatt> and then it checks like 2 things using CreateNewBlock, but I mean direct tests
52 2012-08-24 00:18:43 <Luke-Jr> CreateNewBlock runs ConnectBlock
53 2012-08-24 00:18:54 <BlueMatt> and more, blocks can fail in more than 2 ways
54 2012-08-24 00:19:07 <Luke-Jr> i c
55 2012-08-24 00:19:14 <Luke-Jr> sounds like good tests to add
56 2012-08-24 00:21:56 <BlueMatt> actually, who has lots o' mining power, I have the blocks, just need them mined?
57 2012-08-24 00:21:58 <BlueMatt> doesnt gmaxwell?
58 2012-08-24 00:22:10 <BlueMatt> or Luke-Jr, ofc
59 2012-08-24 00:22:32 <Luke-Jr> I think gmaxwell has more than me, actually
60 2012-08-24 00:23:00 <BlueMatt> ACTION is sitting here with his...cpu
61 2012-08-24 00:23:03 <Luke-Jr> do you have a poolserver we can just point our miners at maybe?
62 2012-08-24 00:23:28 <BlueMatt> I'd have to write something, all I have is a bitcoinj script that makes fun blocks using a diff target of like 0x8fff....
63 2012-08-24 00:24:37 <BlueMatt> meh, Ill write more blocks first, then maybe Ill (eventually) have time to write a getwork server and Ill get this stuff mined into something that doesnt require a low diff target
64 2012-08-24 00:25:50 <gmaxwell> Luke-Jr: there is a specific test case for what he's asking about, but it doesn't fail.
65 2012-08-24 00:25:56 <Luke-Jr> BlueMatt: to make the miner tests, I hacked up bitcoind to make easily-calculable blocks; might be worth looking at
66 2012-08-24 00:26:18 <Luke-Jr> gmaxwell: dead code? is it possible something else takes care of it sooner?
67 2012-08-24 00:26:59 <BlueMatt> Luke-Jr: I dont really wanna rewrite all the blocks I already wrote...
68 2012-08-24 00:28:07 <Luke-Jr> gmaxwell: hmm, this is weird - the diff for #898 shows it being removed!
69 2012-08-24 00:29:09 <gmaxwell> Luke-Jr: see my revised response to him: https://github.com/bitcoin/bitcoin/pull/898#issuecomment-7990483
70 2012-08-24 00:29:10 <Luke-Jr> gmaxwell: in fact, I *don't* see that code in master..
71 2012-08-24 00:29:28 <Luke-Jr> ..yeah
72 2012-08-24 00:30:25 <Luke-Jr> gmaxwell: IMO, someone should purge the non-master branches off github; the 0.6.2/3 ones at least seem to confuse people
73 2012-08-24 00:30:41 <Luke-Jr> freenode-verf I presume is not needed anymore, and blockheaders is I presume very stale
74 2012-08-24 00:31:16 <gmaxwell> I doubt thats his problem. I suspect that he modified his checkout of master at some point, and been git pulling which merged something somewhere without conflict.
75 2012-08-24 00:31:54 <Luke-Jr> ah
76 2012-08-24 00:31:56 <Luke-Jr> probably
77 2012-08-24 00:32:04 <Luke-Jr> but it has been a problem for others at least
78 2012-08-24 00:32:15 <gmaxwell> Luke-Jr: sorry for bugging you about that. I didn't even look at it before asking you because I assumed you'd have some idea why you left that change out. :)
79 2012-08-24 00:32:40 <Luke-Jr> I just assumed dooglus knew what he was talking about >_<
80 2012-08-24 00:32:58 <gmaxwell> Yea, me too! well, git can be tricky. :)
81 2012-08-24 00:33:16 <Luke-Jr> yeah, I think I used to do that occasionally
82 2012-08-24 00:33:22 <Luke-Jr> before I learned to never commit to tracking branches <.<
83 2012-08-24 00:35:56 <gmaxwell> I wonder if we should change the makefiles to build bitcoin-test by default and to run it at build time.
84 2012-08-24 00:36:09 <gmaxwell> unless you make bitcoind-notest or something.
85 2012-08-24 00:36:51 <Luke-Jr> gmaxwell: my GNUmakefile does that :p
86 2012-08-24 04:31:26 <gmaxwell> wumpus: sorry!
87 2012-08-24 04:31:46 <wumpus> lol, no problem
88 2012-08-24 04:32:15 <gmaxwell> (I'm indifferent to the weird rules; I have a code base (not mine) at work that does that one line thing, so I didn't pay it any attention)
89 2012-08-24 04:32:44 <wumpus> I'm usually not obessing over coding style either, but this is really really ugly imo
90 2012-08-24 04:32:59 <wumpus> I'm all for breaking lines if they are too long, but htis is just nonsense
91 2012-08-24 04:34:13 <gmaxwell> there are a number of other cases of it in the source it seems.
92 2012-08-24 04:34:32 <wumpus> let me guess, all caused by a certain person
93 2012-08-24 04:35:17 <gmaxwell> nope
94 2012-08-24 04:35:31 <gmaxwell> hm, well perhaps 2012-08-21 was just code motion.
95 2012-08-24 04:35:48 <Guest95728> gmaxwell: return type should not be on a line by itself
96 2012-08-24 04:36:00 <wumpus> we know Guest95728 :p
97 2012-08-24 04:36:35 <jgarzik_> ACTION kicks freenode
98 2012-08-24 04:45:15 <Luke-Jr> wumpus: "@luke-jr also wants to change that, to show mined transactions at depth 1 instead of depth 2." <-- I do?
99 2012-08-24 04:52:09 <yellowhat> i think i just had a DOS attack on my bitcoin-qt. i had a single tcp connection which was sucking 5Megabytes/sec from me
100 2012-08-24 04:52:32 <gmaxwell> yellowhat: sounds like a node pulling the blockchain from you, not a dos attack.
101 2012-08-24 04:53:13 <yellowhat> well, i never get 5 megabytes/sec when downloading the blockchain :)
102 2012-08-24 04:53:39 <gmaxwell> yellowhat: well now that guy won't either, if you punted him!
103 2012-08-24 04:55:09 <yellowhat> the thing is, my upstream was saturated because of that
104 2012-08-24 04:55:28 <yellowhat> i should configure better qos on my router then
105 2012-08-24 05:01:21 <Luke-Jr> yellowhat: blockchain downloads tend to be bursty, since it's processing-bound
106 2012-08-24 05:28:16 <fiesh> a dos attack over a single tcp connection is nonsense...
107 2012-08-24 05:28:53 <Luke-Jr> fiesh: no, maybe you're confusing DoS with DDoS
108 2012-08-24 05:30:00 <fiesh> no i'm not
109 2012-08-24 05:30:11 <fiesh> you have to send data over the tcp connection in order to saturate anythign
110 2012-08-24 05:30:32 <fiesh> whatever, good night
111 2012-08-24 05:30:44 <Luke-Jr> ???
112 2012-08-24 05:30:55 <Luke-Jr> how is that supposed to mean it isn't a DoS?
113 2012-08-24 05:31:15 <fiesh> because a dos typically sends lots of data, over udp packets or plenty SYN tcp packets
114 2012-08-24 05:31:25 <fiesh> or otherwise tries to exhauste the capacities of the server
115 2012-08-24 05:31:30 <Luke-Jr> that's ONE kind of DoS.
116 2012-08-24 05:31:45 <Luke-Jr> yes, and that *could* have been one that exhausts the upstream bandwidth..
117 2012-08-24 05:31:54 <fiesh> ... and hwo exactly would it do that?
118 2012-08-24 05:32:21 <Luke-Jr> if there was a vulnerability that caused Bitcoin-Qt to just send data on a connection nonstop forever
119 2012-08-24 05:32:50 <fiesh> oh yes, that would be a tremendous bug
120 2012-08-24 05:33:07 <fiesh> but hardly a dos attack, just having one tcp connection sending data
121 2012-08-24 05:33:29 <fiesh> any second tcp connection would still have half the bandwidth
122 2012-08-24 05:33:49 <fiesh> anyhow, good night
123 2012-08-24 05:50:59 <gmaxwell> jrmithdobbs: where the 2#$@#@$@#$#@ is your socks patch?
124 2012-08-24 05:51:15 <gmaxwell> jrmithdobbs: I opened this, https://github.com/bitcoin/bitcoin/issues/1558 and now I don't remeber what its about. (doh)
125 2012-08-24 05:58:10 <gmaxwell> for extreme fun; for i in {0..1000} ; do echo $i ; ( ./bitcoind listtransactions > /dev/null &) ; done on 32bit and watch it fall over when you hit 2GB of vm space (or on 64 bit see it hit numbers like 5GB of vm space)
126 2012-08-24 06:01:16 <iddo> gmaxwell: could you reply in proof-of-stake thread about ECC math-related signing key delegation ?
127 2012-08-24 06:01:30 <iddo> i thought about it and i don't think it can be done, without linkages in the blockchain
128 2012-08-24 06:04:40 <iddo> seems like you'd need some wonderful homomorphic OWF f, pk2=f(pk1)=f(sk1 * G)=f(sk1)f(G)
129 2012-08-24 06:05:03 <iddo> which probably doesnt make since because sk1 is integer and G is point on the curve
130 2012-08-24 06:05:36 <iddo> and couldn't guarantee that f(G) would have high order
131 2012-08-24 06:07:16 <iddo> f needs to be OWF because given the signing key sk2=f(sk1) you shouldnt be able to find sk1
132 2012-08-24 06:07:46 <iddo> so maybe you meant something else by ECC math-related keys?
133 2012-08-24 06:12:28 <Luke-Jr> gmaxwell: I think that was fixed already?
134 2012-08-24 06:13:09 <Luke-Jr> gmaxwell: b19811d5f4140281f99f4eea5e69d9d670f4d549
135 2012-08-24 06:29:13 <iddo> gmaxwell: what we'd really want is OWF on integers f, and an efficient function on curve points g, with g(n*G)=f(n)*G
136 2012-08-24 06:30:23 <iddo> maybe if those functions f,g exist then ECDSA is broken, i don't know
137 2012-08-24 06:32:34 <iddo> or the OWF is broken, i don't know
138 2012-08-24 06:49:09 <tonikt> sipa: I did not fix boost-win32.yml, just went around the issue by removinf the problemating echo + patch. And I patched the file manually in the archive (the one that you place in the input folder before building boost)
139 2012-08-24 08:08:46 <sipa> tonikt: ic
140 2012-08-24 09:39:11 <xz> is the bitcoin protocol specified? if so, where?
141 2012-08-24 09:39:33 <justmoon> xz: https://en.bitcoin.it/wiki/Protocol_specification
142 2012-08-24 09:39:35 <lianj> ;;google bitcoin protocol
143 2012-08-24 09:39:36 <gribble> Protocol specification - Bitcoin: <https://en.bitcoin.it/wiki/Protocol_specification>; Protocol rules - Bitcoin: <https://en.bitcoin.it/wiki/Protocol_rules>; Bitcoin: <https://bitcoin.it/>
144 2012-08-24 09:39:46 <xz> that page seems incomprehensible to me
145 2012-08-24 09:40:01 <sipa> it only describes the protocol
146 2012-08-24 09:40:10 <sipa> i doubt that that is enough to write a functional client
147 2012-08-24 09:40:41 <sipa> unfortunately, a large part of the specification is "how the reference client behaves"
148 2012-08-24 09:40:56 <xz> right, ok that's what I suspected, and wanted to make sure
149 2012-08-24 09:41:09 <xz> has there been much interest in writing a proper specification?
150 2012-08-24 09:41:16 <lianj> xz: but the links gribble gave are a good start
151 2012-08-24 09:41:33 <sipa> sounds like a very hard job
152 2012-08-24 09:41:34 <xz> I would be interested in working on that, (as a prerequisite to happily writing a lightweight client)
153 2012-08-24 09:42:22 <lianj> better write it after you implemented two clients :)
154 2012-08-24 09:42:50 <xz> surely someone here has implemented one or two clients..
155 2012-08-24 09:42:52 <xz> ?
156 2012-08-24 09:43:05 <xz> perhaps they could be persuaded to work on a protocol specification
157 2012-08-24 09:43:19 <sipa> i don't think any completely-full client exits except for the reference client
158 2012-08-24 09:43:23 <sipa> *exists
159 2012-08-24 09:43:33 <justmoon> sipa: oh this again...
160 2012-08-24 09:43:34 <sipa> bitcoin-JS is probably closest?
161 2012-08-24 09:43:56 <justmoon> sipa: I guess we need a specification of what constitutes a "full client" :P
162 2012-08-24 09:43:56 <lianj> sipa: why are the two wiki pages to bad? the first describes the protocol wire messages, the second the protocol rules to check before accepting a block/tx
163 2012-08-24 09:44:27 <sipa> justmoon: right, if you're just talking about block validation, purecoin, bitcoin-js, and pynode qualify, i assume
164 2012-08-24 09:44:45 <justmoon> bitcoinj too now, no? didn't matt implement full verification?
165 2012-08-24 09:44:48 <xz> lianj: it doesn't define what any of those things mean, for one thing (i.e. the overall framework)
166 2012-08-24 09:44:53 <sipa> justmoon: oh yes
167 2012-08-24 09:44:58 <xz> lianj: and a lot of stuff is missing on the wiki pages
168 2012-08-24 09:45:05 <justmoon> and pretty sure libbitcoin and libcoin have full verification
169 2012-08-24 09:45:55 <lianj> xz: read the paper and some other wiki pages on there
170 2012-08-24 09:45:56 <sipa> libcoin certainly, but maybe a bit outdated
171 2012-08-24 09:46:06 <sipa> libbitcoin no idea, to be honest
172 2012-08-24 09:46:57 <xz> lianj: I have read the paper and a lot of the wiki. Even if _I_ can come to understand what's going on by a lot of hard work (which probably must include reading the reference cilent's source), it would still be good for there to be a complete easy-to-read specification for any future client implementers
173 2012-08-24 09:47:05 <justmoon> sipa: libbitcoin has a reimplementation of the script interpreter and amir did want to add the data-driven tests, that much I know
174 2012-08-24 09:47:38 <sipa> the paper certainly doesn't describe anything operational
175 2012-08-24 09:47:39 <lianj> xz: true, but its not like undoable right now. some have done it
176 2012-08-24 09:47:41 <sipa> just some ideas
177 2012-08-24 09:47:55 <xz> lianj: it's not obvious that they have done anything correctly :P
178 2012-08-24 09:48:05 <justmoon> xz: I'm two minds about that - when it came to implementing bitcoinjs, the wiki was mostly a false friend - what specification there was, was the stuff that later turned out to be buggy
179 2012-08-24 09:48:21 <xz> justmoon: what was the friend? the satoshi source?
180 2012-08-24 09:48:22 <justmoon> the stuff I ported directly from the reference client code is the stuff I've had the least amount of problems with
181 2012-08-24 09:48:33 <lianj> xz: well, write tests with real network data fixtures etc
182 2012-08-24 09:48:54 <justmoon> xz: false friend meaning the wiki information seemed helpful, but had errors which ended up costing me more time than it saved
183 2012-08-24 09:49:23 <sipa> especially in things like the block sync mechanism, i think you can easily get non-working code
184 2012-08-24 09:49:23 <xz> justmoon: I know what you meant. I was asking what was a true friend if the wiki was a false one.
185 2012-08-24 09:49:24 <justmoon> so any specification better be absolutely 100% perfect - and like sipa said that's quite hard
186 2012-08-24 09:49:29 <sipa> it's quite intricate
187 2012-08-24 09:49:37 <xz> lianj: how do you test when you don't know the expected behaviour?
188 2012-08-24 09:49:48 <justmoon> xz: yeah the reference client was a true friend, especially their unit tests
189 2012-08-24 09:49:52 <xz> justmoon: the specification should become normative
190 2012-08-24 09:50:11 <justmoon> in the bitcoin network the majority of miners is normative in a sense
191 2012-08-24 09:50:19 <sipa> depends for what
192 2012-08-24 09:50:24 <justmoon> yeah
193 2012-08-24 09:50:25 <sipa> for some things, every full node is
194 2012-08-24 09:50:31 <sipa> for others, just miners
195 2012-08-24 09:50:43 <justmoon> but I mean you can write a normative specification, but that won't mean much if clients don't behave that way
196 2012-08-24 09:50:55 <xz> is it possible for there to be a parallel independent bitcoin network?
197 2012-08-24 09:50:59 <justmoon> sure
198 2012-08-24 09:51:04 <xz> do they exist?
199 2012-08-24 09:51:10 <sipa> there is a test network
200 2012-08-24 09:51:15 <sipa> there are some forks "altcoins"
201 2012-08-24 09:51:17 <justmoon> there are a few forks also, like litecoin
202 2012-08-24 09:51:52 <sipa> if you write a specification that deviates from how the reference nodes behave in a subtle way, you may end up with a split network at some point
203 2012-08-24 09:51:53 <xz> is there much provision in existing clients for knowing what protocol version they are using and switching to upgraded protocol?
204 2012-08-24 09:52:20 <sipa> xz: not sure what you mean
205 2012-08-24 09:52:21 <xz> "reference node" = node using satoshi client?
206 2012-08-24 09:52:24 <sipa> yes
207 2012-08-24 09:52:39 <xz> what if the majority of nodes one day were not using that client?
208 2012-08-24 09:52:56 <justmoon> that's when things get interesting ^^
209 2012-08-24 09:52:56 <sipa> depends on what kind of change we're talking
210 2012-08-24 09:53:13 <sipa> but in the worst case, it's still a permanent split
211 2012-08-24 09:53:47 <xz> so this is basically a popularity contest, and you bet your coins on being in the network everyone will end up in
212 2012-08-24 09:54:24 <justmoon> yes, like any standard that is a strong incentive for spontaneous agreement
213 2012-08-24 09:54:25 <sipa> in general: there is a permanent split when two code versions disagree about the validity of a block, and the majority of the miners is on the code with weaker rules
214 2012-08-24 09:54:30 <justmoon> there* is
215 2012-08-24 09:54:57 <justmoon> there would be little point in me making a non-compatible client, unless I wanted to create an altcoin
216 2012-08-24 09:55:09 <xz> sipa: you mean the majority of miners say the block is valid?
217 2012-08-24 09:55:41 <sipa> xz: well there will be one specific blocks where the majority of miners agree about, and a minority disagrees
218 2012-08-24 09:55:50 <xz> well I would want to make a client that implements the specification (which currently doesn't exist), and to write the specification so that it is as faithful to the satoshi client as possible without comprimising clarity too much
219 2012-08-24 09:56:04 <sipa> xz: please do
220 2012-08-24 09:56:18 <sipa> but i doubt it's an easy task
221 2012-08-24 09:56:27 <lianj> xz: again, gribbles like are no bad start
222 2012-08-24 09:56:31 <xz> what would be so difficult?
223 2012-08-24 09:56:34 <xz> I mean
224 2012-08-24 09:56:38 <justmoon> I still thing out best bet are more and better test cases, but I certainly applaud anyone willing to take on the task of writing a spec
225 2012-08-24 09:56:42 <justmoon> thnk*
226 2012-08-24 09:56:43 <xz> I agree it's not going to be easy, intuitively
227 2012-08-24 09:56:44 <justmoon> think*
228 2012-08-24 09:56:52 <xz> but what specifically do you think is going to be the hard stuff
229 2012-08-24 09:57:18 <justmoon> openssl's encoding of big integers would have to be part of the standard
230 2012-08-24 09:57:27 <justmoon> it's way of doing big integer math (how it's rounding etc.)
231 2012-08-24 09:57:34 <xz> isn't that already standardised?
232 2012-08-24 09:57:55 <justmoon> well the openssl code specifies it
233 2012-08-24 09:58:12 <sipa> xz: currently, signatures in transactions are encoded in DER, but openssl accepts more than just the DER specification
234 2012-08-24 09:58:13 <justmoon> if you use libgmp, you get different and incompatible behavior
235 2012-08-24 09:58:18 <xz> ssl and tsl are specified, I thought
236 2012-08-24 09:58:26 <sipa> we don't use SSL or TLS
237 2012-08-24 09:58:27 <justmoon> sipa: DER is standardized though
238 2012-08-24 09:58:33 <sipa> justmoon: absolutely
239 2012-08-24 09:58:33 <xz> right ok
240 2012-08-24 09:58:36 <sipa> very strictly
241 2012-08-24 09:58:39 <justmoon> sipa; which is more than you can say about the big integer stuff
242 2012-08-24 09:58:48 <sipa> really?
243 2012-08-24 09:59:05 <sipa> can you give an example of something that differs between implementations?
244 2012-08-24 09:59:10 <sipa> (just curious)
245 2012-08-24 09:59:28 <xz> so the bitcoin spec could just say that you have to use der as already specified
246 2012-08-24 09:59:32 <justmoon> yes, division with negative integers differs between gmp and openssl
247 2012-08-24 09:59:37 <justmoon> one rounds towards zero
248 2012-08-24 09:59:41 <justmoon> the other towards neg infinity
249 2012-08-24 09:59:50 <sipa> but i don't think bitcoin every uses negative integers?
250 2012-08-24 09:59:52 <xz> does bitcoin make necessary use of the extra stuff openssl accepts?
251 2012-08-24 10:00:13 <justmoon> sipa: certainly it does :D
252 2012-08-24 10:00:28 <sipa> justmoon: negative *big* integers
253 2012-08-24 10:00:30 <sipa> where?
254 2012-08-24 10:00:47 <sipa> oh, i suppose inside scripts it's possible to use them
255 2012-08-24 10:00:55 <justmoon> well OP_1 OP_5 OP_SUB for example
256 2012-08-24 10:01:05 <justmoon> OP_5 OP_NEGATE
257 2012-08-24 10:01:10 <xz> supposing more than one person might be interested in a specification (do you think so?), do there exist any good places (e.g. mailing list) to have this discussion and get started on it?
258 2012-08-24 10:01:15 <justmoon> there are demo transactions on testnet
259 2012-08-24 10:01:32 <justmoon> or at least there were on the old testnet
260 2012-08-24 10:01:42 <justmoon> that how I found the bug in the first place
261 2012-08-24 10:01:46 <sipa> testnet3 is "preloaded" with tons of special transactions
262 2012-08-24 10:02:11 <justmoon> yeah, I'm pretty sure there are test cases in the data driven tests too
263 2012-08-24 10:02:15 <justmoon> that would detect this difference
264 2012-08-24 10:02:32 <sipa> xz: there have been some attempts at an "explaining" some parts of the protocol by someone who was quite thorough at it
265 2012-08-24 10:02:54 <sipa> see https://bitcointalk.org/index.php?topic=41718.0
266 2012-08-24 10:03:35 <xz> sipa: thanks that looks quite useful
267 2012-08-24 10:06:25 <xz> is there a high-level overview (perhaps slightly more detailed than the paper) anywhere?
268 2012-08-24 10:07:26 <sipa> overview of what?
269 2012-08-24 10:07:38 <xz> bitcoin protocol and network
270 2012-08-24 10:08:16 <sipa> not really, i think, but you're certainly free to ask questions here
271 2012-08-24 10:08:16 <xz> I feel like there's also room to take the basic cryptocurrency idea and do it better
272 2012-08-24 10:08:41 <xz> (where better basically means good documentation from the start :))
273 2012-08-24 10:09:16 <xz> (which might require changing/simplifying the protocol in some cases)