12016-07-24T00:34:25  *** zooko has quit IRC
  22016-07-24T00:42:09  *** spudowiar has quit IRC
  32016-07-24T00:47:46  *** zooko has joined #bitcoin-core-dev
  42016-07-24T01:08:29  *** Giszmo has quit IRC
  52016-07-24T01:14:33  *** randy-waterhouse has joined #bitcoin-core-dev
  62016-07-24T01:16:28  *** gluytium has joined #bitcoin-core-dev
  72016-07-24T01:33:53  <goatpig> is this the right place to ask about some segwit mechanics?
  82016-07-24T01:36:23  *** zooko has quit IRC
  92016-07-24T01:43:04  <sdaftuar> goatpig: sure
 102016-07-24T01:43:48  <goatpig> im mostly concerned about the changes to the transaction format
 112016-07-24T01:43:57  <goatpig> does it change anything for outputs?
 122016-07-24T01:45:48  *** Ylbam has quit IRC
 132016-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
 142016-07-24T01:48:13  <goatpig> there was nothing about changes in txout format in the bips so i was a bit confused
 152016-07-24T01:48:52  <sdaftuar> you're looking at bip144 i assume?
 162016-07-24T01:49:05  <goatpig> aside from the commitment in the coinbase scriptpubkey, are wtxids used elsewhere?
 172016-07-24T01:49:19  <goatpig> 141 143 and 144
 182016-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
 192016-07-24T01:50:27  <sdaftuar> https://github.com/bitcoin/bips/pull/423
 202016-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
 212016-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?
 222016-07-24T01:52:13  <sdaftuar> yes that's right
 232016-07-24T01:52:32  <sdaftuar> (hash == txid)
 242016-07-24T01:52:48  <goatpig> right
 252016-07-24T01:52:49  <goatpig> so
 262016-07-24T01:53:11  <goatpig> how does that reduce maleability attack surface?
 272016-07-24T01:53:31  <achow101> signatures aren't hashed because they are in the witness
 282016-07-24T01:53:44  <goatpig> oic
 292016-07-24T01:53:49  <goatpig> right that makes sense now
 302016-07-24T01:54:03  <achow101> but only for segwit output types
 312016-07-24T01:54:41  <goatpig> you mean outputs defined by segwit'd inputs?
 322016-07-24T01:55:49  <sdaftuar> no, outputs that are defined by being version 0 segwit outputs
 332016-07-24T01:56:09  <achow101> these are defined in bip141
 342016-07-24T01:56:35  <achow101> p2wpkh, p2wsh, and those can also be nested in a normal p2sh
 352016-07-24T01:57:36  <goatpig> you mean the stuff in the example section of bip141?
 362016-07-24T01:57:41  <achow101> yes
 372016-07-24T01:58:16  <goatpig> those look like signed inputs to me
 382016-07-24T01:58:40  <sdaftuar> goatpig: can you explain what you mean?  i don't follow
 392016-07-24T01:58:49  <goatpig> you mean the prepended 0 in the scriptPubKey part?
 402016-07-24T01:59:26  <goatpig> sdaftuar: my current understanding of segwit is this
 412016-07-24T01:59:42  <goatpig> inputs can be segwit enabled, with the proper construct
 422016-07-24T01:59:47  <goatpig> nothing changes in outputs at all
 432016-07-24T01:59:50  <sdaftuar> ah
 442016-07-24T02:00:08  <goatpig> if im wrong, that explains why im confused
 452016-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
 462016-07-24T02:00:28  <goatpig> that's the prepended 0?
 472016-07-24T02:00:36  <sdaftuar> yeah that's the OP_0
 482016-07-24T02:01:03  <sdaftuar> so a segwit version 0 P2WSH output looks like this: [OP_0, 32-byte-hash]
 492016-07-24T02:01:03  <goatpig> ok so you have to first use a non segwit input redemption to create a segwit enabled output
 502016-07-24T02:01:09  <goatpig> then you can segwit input redeem it?
 512016-07-24T02:01:10  <sdaftuar> yes, that's right
 522016-07-24T02:01:14  <achow101> yes
 532016-07-24T02:01:15  <goatpig> ok now it makes sense
 542016-07-24T02:01:18  <goatpig> thanks =)
 552016-07-24T02:01:33  <sdaftuar> sure!
 562016-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?
 572016-07-24T02:03:08  <goatpig> armory doesn't implement much of the concensus layer, certainly something that deep
 582016-07-24T02:03:29  <achow101> It isn't used at all.
 592016-07-24T02:03:55  <achow101> I had to change that hashing stuff to hash the transaction with segwit stuff stripped out
 602016-07-24T02:04:15  <goatpig> oh i case of raw block data with the witness data appended?
 612016-07-24T02:04:22  <achow101> yes
 622016-07-24T02:04:30  <goatpig> ok makes sense
 632016-07-24T02:06:59  <goatpig> so in regard to the p2p layer, transcations with witness are inv'd by wtxid right?
 642016-07-24T02:07:34  <achow101> no, by normal txid
 652016-07-24T02:08:26  <achow101> there is an inv type to get the transaction with witness serialization
 662016-07-24T02:08:36  <goatpig> getdata type you mean?
 672016-07-24T02:08:57  <achow101> yes
 682016-07-24T02:09:06  <goatpig> is there any reason to use anything but MSG_WITNESS_TX in getdata packets instead of MSG_TX?
 692016-07-24T02:09:37  <goatpig> i guess besides backwards compatibility with older nodes
 702016-07-24T02:09:55  <achow101> ^that
 712016-07-24T02:10:02  <goatpig> ok so a non issue for armory then
 722016-07-24T02:10:36  <goatpig> aight guys, thanks for the help
 732016-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.
 742016-07-24T02:17:58  <NicolasDorier> any idea of something obvious I could have forgot ?
 752016-07-24T02:20:32  *** YOU-JI has quit IRC
 762016-07-24T02:21:32  <goatpig> anyone here familiar with the BIP151 discussion?
 772016-07-24T02:21:48  <goatpig> any reason ChaCha20-Poly1305 was picked over AES-GCM?
 782016-07-24T02:26:11  <NicolasDorier> https://www.irccloud.com/pastebin/at6M00hU/
 792016-07-24T02:26:25  <NicolasDorier> holy cow Connect transactions takes 70s
 802016-07-24T02:28:41  <NicolasDorier> ah no 32s... still...
 812016-07-24T02:31:06  <NicolasDorier> ok... did not sleep well 1000ms = 1s. Nevermind what I said.
 822016-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
 832016-07-24T03:03:29  *** moli has quit IRC
 842016-07-24T03:14:10  *** moli has joined #bitcoin-core-dev
 852016-07-24T03:41:31  *** goatpig has quit IRC
 862016-07-24T03:42:03  *** challisto has quit IRC
 872016-07-24T03:51:34  *** justanotheruser has quit IRC
 882016-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 ?
 892016-07-24T04:46:52  *** sanada has quit IRC
 902016-07-24T04:58:08  *** justanotheruser has joined #bitcoin-core-dev
 912016-07-24T05:08:23  <wumpus> NicolasDorier: what kind of CPU/disk?
 922016-07-24T05:11:25  *** kadoban has quit IRC
 932016-07-24T05:18:23  <btcdrak> goatpig: iirc, because SSH uses it. ping jonasschnelli
 942016-07-24T05:36:04  <NicolasDorier> wumpus: 2 core 2.20Ghz, 3.5 RAM. Neither are capped
 952016-07-24T05:36:24  <NicolasDorier> Basically an A2 on azure (https://azure.microsoft.com/en-gb/pricing/details/virtual-machines/)
 962016-07-24T05:37:36  <wumpus> usually the cause of really slow connect times, when CPU is not at 100%, is i/o bottleneck
 972016-07-24T05:53:24  <NicolasDorier> wumpus:
 982016-07-24T05:53:27  <NicolasDorier> https://usercontent.irccloud-cdn.com/file/UeL6uFo1/
 992016-07-24T05:53:35  <NicolasDorier> it seems kind of strange
1002016-07-24T05:53:46  <NicolasDorier> one sec I check io
1012016-07-24T05:54:57  <NicolasDorier> https://usercontent.irccloud-cdn.com/file/glkQVh8o/
1022016-07-24T05:54:59  <NicolasDorier> mmh
1032016-07-24T05:55:04  <wumpus> I've also noticed really slow i/o on windows, but assumed it was just the slow laptop
1042016-07-24T05:55:05  <NicolasDorier> may me that...
1052016-07-24T05:55:15  <NicolasDorier> well on my side it can be worse because
1062016-07-24T05:55:19  <NicolasDorier> it is a VM on azure
1072016-07-24T05:55:41  <wumpus> right
1082016-07-24T06:53:23  *** sanada has joined #bitcoin-core-dev
1092016-07-24T06:54:33  *** pmienk has joined #bitcoin-core-dev
1102016-07-24T07:48:35  <jonasschnelli> [09:47:47]  <goatpig>	[04:21:48] any reason ChaCha20-Poly1305 was picked over AES-GCM?
1112016-07-24T07:48:45  <jonasschnelli> ChaCha20-Poly1305 is also faster
1122016-07-24T07:50:17  *** murch has joined #bitcoin-core-dev
1132016-07-24T07:52:33  *** Guyver2 has joined #bitcoin-core-dev
1142016-07-24T08:15:13  <gmaxwell> The recommendation sipa and I made is because it is considerably faster on anything without hardware AES.
1152016-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)
1162016-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.
1172016-07-24T08:30:22  <adiabat> also stream cipher beats block cipher any day of the week (imho)
1182016-07-24T08:31:08  <gmaxwell> both are stream ciphers.
1192016-07-24T08:31:29  <adiabat> well, AES isn't... GCM sortof makes it into one
1202016-07-24T08:32:24  <gmaxwell> There is no sort of, there. And what was being discussed was AES-GCM not AES-CBC or otherwise.
1212016-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.
1222016-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
1232016-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.
1242016-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
1252016-07-24T08:38:56  <adiabat> I guess chacha20 is more specified than aes, which has a plethora of modes
1262016-07-24T08:40:19  <adiabat> You can certainly shoot yourself in the foot with any of them though
1272016-07-24T09:02:36  <sipa> adiabat: chacha20 is internally also a block transformation, which is being used in counter mode
1282016-07-24T09:10:32  <sipa> except there is no standardization for the pure transformation
1292016-07-24T09:11:14  <sipa> NicolasDorier: what is your db cache?
1302016-07-24T09:11:46  <NicolasDorier> kept default
1312016-07-24T09:12:52  <NicolasDorier> good idea, trying to change it to see how it goes
1322016-07-24T09:16:21  <sipa> it helps massively on systems with slow io
1332016-07-24T09:17:03  <NicolasDorier> just changed to 1024 to see how it goes
1342016-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
1352016-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
1362016-07-24T09:33:44  <sipa> are you hitting swap space?
1372016-07-24T09:35:56  <NicolasDorier> sipa: nop
1382016-07-24T09:36:00  <NicolasDorier> https://usercontent.irccloud-cdn.com/file/oZYm8TtW/
1392016-07-24T09:36:05  <NicolasDorier> my ram seems fine
1402016-07-24T09:36:09  <NicolasDorier> and cpu as well
1412016-07-24T09:36:38  <NicolasDorier> I'll try on a brand new VM later, I think it is just some IO threshold of azure
1422016-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
1432016-07-24T09:39:09  <sipa> are these recent blocks?
1442016-07-24T09:39:18  <sipa> or during initial sync?
1452016-07-24T09:39:28  <NicolasDorier> initial sync
1462016-07-24T09:39:34  <sipa> can you run eith -debug=bench ?
1472016-07-24T09:39:44  <NicolasDorier> it is what I did, look the screenshot I sent
1482016-07-24T09:39:50  <sipa> oops missed that
1492016-07-24T09:40:07  <NicolasDorier> https://usercontent.irccloud-cdn.com/file/oZYm8TtW/
1502016-07-24T09:41:00  <sipa> ok, it's spending really all the time fetching inputs
1512016-07-24T09:41:36  <NicolasDorier> "connect transactions" mean fetching the inputs ?
1522016-07-24T09:41:42  <sipa> yes
1532016-07-24T09:42:24  <sipa> well, it does more than that
1542016-07-24T09:42:39  <sipa> but fetching inouts is the only slow part
1552016-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
1562016-07-24T10:18:55  *** Ginnarr has joined #bitcoin-core-dev
1572016-07-24T10:27:08  *** Giszmo has joined #bitcoin-core-dev
1582016-07-24T10:27:11  <GitHub192> [bitcoin] asteroidsbg opened pull request #8397: 0.13 (master...0.13) https://github.com/bitcoin/bitcoin/pull/8397
1592016-07-24T10:40:01  <GitHub81> [bitcoin] jonasschnelli closed pull request #8397: 0.13 (master...0.13) https://github.com/bitcoin/bitcoin/pull/8397
1602016-07-24T10:49:29  *** ArthurNumbanumba has joined #bitcoin-core-dev
1612016-07-24T11:10:59  *** Ginnarr has quit IRC
1622016-07-24T11:18:25  *** challisto has joined #bitcoin-core-dev
1632016-07-24T12:03:30  *** JackH has joined #bitcoin-core-dev
1642016-07-24T12:12:16  *** randy-waterhouse has quit IRC
1652016-07-24T12:18:34  *** shesek has quit IRC
1662016-07-24T12:32:52  *** goatpig has joined #bitcoin-core-dev
1672016-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.
1682016-07-24T12:39:25  <goatpig> is there a stand alone implementation of that cypher or does one have to go to OpenSSL?
1692016-07-24T12:40:05  <goatpig> also I see in BIP151 that it allows for negotiating the cypher, so will it support AES-GCM too?
1702016-07-24T12:48:53  *** jtimon has quit IRC
1712016-07-24T12:49:04  *** jtimon has joined #bitcoin-core-dev
1722016-07-24T13:00:03  *** jtimon has quit IRC
1732016-07-24T13:17:54  *** murch has quit IRC
1742016-07-24T13:21:04  *** shesek has joined #bitcoin-core-dev
1752016-07-24T13:30:27  *** cjcj has joined #bitcoin-core-dev
1762016-07-24T13:33:14  *** TomMc has joined #bitcoin-core-dev
1772016-07-24T13:34:31  *** laurentmt has joined #bitcoin-core-dev
1782016-07-24T13:36:07  *** laurentmt has quit IRC
1792016-07-24T14:04:29  *** Ylbam has joined #bitcoin-core-dev
1802016-07-24T14:22:12  *** pmienk has quit IRC
1812016-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.
1822016-07-24T14:27:27  <NicolasDorier> *lazily as we need the previous coins
1832016-07-24T14:27:57  <NicolasDorier> might make the Connect Transaction quicker
1842016-07-24T14:36:46  *** pmienk has joined #bitcoin-core-dev
1852016-07-24T14:45:46  *** TomMc has quit IRC
1862016-07-24T15:17:58  *** Giszmo has quit IRC
1872016-07-24T15:19:20  *** Giszmo has joined #bitcoin-core-dev
1882016-07-24T15:33:30  *** laurentmt has joined #bitcoin-core-dev
1892016-07-24T15:46:25  *** aalex has quit IRC
1902016-07-24T15:47:08  <goatpig> can someone answer some more SW related questions?
1912016-07-24T15:47:18  *** ko543 has joined #bitcoin-core-dev
1922016-07-24T15:49:29  <sipa> NicolasDorier: that's actually what happens
1932016-07-24T15:49:41  <sipa> NicolasDorier: haveinputs gets called first
1942016-07-24T15:49:50  <sipa> which loads everything in the cache
1952016-07-24T15:50:17  <NicolasDorier> oooh so that's what the dbcache is about ?
1962016-07-24T15:50:23  *** aalex has joined #bitcoin-core-dev
1972016-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
1982016-07-24T15:51:31  *** laurentmt has quit IRC
1992016-07-24T15:58:28  <sipa> there are several layers of cache :)
2002016-07-24T16:05:34  *** ko543 has quit IRC
2012016-07-24T16:22:31  <sipa> NicolasDorier: there is pcoinsTip
2022016-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
2032016-07-24T16:23:23  <sipa> and when validation succeeds, the changes in the 2nd cache are pushed to pcoinsTip
2042016-07-24T16:23:40  <sipa> if validatiin fails, the changes in the second cache are discarded
2052016-07-24T16:35:24  *** murch has joined #bitcoin-core-dev
2062016-07-24T17:05:26  *** AaronvanW has joined #bitcoin-core-dev
2072016-07-24T17:05:26  *** AaronvanW has joined #bitcoin-core-dev
2082016-07-24T17:20:21  *** spudowiar has joined #bitcoin-core-dev
2092016-07-24T18:38:17  *** spudowiar has quit IRC
2102016-07-24T18:47:29  *** zooko has joined #bitcoin-core-dev
2112016-07-24T19:11:01  *** aalex has quit IRC
2122016-07-24T19:15:30  *** aalex has joined #bitcoin-core-dev
2132016-07-24T19:19:03  *** arubi has quit IRC
2142016-07-24T19:23:35  *** arubi has joined #bitcoin-core-dev
2152016-07-24T19:53:19  *** kadoban has joined #bitcoin-core-dev
2162016-07-24T19:53:35  *** adiabat has quit IRC
2172016-07-24T20:35:30  *** Cheeseo has joined #bitcoin-core-dev
2182016-07-24T20:36:06  *** zooko has quit IRC
2192016-07-24T20:48:54  *** murch has quit IRC
2202016-07-24T21:01:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2212016-07-24T21:28:40  *** a87ry5 has joined #bitcoin-core-dev
2222016-07-24T21:49:42  *** d_t has joined #bitcoin-core-dev
2232016-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)
2242016-07-24T22:00:57  <sipa> file an issue
2252016-07-24T22:01:12  <sipa> this sounds like a simple introduction task
2262016-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.
2272016-07-24T22:04:57  <sipa> we need base66 code
2282016-07-24T22:05:43  <sipa> there are 66 url-safe characters (a-z, A-Z, 0-9, _, -, ., ~)
2292016-07-24T22:07:26  <gmaxwell> https://github.com/bitcoin/bitcoin/issues/8399
2302016-07-24T22:07:39  <gmaxwell> base58 is fine.
2312016-07-24T22:15:45  <sipa> but but but 3.18% less space efficient for the same information density
2322016-07-24T22:22:47  *** d_t has quit IRC
2332016-07-24T22:25:23  *** d_t has joined #bitcoin-core-dev
2342016-07-24T22:28:21  *** justanotheruser has quit IRC
2352016-07-24T22:28:33  *** justanot1eruser has joined #bitcoin-core-dev
2362016-07-24T22:28:56  *** d_t has quit IRC
2372016-07-24T22:35:48  *** aalex has quit IRC
2382016-07-24T22:37:04  *** Guyver2 has quit IRC
2392016-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
2402016-07-24T22:39:49  <gmaxwell> sipa: who cares. :P
2412016-07-24T22:40:23  *** aalex has joined #bitcoin-core-dev
2422016-07-24T22:46:31  *** justanot1eruser is now known as justanotheruser
2432016-07-24T22:46:45  *** Cheeseo has quit IRC
2442016-07-24T23:05:58  *** AaronvanW has quit IRC
2452016-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?
2462016-07-24T23:16:04  *** challisto has quit IRC
2472016-07-24T23:17:58  <sipa> check the code :)
2482016-07-24T23:18:03  <sipa> there are two versiond
2492016-07-24T23:18:27  <sipa> one in script/interpreter, one in test/sighash_testz
2502016-07-24T23:27:17  *** spudowiar has joined #bitcoin-core-dev
2512016-07-24T23:28:14  *** Cheeseo has joined #bitcoin-core-dev
2522016-07-24T23:28:14  *** Cheeseo has joined #bitcoin-core-dev
2532016-07-24T23:36:12  *** Chris_Stewart_5 has quit IRC
2542016-07-24T23:40:05  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2552016-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)?
2562016-07-24T23:41:05  *** jiggalator has joined #bitcoin-core-dev
2572016-07-24T23:42:01  *** jiggalator is now known as netsin_
2582016-07-24T23:48:32  *** netsin_ has quit IRC
2592016-07-24T23:50:06  *** Chris_Stewart_5 has quit IRC
2602016-07-24T23:50:26  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2612016-07-24T23:50:42  *** Giszmo has quit IRC
2622016-07-24T23:51:35  <sipa> Chris_Stewart_5: make sense for whatm
2632016-07-24T23:52:14  <sipa> every value for r can be correct
2642016-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
2652016-07-24T23:52:43  <sipa> you can't individually judge them
2662016-07-24T23:52:45  <Chris_Stewart_5> when trying to recreate a digital signature from bitcoin core
2672016-07-24T23:53:00  <sipa> your r is right but the s is not?
2682016-07-24T23:53:03  <Chris_Stewart_5> yes
2692016-07-24T23:53:20  <Chris_Stewart_5> and it is not due to low-s, i've made to sure to check that
2702016-07-24T23:53:35  <sipa> can you paste the signature?
2712016-07-24T23:53:55  <Chris_Stewart_5> sure, i'll paste the correct one the one i have generated
2722016-07-24T23:58:59  <Chris_Stewart_5> http://pastebin.com/L9veUyXV