1 2016-07-24T00:34:25  *** zooko has quit IRC
  2 2016-07-24T00:42:09  *** spudowiar has quit IRC
  3 2016-07-24T00:47:46  *** zooko has joined #bitcoin-core-dev
  4 2016-07-24T01:08:29  *** Giszmo has quit IRC
  5 2016-07-24T01:14:33  *** randy-waterhouse has joined #bitcoin-core-dev
  6 2016-07-24T01:16:28  *** gluytium has joined #bitcoin-core-dev
  7 2016-07-24T01:33:53  <goatpig> is this the right place to ask about some segwit mechanics?
  8 2016-07-24T01:36:23  *** zooko has quit IRC
  9 2016-07-24T01:43:04  <sdaftuar> goatpig: sure
 10 2016-07-24T01:43:48  <goatpig> im mostly concerned about the changes to the transaction format
 11 2016-07-24T01:43:57  <goatpig> does it change anything for outputs?
 12 2016-07-24T01:45:48  *** Ylbam has quit IRC
 13 2016-07-24T01:47:33  <sdaftuar> the serialization of the outputs hasn't changed, just the serialization for transactions with witness have two extra bytes, i believe
 14 2016-07-24T01:48:13  <goatpig> there was nothing about changes in txout format in the bips so i was a bit confused
 15 2016-07-24T01:48:52  <sdaftuar> you're looking at bip144 i assume?
 16 2016-07-24T01:49:05  <goatpig> aside from the commitment in the coinbase scriptpubkey, are wtxids used elsewhere?
 17 2016-07-24T01:49:19  <goatpig> 141 143 and 144
 18 2016-07-24T01:50:24  <sdaftuar> wtxid's are not yet used elsewhere, though we can expect they will be soon.  sipa just proposed an extension to BIP 152 (compact blocks) that would use them
 19 2016-07-24T01:50:27  <sdaftuar> https://github.com/bitcoin/bips/pull/423
 20 2016-07-24T01:51:15  <sdaftuar> there's been some discussion about whether tx relay might be better with wtxid's rather than txid's, but that hasn't been settled yet from what i can tell
 21 2016-07-24T01:51:48  <goatpig> so outputs are still referred to by hash in inputs and the merkle root is still built of off hashes?
 22 2016-07-24T01:52:13  <sdaftuar> yes that's right
 23 2016-07-24T01:52:32  <sdaftuar> (hash == txid)
 24 2016-07-24T01:52:48  <goatpig> right
 25 2016-07-24T01:52:49  <goatpig> so
 26 2016-07-24T01:53:11  <goatpig> how does that reduce maleability attack surface?
 27 2016-07-24T01:53:31  <achow101> signatures aren't hashed because they are in the witness
 28 2016-07-24T01:53:44  <goatpig> oic
 29 2016-07-24T01:53:49  <goatpig> right that makes sense now
 30 2016-07-24T01:54:03  <achow101> but only for segwit output types
 31 2016-07-24T01:54:41  <goatpig> you mean outputs defined by segwit'd inputs?
 32 2016-07-24T01:55:49  <sdaftuar> no, outputs that are defined by being version 0 segwit outputs
 33 2016-07-24T01:56:09  <achow101> these are defined in bip141
 34 2016-07-24T01:56:35  <achow101> p2wpkh, p2wsh, and those can also be nested in a normal p2sh
 35 2016-07-24T01:57:36  <goatpig> you mean the stuff in the example section of bip141?
 36 2016-07-24T01:57:41  <achow101> yes
 37 2016-07-24T01:58:16  <goatpig> those look like signed inputs to me
 38 2016-07-24T01:58:40  <sdaftuar> goatpig: can you explain what you mean?  i don't follow
 39 2016-07-24T01:58:49  <goatpig> you mean the prepended 0 in the scriptPubKey part?
 40 2016-07-24T01:59:26  <goatpig> sdaftuar: my current understanding of segwit is this
 41 2016-07-24T01:59:42  <goatpig> inputs can be segwit enabled, with the proper construct
 42 2016-07-24T01:59:47  <goatpig> nothing changes in outputs at all
 43 2016-07-24T01:59:50  <sdaftuar> ah
 44 2016-07-24T02:00:08  <goatpig> if im wrong, that explains why im confused
 45 2016-07-24T02:00:15  <sdaftuar> no, the right way to think about this is that we've carved out some of the output space to have special semantics
 46 2016-07-24T02:00:28  <goatpig> that's the prepended 0?
 47 2016-07-24T02:00:36  <sdaftuar> yeah that's the OP_0
 48 2016-07-24T02:01:03  <sdaftuar> so a segwit version 0 P2WSH output looks like this: [OP_0, 32-byte-hash]
 49 2016-07-24T02:01:03  <goatpig> ok so you have to first use a non segwit input redemption to create a segwit enabled output
 50 2016-07-24T02:01:09  <goatpig> then you can segwit input redeem it?
 51 2016-07-24T02:01:10  <sdaftuar> yes, that's right
 52 2016-07-24T02:01:14  <achow101> yes
 53 2016-07-24T02:01:15  <goatpig> ok now it makes sense
 54 2016-07-24T02:01:18  <goatpig> thanks =)
 55 2016-07-24T02:01:33  <sdaftuar> sure!
 56 2016-07-24T02:02:46  <goatpig> achow101: so if the wtxid isn't used anywhere but in the coinbase commitment, what where you using that for?
 57 2016-07-24T02:03:08  <goatpig> armory doesn't implement much of the concensus layer, certainly something that deep
 58 2016-07-24T02:03:29  <achow101> It isn't used at all.
 59 2016-07-24T02:03:55  <achow101> I had to change that hashing stuff to hash the transaction with segwit stuff stripped out
 60 2016-07-24T02:04:15  <goatpig> oh i case of raw block data with the witness data appended?
 61 2016-07-24T02:04:22  <achow101> yes
 62 2016-07-24T02:04:30  <goatpig> ok makes sense
 63 2016-07-24T02:06:59  <goatpig> so in regard to the p2p layer, transcations with witness are inv'd by wtxid right?
 64 2016-07-24T02:07:34  <achow101> no, by normal txid
 65 2016-07-24T02:08:26  <achow101> there is an inv type to get the transaction with witness serialization
 66 2016-07-24T02:08:36  <goatpig> getdata type you mean?
 67 2016-07-24T02:08:57  <achow101> yes
 68 2016-07-24T02:09:06  <goatpig> is there any reason to use anything but MSG_WITNESS_TX in getdata packets instead of MSG_TX?
 69 2016-07-24T02:09:37  <goatpig> i guess besides backwards compatibility with older nodes
 70 2016-07-24T02:09:55  <achow101> ^that
 71 2016-07-24T02:10:02  <goatpig> ok so a non issue for armory then
 72 2016-07-24T02:10:36  <goatpig> aight guys, thanks for the help
 73 2016-07-24T02:17:44  <NicolasDorier> I have am synching a node (from currrent master) from another single localhost node. At around 320 000 it takes several second per block (around 5 seconds) my CPU is not speaking, nor disk access, nor memory access.
 74 2016-07-24T02:17:58  <NicolasDorier> any idea of something obvious I could have forgot ?
 75 2016-07-24T02:20:32  *** YOU-JI has quit IRC
 76 2016-07-24T02:21:32  <goatpig> anyone here familiar with the BIP151 discussion?
 77 2016-07-24T02:21:48  <goatpig> any reason ChaCha20-Poly1305 was picked over AES-GCM?
 78 2016-07-24T02:26:11  <NicolasDorier> https://www.irccloud.com/pastebin/at6M00hU/
 79 2016-07-24T02:26:25  <NicolasDorier> holy cow Connect transactions takes 70s
 80 2016-07-24T02:28:41  <NicolasDorier> ah no 32s... still...
 81 2016-07-24T02:31:06  <NicolasDorier> ok... did not sleep well 1000ms = 1s. Nevermind what I said.
 82 2016-07-24T02:50:36  <GitHub73> [bitcoin] cqtenq opened pull request #8396: remove outdated legacy code (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8396
 83 2016-07-24T03:03:29  *** moli has quit IRC
 84 2016-07-24T03:14:10  *** moli has joined #bitcoin-core-dev
 85 2016-07-24T03:41:31  *** goatpig has quit IRC
 86 2016-07-24T03:42:03  *** challisto has quit IRC
 87 2016-07-24T03:51:34  *** justanotheruser has quit IRC
 88 2016-07-24T04:09:24  <NicolasDorier> my connect block takes really long, I'm not sure it is normal. Some blocks take more than 15s... I never benchmarked before, is it normal ?
 89 2016-07-24T04:46:52  *** sanada has quit IRC
 90 2016-07-24T04:58:08  *** justanotheruser has joined #bitcoin-core-dev
 91 2016-07-24T05:08:23  <wumpus> NicolasDorier: what kind of CPU/disk?
 92 2016-07-24T05:11:25  *** kadoban has quit IRC
 93 2016-07-24T05:18:23  <btcdrak> goatpig: iirc, because SSH uses it. ping jonasschnelli
 94 2016-07-24T05:36:04  <NicolasDorier> wumpus: 2 core 2.20Ghz, 3.5 RAM. Neither are capped
 95 2016-07-24T05:36:24  <NicolasDorier> Basically an A2 on azure (https://azure.microsoft.com/en-gb/pricing/details/virtual-machines/)
 96 2016-07-24T05:37:36  <wumpus> usually the cause of really slow connect times, when CPU is not at 100%, is i/o bottleneck
 97 2016-07-24T05:53:24  <NicolasDorier> wumpus:
 98 2016-07-24T05:53:27  <NicolasDorier> https://usercontent.irccloud-cdn.com/file/UeL6uFo1/
 99 2016-07-24T05:53:35  <NicolasDorier> it seems kind of strange
100 2016-07-24T05:53:46  <NicolasDorier> one sec I check io
101 2016-07-24T05:54:57  <NicolasDorier> https://usercontent.irccloud-cdn.com/file/glkQVh8o/
102 2016-07-24T05:54:59  <NicolasDorier> mmh
103 2016-07-24T05:55:04  <wumpus> I've also noticed really slow i/o on windows, but assumed it was just the slow laptop
104 2016-07-24T05:55:05  <NicolasDorier> may me that...
105 2016-07-24T05:55:15  <NicolasDorier> well on my side it can be worse because
106 2016-07-24T05:55:19  <NicolasDorier> it is a VM on azure
107 2016-07-24T05:55:41  <wumpus> right
108 2016-07-24T06:53:23  *** sanada has joined #bitcoin-core-dev
109 2016-07-24T06:54:33  *** pmienk has joined #bitcoin-core-dev
110 2016-07-24T07:48:35  <jonasschnelli> [09:47:47]  <goatpig>	[04:21:48] any reason ChaCha20-Poly1305 was picked over AES-GCM?
111 2016-07-24T07:48:45  <jonasschnelli> ChaCha20-Poly1305 is also faster
112 2016-07-24T07:50:17  *** murch has joined #bitcoin-core-dev
113 2016-07-24T07:52:33  *** Guyver2 has joined #bitcoin-core-dev
114 2016-07-24T08:15:13  <gmaxwell> The recommendation sipa and I made is because it is considerably faster on anything without hardware AES.
115 2016-07-24T08:15:43  <gmaxwell> And the devices with hardware AES it is only slightly slower, and those devices we largely don't care about how fast it is (as they're faster hardware)
116 2016-07-24T08:16:30  <gmaxwell> helpfully it also requires very little code for a good implementation. The same can't really be said for AES-GCM.
117 2016-07-24T08:30:22  <adiabat> also stream cipher beats block cipher any day of the week (imho)
118 2016-07-24T08:31:08  <gmaxwell> both are stream ciphers.
119 2016-07-24T08:31:29  <adiabat> well, AES isn't... GCM sortof makes it into one
120 2016-07-24T08:32:24  <gmaxwell> There is no sort of, there. And what was being discussed was AES-GCM not AES-CBC or otherwise.
121 2016-07-24T08:33:34  <gmaxwell> it is unambigiously a stream cipher. Which is an appropritate tool here even though stream ciphers have a long and well established history of resulting, in practice, in insecure protocols usually because of the fragility of IV handling, and how often developers mishandle them.
122 2016-07-24T08:33:39  <adiabat> maybe linked to the "very little code", I think using a counter mode to make a stream cipher is more complex than starting with one
123 2016-07-24T08:36:17  <gmaxwell> much of the code complexity for AES-GCM comes from sidechannel resistance for AES being hard, especially if performance must be maintained. chach20 (which is _also_ a block cipher in CTR mode internally) is unusually simple however.
124 2016-07-24T08:38:18  <adiabat> I mean, I understand that the code is what matters but if you look up "AES", people call it a block cipher, and "chacha20", people call a stream cipher
125 2016-07-24T08:38:56  <adiabat> I guess chacha20 is more specified than aes, which has a plethora of modes
126 2016-07-24T08:40:19  <adiabat> You can certainly shoot yourself in the foot with any of them though
127 2016-07-24T09:02:36  <sipa> adiabat: chacha20 is internally also a block transformation, which is being used in counter mode
128 2016-07-24T09:10:32  <sipa> except there is no standardization for the pure transformation
129 2016-07-24T09:11:14  <sipa> NicolasDorier: what is your db cache?
130 2016-07-24T09:11:46  <NicolasDorier> kept default
131 2016-07-24T09:12:52  <NicolasDorier> good idea, trying to change it to see how it goes
132 2016-07-24T09:16:21  <sipa> it helps massively on systems with slow io
133 2016-07-24T09:17:03  <NicolasDorier> just changed to 1024 to see how it goes
134 2016-07-24T09:26:44  <NicolasDorier> does not seems to improve it that much... It may come from some kind of IO threshold I may be hitting on Azure. If nobody experience that it's fine
135 2016-07-24T09:27:18  <NicolasDorier> this is highly possible, as I have several bitcoind instance as well as an indexer for my blockexplorer on the same machine
136 2016-07-24T09:33:44  <sipa> are you hitting swap space?
137 2016-07-24T09:35:56  <NicolasDorier> sipa: nop
138 2016-07-24T09:36:00  <NicolasDorier> https://usercontent.irccloud-cdn.com/file/oZYm8TtW/
139 2016-07-24T09:36:05  <NicolasDorier> my ram seems fine
140 2016-07-24T09:36:09  <NicolasDorier> and cpu as well
141 2016-07-24T09:36:38  <NicolasDorier> I'll try on a brand new VM later, I think it is just some IO threshold of azure
142 2016-07-24T09:38:21  <NicolasDorier> or try to just update the disk to be SSD on the vm, on a separate azure storage account (the threshold "domain"). I think we can disregard my machine for now, if nobody experience such slowness it is probably my VM's fault
143 2016-07-24T09:39:09  <sipa> are these recent blocks?
144 2016-07-24T09:39:18  <sipa> or during initial sync?
145 2016-07-24T09:39:28  <NicolasDorier> initial sync
146 2016-07-24T09:39:34  <sipa> can you run eith -debug=bench ?
147 2016-07-24T09:39:44  <NicolasDorier> it is what I did, look the screenshot I sent
148 2016-07-24T09:39:50  <sipa> oops missed that
149 2016-07-24T09:40:07  <NicolasDorier> https://usercontent.irccloud-cdn.com/file/oZYm8TtW/
150 2016-07-24T09:41:00  <sipa> ok, it's spending really all the time fetching inputs
151 2016-07-24T09:41:36  <NicolasDorier> "connect transactions" mean fetching the inputs ?
152 2016-07-24T09:41:42  <sipa> yes
153 2016-07-24T09:42:24  <sipa> well, it does more than that
154 2016-07-24T09:42:39  <sipa> but fetching inouts is the only slow part
155 2016-07-24T09:43:17  <NicolasDorier> ok yeah so no worry. I'll try with better hard drive and separate on another azure storage account and see if it is better later
156 2016-07-24T10:18:55  *** Ginnarr has joined #bitcoin-core-dev
157 2016-07-24T10:27:08  *** Giszmo has joined #bitcoin-core-dev
158 2016-07-24T10:27:11  <GitHub192> [bitcoin] asteroidsbg opened pull request #8397: 0.13 (master...0.13) https://github.com/bitcoin/bitcoin/pull/8397
159 2016-07-24T10:40:01  <GitHub81> [bitcoin] jonasschnelli closed pull request #8397: 0.13 (master...0.13) https://github.com/bitcoin/bitcoin/pull/8397
160 2016-07-24T10:49:29  *** ArthurNumbanumba has joined #bitcoin-core-dev
161 2016-07-24T11:10:59  *** Ginnarr has quit IRC
162 2016-07-24T11:18:25  *** challisto has joined #bitcoin-core-dev
163 2016-07-24T12:03:30  *** JackH has joined #bitcoin-core-dev
164 2016-07-24T12:12:16  *** randy-waterhouse has quit IRC
165 2016-07-24T12:18:34  *** shesek has quit IRC
166 2016-07-24T12:32:52  *** goatpig has joined #bitcoin-core-dev
167 2016-07-24T12:39:06  <goatpig> gmaxwell: adiabat: so to summarize, ChaCha20-Poly1305 has a simpler implementation (less chance of mishandling) and is faster on desktop CPUs.
168 2016-07-24T12:39:25  <goatpig> is there a stand alone implementation of that cypher or does one have to go to OpenSSL?
169 2016-07-24T12:40:05  <goatpig> also I see in BIP151 that it allows for negotiating the cypher, so will it support AES-GCM too?
170 2016-07-24T12:48:53  *** jtimon has quit IRC
171 2016-07-24T12:49:04  *** jtimon has joined #bitcoin-core-dev
172 2016-07-24T13:00:03  *** jtimon has quit IRC
173 2016-07-24T13:17:54  *** murch has quit IRC
174 2016-07-24T13:21:04  *** shesek has joined #bitcoin-core-dev
175 2016-07-24T13:30:27  *** cjcj has joined #bitcoin-core-dev
176 2016-07-24T13:33:14  *** TomMc has joined #bitcoin-core-dev
177 2016-07-24T13:34:31  *** laurentmt has joined #bitcoin-core-dev
178 2016-07-24T13:36:07  *** laurentmt has quit IRC
179 2016-07-24T14:04:29  *** Ylbam has joined #bitcoin-core-dev
180 2016-07-24T14:22:12  *** pmienk has quit IRC
181 2016-07-24T14:27:09  <NicolasDorier> There is a refactoring I am thinking about as part as libconsenus work: Instead of calling UTXOs database directly in the consensus code lazily as we need them, aggressively fetching them before calling consensus functions. This would also mean we can parallelize previous coin fetching more easily.
182 2016-07-24T14:27:27  <NicolasDorier> *lazily as we need the previous coins
183 2016-07-24T14:27:57  <NicolasDorier> might make the Connect Transaction quicker
184 2016-07-24T14:36:46  *** pmienk has joined #bitcoin-core-dev
185 2016-07-24T14:45:46  *** TomMc has quit IRC
186 2016-07-24T15:17:58  *** Giszmo has quit IRC
187 2016-07-24T15:19:20  *** Giszmo has joined #bitcoin-core-dev
188 2016-07-24T15:33:30  *** laurentmt has joined #bitcoin-core-dev
189 2016-07-24T15:46:25  *** aalex has quit IRC
190 2016-07-24T15:47:08  <goatpig> can someone answer some more SW related questions?
191 2016-07-24T15:47:18  *** ko543 has joined #bitcoin-core-dev
192 2016-07-24T15:49:29  <sipa> NicolasDorier: that's actually what happens
193 2016-07-24T15:49:41  <sipa> NicolasDorier: haveinputs gets called first
194 2016-07-24T15:49:50  <sipa> which loads everything in the cache
195 2016-07-24T15:50:17  <NicolasDorier> oooh so that's what the dbcache is about ?
196 2016-07-24T15:50:23  *** aalex has joined #bitcoin-core-dev
197 2016-07-24T15:50:49  <NicolasDorier> I thought the dbcache was just about keeping recent output in cache as they have higher chance to get used later
198 2016-07-24T15:51:31  *** laurentmt has quit IRC
199 2016-07-24T15:58:28  <sipa> there are several layers of cache :)
200 2016-07-24T16:05:34  *** ko543 has quit IRC
201 2016-07-24T16:22:31  <sipa> NicolasDorier: there is pcoinsTip
202 2016-07-24T16:23:06  <sipa> but there is also a second cache in ConnectBlock, which fetches the inputs, does validation, applies the changes to the utxo set to thid 2nd cache
203 2016-07-24T16:23:23  <sipa> and when validation succeeds, the changes in the 2nd cache are pushed to pcoinsTip
204 2016-07-24T16:23:40  <sipa> if validatiin fails, the changes in the second cache are discarded
205 2016-07-24T16:35:24  *** murch has joined #bitcoin-core-dev
206 2016-07-24T17:05:26  *** AaronvanW has joined #bitcoin-core-dev
207 2016-07-24T17:05:26  *** AaronvanW has joined #bitcoin-core-dev
208 2016-07-24T17:20:21  *** spudowiar has joined #bitcoin-core-dev
209 2016-07-24T18:38:17  *** spudowiar has quit IRC
210 2016-07-24T18:47:29  *** zooko has joined #bitcoin-core-dev
211 2016-07-24T19:11:01  *** aalex has quit IRC
212 2016-07-24T19:15:30  *** aalex has joined #bitcoin-core-dev
213 2016-07-24T19:19:03  *** arubi has quit IRC
214 2016-07-24T19:23:35  *** arubi has joined #bitcoin-core-dev
215 2016-07-24T19:53:19  *** kadoban has joined #bitcoin-core-dev
216 2016-07-24T19:53:35  *** adiabat has quit IRC
217 2016-07-24T20:35:30  *** Cheeseo has joined #bitcoin-core-dev
218 2016-07-24T20:36:06  *** zooko has quit IRC
219 2016-07-24T20:48:54  *** murch has quit IRC
220 2016-07-24T21:01:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
221 2016-07-24T21:28:40  *** a87ry5 has joined #bitcoin-core-dev
222 2016-07-24T21:49:42  *** d_t has joined #bitcoin-core-dev
223 2016-07-24T21:57:35  <gmaxwell> ::sigh:: cookie auth picks passwords which are apparer to be incompatible with the python json rpc stuff. (apparently it can't handle passwords with / in them)
224 2016-07-24T22:00:57  <sipa> file an issue
225 2016-07-24T22:01:12  <sipa> this sounds like a simple introduction task
226 2016-07-24T22:02:21  <gmaxwell> I think the bug is in some python URL lib, though for the code that provided recommended rpcpasswords in the past I used base58 in order to avoid any characters that would get mishandled in URLs.
227 2016-07-24T22:04:57  <sipa> we need base66 code
228 2016-07-24T22:05:43  <sipa> there are 66 url-safe characters (a-z, A-Z, 0-9, _, -, ., ~)
229 2016-07-24T22:07:26  <gmaxwell> https://github.com/bitcoin/bitcoin/issues/8399
230 2016-07-24T22:07:39  <gmaxwell> base58 is fine.
231 2016-07-24T22:15:45  <sipa> but but but 3.18% less space efficient for the same information density
232 2016-07-24T22:22:47  *** d_t has quit IRC
233 2016-07-24T22:25:23  *** d_t has joined #bitcoin-core-dev
234 2016-07-24T22:28:21  *** justanotheruser has quit IRC
235 2016-07-24T22:28:33  *** justanot1eruser has joined #bitcoin-core-dev
236 2016-07-24T22:28:56  *** d_t has quit IRC
237 2016-07-24T22:35:48  *** aalex has quit IRC
238 2016-07-24T22:37:04  *** Guyver2 has quit IRC
239 2016-07-24T22:38:33  <GitHub87> [bitcoin] yurizhykin opened pull request #8400: [qa]: enable rpcbind_test (master...rpcbind-test) https://github.com/bitcoin/bitcoin/pull/8400
240 2016-07-24T22:39:49  <gmaxwell> sipa: who cares. :P
241 2016-07-24T22:40:23  *** aalex has joined #bitcoin-core-dev
242 2016-07-24T22:46:31  *** justanot1eruser is now known as justanotheruser
243 2016-07-24T22:46:45  *** Cheeseo has quit IRC
244 2016-07-24T23:05:58  *** AaronvanW has quit IRC
245 2016-07-24T23:12:36  <Chris_Stewart_5> When checking signatures for a SIGHASH_ALL, do you remove all inputs AFTER the input index you are checking?
246 2016-07-24T23:16:04  *** challisto has quit IRC
247 2016-07-24T23:17:58  <sipa> check the code :)
248 2016-07-24T23:18:03  <sipa> there are two versiond
249 2016-07-24T23:18:27  <sipa> one in script/interpreter, one in test/sighash_testz
250 2016-07-24T23:27:17  *** spudowiar has joined #bitcoin-core-dev
251 2016-07-24T23:28:14  *** Cheeseo has joined #bitcoin-core-dev
252 2016-07-24T23:28:14  *** Cheeseo has joined #bitcoin-core-dev
253 2016-07-24T23:36:12  *** Chris_Stewart_5 has quit IRC
254 2016-07-24T23:40:05  *** Chris_Stewart_5 has joined #bitcoin-core-dev
255 2016-07-24T23:40:43  <Chris_Stewart_5> sipa: Does it make sense to have a correct r value when creating a digital signature but an incorrect s value (and that is not related to low-s)?
256 2016-07-24T23:41:05  *** jiggalator has joined #bitcoin-core-dev
257 2016-07-24T23:42:01  *** jiggalator is now known as netsin_
258 2016-07-24T23:48:32  *** netsin_ has quit IRC
259 2016-07-24T23:50:06  *** Chris_Stewart_5 has quit IRC
260 2016-07-24T23:50:26  *** Chris_Stewart_5 has joined #bitcoin-core-dev
261 2016-07-24T23:50:42  *** Giszmo has quit IRC
262 2016-07-24T23:51:35  <sipa> Chris_Stewart_5: make sense for whatm
263 2016-07-24T23:52:14  <sipa> every value for r can be correct
264 2016-07-24T23:52:20  <Chris_Stewart_5> hmm yeah, I guess I don't know really what I am trying to say. It seems strange that only one of the values would be incorrect on a signature and not both of them
265 2016-07-24T23:52:43  <sipa> you can't individually judge them
266 2016-07-24T23:52:45  <Chris_Stewart_5> when trying to recreate a digital signature from bitcoin core
267 2016-07-24T23:53:00  <sipa> your r is right but the s is not?
268 2016-07-24T23:53:03  <Chris_Stewart_5> yes
269 2016-07-24T23:53:20  <Chris_Stewart_5> and it is not due to low-s, i've made to sure to check that
270 2016-07-24T23:53:35  <sipa> can you paste the signature?
271 2016-07-24T23:53:55  <Chris_Stewart_5> sure, i'll paste the correct one the one i have generated
272 2016-07-24T23:58:59  <Chris_Stewart_5> http://pastebin.com/L9veUyXV